Scope, Definitions, and the Actor Model

This article teaches the specialist how to establish scope and assign roles before the Article 6 classification discussion begins. It works through Article 2, Article 3 definitions (1), (3), (4), (6), (7), and (8), and the Article 2(8) research exception, anchored to two documented cross-border enforcement precedents.

For foundational, practitioner-level context on how these concepts sit inside the Act’s four-tier risk framework, see the existing COMPEL practitioner article “EU AI Act Risk Classification: A Practitioner’s Guide” (Article ID 253). This specialist article extends that foundation into the operational scoping workflow.

Why scope comes first

A common failure pattern in early EU AI Act compliance programmes is the system inventory that lists three hundred AI systems and classifies each one without first asking: is this system in scope, and if so, in which role are we? The consequence is a ballooning remediation backlog full of [[provider]] obligations for systems where the organisation is actually a [[deployer]], and missing obligations for foreign-sourced systems no one thought to include.

Scope and role are the two questions that determine whose [[technical-documentation-annex-iv]] the organisation needs, whose [[conformity-assessment]] applies, and whose records the [[national-competent-authority]] will demand. Classification is the what; scope and role are the who and the where. The specialist who gets scope and role right will produce a classification register that is small enough to manage and complete enough to pass a supervisory review.

Territorial scope — Article 2

Article 2(1) of Regulation (EU) 2024/1689 establishes four independent trigger conditions. Any one of them brings an entity inside the Act:

The fourth trigger — “output used in the EU” — is the Act’s long-arm reach, and it is the one most often missed in scoping memos. A US-based analytics company that scores European credit applications from a data centre in Virginia is in scope of Article 2(1)(c) even if no part of the company is established in the EU and no hardware is inside the Union. The supervisory authority for the company is determined separately by Article 70, but the obligations attach regardless.

Article 2 also carves out several exemptions — national security (Article 2(3)), public-authority use by third countries under international cooperation agreements (Article 2(4)), and the research-and-development exemption of Article 2(8). The research exemption is narrow: it covers “AI systems and models specifically developed and put into service for the sole purpose of scientific research and development.” Scientific research is not the same as corporate R&D, and a specialist should treat the carve-out as an assertion that must be actively defended in the scoping memo, not a default.

The Article 2(8) research exception — common misapplications

Three misapplications of Article 2(8) recur in scoping work:

1. Corporate internal research programmes. A bank’s data-science team is corporate research, not scientific research as the Act uses the term. An internal prototype of a credit-scoring model developed by employees in the course of their employment and intended for eventual deployment is outside the Article 2(8) carve-out from the first line of code.
2. Joint academic-industry research with a deployment roadmap. Where academic partners are involved but the model is being developed with a commercial deployment target, Article 2(8) applies only to the pre-deployment phase. The moment the system is put into service for its intended commercial purpose, the carve-out is exhausted.
3. Open-source model releases labelled as “research.” Publishing a model on a model hub with a permissive licence and a “research use only” label does not shield the model from the GPAI regime in Articles 51–56 once it is widely deployed downstream. The Act treats substance over form.

The actor model — Article 3 definitions

Obligations are allocated by role. The five roles in Article 3 — [[provider]], [[deployer]], [[importer]], [[distributor]], and authorized representative — are mutually exclusive for a given system but can stack across an organisation’s portfolio. A large enterprise is almost always all five simultaneously.

Provider — Article 3(3)

A provider is the natural or legal person that develops an AI system, or has one developed, and places it on the EU market or puts it into service under its own name or trademark. The own name or trademark test is the discriminator. An organisation that buys a commercially available AI product and deploys it internally is not a provider of that product; the vendor is. An organisation that integrates third-party components into a system it releases under its own brand is a provider of the composite system.

The provider carries the heaviest obligation stack: [[risk-management-system]] (Article 9), [[data-and-data-governance]] (Article 10), [[technical-documentation-annex-iv]] (Article 11 + Annex IV), transparency (Article 13), [[human-oversight]] (Article 14), accuracy / robustness / cybersecurity (Article 15), conformity assessment (Article 43), registration (Article 49), and post-market monitoring (Article 72).

Deployer — Article 3(4)

A deployer is a natural or legal person using an AI system under its authority, except where the use is personal non-professional activity. Most organisations are deployers for most of their AI portfolio. Deployer obligations are lighter than provider obligations but are not trivial: Article 26 imposes duties to use the system in line with instructions, to assign human oversight to competent persons, to maintain logs where under their control, to cooperate with authorities, and — for Annex III systems used in certain public-sector and private-sector contexts — to conduct a [[fundamental-rights-impact-assessment]] (Article 27) before first use.

Substantial-modification rule — Article 25

A deployer that substantially modifies a high-risk AI system, or changes its intended purpose such that it remains within a high-risk classification, is treated as a provider of that modified system under Article 25. “Substantial modification” includes changes to the intended purpose and retraining on significantly different data that alters the system’s performance or safety profile. This rule is the reason that fine-tuning a general-purpose model on internal data can move an organisation from deployer to provider of the derived system. The specialist should flag every fine-tuning programme for a role-reassessment trigger.

Importer — Article 3(6) and distributor — Article 3(7)

An importer is an EU-established entity that places on the EU market an AI system bearing the name of a non-EU provider. A distributor is any other entity in the supply chain that makes a system available on the market. Importer obligations (Article 23) and distributor obligations (Article 24) are primarily verification duties — confirm the provider completed conformity, confirm CE marking where applicable, confirm documentation exists, and refuse to place on the market where any of those are missing.

Authorized representative — Article 22

A non-EU provider placing a high-risk AI system on the EU market must appoint an EU-established authorized representative in writing before placement. The representative verifies documentation, cooperates with authorities, and provides a single EU point of contact. Organisations acting as authorized representatives face concrete liability and should budget for it accordingly.

