Recital 22 of the EU AI Act (Regulation (EU) 2024/1689) frames the Act’s reach beyond the EEA around output “intended to be used” there. Article 2(1)(c), the operative provision that actually does the work, drops the word “intended” entirely: it applies to providers and deployers established outside the EEA “where the output produced by the system is used in the [EEA].” White & Case’s own Handbook calls the two “inconsistent,” and works through what that inconsistency actually does to a business that never meant to come near EU law. The argument worth making explicitly, rather than leaving implicit: the operative text creates a jurisdictional trigger with no off-switch built in, and the recital that would have installed one has no binding force of its own.
The claim
Read literally, Article 2(1)(c)’s territorial trigger is an event downstream of the operator’s own control — a later, independent decision by someone else about where to use an AI system’s output — rather than a choice the operator itself makes. That is a genuinely unusual jurisdictional design for EU law, and it is not what Recital 22 says the rule is supposed to be.
How this differs from the GDPR, precisely
Article 3 GDPR turns on offering goods or services to, or monitoring, individuals in the EEA — both are tests shaped around the entity’s own intent or conduct. You come within the GDPR’s territorial scope by doing something aimed at the EEA. Article 2(1)(c) isn’t built the same way: nothing in its text asks what the provider or deployer meant to do. This is worth stating carefully rather than overstating — it’s a difference in what triggers the rule, not necessarily a difference in how ambitious EU lawmakers were being. The GDPR and the AI Act both clearly intend broad reach; only one of them ties that reach to the regulated party’s own choices.
The worked example, in full
White & Case’s Handbook walks through exactly this scenario. An advertising agency based in Japan uses third-party AI systems in its ordinary workflow to generate branding concepts for clients. A customer based in Argentina commissions branding for one of its products; the agency delivers it, using AI to generate some elements; the client is happy and pays. A year passes. The Argentine client then opens a new office in Spain, and uses that branding there.
Under a literal reading of Article 2(1)(c), the Japanese agency is the deployer of the AI system it used to produce the branding; the branding itself is the “output”; the client has now used that output in the EEA. The agency — based solely in Japan, with no intention of ever doing business in Europe — falls within scope, a year after the work was finished, because of a decision it had no part in and no visibility into. White & Case’s own conclusion is blunt: there does not appear to be any way for the agency to avoid this outcome. A contractual clause prohibiting the client from using the branding in the EEA wouldn’t help, because Article 2(1)(c) doesn’t appear to take intent into account at all — and a restriction aimed at intent has nothing to grip onto in a test that doesn’t ask about intent.
Why the usual mitigations fail
This is worth arguing through rather than just asserting, because the reason both standard defences fail is structural, not incidental. A contractual prohibition on EEA use is a tool for shaping intent — it tells a counterparty what they’re not supposed to do, and creates a remedy if they do it anyway. Article 2(1)(c) doesn’t test intent, so a tool built to manage intent has nothing to act on; the client’s actual use in Spain triggers the provision regardless of what the contract said the client was and wasn’t allowed to do with the deliverable.
Geo-blocking your own service has the same structural mismatch, from a different angle. It controls who can reach your system directly. It does nothing about a customer who received an output outside any geo-blocked environment and later, independently, carries that output somewhere you can’t see and never contracted around. The output has already left your hands by the time the triggering event happens.
The second, quieter expansion
Article 2(1)(g) adds a separate line: the Act applies to affected persons located in the EEA. Under the GDPR, failing every Article 3 test ends the analysis — even if some of the people affected by a business’s processing happen to be in the EEA, that alone doesn’t pull an otherwise out-of-scope business in. Article 2(1)(g)’s wording is genuinely unclear, and White & Case reads it as possibly meaning something different: that an affected person located in the EEA might be able to exercise rights under the Act against a business that passes none of the other territorial tests at all. This is worth flagging precisely as unresolved rather than pushed toward an answer — the source itself doesn’t resolve it, and neither should this piece.
The counter-arguments
None of this is airtight, and the case against reading Article 2(1)(c) this literally deserves its full weight rather than a token mention before moving on. Recitals exist to guide interpretation, and a court taking a purposive approach could plausibly read the “intended to be used” language from Recital 22 back into Article 2(1)(c), resolving the inconsistency in the operator’s favour rather than the literal reading’s. Practically, enforcing the AI Act against a Japanese advertising agency with no EEA presence, no EEA assets, and no EEA representative is a real exercise in fiction — scope on paper and an enforceable judgment are different things, and the gap between them matters. And even where scope does attach, the actual obligation set for a business whose system is genuinely minimal-risk is thin: Article 4 AI literacy, and Article 50 transparency only if the system interacts directly with people. None of the high-risk apparatus this territory usually brings to mind switches on just because Article 2(1)(c)’s trigger fired.
What this means if you sell outside the EU
The honest conclusion sits between the alarming reading and the dismissive one. The exposure is real — the literal text supports it, and the most detailed commentary available concludes there’s no clean way to engineer around it. But for most businesses whose output ends up in the EEA through someone else’s later, unplanned decision, the resulting obligation set is genuinely small. The practical question worth asking isn’t “could we ever technically fall in scope” — for almost any business whose output could travel, the honest answer is probably yes, eventually. It’s which of your systems could ever be high-risk if that trigger fires, since that’s where the actual stakes of this whole analysis live.
The carve-outs that actually help
A handful of exclusions do real work here, separate from the territorial question itself. Article 2(3) excludes AI systems used exclusively for military, defence, or national security purposes. Article 2(6) excludes AI systems and models designed and used solely for scientific research and development. Article 2(8) excludes research, testing, and development of AI systems before they’re placed on the market or put into service — though this exclusion does not extend to testing under real-world conditions, which is treated differently. And Article 2(12) excludes AI systems released under free and open-source licences, except where they are high-risk systems, prohibited systems, or systems subject to the Article 50 transparency obligations. None of these touch the territorial trigger itself, but each one can take a given system out of the analysis before the question of where its output ends up ever needs asking.