Article 2 Scope Rules

Whether the EU AI Act applies to a company depends on what the company does with an AI system, where it does it, and whether the system or its output reaches the Union market. Article 2 of Regulation (EU) 2024/1689 sets that threshold by combining operator role, establishment, market access, and output use. For global companies, the practical question is not whether they are headquartered in Europe, but whether their AI activities fall within one of the jurisdictional triggers in Article 2(1).

Article 2 sets scope through operator role, establishment, and market connection

Article 2(1) applies the Regulation to several categories of actors and activities. It covers providers placing AI systems on the market or putting them into service in the Union, as well as providers placing general-purpose AI models on the market, regardless of whether those providers are established or located in the Union or in a third country. It also covers deployers of AI systems that have their place of establishment or are located within the Union, and providers and deployers established in a third country where the output produced by the AI system is used in the Union. The same provision extends to importers, distributors, product manufacturers placing an AI system on the market with their product under their own name or trademark, authorised representatives of providers not established in the Union, and affected persons located in the Union.

That structure matters because the Act does not rely on a single connecting factor. Incorporation in the EU is not the only route into scope, and non-EU incorporation is not a safe harbor. A company may fall within the Regulation because it supplies AI systems to the Union market, because it deploys AI systems within the Union, because the output of the system is used in the Union, or because it participates in the supply chain in a way that brings it within the listed operator categories. The official consolidated text of Regulation (EU) 2024/1689 confirms that Article 2 is built around these role- and market-based triggers.

Article 2 also has to be read with Article 3. The definitions of provider, deployer, importer, distributor, operator, placing on the market, making available on the market, and putting into service determine how the scope rule operates in practice. Without those definitions, Article 2 remains a list of categories rather than a working test.

Providers are in scope even when established outside the EU

The provider rule is the clearest extraterritorial trigger. Under Article 2(1)(a), a provider is within scope when it places an AI system on the market or puts it into service in the Union, irrespective of whether it is established or located in the Union or in a third country. The same applies to providers placing general-purpose AI models on the market. The provider definition in Article 3(3) covers a person or body that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

This means the analysis turns on market conduct. A company that develops an AI system only for internal experimentation may not yet be acting as a provider within the meaning of the Regulation. Once that same company makes the system available on the Union market, supplies it for use in the Union, or puts it into service under its own branding, the scope question changes. The distinction between development, making available, and putting into service is therefore central. Article 3 defines placing on the market as the first making available of an AI system or general-purpose AI model on the Union market, making available as supply for distribution or use on the Union market in the course of a commercial activity whether paid or free, and putting into service as supply for first use directly to the deployer or for own use in the Union for its intended purpose.

For non-EU companies, the commercial model matters. Direct sales into the EU, API access for EU customers, SaaS delivery to Union users, and embedded AI functionality in products offered in the Union can all raise provider-scope questions. The legal issue is not the label used in contracts. It is whether the company, in substance, develops or commissions the system and then places it on the market or puts it into service in the Union under its own name or trademark.

Deployer location and output use determine applicability for users of AI systems

Article 2(1)(b) brings deployers of AI systems within scope where they have their place of establishment or are located within the Union. Article 3(4) defines a deployer as a person or body using an AI system under its authority, except where the system is used in the course of a personal non-professional activity. This means a company can enter scope through use rather than supply. A business that does not develop AI at all may still be regulated as a deployer if it uses an AI system in the Union under its own authority.

Article 2(1)(c) adds a separate and often overlooked trigger. Providers and deployers established in a third country are also within scope where the output produced by the AI system is used in the Union. That provision is especially relevant for multinational groups that run AI systems outside Europe but use the results in EU operations. It is also relevant for vendors whose systems are technically operated abroad but generate outputs that are relied on in the Union. In those cases, the question is not only where the model sits or where the server is located. The question is whether the output is used in the Union.

This output-based trigger is one of the most important scope rules for global companies. It means that a non-EU company cannot assume the Act is irrelevant merely because the AI system itself is hosted, trained, or operated outside Europe. If the output is used in the Union, the company may still need to assess whether it falls within Article 2(1)(c). The official Commission overview of the AI Act entering into force reflects the broader implementation context, but the binding scope test remains the text of Article 2 itself.

Importers, distributors, and product manufacturers can inherit scope through the supply chain

Article 2(1)(d), (e), and (f) extend the Regulation beyond the original developer and user. Importers and distributors of AI systems are within scope, as are product manufacturers that place an AI system on the market or put it into service together with their product under their own name or trademark. Authorised representatives of providers not established in the Union are also included. These provisions matter because responsibility under the Act does not stay with the original developer in every case.

Article 3(6) defines an importer as a person located or established in the Union that places on the market an AI system bearing the name or trademark of a person established in a third country. Article 3(7) defines a distributor as a person in the supply chain, other than the provider or importer, that makes an AI system available on the Union market. These roles can create regulatory exposure for companies that do not design the AI system but still bring it into the EU market or distribute it there. A reseller, integrator, or channel partner may therefore need its own scope analysis.

