What the EU AI Act Requires of Companies Outside the EU
The most common reaction to the EU AI Act from companies outside Europe is that it does not apply to them. For a meaningful number of those companies, that is wrong, and the reason is written into the second article of the regulation.
The Act reaches organizations established outside the European Union in several circumstances. The one that catches most companies is placing an AI system on the EU market or putting it into service there, regardless of where you are incorporated. If you sell software containing an AI system to customers in the EU, you are in scope for that system.
There is a second and less obvious trigger. Providers and deployers established outside the EU are also covered where the output produced by the AI system is used within the Union. A model run entirely on infrastructure outside Europe, by a company with no European entity, can fall within scope because of where its output lands.
Your obligations depend on what role you play
Before asking what you have to do, establish what you are. The Act assigns duties by role, and the same company can hold different roles for different systems.
- A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Providers carry the heaviest obligations.
- A deployer uses an AI system under its own authority in a professional capacity. Deployer duties are lighter but real, and they include things like human oversight and using the system in line with the provider’s instructions.
- Importers and distributors sit in the supply chain and carry verification duties.
A point that trips people up: modifying someone else’s system, or putting your own name on it, can make you a provider of that system with the full set of provider obligations. If you build on a third-party model and ship it as your product, do not assume the original developer carries the compliance weight.
The risk tiers, and which one you are in
The Act is structured around risk rather than technology. What your system does, and in what context, determines the obligations, not how it is built.
A small set of practices is prohibited outright. These include certain manipulative techniques, social scoring by public authorities, and specified uses of biometric categorisation and emotion recognition. These prohibitions have applied since 2 February 2025 and are not subject to the later deadlines discussed below.
High-risk systems carry the substantial obligations: a risk management system, data governance, technical documentation, record keeping, transparency to deployers, human oversight, and accuracy, robustness, and cybersecurity requirements, along with a conformity assessment. Systems fall into this category either because they are safety components of products already regulated under EU law, or because they fall within the use cases listed in Annex III, which covers areas including employment, education, essential services, and law enforcement.
Limited-risk systems carry transparency duties. If people interact with an AI system, or if content is artificially generated or manipulated, that generally has to be disclosed.
General-purpose AI models carry their own separate obligations, including technical documentation, information for downstream providers, a copyright policy, and a public summary of training content, with additional requirements for models presenting systemic risk. These have applied since 2 August 2025.
The timeline moved, and it is worth being precise about how
The Act entered into force on 1 August 2024 with obligations phased in over several years. That phasing has since been amended.
In May 2026, EU negotiators reached a provisional agreement on a package amending the AI Act, and the resulting regulation entered into force in July 2026. The most consequential change for most organizations is a deferral of the high-risk obligations.
- Obligations for high-risk systems falling under the Annex III use cases moved from 2 August 2026 to 2 December 2027.
- Obligations for high-risk systems that are safety components of products regulated under existing EU product legislation, listed in Annex I, moved from 2 August 2027 to 2 August 2028.
- The prohibitions and the general-purpose AI model obligations were not deferred and are already in effect.
Two things follow from this. First, if you have been working toward an August 2026 date for a high-risk system, that date has moved and you should re-plan against the new one rather than the old one. Second, and more importantly, the deferral applies to a specific set of obligations. The prohibitions bind now. The general-purpose model obligations bind now. Reading the deferral as a general reprieve is a mistake.
It is also worth treating the timeline as still capable of movement. This package was itself an amendment driven by the difficulty of operationalising the original schedule, and further clarification through implementing acts and harmonised standards is ongoing. Anything you build should be able to absorb a changed date without being rebuilt.
What a company outside the EU should actually do now
The first task is inventory, and it is less trivial than it sounds. Most organizations do not have a reliable list of the AI systems they build, embed, or deploy, particularly where features were added by individual product teams or arrived inside a vendor’s product. You cannot classify what you have not enumerated.
The second task is classification. For each system, establish your role, whether the system is in scope at all, and which tier it falls into. Most systems in most companies are not high-risk, and establishing that with reasoning you can show is itself a useful compliance artifact. The expensive mistake is assuming everything is high-risk and building for the heaviest obligations across the board.
The third task is the record. For anything in scope, the obligations are documentary in character: technical documentation, risk management records, data governance evidence, logs, and instructions for downstream users. This is the same shape of work as any other controls-and-evidence regime, which is why organizations with mature security compliance functions tend to find it more familiar than they expect.
One structural note: if you are a provider outside the Union placing a high-risk system on the EU market, you will generally need an authorised representative established in the Union. That is an appointment to make deliberately, not something to discover late.
The general-purpose model obligations are already live
Because so much attention has gone to the high-risk deferral, the general-purpose AI provisions are worth restating on their own. They have applied since 2 August 2025 and were not moved.
A provider of a general-purpose AI model has to maintain technical documentation of the model and its training and testing process, make information available to downstream providers who integrate it so that those parties can meet their own obligations, put in place a policy to comply with Union copyright law, and publish a sufficiently detailed summary of the content used for training. Models determined to present systemic risk carry further obligations including model evaluation, adversarial testing, incident reporting, and cybersecurity protection.
The reason this matters to companies outside the EU is the downstream information duty. If you integrate a third-party model into your product, the documentation you need in order to meet your own obligations is documentation the model provider is required to give you. Asking for it is reasonable, and building a product on a model whose provider cannot supply it is a risk worth surfacing before you ship rather than afterward.
What non-compliance costs
Penalties are tiered to the severity of the breach, and the ceilings are set as the higher of a fixed amount or a percentage of worldwide annual turnover, which is what makes them significant for large organizations.
Engaging in a prohibited practice sits at the top tier. Breaching other obligations, including the high-risk requirements, sits at a middle tier. Supplying incorrect, incomplete, or misleading information to authorities or notified bodies carries its own lower tier, which is worth noting because it makes the accuracy of what you file a compliance question in its own right rather than merely a matter of presentation.
For small and medium enterprises the caps are applied so as to take proportionality into account. That reduces exposure but does not remove the obligation, and the reputational and commercial consequences of a finding tend to outweigh the fine for a company whose buyers are asking about AI governance.
Our EU AI Act overview sets out how we handle classification and the ongoing record for clients in scope.
Related framework
The Verdict Forum publishes educational guidance, not legal or compliance advice. Confirm requirements against the authoritative sources and your assessor before acting.
Read next
ISO 42001 and the Emerging Shape of AI Management Systems
What an AI management system standard actually requires, how certification audits work, and where ISO 42001 sits against the EU AI Act and the NIST AI RMF.
HIPAA Security Rule Obligations for Technology Vendors
Business associates carry direct statutory obligations, not contractual ones. What the Security Rule requires, what "addressable" really means, and where the 2025 proposed update stands.