EU AI Act Article 2: Scope and Who It Applies To

Article 2 of Regulation (EU) 2024/1689 is the regulation's first real question: does any of this apply to you? Before you examine risk tiers, assess documentation requirements, or work out whether a conformity assessment is needed, you have to answer the jurisdictional threshold. Get it wrong in either direction — claiming an exemption you don't have, or assuming you're out of scope when you aren't — and every compliance decision downstream is built on sand.

This article walks through who is caught, who is excluded, and why the answer is rarely obvious in practice.

Why Scope Comes Before Everything Else

The EU AI Act imposes obligations by attaching them to roles — provider, deployer, importer, distributor — and to the territories where a system is placed, put into service, or whose outputs are used. Article 2 defines both. Until you know which role you occupy and whether the territorial trigger fires, there is nothing useful you can do with Articles 9 through 49.

The scope question also has a hard asymmetry. If you are in scope, a cascade of obligations follows: risk classification under Article 6, technical documentation under Article 11, human oversight requirements under Article 14 for high-risk systems, registration under Article 49, and so on. If you are genuinely out of scope — because your system is a research prototype, or serves only non-professional personal use — none of those obligations attach. The stakes of the threshold question are therefore high.

One more reason scope analysis comes first: the EU AI Act's territorial reach extends well beyond the EU's borders. Many organisations are surprised to find themselves in scope.

Who Is Covered: The Six Actor Categories

Article 2(1) identifies six categories of actors that fall within the regulation. Each carries different downstream obligations.

Providers placing on the market or putting into service in the EU

A provider, as defined in Article 3(3), is any natural or legal person that 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. The defining feature of the provider role is that the provider is the entity that makes the system available to others or deploys it under its own authority.

Geography of establishment is irrelevant. A company headquartered in San Francisco that licenses an AI-based credit-scoring model to banks in Germany, Austria, and the Netherlands is a provider under Article 2(1)(a). The regulation reaches it just as it reaches a provider incorporated in Munich. US, UK, Israeli, or any other non-EU SaaS vendors selling AI-enabled tools into the EU market are providers in scope.

The provider role carries the heaviest obligation stack: the risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency to deployers (Article 13), human oversight measures (Article 14), accuracy and robustness requirements (Article 15), quality management (Article 17), conformity assessment (Article 43), and registration (Article 49) — for high-risk systems. Providers of General-Purpose AI (GPAI) models have a separate set of baseline obligations under Article 53, which have applied since 2 August 2025.

Deployers established or located in the EU

A deployer is any natural or legal person, public authority, agency, or other body that uses an AI system under its authority in a professional context — except where the system is used in the course of a personal non-professional activity. If a logistics company in Warsaw uses a third-party route-optimisation AI, it is a deployer. If a hospital in Lyon uses an AI diagnostic support tool built by a US medtech firm, the hospital is a deployer.

Deployer obligations under Article 26 are lighter than provider obligations, but they are not trivial. Deployers must follow the provider's instructions for use, ensure human oversight where the system requires it, monitor the system in operation, and — for certain high-risk uses — carry out a Fundamental Rights Impact Assessment (FRIA) under Article 27. Deployers that are public bodies or deploy high-risk systems in specific contexts have additional transparency and registration duties.

Most companies that buy and integrate AI tools from third parties are deployers, not providers. That is the practical starting point for the majority of businesses.

Providers and deployers established in third countries where outputs are used in the EU

This is the extraterritorial hook. Article 2(1)(c) catches providers and deployers established outside the EU when the output of the AI system is used within the EU. It does not require that the system be deployed on EU soil; it requires that the results — the decisions, recommendations, classifications, content, or scores the system produces — are consumed by people or processes inside the EU.

A worked example: a US-based HR analytics firm, headquartered in Austin, runs a candidate-screening AI for a multinational client. The system is hosted in Virginia. But the candidates being screened are applying for roles in Frankfurt, Amsterdam, and Madrid — meaning the screening output is used within the EU. The Austin firm is a provider in scope under Article 2(1)(c).

This provision closes a loophole that would otherwise allow non-EU actors to serve EU users from outside EU jurisdiction without regulatory accountability.

Importers and distributors

Article 2(1)(d) covers importers — entities that place a non-EU provider's AI system on the EU market — and distributors, who make an AI system available in the EU without placing it on the market themselves. Their obligations, set out in Articles 23 and 24, focus on supply-chain compliance: checking that the provider has completed the conformity assessment, ensuring CE marking is in place, and notifying competent authorities and the provider if a system presents a risk.

Importers and distributors can become providers in the full sense under Article 25(1) if they place a system on the market under their own name or trademark, substantially modify it, or change its intended purpose in a way that brings it into the high-risk category.

Product manufacturers placing an AI system with their product under their name