Product manufacturers face a related issue. Where a manufacturer places a product on the market with an embedded AI system under its own name or trademark, it may be treated as the relevant operator for that system. This is especially significant for hardware, industrial equipment, medical devices, consumer products, and other sectors where AI is embedded in a broader product offer. The company’s brand on the product can matter as much as the origin of the underlying model.

Supply-chain role confusion is one of the most common compliance weaknesses. A company may think of itself only as a customer or reseller, while in regulatory terms it may be acting as importer, distributor, or even provider in specific circumstances. That is why Article 2 should be assessed at the level of each product line and distribution arrangement, not just at the level of the corporate group.

Exclusions narrow the scope but do not create broad safe harbors

Article 2 also excludes certain systems and use cases. The Regulation does not apply to AI systems placed on the market, put into service, or used with or without modification exclusively for military, defence, or national security purposes, regardless of the type of entity carrying out those activities. It also does not apply to systems that are not placed on the market or put into service in the Union where the output is used in the Union exclusively for military, defence, or national security purposes. In addition, the Regulation does not apply to AI systems or models, including their output, specifically developed and put into service for the sole purpose of scientific research and development.

These exclusions are narrow. A system developed for both civilian and military purposes, or later repurposed outside the excluded category, can still fall within scope. The same is true for research systems that move beyond the sole purpose of scientific research and development. The exclusion should therefore be treated as a fact-specific legal assessment, not as a broad category label. Where an exclusion is claimed, the company should retain evidence showing that the system is exclusively within the excluded use case.

Article 2 also excludes several other situations not covered in detail here: AI systems released under free and open-source licences (unless high-risk or covered by Articles 5 or 50), research, testing, or development activity prior to an AI system being placed on the market or put into service, and use by deployers who are natural persons acting in a purely personal, non-professional capacity. Each of these carries its own conditions and should be assessed separately rather than assumed.

Article 2(4) also addresses public authorities in third countries and international organisations using AI systems in the framework of international cooperation or agreements for law enforcement and judicial cooperation with the Union or one or more Member States, provided adequate safeguards exist. Article 2(5) preserves the application of intermediary service liability rules under Regulation (EU) 2022/2065. These provisions limit or qualify scope in specific settings, but they do not displace the general market- and output-based triggers for private companies.

How global companies should run the Article 2 applicability test

A practical Article 2 assessment should begin with the company’s role. The first question is whether the company develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. If yes, the company should assess provider scope. If the company uses an AI system under its authority, it should assess deployer scope. If it brings third-country AI systems into the EU market, distributes them, or embeds them in products sold under its own brand, it should assess importer, distributor, and product-manufacturer scope. If it acts under a written mandate for a non-EU provider, it should assess authorised-representative scope.

The second question is geographic. The company should determine whether the AI system is placed on the market or put into service in the Union, whether the company is established or located in the Union, and whether the output produced by the AI system is used in the Union. These are separate inquiries. A company may fail one and still satisfy another.

The third question is whether any exclusion applies. That inquiry should come after the role and geographic analysis, not before it. Exclusions are exceptions to scope, not the starting point. If a company begins with the assumption that its system is outside the Act because of its sector, customer type, or intended use, it risks skipping the threshold analysis that Article 2 requires.

The evidence supporting each answer should be retained. Relevant records include product and distribution agreements, branding decisions, technical documentation, deployment records, customer-location analysis, output-use analysis, and the rationale for any exclusion. This documentation becomes especially important where the same system is sold through multiple channels or used by multiple group entities in different jurisdictions.

What Article 2 does not settle on its own

Article 2 answers whether the Regulation applies. It does not answer every question about what the company must do next. Once a company is in scope, the next layer of analysis depends on the type of system, the operator’s role, and the applicable obligations elsewhere in the Regulation. A provider of a general-purpose AI model faces a different compliance path from a deployer of a limited-risk system or a distributor of a high-risk system. Scope is the threshold determination, not the final obligations assessment.

That distinction matters for governance design. Compliance teams should avoid treating an Article 2 analysis as a complete legal review. The better approach is to treat it as the first control in a wider regulatory workflow: determine whether the Act applies, identify the company’s operator role, classify the system, and then map the resulting obligations. This sequencing reduces the risk of either over-compliance based on assumption or under-compliance based on a mistaken belief that the company is outside the EU and therefore outside the Act.

How compliance teams should document Article 2 scope decisions

Every scope determination should be tied to a specific AI system, business unit, and distribution model. A group-level conclusion that “the EU AI Act may apply” is not enough. The record should identify the relevant operator role, the market-access route, the location of deployment, whether output is used in the Union, and whether any exclusion is being relied on. Where the company acts in more than one role, each role should be documented separately.

The analysis should also be refreshed when the business model changes. Rebranding a third-party system, modifying its intended purpose, making a substantial modification, expanding into the EU market, or shifting from internal use to external supply can all alter the scope conclusion. Article 2 is not a one-time classification exercise. It is a recurring governance control that should be revisited whenever the system, the market, or the company’s role changes.