Why the scope question comes first
An organization should establish the territorial connection and legal role before applying an obligation checklist. A U.S. software vendor, a multinational operating subsidiary and a publisher using generated content may have different connections and responsibilities. A group-wide statement that "we are outside Europe" cannot substitute for analysis of those activities.
Several obligation families are already applicable, including literacy, prohibited practices, GPAI and Article 50 transparency within their scope. The later high-risk timetable is not a general exemption for overseas organizations.
Article 2 in plain language
| Connecting factor | What to examine | Limit |
|---|---|---|
| Provider brings a system to the EU market or puts it into service | Development/commissioned development, own-name offering and market or service activity | First own use can be relevant to system putting into service. |
| GPAI provider places a model on the EU market | Model identity, provider and supply/placement activity | Model placement is distinct from system putting into service. |
| Deployer is established or located in the EU | Actual operating legal entity using the system under its authority | Parent-company location does not answer subsidiary activity. |
| Third-country provider/deployer has system output used in the EU | Actual output use and the activity around it | Worldwide accessibility alone is not a settled automatic scope test in this baseline. |
| Other enumerated supply-chain actors | Import, distribution, specified product-manufacturer activity or representation | Roles have their own statutory conditions. |
The output-use rule matters because a system can operate outside the EU while its output is used inside it. It does not support a claim that every online output establishes scope everywhere. The research leaves globally accessible publication cases for factual review.
Illustrative business situations
These examples identify questions to examine. They are not legal determinations about a real company.
A U.S. vendor develops an application and offers it under its own name to EU customers. Review whether the vendor is placing the system on the EU market or putting it into service. Then test the application's purposes and functions against prohibitions, Article 50 and high-risk routes. A customer chatbot raises different questions from a system that ranks job candidates.
A multinational's EU subsidiary uses a third-party AI system under its authority. Review the subsidiary as a deployer. Do not assume the overseas parent is the only relevant organization or that the supplier's provider duties remove the deployer's duties.
A U.S. team operates a system whose output is used by an EU business unit. Examine the rule for third-country providers and deployers, the entities involved and their activities. Record how and where the output is used instead of treating the server location as the answer.
A U.S. model developer supplies a GPAI model for EU distribution. Review model placement, the provider definition and Chapter V. The model's obligations differ from the responsibilities of system builders integrating it. Third-country GPAI representation may be required, subject to the qualifying non-systemic open-source exception.
Exclusions need their own conditions
Article 2 excludes exclusively military, defence or national-security systems under its conditions. A mixed-purpose commercial offering does not automatically acquire that exclusion. Sole-purpose scientific research and certain pre-market research/testing activities also have exclusions, but real-world testing is not excluded by Article 2(8).
The personal-use exclusion concerns natural persons in purely personal, non-professional activity. It does not establish a corporate exemption for informal or employee-initiated use. The free/open-source system exclusion does not apply where a system is high-risk or covered by Articles 5 or 50. GPAI models have separate, narrower open-source exceptions.
Annex I Section B products have restricted direct application and sector integration rules. A product company needs product-specific analysis rather than a generic statement that the entire AI Act either applies or is excluded.
Role determines the next question
A provider and deployer do different things. Article 50 assigns direct-interaction disclosure and synthetic-output marking to system providers, while deepfake and qualifying public-interest-text disclosure belong to deployers. Literacy concerns both. High-risk provider design requirements and deployer operating duties are also distinct.
One company can occupy different roles for different systems or activities. Article 25 can change responsibility for specified high-risk system activities, including own-name supply or qualifying modification. Model fine-tuning is a separate analysis; the baseline does not support automatic GPAI-provider conversion from the label "fine-tuning."
Read provider vs deployer before allocating the work to a supplier or local operating team.
Representation and supplier dependencies
The Act has an authorised-representative role based on a written mandate accepted by a Union-established or located person. Article 22 concerns non-EU high-risk system providers. Article 54 addresses GPAI providers with a distinct qualifying exception. These are separate routes with separate applicability. A representative does not turn every internal corporate user into a provider.
Operationally, ask what information and technical access the relevant entity needs. A deployer may depend on provider instructions and system limits; a downstream system provider may need model documentation. Establish who can change a notice, supply technical records, investigate an output or support corrective action. These are recommended dependency questions derived from the distinct roles.
Do not treat a contract's "customer" or "technology partner" label as the completed role analysis. Record the actual development, supply, naming, use and modification facts. Agreements can support implementation arrangements; they do not replace the statutory conditions.
Dates that affect planning
| Date | Relevant branch | Qualification |
|---|---|---|
| 2 February 2025 | Original prohibitions and literacy | Within their scope; Article 4 later amended. |
| 2 August 2025 | GPAI Chapter V | Older model transition applies to models placed before that date. |
| 2 August 2026 | Article 50 general application and relevant Commission enforcement | Paragraph-specific exceptions and transitions matter. |
| 2 December 2027 | Principal Annex III high-risk requirements | Chapter III Sections 1 through 3, excluding Article 6(5), with transitions. |
| 2 August 2028 | Principal Annex I high-risk requirements | Product route and sector scope need review. |
Use the timeline for the December 2026 marking transition, older GPAI transition and limits of a single corporate deadline.
What facts a scope review needs
Ask business and technical teams to describe one actual deployment from development through use. Our recommended record is not a statutory form. It should keep confirmed facts separate from plans and connect each conclusion to supporting evidence.
| Question | Evidence that may help | Review trigger |
|---|---|---|
| Which legal entity developed, commissioned, supplied or operates the system? | Development agreements, product records and operating records. | A new entity assumes development, supply or operating responsibility. |
| Where are users located and where is output used? | Access records, workflow documentation and system routing. | A launch in a new territory or a change in where output goes. |
| Who controls the name, intended purpose and system changes? | Market materials, release records and change approvals. | Rebranding, a new purpose or a material system change. |
| Which system and model versions were assessed, and when? | Architecture records, model records and the dated assessment. | A system release, model change or supplier change. |
No one artifact answers every scope question. Record missing facts and review the evidence with counsel when the determination is consequential or disputed. A conclusion for one subsidiary or use does not automatically carry over to another.
AI Act analysis does not replace data-protection or product-law analysis. The Act preserves the specified interactions with those rules; assess their applicability separately.
FAQ
Can the Act apply without an EU headquarters?
Yes. The rules for provider market or service activity and third-country output use are not limited to EU-established headquarters. Their factual conditions still need to be met.
Does an EU subsidiary's use matter separately?
Yes. Article 2 covers EU-established or located deployers. Examine the operating entity using the system under its authority.
Is every public website automatically in scope?
The baseline does not establish that categorical rule. Article 2's statutory output-use connection is the starting point, and globally accessible publication cases remain fact-sensitive.
Does open source remove the obligations?
No blanket exemption follows. Article 2's system exclusion has Article 5/50 and high-risk limitations. GPAI documentation exceptions have their own conditions and do not remove copyright and training-summary duties.
Next step
Use the role analysis and operational readiness sequence to organize the scope facts before drawing a conclusion.
Primary sources
Use the consolidated text to navigate provisions and the authentic original and amending Official Journal acts for the legislation. Guidance and Q&A retain their separate legal status.
- Consolidated text: Regulation (EU) 2024/1689, 27 July 2026 · legislation.
- Regulation (EU) 2024/1689 of 13 June 2024 · legislation.
- Regulation (EU) 2026/1744 of 8 July 2026 · legislation.
- Commission Guidelines on the scope of obligations for providers of general-purpose AI models · final Commission guidance.