When an AI system is incorporated into a physical product subject to Union harmonisation legislation — the Machinery Regulation, the Medical Device Regulation, the General Product Safety Regulation, and others listed in Annex I — and the manufacturer places the combined product on the market under its own name, the manufacturer is treated as the provider of the AI component. This matters because such systems are classified as high-risk under Article 6(1): they are safety components of products covered by Annex I, and the applicable conformity assessment procedure runs from 2 August 2028 (under the Digital Omnibus agreed in May 2026).

A manufacturer of industrial robots incorporating AI-based collision detection is the paradigm case. The robot maker, not the AI software vendor, carries the provider obligations for the system as deployed in that product.

Authorised representatives of non-EU providers

Where a provider is not established in the EU, it must designate an authorised representative under Article 22 — a natural or legal person established in the EU that is mandated in writing to act on behalf of the provider. The authorised representative becomes a named point of contact for EU competent authorities and assumes defined compliance responsibilities. Non-EU providers that place high-risk AI systems on the EU market without designating an authorised representative are in breach from the moment general application of those provisions begins.

Affected persons located in the EU

Article 2(1)(g) extends protection to natural persons physically located in the EU who are subject to AI system outputs, regardless of where those persons are nationals or residents. This provision underpins enforcement in cases where, for example, an AI system used by a non-EU government makes decisions about individuals who happen to be in EU territory.

Key Exclusions: What Sits Outside Article 2

The regulation carves out several categories expressly. Each exclusion has its own scope and limits; none of them is as broad as it might first appear.

National security, military, and defence

Article 2(3) excludes AI systems used exclusively for military and defence purposes, and AI systems used exclusively for national security purposes — regardless of the type of entity carrying out those activities. A system built and operated solely for national security is outside the regulation entirely.

The word "exclusively" is load-bearing. A system that serves both a classified national-security function and a civilian commercial function — a supplier that sells the same underlying model to intelligence agencies and to financial-services customers — cannot claim the exemption for its civilian uses. The exemption is use-specific, not entity-specific.

Scientific research and development

Article 2(6) excludes AI systems developed and put into service for the sole purpose of scientific research and development. A university group building an experimental natural-language processing model for a linguistics study is outside scope during the research phase. The moment the institution deploys that model for operational use — in a clinical setting, as a commercial product, or in any other non-research context — Article 2 applies.

Research and testing activity prior to placing a system on the market also falls outside scope, with one critical caveat: real-world testing of high-risk AI systems in the EU may constitute "putting into service" and can therefore trigger scope. Article 2(8) provides a narrow exception for testing under specific conditions, but it is not a blanket research exemption.

The research exclusion is not available to a company that is piloting a system with paying customers while calling it a "beta." That is market deployment, not scientific research.

Free and open-source AI

Article 2(12) exempts AI systems released under free and open-source licences from most of the regulation's requirements — with three exceptions that eliminate most of the apparent relief:

1. Systems that fall under Article 5 (prohibited practices) are not exempt regardless of licensing.
2. High-risk systems under Article 6 are not exempt. An open-source developer releasing a model designed for credit scoring or applicant screening inherits the full high-risk obligation stack.
3. Systems subject to the Article 50 transparency obligations (chatbots, synthetic-content labelling, emotion recognition, deepfakes) are not exempt.

In practice, the open-source exemption covers genuinely minimal-risk systems. Any foundation model that could plausibly be adapted for prohibited or high-risk uses, and whose provider has not restricted or documented against such use, should be assessed carefully before relying on this exclusion.

GPAI model providers releasing under open-source licences retain the Article 53 baseline obligations (copyright compliance policy, training-data summary) unless they qualify for a specific limited exception under Article 53(2).

Personal and non-professional use

AI systems used by natural persons for purely personal, non-professional activities are outside scope. Using a writing assistant to draft personal emails, or a fitness AI to plan workouts, is not regulated conduct. The moment the same system is used in a professional or business context — to process customer data, to manage employees, to provide a service — the exemption falls away.

This exclusion matters primarily for individuals. It does not help companies.

Other Union law and sectoral interactions

Article 2 also addresses systems already regulated under specific sectoral Union law. Where a Union legislative act specific to an AI application already applies, the AI Act's requirements yield to that sectoral framework in limited ways — primarily to avoid duplicating conformity assessment procedures. The Medical Device Regulation, for example, has its own notified-body assessment process; Article 2 accommodates that rather than layering an entirely separate AI-Act conformity assessment on top. But this coordination is procedural, not substantive: it does not exempt medical-device AI from the regulation's substantive requirements, only from duplicating certain procedural steps.

Interplay with GDPR

Article 2 of the EU AI Act and the General Data Protection Regulation (GDPR) operate in parallel, not in sequence. An AI system that processes personal data must comply with both. They target different risks — GDPR addresses data subject rights, lawfulness of processing, and data minimisation; the AI Act addresses the risks that AI systems pose to health, safety, and fundamental rights. An AI system can breach GDPR without breaching the AI Act, and vice versa.

