Territorial Scope of the EU AI Act: When Non-EU Companies Are Caught

The territorial scope of the EU AI Act is one of the first questions for any AI business with European touchpoints. The Act is not limited to companies incorporated in the EU. It can also apply to providers and deployers established outside the Union where their AI systems, general-purpose AI models or outputs have the kind of EU market or EU-use connection described in Article 2.

That does not mean that every foreign company using AI is automatically caught. The territorial analysis is more precise. It asks who is acting, what is being supplied or used, whether the activity reaches the Union market, and whether outputs produced outside the Union are used in the Union. Those questions should be answered before a business gives customers broad AI Act assurances or assumes the Act is irrelevant because the company has no EU entity.

Article 2 in plain English

In simplified terms, Article 2 covers several groups. It covers providers placing AI systems on the Union market or putting AI systems into service in the Union, whether or not those providers are established in the EU. It also covers providers of general-purpose AI models placed on the Union market. It covers deployers established or located in the Union. It also covers providers and deployers established or located in a third country where the output produced by the AI system is used in the Union.

This structure is market-facing and use-facing. A business should not treat territorial scope as a purely corporate-law question. An EU subsidiary, EU customer, EU distributor, EU product launch, EU-hosted deployment, or EU use of system outputs can each be relevant, but they do not all have the same effect. The analysis needs to connect the factual touchpoint to a specific Article 2 trigger and to the role the company performs.

EU-established actors

For organisations established or located in the Union, the territorial link is usually easier to identify. EU-based providers, deployers, importers, distributors, product manufacturers and authorised representatives may all fall within the framework depending on their role. A European company that develops and launches an AI system under its own name is likely to be analysed as a provider. A European company using another party's AI system under its authority may be a deployer. An EU company bringing a third-country system into the Union market may be an importer.

That role mapping matters because obligations are not identical. A provider of a high-risk AI system carries a different compliance burden from a deployer using the system. Importers and distributors have their own verification and supply-chain duties. A product manufacturer may become central where an AI system is embedded into a regulated product or functions as a safety component. Territorial scope identifies whether the EU framework can reach the activity; role mapping identifies who must do what.

Non-EU providers and the Union market

A non-EU provider may fall within the AI Act when it places an AI system or a general-purpose AI model on the Union market, or puts an AI system into service in the Union. This is a key issue for SaaS companies, model developers, API providers, product manufacturers and software vendors that sell or make AI-enabled products available to EU customers, even if development, hosting and management take place elsewhere.

The practical difference between EU customers, EU market placement and mere foreign operation should not be blurred. A non-EU company may operate an internal AI tool entirely outside the EU with no EU market or EU-output connection. That is different from offering an AI system into the Union market, deploying it for an EU customer, or supplying a model that downstream providers use in EU-facing products. Mere website accessibility from Europe should not be treated as an automatic answer on its own. The relevant question is whether the business is actually placing the system or model on the Union market, putting it into service in the Union, or otherwise falling within an Article 2 scenario.

Outputs used in the Union

Article 2 also covers certain third-country situations where the output produced by an AI system is used in the Union. This can be important for remote service models. A system may be operated from outside the EU, but its classifications, recommendations, scores, generated content, predictions or other outputs may feed into an EU business process or be used by an EU customer.

This output trigger needs careful handling. It does not mean that every remote AI calculation anywhere in the world is regulated in the same way. The output must have a Union use connection of the kind contemplated by the Act, and the next steps still depend on the nature of the system, risk category and role. A foreign supplier generating fraud-risk outputs for an EU financial institution raises a different profile from a foreign business using a generic AI drafting tool only for its own non-EU operations.

Practical examples

The following examples illustrate the kind of distinctions businesses should make without treating them as fixed legal answers:

• A US SaaS company launches an AI-enabled compliance tool for EU customers under its own brand. The Article 2 market-placement analysis and provider role should be reviewed.
• A non-EU model developer makes a broadly capable model available for integration by EU downstream providers. GPAI model placement on the Union market may be relevant.
• A Slovak company uses an AI system from a third-country vendor in its HR process. The Slovak company may be a deployer, while the vendor and any EU market-entry actor need separate role analysis.
• A non-EU business uses AI internally to support non-EU operations, with no EU market supply and no outputs used in the Union. Territorial scope should not be assumed merely because the company has a public website.
• A product manufacturer embeds an AI safety component into a product sold in the EU. Product-manufacturer and provider rules may need to be considered together.

Exemptions and caution areas

Territorial scope should also be read with the Act's exclusions and special contexts. The AI Act contains carve-outs and differentiated treatment for areas such as military, defence or national security purposes, certain research and development activity, and purely personal non-professional use. These points should be checked before treating a use case as ordinary commercial deployment, but they should not be stretched into broad exemptions where the facts do not support them.

A further caution is that territorial scope is only one layer. A system may be within scope but low-risk. Another system may be within scope and high-risk. A general-purpose AI model may trigger model-level duties even before a downstream application is classified. A transparency duty may apply to an interaction or content-output scenario without the system being high-risk. The correct conclusion usually requires territorial scope, personal scope, material scope and risk classification to be read together.

Timing for EU-facing planning

The AI Act applies in phases. The Commission explains that it entered into force on 1 August 2024 and is generally applicable from 2 August 2026. Prohibited practices and AI literacy obligations applied from 2 February 2025, and governance rules and obligations for general-purpose AI models applied from 2 August 2025. The Commission also identifies transparency rules as coming into effect in August 2026.

For non-EU companies, this staged timetable matters because enterprise customers, procurement teams and EU partners may ask for AI Act positions before every obligation is fully applicable. A territorial-scope review can therefore become part of contract negotiation, market-entry planning, supplier onboarding or product documentation well before enforcement questions arise in practice.

Checklist for non-EU companies

• List each AI system and general-purpose AI model connected to EU customers, EU partners or EU users.
• Identify whether the company is placing the system or model on the Union market, putting it into service in the Union, or generating outputs used in the Union.
• Map the role for each product or use case: provider, deployer, importer, distributor, authorised representative or product manufacturer.
• Check whether the system is prohibited, high-risk, subject to transparency duties, linked to GPAI model obligations, or likely minimal/no risk under the Act.
• Review contracts to see whether legal labels match operational reality, especially in white-label, reseller, API and integration models.
• Prepare customer-facing explanations that are precise and do not overstate compliance status.

Practical takeaway

The territorial scope of the EU AI Act is broad, but it is not unlimited. Non-EU companies are most exposed where they place AI systems or general-purpose AI models on the Union market, put systems into service in the Union, rely on EU market-entry actors, or generate outputs that are used in the Union in a legally relevant way.

The safest first step is a factual map by system, model, customer route, role and EU touchpoint. Only then can the organisation assess whether the relevant activity creates provider, deployer, importer, distributor, product-manufacturer or GPAI obligations under the Act.

Legal references

• Regulation (EU) 2024/1689, in particular Articles 2, 3, 25 and 113.
• European Commission, AI Act overview and implementation timeline, including staged application dates for prohibited practices, GPAI obligations, transparency rules and general application.