Why the EU AI Act Matters Even If You're Not in the EU
It's not about direct sales to EU customers. There's much more.
Someone asked you in a meeting — maybe your product manager, maybe your CTO, maybe a client — “does the EU AI Act apply to us? We’re not in the EU.”
You said no.
Or you shrugged.
Or you said “I’ll look into it” — which is code for “I hope this goes away.”
However, it didn’t go away. So here you are, googling it.
The short answer is: it depends.
But the EU AI Act reaches further than most non-EU companies expect — and the line between “in scope” and “not in scope” isn’t where you think it is.
What the Law Actually Says
Article 2(1) of the EU AI Act lists seven categories of entities this regulation applies to. For non-EU companies, three separate hooks matter the most — and you only need to trigger one.
(a) Providers placing on the market or putting into service AI systems in the EU — regardless of where they're established. A US company that sells an AI-powered SaaS product to EU customers is "placing on the market" in the EU. Same logic as GDPR — location of the company is irrelevant, location of the market matters.
(b) Deployers of AI systems located in the EU — this one catches EU-based companies using non-EU AI tools. But it also indirectly affects the non-EU provider, because the EU deployer will demand compliance from their vendor. Even if the Act doesn't directly apply to you, your EU customer's obligations flow uphill.
(c) Providers and deployers in third countries where the OUTPUT of the AI system is used in the EU — this is the broadest hook, and the one most non-EU companies underestimate. If your AI system generates an output — a prediction, a recommendation, a decision, a piece of content — and that output ends up being used by someone in the EU, you're potentially in scope.
A few terms worth understanding before we go further:
“Placing on the market” means the first time an AI system becomes available on the EU market. Selling, licensing, offering as SaaS — any way a system reaches an EU user for the first time.
“Putting into service” means supplying an AI system directly to a deployer for first use, or using it yourself for its intended purpose. If you deploy your own AI system and it touches EU operations — this is you.
“Output produced by the AI system is used in the Union” is the broadest trigger. It doesn't require physical presence. It doesn't require an EU customer relationship. If the output lands in the EU and gets used there, the connection is made.
The Nuance
Recital 22 narrows the “output used in the Union” trigger somewhat. It frames this as intended use — the example given is an EU provider contracting with a non-EU provider to process data and send back AI-generated outputs.
The AI system processes data lawfully collected and transferred from the EU, and the output goes back to the EU contracting party.
This matters because the level of “intention” is still open to interpretation.
There’s no official guidance yet on what counts as intended vs. incidental output reaching the EU. This is a grey area that will likely be clarified through enforcement and guidance — but companies shouldn’t wait for that.
When You’re Caught
Here's where it gets practical. These are scenarios where the EU AI Act catches you even if your business is headquartered nowhere near the EU.
Scenario 1: US SaaS company with EU customers
A US company offers an AI-powered hiring tool. EU companies subscribe and use it to screen candidates in the EU. The US company is a provider placing an AI system on the EU market. Fully in scope. If the tool qualifies as high-risk (employment is Annex III, point 4), they need full compliance — risk management, data governance, transparency, human oversight, the works.
Scenario 2: The API provider
A Singapore-based fintech provides a credit scoring API. EU banks call the API to assess loan applications from EU citizens. No EU office, no EU entity, no EU employees — but the output (credit scores) is used in the EU to make decisions about EU persons. The Singapore company is in scope as a provider under Article 2(1)(c).
Scenario 3: The outsourced AI processing
An EU insurer contracts with an Indian AI company to process claims data. The Indian company uses AI to generate risk assessments, which are sent back to the EU insurer for decision-making. This is the Recital 22 scenario — output generated outside the EU, used inside the EU. The Indian company is caught.
Scenario 4: Internal AI tools used globally
A US multinational builds an internal AI system for performance reviews. It's used by managers globally — including at the company's EU offices. The output (performance assessments affecting EU employees) is used in the EU. The US parent company is likely in scope — both as provider and deployer.
Scenario 5: GPAI model providers
A US company develops and releases a general-purpose AI model (think: foundation models, LLMs). If the model is made available on the EU market — including via API access to EU developers — the GPAI-specific obligations under Articles 51-56 apply. Technical documentation, transparency about training data, copyright compliance.
When You’re Probably Not Caught
Not every non-EU company needs to worry. Here's when you can exhale.
Scenario A: Purely domestic, no EU touchpoint
A US company builds an AI tool used only by US employees, for US customers, processing US data. No EU customers, no EU users, no output reaching the EU. Not in scope.
Scenario B: Open-source with no EU market targeting
Free and open-source AI models are generally exempt under Article 2(12) — unless they're classified as high-risk AI systems, prohibited AI practices, or have transparency obligations. This exemption has conditions and edges. It's not a blanket free pass.
Scenario C: R&D only
AI systems in research, testing, or development — before being placed on the market or put into service — are excluded under Article 2(8). But the moment you move from testing to deployment with EU users, the exemption ends.
Scenario D: Military/defence/national security
AI systems whose output is used in the EU exclusively for military, defence, or national security purposes are carved out under Article 2(3). But "exclusively" is doing heavy lifting there — any dual-use or civilian spillover could bring it back in scope.
The Grey Zone
If your AI system’s output could reach EU users but you’re not specifically targeting them — this is genuinely unclear.
The GDPR analogy would suggest some form of “targeting” test (like GDPR’s Recital 23, which looks at language, currency, and other indicators that you’re aiming at EU users). But the AI Act doesn’t have that explicit test. Recital 22 hints at intentionality, but it hasn’t been tested through enforcement.
My reading: incidental or unintended output reaching the EU is probably not enough to bring you in scope. But no one has confirmed that yet. This is an open question — and if it matters for your business, it’s worth getting a proper legal opinion rather than betting on a “probably”.
You Need a Person in the EU
Article 22 adds a practical requirement that catches some non-EU companies off guard.
Providers established outside the EU who place high-risk AI systems on the EU market must appoint an authorized representative in the EU — by written mandate — before making the system available. Not after. Before.
The representative verifies that the declaration of conformity and technical documentation exist. They provide information to competent authorities when requested. They cooperate on corrective actions. They flag complaints and risks to the provider. They ensure registration obligations are met under the database in Article 71.
What the representative does not do: take over the provider’s core compliance obligations (Articles 9-17). You still have to do the actual compliance work. The representative is your EU-facing contact point — not a compliance outsourcer.
If you went through GDPR, this mirrors the Article 27 representative requirement. Same structure, same logic. If you didn’t go through GDPR... this is your wake-up call.
One more thing about your EU representative. The representative can terminate the mandate if they believe the provider is acting contrary to the regulation. And when they do, they must report it to market surveillance authorities. Your EU representative isn’t just an address on file. They’re a compliance checkpoint with the power to blow the whistle.
The GDPR Déjà Vu
If this whole article feels familiar — it should.
The EU AI Act’s extraterritorial reach follows the GDPR playbook. It applies regardless of where the company is established. It requires an authorized representative for non-EU entities. “output used in the EU” mirrors GDPR’s “offering goods or services to” or “monitoring behavior of” EU data subjects. And the fines are higher — up to €35 million or 7% of global annual turnover for the most serious violations, compared to GDPR’s ceiling of €20 million or 4%.
But there are differences worth knowing.
The AI Act’s “output used in the Union” hook is arguably broader than GDPR’s targeting test. Under GDPR, you need to be “offering” to or “monitoring” EU persons. Under the AI Act, even being a subcontractor whose output happens to be used in the EU could be enough.
GDPR has had years of enforcement, case law, and guidance to clarify the grey zones. The AI Act has none of that yet. Everything right now is interpretation — informed interpretation, but interpretation nonetheless.
And the AI Act layers on top of GDPR. It doesn’t replace it. If your AI system processes personal data, you need to comply with both.
It’s Not Just the EU
Here’s the part that might matter even more than the extraterritorial reach.
The EU AI Act gets the headlines. But if you’re dismissing it because “we don’t operate in the EU” — you might want to check what’s happening closer to home.
United States — the patchwork
There’s no federal AI law. The current administration is actively trying to prevent one — the December 2025 executive order (”Ensuring a National Policy Framework for AI”) directed the Attorney General to challenge state AI laws and the Commerce Secretary to flag “burdensome” state regulation by March 2026.
But executive orders don’t override existing law. And the states aren’t waiting.
Colorado’s AI Act takes effect June 30, 2026 — delayed from February, but still coming. It requires developers and deployers to exercise reasonable care to prevent algorithmic discrimination, conduct impact assessments, and provide consumer disclosures. This is the closest a US state has come to EU-style AI obligations. California’s Transparency in Frontier AI Act hit January 1, 2026. Texas’s Responsible AI Governance Act — same date.
Until Congress acts or courts rule, state laws remain enforceable. Even if you’re a US company that doesn’t touch the EU — check Colorado, California, and Texas. The regulation is coming from inside the house.
United Kingdom — no law yet, but don't get comfortable
The UK doesn’t have a dedicated AI statute. Its current approach is the 2023 “Pro-Innovation” white paper — five principles applied by existing sector regulators rather than a central AI authority.
But legislation is expected in the second half of 2026, likely covering the most powerful general-purpose AI models. In January 2026, the government wrote to 19 regulators asking them to publish plans for safe AI innovation. The Financial Conduct Authority and others are already issuing sector-specific AI guidance.
The UK hasn’t passed an AI law yet. That doesn’t mean it isn’t building one.
Singapore — "voluntary" until it isn't
Singapore governs AI through voluntary frameworks — the Model AI Governance Framework (updated for generative AI in 2024-2025), the Agentic AI Governance Framework (January 2026, first of its kind globally), and AI Verify, a government-developed testing toolkit.
“Voluntary” sounds comfortable. But the Monetary Authority of Singapore already has mandatory AI governance requirements for financial institutions as of December 2024. Sector by sector, the voluntary frameworks are hardening into rules.
Singapore is building the infrastructure — the frameworks, the testing tools, the sectoral requirements — that makes binding regulation easy to switch on. When it does, the companies already following the frameworks won’t notice. The ones that ignored them will.
AI regulation used to be one law in one place. It isn’t anymore. It’s a permanent, growing area of law — worldwide — and the companies that figure that out now are the ones that won’t be scrambling later.
You already took the first step. You’re here, reading this, instead of shrugging it off in a meeting.
That matters more than you think.