A US company does not opt into the EU AI Act by selling into Europe, and it does not opt out by staying home. Scope is set by Article 2, and Article 2 is written to catch conduct wherever the operator sits. The Regulation says so in terms: it binds providers that place systems on the Union market irrespective of whether those providers are established or located within the Union or in a third country. Incorporation in Delaware, servers in Virginia and a team that has never left the United States change nothing about that test.
The question that actually decides your exposure is narrower and more concrete than “do we do business in Europe”. It is whether a specific system meets one of the hooks in Article 2(1), read per system rather than per company. This page walks the hooks that catch US operators, the output-in-Union trigger that surprises people, how the reach differs from the GDPR test you may already know, and what you owe once you are in.
The Article 2 scope test, in three limbs
Article 2(1) lists the operators the Regulation binds. Three of its limbs are the ones that reach a US company, and any single one is enough on its own.
- Providers placing on the Union market. Anyone who places an AI system on the market, puts it into service, or places a general-purpose AI model on the market in the Union, irrespective of whether they are established in the Union or in a third country. Art 2(1)(a)
- Deployers located in the Union. Deployers of AI systems that have their place of establishment or are located within the Union. If your EU customer or your EU subsidiary uses the system, they are the deployer, and you are their provider. Art 2(1)(b)
- Third-country operators whose output is used in the Union. Providers and deployers established or located in a third country, where the output produced by the AI system is used in the Union. This is the limb that catches a US company running the system entirely at home. Art 2(1)(c)
Two further limbs matter in supply chains. Importers and distributors that bring a system onto the Union market carry their own duties under Art 2(1)(d), and a product manufacturer that ships an AI system with its product under its own name takes the provider seat. The point is that establishment is never the test. Conduct is.
| What the US company does | In scope? | Limb of Article 2 |
|---|---|---|
| Sells, licenses or offers an AI system or GPAI model for use in the Union | Yes | 2(1)(a) provider |
| Has an EU-established customer, subsidiary or team use the system | Yes, they deploy, you provide | 2(1)(a) and 2(1)(b) |
| Runs the system only in the US, but its output is sent to or relied on in the Union | Yes | 2(1)(c) output used in the Union |
| Screens EU-based applicants or scores users in the Union from a US server | Yes | 2(1)(c) |
| Imports or distributes a third-party AI system into the Union | Yes | 2(1)(d) importer or distributor |
| Purely internal US use, output never reaches the Union | No | none engaged |
The output-in-Union trigger, and why it is broader than you think
Article 2(1)(c) is the provision that unsettles US teams, because it does not depend on a sale, a contract, or an EU establishment on either side. It binds a third-country provider or deployer where the output produced by the AI system is used in the Union. Output here means what the system produces: its predictions, generated content, recommendations or decisions. Recital 22 sets out the reason plainly, which is to prevent circumvention of the Regulation by operators who keep the system offshore while the result is consumed inside the Union.
Read literally, that reaches ordinary patterns a US company would not flag as “selling into Europe”. A US-hosted model that scores a candidate physically in the Union produces output used in the Union. A recommendation engine on a US platform whose rankings are shown to users in a Member State produces output used in the Union. An internal assistant whose answers are relied on by a colleague working from Berlin produces output used in the Union. None of these requires a euro to change hands or a European entity to exist.
The trigger is the destination of the output, not the location of the compute. Moving the servers to the United States does not move you out of scope if the answer, score or recommendation is used in the Union. Conversely, output that stays entirely within the United States does not engage Article 2(1)(c) at all. Map your systems by where their output actually lands, and record that determination the way you would any other scope decision.
How the AI Act reach differs from GDPR extraterritoriality
Most US companies meet the AI Act after years of GDPR work, and the instinct is to reuse the GDPR scope answer. Do not. The two Regulations reach across borders on different tests, and they can land differently on the same system.
| Question | GDPR, Regulation 2016/679 | AI Act, Regulation (EU) 2024/1689 |
|---|---|---|
| What triggers extraterritorial reach | Offering goods or services to, or monitoring, data subjects in the EU, under Article 3(2) | Placing a system or model on the Union market under 2(1)(a), or output used in the Union under 2(1)(c) |
| Does it require personal data | Yes, it governs the processing of personal data | No, it governs AI systems and their output regardless of personal data |
| Is targeting EU individuals required | Yes, offering or monitoring must be directed at people in the EU | No, output used in the Union suffices even without targeting |
| Local representative | EU representative under Article 27 | Authorised representative under Article 22 for high-risk, Article 54 for GPAI models |
| Top penalty ceiling | 20 million EUR or 4% of total worldwide annual turnover | 35 million EUR or 7% for prohibited practices, 15 million EUR or 3% for high-risk and Article 50 |
The practical consequence is that scope has to be redetermined for the AI Act rather than inherited. A system that processes no personal data can sit outside the GDPR and squarely inside the AI Act. And because the AI Act attaches its heaviest duties to a system being classified as high-risk rather than to it touching personal data, the compliance work behind the scope answer is different in kind, not just in degree.
When a US company is genuinely out of scope
Scope is not a dragnet over every US company with a model. You are outside the Regulation for a given system when no hook in Article 2(1) is met: you do not place it on the Union market, no deployer using it is established or located in the Union, and its output is never used in the Union. Purely domestic US use whose results stay in the US is the clean case.
Article 2 also removes some activity from scope regardless of geography. These are exclusions to confirm you fall inside, not defaults to assume.
- Military, defence and national security. AI systems placed on the market, put into service or used exclusively for these purposes are outside the Regulation. Art 2(3)
- Scientific research and development. AI systems and models developed and put into service for the sole purpose of scientific research and development are excluded, as is pre-market research, testing and development activity before a system is placed on the market. Art 2(6), 2(8)
- Purely personal, non-professional use. A deployer who is a natural person using a system in a purely personal, non-professional activity is outside the deployer duties. Art 2(10)
- Free and open-source systems, with limits. These are partly excluded, but the carve-out falls away where the system is high-risk, is a prohibited practice, or is caught by the Article 50 transparency duties. Art 2(12)
Do not over-read these. The research exclusion is for genuine R&D, not for a live product you describe as experimental, and the open-source carve-out does nothing for a high-risk use case. If your exclusion depends on a characterisation a regulator might reject, document why it holds before you rely on it.
The EU authorised representative you may already need
Being in scope from the United States can carry a structural obligation that has no GDPR-style workaround: appointing someone inside the Union to stand in your place. It attaches to two situations.
- High-risk systems. A provider established in a third country must, by written mandate, appoint an authorised representative established in the Union before making a high-risk AI system available on the Union market. The representative verifies and holds the technical documentation, cooperates with authorities and can be addressed instead of the provider. Art 22
- General-purpose AI models. A provider established in a third country must appoint an authorised representative in the Union before placing a general-purpose AI model on the market, with parallel duties around documentation and cooperation. Art 54
Two things follow. First, the requirement keys off your role and risk tier, not merely off being in scope: a pure deployer does not appoint a representative, and a system that is neither high-risk nor a GPAI model does not trigger it. Establish whether you are a provider or a deployer and whether the system is high-risk before you decide you need one. Second, the mandate is a real allocation of responsibility, not a mailbox. The representative you name is the person an authority will contact, so choose one that can actually hold the documentation and answer for it.
Your role, your deadlines and your exposure
Once a system is in scope, a US operator carries exactly the same duty set as an EU one for the same role. There is no lighter regime for foreign operators. What you owe is driven by your role and the system risk tier, and the provider bears almost the entire high-risk burden while the deployer carries a lighter set built around using the system as instructed. The dates below apply to you on the same calendar as everyone else, using the timeline as amended by the Digital Omnibus.
The exposure is the standard Article 99 tier structure, and it applies to in-scope third-country operators. Prohibited practices sit at the higher of 35 million EUR or 7% of total worldwide annual turnover. The high-risk regime and every Article 50 duty sit at the higher of 15 million EUR or 3%. Supplying an authority with incorrect, incomplete or misleading information sits at 7.5 million EUR or 1%. Enforcement does not require a European entity to sue: an authority can restrict or withdraw a non-compliant system from the Union market, and where an authorised representative was required, that person can be addressed in your place.
A decision path for US companies
The determination is per system and it is repeatable. Run it in this order and write down the answer with its date and the facts it rested on.
- Map where each output lands. For every AI system you operate, ask whether its output is used in the Union, whether any deployer of it is established or located in the Union, and whether you place it or a GPAI model on the Union market. One yes puts that system in scope.
- Fix your role for the in-scope systems. Provider, deployer, importer, distributor or product manufacturer, and you can hold several at once across your estate. The role sets the duty list.
- Classify the risk tier. Check whether the use is prohibited under Article 5, high-risk under Annex III or Annex I, or a general-purpose model, since that decides the weight of the obligations and the applicable date.
- Appoint a representative where required. A third-country provider of a high-risk system or a GPAI model appoints an EU authorised representative before making it available.
- Record the determination. Scope, role, tier and the reasoning, kept current as the systems and their outputs change. That record is what you would put in front of a market surveillance authority.
If you want the per-system answer rather than a general one, the free AI Act triage classifier walks the same tests in order and tells you which tier a given system trips, with the article each answer rests on. And if you are still orienting to the calendar, start with what actually applies on 2 August 2026. The primary text is worth reading directly at EUR-Lex, alongside the European Commission AI policy pages.