Key takeaways
- A U.S. headquarters does not by itself put a company outside the EU AI Act. The regulation can apply when a company places an AI system or general-purpose AI model on the EU market, operates as an EU deployer, or produces AI output that is used in the Union.
- Most middle-market companies are deployers of third-party AI rather than providers of foundation models, but a company can become a provider when it sells, materially modifies, relabels, or puts an AI system into service under its own name.
- The current compliance calendar is phased. Prohibited practices and AI-literacy provisions have applied since February 2025; general-purpose AI obligations since August 2025; Article 50 transparency rules since August 2026; specified high-risk rules begin in December 2027; and product-integrated high-risk rules begin in August 2028.
- The fastest practical starting point is an AI-system register that records each use case, geography, legal role, purpose, affected people, data, vendor, output, decision significance, owner, controls, and evidence.
- A policy alone is not readiness. Management needs operating evidence: role classification, use-case screening, disclosures, training records, vendor documentation, human oversight, logs, incident procedures, and a controlled process for approving changes.
In this article
- Why a U.S. middle-market company may be in scope
- Classify the company's role before classifying risk
- The current AI Act timeline as of August 2026
- Screen first for prohibited AI practices
- Understand minimal, transparency, and high-risk use cases
- Article 50 transparency duties that apply now
- AI literacy is an operating obligation, not a one-time course
- High-risk readiness: provider and deployer responsibilities
- Do not confuse using a model with providing a GPAI model
- Vendor diligence and contracts must support compliance
- A 90-day readiness plan for a middle-market company
- Build an evidence file that survives diligence and enforcement
- Enforcement exposure and management judgment
- Common questions from U.S. management teams
AI governance tradeoffs
Why a U.S. middle-market company may be in scope
The EU Artificial Intelligence Act, Regulation (EU) 2024/1689, creates a risk-based legal framework for AI systems and general-purpose AI models. It is an EU regulation, but its reach is not limited to companies incorporated in Europe. Article 2 expressly covers providers that place AI systems or general-purpose AI models on the EU market regardless of where the provider is established. It also covers providers and deployers located outside the EU when output produced by the AI system is used in the Union.
That extraterritorial rule matters to U.S. software companies, service businesses, manufacturers, employers, and online businesses. A U.S. company may need a scope analysis if it sells an AI-enabled product to European customers, operates an EU subsidiary, uses AI in decisions affecting EU employees or applicants, provides an AI-generated deliverable used in Europe, or distributes a third-party AI system in the EU. A website being technically accessible from Europe is not a complete scope analysis; the actual product, customer, output, contractual chain, geography, and intended use matter.
Do not begin with the question “Are we an AI company?” Begin with “Which AI systems do we provide or use, where are their outputs used, and what role do we play for each one?”
The AI Act does not replace the General Data Protection Regulation, employment law, consumer-protection rules, sector regulation, intellectual-property law, product-safety requirements, or contractual duties. One workflow can trigger several regimes. A recruiting system may require AI Act classification, a GDPR data-protection impact assessment, works-council consultation, employment-law review, and vendor security diligence at the same time.
Classify the company's role before classifying risk
The same technology can create different obligations for different companies in the supply chain. The AI Act distinguishes providers, deployers, importers, distributors, product manufacturers, authorised representatives, and providers of general-purpose AI models. Middle-market teams often call everyone a vendor or user; that language is not precise enough for compliance.
A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority in a professional context. Importers and distributors make systems available in the EU supply chain. A product manufacturer may inherit obligations when an AI system is placed on the market with a regulated product under the manufacturer's name.
A company can change roles through its conduct. Rebranding a system, placing it under the company's own name, making a substantial modification, or changing the intended purpose can move obligations toward the company that made the change. Contract labels do not necessarily control the regulatory result. Product, legal, engineering, procurement, and commercial teams should agree on one role map for each use case.
Role Classification File
Legal entity providing or using the system.
System and model provider names.
Product name, version, and material integrations.
Contractual description of each party's role.
Who determines the intended purpose and operating instructions.
Whose name or trademark appears on the system.
Whether the company modified, fine-tuned, retrained, relabelled, or repurposed the system.
EU countries where the system is sold, used, or produces relied-upon output.
Named business owner and legal reviewer.
Date of the last classification review.
The current AI Act timeline as of August 2026
The AI Act applies in phases. Older summaries often state that the entire regime became applicable on 2 August 2026. That is no longer a reliable planning assumption. Companies should work from the current consolidated regulation and Commission implementation guidance, especially for high-risk deadlines.
A future deadline is not permission to wait. System inventories, contract changes, data documentation, logging architecture, validation, human-oversight design, and conformity work can require several budget cycles. Acquirers, enterprise customers, insurers, and boards may also demand evidence before the statutory application date.
Treat the timeline as a controlled legal assumption. Record the source and review date, assign counsel to monitor amendments and guidance, and update the compliance plan when the consolidated regulation or Commission implementation position changes.
AI governance check
Use the scan to separate governance blockers from practical, low-risk workflow opportunities.
Run the governance scan →Screen first for prohibited AI practices
Prohibited practices deserve the first review because they are not merely high-risk activities awaiting future controls. Article 5 bans specified uses that the EU considers unacceptable. The categories include certain manipulative or deceptive techniques that cause or are likely to cause significant harm, exploitation of vulnerabilities, specified social-scoring practices, certain prediction of criminal risk based solely on profiling, untargeted scraping to build or expand facial-recognition databases, and specified biometric categorisation, real-time remote biometric identification, and emotion-recognition uses subject to the regulation's detailed conditions and exceptions.
For a typical middle-market company, workplace emotion recognition is an especially important screening question. Tools marketed as engagement, sentiment, attention, stress, honesty, or interview analysis may infer emotions from biometric or behavioural signals. A familiar product label does not determine whether the prohibited-practice definition is met. The intended purpose, inputs, inference, context, and exception must be reviewed.
Prohibited-Practice Screen
Does any system manipulate choices through subliminal, deceptive, or purposefully manipulative techniques?
Does any system exploit age, disability, or social or economic vulnerability in a way connected to significant harm?
Does any system assign a social score that produces unrelated or disproportionate detrimental treatment?
Does any system predict criminal risk based solely on profiling or personality traits?
Does any vendor build facial-recognition databases through untargeted image scraping?
Does any workplace or education tool infer emotions from biometric data?
Does any system categorise people using biometric data to infer protected or sensitive characteristics?
Does any system use remote biometric identification in publicly accessible spaces?
Has qualified counsel documented whether an exception applies?
Can procurement block renewal or deployment until the screen is complete?
The control should cover experiments as well as production. A business unit can create exposure by piloting a prohibited use with a vendor before central procurement learns about it. Require pre-approval for biometric, emotion, behavioural-scoring, employee-monitoring, and other people-impacting AI use cases.
Understand minimal, transparency, and high-risk use cases
After prohibited-practice screening, classify the use case by risk and obligation. Many business applications are minimal or limited risk under the AI Act. Spam filtering, internal drafting assistance, ordinary forecasting, document search, and narrow workflow automation may not be high-risk. They can still create privacy, security, confidentiality, accuracy, employment, consumer, or contractual risk, but the AI Act does not impose the same requirements on every use.
Transparency-risk systems are subject to Article 50 duties. High-risk systems generally fall into two routes: AI that is a safety component of specified regulated products, and stand-alone systems used for listed purposes in Annex III. The latter includes certain biometric, critical-infrastructure, education, employment, access-to-essential-services, law-enforcement, migration, and justice uses. The exact intended purpose and the exceptions in Article 6 and Annex III matter.
Classification belongs at the use-case level, not the vendor level. One platform can support a low-risk drafting workflow and a high-risk employment workflow. “We use Vendor X” is therefore not a sufficient inventory entry; the company must record what the system does in each business process and what decisions rely on its output.
Article 50 transparency duties that apply now
Article 50 has applied since 2 August 2026. Providers of systems intended to interact directly with people must design them so the person is informed that they are interacting with AI unless that fact is obvious to a reasonably well-informed, observant, and circumspect person in the circumstances. Providers of systems that generate synthetic audio, image, video, or text must support machine-readable detection of generated or manipulated output, subject to the provision's scope and technical-feasibility standard.
Deployers have separate duties. People exposed to emotion-recognition or biometric-categorisation systems must receive specified information. Deployers of systems that generate or manipulate deepfake content must disclose that the content was artificially generated or manipulated. Deployers publishing AI-generated or manipulated text to inform the public on matters of public interest must disclose its artificial origin unless an applicable exception, including human review or editorial control with identified responsibility, is satisfied.
Article 50 Implementation File
List every chatbot, voicebot, virtual assistant, and interactive AI interface.
Record the disclosure text, placement, timing, language, and accessibility treatment.
List every workflow generating or manipulating audio, images, video, or text.
Determine which outputs require machine-readable marking and which require visible disclosure.
Document controls for deepfakes and public-interest publications.
Capture the provider's technical marking capabilities and instructions.
Define how human review and editorial responsibility are evidenced.
Test whether disclosures persist after export, editing, transcoding, or publication.
Create an approval path for exceptions.
Retain dated screenshots, test outputs, system versions, and responsible owners.
A generic statement in a privacy policy may not solve an interaction-level disclosure duty. The control needs to appear at the relevant experience or content, in a form and time that a person can understand. Marketing, product, communications, legal, and engineering teams should own the implementation together.
The European Commission has published Article 50 guidelines and a voluntary Code of Practice on Transparency of AI-Generated Content. These materials do not replace the regulation, but they provide important implementation direction and should be incorporated into the company's control design and evidence file.
AI literacy is an operating obligation, not a one-time course
Article 4 requires providers and deployers to take measures, to their best extent, to ensure a sufficient level of AI literacy among staff and other people operating or using AI systems on their behalf. The required level depends on technical knowledge, experience, education, training, the context of use, and the people affected. One generic annual slide deck is unlikely to be equally appropriate for software engineers, recruiters, customer-service representatives, finance analysts, and executives approving high-impact systems.
A practical program starts with baseline training for anyone using approved AI tools. It then adds role-specific modules. Procurement should know what documentation to request. Product teams should understand provider-versus-deployer consequences. HR should recognize employment-risk triggers. Finance should verify AI-generated analysis and protect confidential data. Engineers should understand logging, evaluation, security, and change control. Executives and directors should understand the inventory, risk acceptance, incidents, and investment plan.
Keep evidence of the program: curriculum, audience, attendance, assessment, completion date, trainer, system-specific modules, and refresh triggers. Training should update when the company introduces a material use case, changes roles, modifies a system, receives an incident, or encounters new guidance.
High-risk readiness: provider and deployer responsibilities
High-risk compliance is the most demanding part of the AI Act. Providers generally carry system-level requirements involving risk management, data and data governance, technical documentation, record keeping, transparency and instructions, human-oversight design, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, corrective action, and post-market monitoring. The exact route depends on the system and applicable product legislation.
Deployers have their own responsibilities. Commission guidance describes duties to follow instructions, assign qualified and empowered human oversight, monitor operation, act on risk or serious incidents, and ensure input data under the deployer's control is relevant and sufficiently representative for the intended purpose. Workplace deployments can require advance information to affected employees and worker representatives. Systems making or assisting decisions about natural persons can trigger information duties to the affected person. Certain public-service, creditworthiness, and life or health insurance uses can require a fundamental-rights impact assessment.
A middle-market deployer should not attempt to recreate a provider's technical file, but it must obtain enough information to classify and operate the system responsibly. If a vendor cannot identify the system's intended purpose, limitations, role, version, documentation, logging, and high-risk position, that uncertainty belongs in the purchase decision.
Begin high-risk readiness at least 12 to 18 months before the applicable deadline for material systems. Contract negotiation, system replacement, data remediation, integration logging, validation, and employee consultation can consume more time than policy drafting.
Do not confuse using a model with providing a GPAI model
General-purpose AI models, or GPAI models, are regulated at the model layer. Most middle-market companies using a commercial large-language-model API are downstream providers or deployers of AI systems rather than providers of the underlying GPAI model. Building an application on a model does not automatically make the application company the provider of that model.
The distinction can change when a company develops its own broadly capable model or makes a significant modification to an existing model. The Commission's GPAI guidelines provide interpretive criteria, including guidance on when modifications may move an actor into provider obligations. The analysis should consider the model, the downstream system, the degree of modification, how each is placed on the market, and whose name appears on it.
Providers of GPAI models face obligations concerning technical documentation, information for downstream system providers, copyright compliance, and a sufficiently detailed public summary of training content. Providers of models with systemic risk have additional evaluation, risk-assessment, incident-reporting, cybersecurity, and related duties. The voluntary GPAI Code of Practice provides a pathway for demonstrating compliance with specified transparency, copyright, safety, and security obligations.
For an ordinary company purchasing model access, the operational priority is downstream assurance: identify the model and version, understand data-use and retention settings, obtain vendor documentation, track material model changes, test the application in its intended context, and ensure the company does not make claims that improperly shift the provider role onto itself.
Vendor diligence and contracts must support compliance
AI compliance fails when the operating company has obligations but the vendor contract does not provide the information or rights needed to meet them. Standard software terms may disclaim output accuracy, permit rapid model changes, limit audit support, provide little incident notice, and say nothing about AI Act roles. Procurement should tier diligence by the consequence of the use case rather than applying the same questionnaire to every tool.
AI Vendor Diligence File
Legal entity, product, model, version, hosting location, and subcontractors.
Provider, deployer, importer, distributor, and GPAI role position.
Intended purpose, prohibited uses, system limitations, and target users.
AI Act classification and supporting rationale.
Training, validation, testing, and input-data information appropriate to the company's role.
Data ownership, processing, retention, training use, deletion, residency, and cross-border transfers.
Security architecture, access controls, logging, incident history, and certifications.
Accuracy, bias, robustness, cybersecurity, evaluation, and monitoring evidence.
Human-oversight capabilities, explanations, contestability, and override controls.
Synthetic-content marking, disclosure, and export behavior.
Material-change, model-change, deprecation, and regulatory-change notices.
Audit support, authority cooperation, serious-incident support, indemnity, insurance, and termination assistance.
Contract terms should allocate responsibility without pretending the customer can contract away statutory duties. Important provisions can include role acknowledgements, documentation delivery, ongoing compliance commitments, change notice, incident notice, audit and cooperation rights, data restrictions, output rights, record retention, service continuity, regulatory termination, remediation, and migration support.
A vendor answer of “our model is compliant” is not sufficient. Compliance attaches to roles, systems, and use contexts. Ask what evidence supports the statement, which legal entity makes it, which product version it covers, which obligations it addresses, and how the vendor will notify customers when any of those facts change.
A 90-day readiness plan for a middle-market company
The objective of the first 90 days is not to certify the entire enterprise. It is to establish control over the inventory, stop prohibited or unapproved uses, satisfy obligations already in force, identify material future work, and create an evidence trail management can sustain.
Days 1–30: Discover and Triage
Name an accountable executive and cross-functional working group.
Issue a short business-unit survey and reconcile it to procurement, expense, browser, identity, API, and software records.
Create the AI-system register at the use-case level.
Map EU entities, customers, employees, products, and output destinations.
Screen immediately for prohibited practices and people-impacting use cases.
Identify interactive and synthetic-content workflows subject to Article 50.
Freeze unapproved biometric, emotion, recruiting, credit, and other consequential pilots pending review.
Days 31–60: Classify and Remediate
Assign provider, deployer, importer, distributor, product-manufacturer, and GPAI roles.
Classify each use case as prohibited, transparency, potential high-risk, or minimal/other risk.
Implement missing chatbot, deepfake, public-interest, and synthetic-content controls.
Launch baseline and role-specific AI-literacy training.
Tier vendors by risk and send diligence requests to the most material providers.
Document retention, data, security, human-review, and incident requirements.
Escalate unclear scope, exceptions, and substantial-modification questions to qualified EU counsel.
Days 61–90: Operationalize and Govern
Approve a risk-based AI policy and use-case intake process.
Assign control owners, review frequency, evidence, and escalation paths.
Negotiate priority vendor amendments or define replacement plans.
Create a high-risk readiness roadmap through the applicable 2027 or 2028 date.
Run a tabletop incident involving harmful output, vendor model change, or disclosure failure.
Report material systems, gaps, decisions, budget, and milestones to executive management or the board.
Add AI controls to acquisition diligence, customer contracting, enterprise risk, internal audit, and transaction-readiness processes.
EU AI Act readiness path
Build an evidence file that survives diligence and enforcement
Readiness is easier to defend when evidence is created through normal operations. A policy dated last week is weak if the company cannot show which systems it uses, who approved them, what vendors promised, how people are informed, who reviews consequential outputs, or what happened after an incident. The evidence file should connect the legal requirement to a named control, owner, record, system, and review date.
EU AI Act Evidence Index
- Corporate and EU operating-entity map.
- AI-system and GPAI-model register with use-case-level records.
- Role and scope memoranda, including Article 2 analysis where relevant.
- Prohibited-practice screening and exception analysis.
- Risk classification decisions and supporting product or use-case evidence.
- Article 50 disclosure, marking, testing, and editorial-control records.
- AI-literacy curriculum, attendance, assessment, and refresh schedule.
- Provider documentation, deployer instructions, conformity information, and registrations where applicable.
- Data governance, input-data, evaluation, accuracy, robustness, and cybersecurity evidence.
- Human-oversight design, reviewer authority, interventions, and overrides.
- Logs, monitoring, complaints, incidents, corrective actions, and authority communications.
- Vendor diligence, contracts, amendments, change notices, and exit plans.
- Policy, approval minutes, risk acceptances, internal audit results, and remediation tracker.
This file also matters in M&A. A buyer will not view unknown AI use as innovation. It may view it as undisclosed regulatory, data, intellectual-property, employment, customer, cyber, or operational exposure. A clean register and evidence trail allow management to distinguish controlled, value-producing workflows from experimental or unmanaged use.
The company should also incorporate AI Act questions into acquisition diligence. Buying a software company, an EU operation, or a business that uses AI in employment, credit, healthcare, or regulated products can transfer remediation cost and contractual exposure. The acquisition team should identify systems, roles, classifications, material vendors, incidents, representations, and readiness milestones before signing.
Enforcement exposure and management judgment
The AI Act provides material maximum penalties. Non-compliance with prohibited-practice rules can reach EUR 35 million or 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher for an undertaking. Specified violations of provider, deployer, and transparency obligations can reach EUR 15 million or 3 percent. Supplying incorrect, incomplete, or misleading information to authorities can reach EUR 7.5 million or 1 percent. The regulation provides lower-of protections for SMEs for the referenced caps, and actual enforcement must consider proportionality and the circumstances specified in the regulation.
Those figures should not become the entire business case. For a middle-market company, the more immediate risks may be a delayed enterprise sale, failed customer diligence, loss of an EU contract, an employment claim, mandatory remediation, a vendor replacement, an incident response, or management distraction. Compliance design should prioritize the systems with the greatest human and enterprise consequence, not merely those with the most visible AI branding.
The European Commission and national authorities began exercising enforcement powers from 2 August 2026. Companies can use the Commission's AI Act Single Information Platform, Compliance Checker, AI Act Explorer, and Service Desk as official support resources. These tools are useful inputs; they do not replace system-specific legal advice or management accountability.
The board-level question is not “Are we compliant with AI?” It is “Do we know which systems matter, which obligations apply now, what evidence proves control, and what decisions or investments remain before the next deadline?”
Common questions from U.S. management teams
This article reflects official EU materials available on 27 August 2026. The AI Act implementation framework continues to develop through consolidated legislation, Commission guidelines, codes of practice, standards, national enforcement, and future amendments. Management should maintain a dated legal-obligations register and confirm material conclusions with qualified EU counsel.
Frequently asked questions
Does the EU AI Act apply if we have no European subsidiary?
It can. Article 2 can cover non-EU providers placing systems or GPAI models on the EU market and non-EU providers or deployers where AI output is used in the Union. The facts require a product, output, customer, geography, and role analysis.
Are we outside the Act because we only use third-party AI?
No. You may be a deployer and can have obligations tied to use. You can also become a provider through branding, material modification, or changed intended purpose.
Is every use of generative AI high-risk?
No. Most AI use is not automatically high-risk. Interactive and generative systems may have Article 50 transparency duties, while high-risk classification depends on the system and intended use.
Do we need to label every AI-assisted document?
No blanket rule should be inferred. Article 50 distinguishes provider marking duties and deployer disclosure duties for specified content and contexts, with exceptions and transition provisions. Review the current text and Commission guidelines.
Does human review make an employment AI system low-risk?
Not automatically. Human review may be an important control, but classification depends on intended purpose and the statutory criteria.
Can our vendor handle compliance for us?
The vendor must handle its obligations, but your company retains duties associated with its own role and deployment. Contracts and documentation should support, not replace, that responsibility.
What should we do first?
Create a use-case-level inventory, map EU touchpoints, assign roles, screen prohibited practices, and remediate transparency and literacy duties already in force.
Should we wait until the 2027 high-risk deadline?
No. Material systems may require new contracts, logging, validation, data remediation, employee consultation, technical changes, or replacement. Start with the longest-lead gaps.
Is this article legal advice?
No. It is an operating-readiness guide. The AI Act, implementing measures, national enforcement, contractual facts, and related privacy, employment, product, and sector laws require qualified counsel.
Work with Glacier Lake Partners
Build a controlled AI readiness plan
We help management teams inventory AI workflows, assign ownership, document controls, and connect compliance work to operating value and transaction readiness.
Get in Touch →AI governance check
Pressure-test AI readiness before tools spread informally.
Use the scan to separate governance blockers from practical, low-risk workflow opportunities.
Run the governance scan →Research sources
Disclaimer: Financial figures and case-study details in this article are anonymized, composite, or representative examples based on middle market operating situations, and are not guarantees of outcome. Statistical references are drawn from cited third-party research; individual transaction and operational results vary based on business characteristics, market conditions, and deal structure. This content is for informational purposes only and does not constitute legal, financial, or investment advice. Consult qualified advisors for guidance specific to your situation.
Explore adjacent topics
