EU AI Act Extraterritorial Reach: What Non-EU Companies Must Do

If your company is incorporated in New York, Bangalore, or Toronto and has no office anywhere in the EU, the EU AI Act still applies to you. That is the short version. The longer version — the one that determines what you actually have to do — depends on how your AI system connects to the EU market.

Regulation (EU) 2024/1689 states its territorial scope in Article 2(1). Three sub-clauses catch non-EU companies:

• Article 2(1)(a): providers placing AI systems on the EU market or putting them into service in the EU, regardless of where those providers are established.
• Article 2(1)(b): deployers of AI systems located in the EU — meaning a non-EU company running EU-based operations that use AI is also in scope.
• Article 2(1)(c): providers and deployers established in a third country where the output of an AI system is used in the EU.

That third clause is the broadest. It reaches a non-EU company whose model never processes data on EU soil and never contracts directly with an EU entity, as long as the system's output — a decision, a recommendation, a score, a generated text — reaches a person in the EU. A US HR-tech vendor whose AI scores CVs of applicants to a German employer falls under Article 2(1)(c) even if the German employer processes everything locally. An Indian BPO that uses an AI tool to route customer calls has the output — the routing decision — used by EU customers on the other end. Both are in scope.

This is structurally identical to how GDPR extends to non-EU processors: if the data subject is in the EU, the Regulation follows. Companies that went through GDPR extraterritorial compliance in 2018 will find the logic familiar, though the obligations are different. Under GDPR, the hook was processing personal data of EU residents; under the AI Act, the hook is the use of AI output in the EU. You do not need to be the one using it — you need to be the one whose system produces it.

---

The two roles that matter most: provider and deployer

Article 3(3) defines a provider as any entity that develops an AI system and places it on the market or puts it into service under its own name or trademark. Article 3(4) defines a deployer as any entity using an AI system under its authority in a professional context.

Most non-EU companies caught by the Act are providers — they build AI products or APIs and sell access to EU customers. But a non-EU company that purchases a third-party AI tool and uses it to produce outputs that reach EU users is a deployer, with its own lighter but real set of obligations under Article 26.

The distinction matters because the provider carries the heavy technical load: risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency to deployers (Article 13), human oversight design (Article 14), accuracy and robustness (Article 15), conformity assessment (Article 43), and registration (Article 49). Deployers must monitor the system, ensure human oversight, maintain logs for at least six months, and — for certain high-risk uses — run a Fundamental Rights Impact Assessment under Article 27.

Article 25 adds one more wrinkle: a deployer that puts its own name on a high-risk system, substantially modifies it, or changes its intended purpose becomes the provider. That conversion matters for non-EU companies that white-label third-party AI under their brand and sell it to EU customers.

---

The authorised representative requirement

Non-EU providers of high-risk AI systems cannot simply sell into the EU and rely on their EU customers to handle compliance. Article 22 requires every non-EU provider of a high-risk AI system to appoint an authorised representative established in the EU before placing the system on the market.

The representative must:

• hold a written mandate from the provider;
• be registered in the EU AI database under Article 49;
• verify that the technical documentation and conformity assessment are complete;
• keep copies of the EU declaration of conformity and the technical documentation for ten years;
• cooperate with market surveillance authorities, including handing over documentation and accepting inspections; and
• act as the single point of contact for EU authorities if the provider cannot be reached directly.

This is not a paper formality. If a market surveillance authority in France or Germany opens an investigation into a US AI system being deployed by French employers, they will contact the authorised representative first. The representative needs real authority and real access to the documentation.

For GPAI model providers — companies that develop general-purpose AI models offered to downstream developers — the equivalent requirement sits in Article 54. A non-EU GPAI provider must also appoint an authorised representative in the EU before making the model available on the Union market.

---

Worked example 1: US HR-tech vendor