Where the overlap bites hardest is in high-risk systems that also process personal data at scale: a biometric identification system, an AI-based creditworthiness scoring tool, a recruitment-screening model. In those cases, the GDPR data protection impact assessment (DPIA) under Article 35 GDPR and the FRIA under Article 27 of the AI Act address overlapping ground from different angles. Both must be conducted; neither substitutes for the other. Supervisory authorities under GDPR and competent market surveillance authorities under the AI Act are distinct bodies with distinct enforcement powers.

For organisations already embedded in GDPR compliance programmes, the AI Act's documentation, logging, and transparency obligations will feel structurally familiar. But the legal bases and evidence required are not the same.

Two Worked Examples

Example 1: A US SaaS vendor selling into the EU

A 60-person software company based in Chicago sells a candidate-assessment tool that uses a scoring model to rank job applicants. The company has no EU office and no EU employees. Its customers include HR departments in Germany, Spain, and Sweden.

This company is a provider under Article 2(1)(a) — placing an AI system on the Union market — and also caught by Article 2(1)(c) — outputs are used within the EU. The system almost certainly falls within Annex III area 4 (employment, worker management, access to self-employment) and is therefore presumptively high-risk under Article 6(1). The company must comply with the full high-risk obligation stack, designate an authorised representative under Article 22, and register the system under Article 49. It cannot shelter behind its non-EU establishment.

The revised deadline for stand-alone Annex III high-risk systems is 2 December 2027 under the Digital Omnibus agreed in May 2026 — that is the compliance target for the core high-risk requirements.

Example 2: An internal R&D prototype

A 200-person fintech in Amsterdam has a data-science team building a proof-of-concept fraud-detection model. The model runs on internal test data, has never processed live customer transactions, and is not deployed in production. No external parties use it.

During this phase, the system is likely outside scope under Article 2(6) (sole purpose of research and development). But the exclusion is conditional. The moment the team deploys it on live customer transaction data, even in a "pilot" framing, the Article 2(6) exclusion falls away. At that point, the company must assess whether it is a high-risk system (fraud detection is expressly excluded from the creditworthiness category in Annex III area 5, so the classification result may be minimal risk — but the analysis must still be documented), determine its role, and proceed accordingly.

Penalties in Context

Non-compliance with obligations triggered by being in scope — failing to conduct a conformity assessment, not maintaining technical documentation, not designating an authorised representative — falls under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Supplying incorrect, incomplete, or misleading information to authorities or notified bodies carries the lower Article 99(5) tier: up to €7,500,000 or 1% of turnover.

Under Article 99(6), fines for SMEs and start-ups are capped at the lower of the percentage and the fixed amount. For a company with €4 million annual turnover, the ceiling for a general non-compliance breach is €120,000 (3% of €4M), not €15 million. That proportionality protection is worth noting, though it is not a licence to deprioritise compliance.

The penalties that can flow from a wrong scope determination are not direct — you cannot be fined for "getting Article 2 wrong" in isolation. The fine attaches to the obligation that you failed to meet because you incorrectly concluded you were out of scope. That makes the stakes high and the documentation of your scope analysis valuable: a contemporaneous, reasoned record that you considered the question and reached a defensible conclusion is meaningful evidence in any enforcement investigation.

How Confir Helps

The first thing Confir asks when you register an AI system is a set of plain-English questions about how the system is deployed, where its outputs are used, and who controls it. The answers drive a deterministic, rule-based classification of your role under Article 2 — provider, deployer, importer, distributor, or none — and map that role to the specific articles that attach. The same intake flags whether any exemption applies and documents the basis for that determination.

That scoping output feeds directly into the compliance workflow: if you are a provider of a high-risk system, Confir opens the Article 9 risk management assessment, the Article 11 documentation builder, and the Article 27 FRIA track if applicable. If the system classifies as minimal risk, those tracks stay closed and the record shows why. The logic is transparent and human-readable — same input, same output, every time.

From Scope to Substance

Article 2 is not itself a burden. It imposes no documentation requirements, no assessments, no deadlines of its own. What it does is determine whether every other provision in the regulation applies to you. That makes it the right starting point, and the right place to invest analytical care before proceeding to the obligation-heavy articles that follow.

The scope analysis is also not a one-time exercise. If you launch a new AI system, change an existing system's intended purpose materially, acquire a company that develops AI, or start selling an AI tool to EU customers for the first time, Article 2 needs to be reassessed. The scope question is live for as long as your AI portfolio is live.

Related guides

• Article 2 jurisdictional scope
• SMB compliance requirements
• startup compliance roadmap
• Article 3 definitions
• EU AI Act overview
• compliance deadlines
• EU AI Act fundamentals
• provider vs deployer roles