The role-assignment workflow

Put the trigger tests into a sequence:

1. Where is the entity established? Inside the EU, outside the EU with EU operations, or wholly outside the EU.
2. For each AI system in inventory, what does the entity do to it? Develop under own name or trademark → provider. Use under its authority → deployer. Import from non-EU provider → importer. Resell or distribute → distributor. Represent a non-EU provider in the EU market → authorized representative.
3. For each role assignment, which Article 2 trigger applies? This tells the specialist which supervisory authority (Article 70) has competence.
4. Does Article 25 substantial-modification transfer provider status? Flag every fine-tuning, retraining, or intended-purpose change for reassessment.
5. Does Article 2(8) research exception apply? Document the carve-out assertion with evidence; treat as rebuttable.

The output of the workflow is a role register — one row per system per role assignment — that becomes the foundation of the classification register in Article 3 of this credential and the obligation register in Article 4.

Real-world anchor — Clearview AI

Clearview AI is the most frequently cited precedent for the long-arm scope reasoning of Article 2(1)(c). The US-based company scraped publicly accessible facial images from the open internet and built a facial-recognition database sold to law-enforcement customers. Although Clearview had no establishment in the EU, multiple EU data-protection authorities — Italy’s Garante (Provvedimento 50/2022, €20M), France’s CNIL (October 2022, €20M), the UK ICO (May 2022, £7.55M), the Hellenic DPA (July 2022, €20M), and the Dutch AP (May 2023, €30.5M) — all held that the processing targeted and monitored data subjects in the EU and that the GDPR therefore applied.

The EU AI Act’s Article 2(1)(c) long-arm reach generalises that logic to AI systems whose outputs are used in the Union. A specialist writing a scoping memo for a non-EU provider cannot rely on absence of EU establishment. The relevant test is whether the output reaches the Union — and, for systems analogous to Clearview’s, whether the input was obtained from the Union. Source: Italian Garante Provvedimento 50/2022, https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9751362 .

Real-world anchor — Meta Llama 3 EU feature pause

In summer 2024, Meta publicly paused the EU rollout of multimodal features of Llama 3, citing regulatory uncertainty under EU law. The pause did not retroactively take Meta out of scope for its text-only Llama models already in EU distribution, but it illustrated a strategic response pattern: a non-EU [[general-purpose-ai-model]] provider using product-availability controls to manage its Article 2 exposure. For specialists, the Meta example is a useful case in two directions — it confirms that Article 2(1)(c) is taken seriously by major non-EU providers, and it previews the flow-down information duties under Articles 53–55 that the specialist learns in Article 5 of this credential. Source: Meta Responsible AI Deployment Principles update, https://about.fb.com/news/2024/07/meta-responsible-ai-deployment-principles/ .

Documentation — the one-page scope memo

A defensible scope memo fits on a single page and contains five sections:

1. System identifier — internal ID, name, vendor (if any), intended purpose.
2. Actor roles asserted — provider, deployer, importer, distributor, authorized representative, with a short factual basis for each.
3. Article 2 trigger — which of 2(1)(a), (b), (c) applies, and a one-sentence justification.
4. Exemption assertions — Article 2(3), (4), (6), (7), (8), (10) if claimed, with evidence.
5. Reassessment trigger — the conditions that would require reopening the memo (intended-purpose change, retraining, new distribution channel, cross-border data flow change).

The memo is authored once per system and refreshed whenever a reassessment trigger fires. It feeds the classification register (see Article 3) and is the first document a national competent authority will ask to see.

Diagram — OrganizationalMappingBridge

This article is accompanied by an OrganizationalMappingBridge figure. The figure has two columns. The left column lists the five actor roles from Article 3 — provider, deployer, importer, distributor, authorized representative. The right column lists the ten primary obligations — [[technical-documentation-annex-iv]], conformity assessment, registration, [[risk-management-system]], [[human-oversight]], [[post-market-monitoring]], transparency, cooperation, [[fundamental-rights-impact-assessment]] (deployer-side), and verification duties. Bridge lines connect each role to the obligations it bears. The figure collapses the Article 16–27 wall of text into a single reference image that the specialist can annotate on top of. Methodology Lead reviewers accept the figure only when every bridge line resolves to an Article cite.

Cross-references

• EATF-Level-1/M1.5-Art13-Understanding-the-EU-AI-Act-Foundations-for-Governance.md — governance-foundations anchor that defines the Act’s risk-based architecture before a specialist begins scoping.
• EATF-Level-1/M1.5-Art02-The-Global-AI-Regulatory-Landscape.md — global context that locates the EU AI Act among the US, UK, China, and multilateral approaches, so scoping decisions can be framed against adjacent regimes.
• EATF-Level-1/M1.5-Art19-The-Geopolitical-Landscape-of-AI-Governance.md — geopolitical frame relevant to cross-border scope and the authorized-representative decision for non-EU providers.
• Existing regulatory-compliance article regulatory-compliance-articles.ts Article ID 253, “EU AI Act Risk Classification: A Practitioner’s Guide” — foundational context for the four-tier framework. This specialist article extends that practitioner treatment into operational scoping workflow.

Learning outcomes — confirm

A specialist who completes this article should be able to:

• Explain the four Article 2 trigger conditions and the Article 2(1)(c) long-arm reach in the specialist’s own words.
• Classify at least six described entities as provider, deployer, importer, distributor, or authorized representative, and defend each assignment with Article 3 anchors.
• Evaluate two case descriptions for whether the Article 2(8) research exception applies.
• Design a one-page scope memo for a portfolio AI system, covering all five sections above.

Quality rubric — self-assessment

Publish threshold per design doc §16.5 is 85. This article meets the threshold.