A US company, call it TalentScore Inc., develops an AI system that ranks job applicants using CV data, structured test results, and inferred personality scores. TalentScore sells API access to EU employers — German automotive suppliers, Dutch logistics companies, Spanish retailers.

Under Article 2(1)(a), TalentScore is a provider placing a system on the EU market. Under Annex III, point 4(a), AI systems used for recruitment and selection of natural persons are high-risk. That classification triggers the full provider stack.

Before any EU employer goes live with TalentScore's API, TalentScore must:

1. Complete a risk management system under Article 9 — a living document, not a one-time audit.
2. Produce technical documentation under Article 11 and Annex IV covering system architecture, training data characteristics, performance metrics, and foreseeable misuse.
3. Run a conformity assessment under Article 43 (internal self-assessment for this Annex III category, since point 4 does not require a notified body).
4. Issue an EU declaration of conformity under Article 47.
5. Affix CE marking under Article 48.
6. Register the system in the EU database under Article 49.
7. Appoint an authorised representative in the EU under Article 22.

TalentScore must also check Article 5(1)(f): emotion recognition used in the workplace or educational setting is prohibited outright. If TalentScore's personality scoring infers emotions from video interviews, that element must be removed before EU market access, regardless of high-risk classification.

The deadline for stand-alone Annex III high-risk systems is 2 December 2027, under the Digital Omnibus agreed in May 2026, which deferred the original August 2026 date. That gives TalentScore time — but the documentation alone takes months to assemble, and the authorised representative must be in place before the system goes to market.

Non-compliance exposes TalentScore to fines up to €15,000,000 or 3% of worldwide annual turnover under Article 99(4), whichever is higher. Those are global revenue figures, not EU revenue.

---

Worked example 2: Indian BPO with AI-routed EU customer contacts

An Indian business-process outsourcer operates a contact centre handling EU customer support for several European financial institutions. It deploys a third-party AI tool that routes incoming calls and chats, prioritises cases, and flags customers whose messages contain distress signals.

The BPO is a deployer. The output — routing decisions, priority flags — is used in the EU by EU customers. Article 2(1)(c) catches it.

Whether the AI tool is high-risk depends on what the financial institutions use it for. If the tool influences decisions about which customers receive emergency payment deferrals or debt-restructuring conversations, it may touch Annex III point 5 (access to essential private services). If it is a general call-routing tool with no influence on credit decisions, it is likely minimal-risk.

As a deployer of a high-risk system, the BPO's obligations under Article 26 include: using the system only per the provider's instructions; ensuring human oversight of consequential decisions; monitoring for drift, bias, or anomalies; maintaining logs for at least six months; and informing the provider and authorities of any serious incidents. If the BPO serves public-sector financial institutions, Article 27 may also require a Fundamental Rights Impact Assessment before deployment.

What the BPO cannot do is argue that because it sits outside the EU, EU rules do not reach it. They do.

---

How extraterritoriality compares to GDPR

GDPR Article 3(2) applies to any controller or processor outside the EU that processes personal data of individuals in the EU in connection with offering goods or services, or monitoring their behaviour. The AI Act's Article 2(1)(c) follows the same logic: the hook is whether EU persons are on the receiving end of your system's output.

Two differences are worth noting. First, GDPR's hook requires processing personal data; the AI Act's hook is the use of output, which may or may not involve personal data. A non-EU company running a purely statistical market-forecast model whose outputs are used by EU traders is arguably in scope under Article 2(1)(c) even if no personal data flows through the system. Second, GDPR obligations apply to almost every processor regardless of risk level; the AI Act front-loads its heaviest obligations on high-risk and prohibited-use systems, leaving minimal-risk use largely obligation-free.

The practical implication: if your company already went through GDPR compliance, the governance infrastructure — documentation practices, cross-border accountability mechanisms, designated EU representatives — gives you a head start. The AI Act's authorised representative under Article 22 is conceptually similar to a GDPR Article 27 EU representative. They are distinct legal roles and cannot be merged into one appointment, but the same EU law firm or compliance partner can hold both mandates.

---

What a non-EU company should do

First, map your AI systems against Article 2(1) to confirm whether any reach the EU through any of the three clauses — direct market placement, EU-based operations, or output used in the EU.

Second, classify each in-scope system. Use Article 5 as the hard gate: any prohibited practice must stop before any other analysis. Then apply Article 6 and Annex III to identify high-risk systems. If the use falls outside Annex III entirely, check Article 50 for limited-risk transparency duties (relevant if you operate customer-facing chatbots or generate synthetic content seen by EU users).

Third, determine your role — provider, deployer, or (after Article 25 analysis) a deployer who has become a provider by rebrand or modification.

Fourth, if you are a high-risk provider, appoint your authorised representative under Article 22 before you go to market. For GPAI providers, do the same under Article 54. This is a legal prerequisite, not a post-launch nicety.

Fifth, build the compliance file: risk management system, technical documentation, conformity assessment, declaration of conformity. The authorised representative needs access to all of it.

The stand-alone high-risk deadline is 2 December 2027. Annex I product-safety-component AI follows on 2 August 2028. For prohibited practices, the deadline already passed — Article 5 has applied since 2 February 2025.

---

How Confir helps

Confir's intake process derives your role (provider, deployer, or both) from plain-English scenario questions and classifies your AI systems under Articles 5 and 6 using Annex III logic — deterministic and rule-based, not AI-generated. The classification output identifies whether an authorised representative obligation under Article 22 or Article 54 applies to your system.

For high-risk systems, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 / Annex V EU declaration of conformity — the two documents your authorised representative must hold and present to authorities on request.

---

FAQ

Does the EU AI Act apply if I have no EU customers, but my system's output is used by an EU company's own operations?

Yes. Article 2(1)(c) applies whenever the output is used in the Union, regardless of whether the direct contractual relationship is with an EU entity. If a non-EU company provides an AI tool to a multinational and that tool produces output used by the multinational's EU subsidiaries or EU employees, the non-EU company is in scope.

What is the difference between an authorised representative under Article 22 and one under Article 54?

Article 22 applies to providers of high-risk AI systems that are not established in the EU. Article 54 applies to providers of GPAI models that are not established in the EU. They are separate obligations. A company that develops a GPAI model and builds a high-risk application on top of it may need to fulfil both, though in practice one EU entity can hold both mandates simultaneously under separate written agreements.

Do I need to appoint an authorised representative if I only offer a minimal-risk AI tool?

No. The Article 22 requirement applies specifically to providers of high-risk AI systems under Annex III. If your system is minimal-risk (Annex III does not apply, no Article 5 prohibition, no Article 50 limited-risk transparency duties), no representative is mandated by the AI Act, though having EU legal counsel familiar with the Act is still prudent.

What are the penalties for a non-EU company that ignores the Act?

Under Article 99(4), non-compliance with high-risk provider obligations carries fines up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Violations of Article 5 prohibited practices reach €35,000,000 or 7% under Article 99(3). Fines are calculated on global revenue, not EU revenue. EU market surveillance authorities can also restrict or ban market access.

Is the GDPR's EU representative the same as the AI Act's authorised representative?

No. A GDPR Article 27 representative handles data-protection obligations. An AI Act Article 22 representative handles AI-system compliance obligations. They are distinct legal roles under different regulations. The same EU-based entity can hold both mandates, but must do so under separate written designations and with competence in both frameworks.

When must the authorised representative be in place?

Before the AI system is placed on the Union market. For high-risk Annex III stand-alone systems, the compliance deadline is 2 December 2027 under the Digital Omnibus agreed in May 2026. The representative and the compliance documentation must be ready by that date, not after.

---

Related guides

• Article 2: who the EU AI Act applies to
• EU AI Act scope explained
• Provider vs deployer: which role applies
• Article 3: key definitions