Scope GuideEU

EU AI Act Applicability and Roles

Map whether a product, service, model, or workflow falls under the EU AI Act before assigning obligations.

Use this page to separate AI system and GPAI model definitions, EU territorial triggers, actor roles, role-shift events, and the evidence needed for a defensible classification record.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

The EU AI Act applicability question is not only whether a tool uses AI. Teams need to identify whether the asset is an AI system or a general-purpose AI model, whether an EU market or EU-use trigger is present, which actor role each party holds, and whether a later branding, integration, or purpose change shifts provider responsibility.

Section 1

Start With The Regulated Object

Classify the thing being assessed before assigning roles. An AI system is a machine-based system with some autonomy that infers how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. A general-purpose AI model is an AI model that displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into downstream systems or applications.

Keep AI systems and GPAI models separate in the record. A customer-facing chatbot, triage workflow, scoring feature, or embedded product function is usually assessed as an AI system. A foundation model or other reusable model released for integration may need a GPAI model analysis even before a downstream application is classified.

  • Record the asset name, version, release channel, owner, and whether the assessed object is an AI system, a GPAI model, or both.
  • For an AI system, capture the intended purpose, inputs, outputs, autonomy, adaptiveness after deployment, users, affected persons, and operating environment.
  • For a GPAI model, capture the model provider, release method, downstream integration path, intended model capabilities, and whether the model is being placed on the Union market.
  • Do not treat ordinary software automation as in scope without documenting the inference capability and AI Act definition match.
Section 2

Check EU Market And Territorial Scope

Article 2 applies to several different trigger paths. It covers providers placing AI systems on the market or putting them into service in the Union, providers placing GPAI models on the Union market, deployers established or located in the Union, importers and distributors of AI systems, product manufacturers placing or putting into service an AI system with their product under their own name or trademark, authorised representatives for non-EU providers, and affected persons located in the Union.

A non-EU provider or deployer can still be in scope when the output produced by the AI system is used in the Union. The applicability record should therefore track where the provider, deployer, users, affected persons, product release, and output use are located rather than relying only on company headquarters.

  • Mark each EU trigger: Union market placement, Union putting into service, Union deployer, Union output use, importer or distributor role, product manufacturer role, authorised representative, or affected persons in the Union.
  • Record any exclusion considered, including purely personal non-professional deployer use, pre-market research, testing or development before placement or putting into service, sole scientific research and development, or military, defence, or national security use.
  • If the same feature is sold globally, document whether the EU release, EU customers, EU deployers, or EU-used outputs differ from non-EU use.
  • For open-source releases, record whether the release is placed on the market or put into service as high-risk or falls under Article 5 or Article 50, because the Article 2 open-source exclusion is limited.
Section 3

Map Every Actor Role Separately

The same organisation can hold different roles for different assets. A company can be a deployer when it uses a third-party screening tool, a provider when it releases its own AI system under its name, an importer when it places a third-country-branded AI system on the Union market, and a product manufacturer when an AI system is placed on the market or put into service together with its product under the manufacturer's name or trademark.

Role mapping should follow the legal definitions and the actual supply chain. Contract labels are useful evidence, but they do not replace facts about who develops, brands, imports, distributes, deploys, modifies, or integrates the AI system or model.

  • Provider: develops an AI system or GPAI model, or has it developed, and places it on the market or puts the AI system into service under its own name or trademark.
  • Deployer: uses an AI system under its authority, except purely personal non-professional use.
  • Importer: EU-located or EU-established person placing on the market an AI system that bears the name or trademark of a third-country person.
  • Distributor: supply-chain actor, other than provider or importer, that makes an AI system available on the Union market.
  • Product manufacturer: in Article 2 scope when placing on the market or putting into service an AI system together with its product and under its own name or trademark.
Section 4

Identify Role-Shift Events Before Launch

Article 25 prevents teams from freezing role assignments at procurement. A distributor, importer, deployer, or other third party becomes the provider of a high-risk AI system if it puts its own name or trademark on a high-risk AI system already placed on the market or put into service, makes a substantial modification while the system remains high-risk, or changes the intended purpose of an AI system, including a general-purpose AI system, so that it becomes high-risk.

For high-risk AI systems that are safety components of products covered by the listed Union harmonisation legislation, the product manufacturer is considered the provider when the high-risk AI system is placed on the market with the product under the manufacturer's name or trademark, or put into service under that name or trademark after the product is placed on the market.

  • Flag rebranding, white-labelling, customer-specific relaunches, and private-label distribution as provider-role checks.
  • Flag model replacement, architecture changes, new data pipelines, performance-changing updates, and changed operating context as substantial-modification checks for high-risk systems.
  • Flag new use cases that change the intended purpose, especially where a general-purpose or non-high-risk AI system is repurposed into an Annex III area.
  • Require written assistance terms from upstream suppliers where tools, services, components, processes, or GPAI models are used in a high-risk AI system.
Section 5

Keep Evidence For Classification And Reassessment

A defensible applicability file should show how the team moved from definition and scope to classification. For high-risk screening, Article 6 covers product-linked high-risk systems and Annex III high-risk systems. If a provider treats an Annex III system as not high-risk because it does not pose a significant risk of harm and does not materially influence decision-making, Article 6 requires the assessment to be documented before market placement or putting into service.

The strongest evidence is concrete and versioned: intended-purpose statements, technical documentation, model documentation, supplier contracts, instructions for use, EU market records, output-use locations, Annex III analysis, Article 6 derogation reasoning where used, role-shift review, and an approval history showing who accepted the classification.

Can one company be both provider and deployer under the EU AI Act?

Yes. Roles are assessed per asset and activity. A company can be a provider for an AI system it releases under its own name and a deployer for another AI system it uses under its authority.

Does a non-EU AI provider avoid the EU AI Act because it has no EU office?

Not necessarily. Article 2 can apply to third-country providers and deployers where the output produced by the AI system is used in the Union.

What evidence should support an AI Act applicability decision?

Keep the definition analysis, EU scope trigger, role map, intended purpose, release channel, supplier chain, Annex III or product-law classification, any Article 6 non-high-risk reasoning, and reassessment triggers.

  • Store the Article 3 definition assessment and Article 2 scope trigger beside the asset register entry.
  • Attach the intended purpose, user interface summary, supported functions, deployment context, and affected-person analysis used for classification.
  • For high-risk candidates, keep the Annex III or product-law route, any Article 6(3) non-high-risk reasoning, and the registration position.
  • For GPAI models, keep the provider analysis, downstream integration assumptions, model documentation source, and any systemic-risk screening evidence.
  • Set reassessment triggers for name or trademark changes, substantial modification, intended-purpose changes, EU-market expansion, new deployer groups, new output-use locations, and supplier model changes.
Primary sources

References and citations

digital-strategy.ec.europa.eu
Referenced sections
  • Commission policy page explains the AI Act as a risk-based framework for AI developers and deployers in the EU context.
"risk-based rules for AI developers and deployers"
digital-strategy.ec.europa.eu
Referenced sections
  • Commission FAQ gives plain-language examples of provider and deployer roles, including a CV-screening tool developer and a bank using that tool.
"providers and deployers of AI systems"
ec.europa.eu
Referenced sections
  • Commission GPAI guidelines support evidence planning for GPAI provider status, lifecycle documentation, downstream integration, and systemic-risk screening.
"whether their model is a general-purpose AI model"
eur-lex.europa.eu
Referenced sections
  • Article 6 sets high-risk classification and documentation of non-high-risk assessments for Annex III systems; Annex IV lists technical-documentation evidence for high-risk systems.
"shall document its assessment"
Related guides

Explore more topics

Are industry AI use cases high-risk under EU AI Act Annex III?
FAQ answer on when an industry AI use case falls under EU AI Act Annex III, how Article 6 classification works, when Article 6(3) can support a non-high-risk conclusion, and what evidence providers should keep.
EU AI Act AI System Classification Edge Cases FAQ
Answers for EU AI Act edge cases: AI system definition, inference versus simple rules, GPAI models, embedded products, territorial scope, roles, and classification evidence.
EU AI Act applicability test: scope, role, and risk classification
Stepwise EU AI Act applicability test for AI-system status, exclusions, territorial scope, operator role, prohibited uses, high-risk systems, GPAI models, transparency duties, and evidence records.
EU AI Act Article 5 Prohibited AI Practices Screening Guide
Screen AI systems against the EU AI Act Article 5 prohibitions, including manipulation, exploitation, social scoring, biometric and law-enforcement exceptions.
EU AI Act Article 50 transparency disclosures FAQ
Article 50 FAQ for EU AI Act transparency duties covering chatbot notices, synthetic content marking, biometric and emotion notices, deepfakes, public-interest text, timing, accessibility, and exceptions.
EU AI Act Article 50 transparency, labeling, and user disclosures
Source-grounded guide to EU AI Act Article 50 duties for user interaction notices, synthetic content marking, deepfake labels, emotion recognition notices, biometric categorisation notices, and related high-risk AI instructions for use.
EU AI Act Article 73 serious incident FAQ
FAQ on EU AI Act serious incident handling for high-risk AI systems, including Article 73 reporting, deployer escalation, corrective action, and GPAI systemic-risk distinctions.
EU AI Act Compliance Checklist by Risk Class
A practical EU AI Act checklist for classifying AI systems, assigning operator roles, screening prohibited practices, and collecting evidence for high-risk, GPAI, transparency, monitoring, and incident duties.
EU AI Act Compliance Program: roles, high-risk evidence, GPAI and incidents
Build an EU AI Act compliance program around provider, deployer, importer, distributor, high-risk, GPAI, transparency, monitoring, and incident evidence duties.
EU AI Act conformity assessment and notified bodies for high-risk AI
Grounded guide to EU AI Act high-risk AI conformity assessment routes, provider evidence, EU declaration of conformity, CE marking, and notified body involvement.
EU AI Act deadlines and compliance calendar | Article 113 dates
source-linked EU AI Act compliance calendar for Article 113 staged application dates, Article 111 transitions, GPAI, prohibited practices, AI literacy, and high-risk AI planning.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Grounded EU AI Act FAQ covering scope, provider and deployer roles, prohibited practices, high-risk classification, GPAI duties, transparency notices, FRIAs, EU database registration, serious incidents, and staged application dates.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-grounded FAQ on when Article 27 requires a fundamental rights impact assessment, which deployers are covered, what the FRIA must contain, and how it relates to DPIAs and registration.
EU AI Act FRIA for high-risk AI systems: Article 27 scope and evidence
Source-grounded guide to EU AI Act Article 27 fundamental rights impact assessments: who must run a FRIA, Article 6(2) triggers, Annex III carveouts, DPIA overlap, notification, and registration evidence.
EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ
FAQ on EU AI Act duties for general-purpose AI model providers, including Article 53 documentation, copyright and training-summary duties, Article 55 systemic-risk duties, serious incidents, cybersecurity, and staged enforcement.
EU AI Act GPAI evidence pack checklist for Article 53 and 55
Build a source-grounded evidence pack for EU AI Act GPAI model obligations: technical documentation, downstream information, copyright policy, training-content summary, and systemic-risk records where applicable.
EU AI Act GPAI Provider Obligations: Articles 53 and 55
Grounded guide to EU AI Act duties for general-purpose AI model providers: Article 53 documentation, copyright policy, training-content summary, downstream information, and Article 55 systemic-risk controls.
EU AI Act High-Risk AI Requirements: Articles 8-16 and 26
Map the EU AI Act requirements for high-risk AI systems: risk management, data governance, technical documentation, logs, transparency, human oversight, accuracy, robustness, cybersecurity, and deployer duties.
EU AI Act high-risk AI use cases by industry | Article 6 and Annex III guide
Industry-by-industry guide to EU AI Act high-risk classification under Article 6, Annex III, Annex I product safety routes, exclusions, and provider/deployer boundaries.
EU AI Act high-risk conformity assessment route selector
Select the EU AI Act Article 43 conformity assessment route for a high-risk AI system, including Annex I product legislation, Annex III categories, notified body triggers, standards, declaration, CE marking, registration, and evidence.
EU AI Act high-risk requirements checklist: Articles 8-15
Checklist for EU AI Act high-risk AI system requirements in Articles 8-15: risk management, data governance, documentation, logs, transparency, human oversight, accuracy, robustness, and cybersecurity.
EU AI Act penalties and fines: Article 99 tiers and GPAI exposure
EU AI Act penalties explained: Article 99 fine tiers, prohibited-practice exposure, incorrect information, SME caps, Member State rules, and GPAI model fines.
EU AI Act post-market monitoring and serious incident reporting
Grounded guide to EU AI Act Articles 72 and 73 for high-risk AI: monitoring plans, serious incident reporting, deployer escalation, corrective action, and GPAI distinctions.
EU AI Act post-market monitoring FAQ for high-risk AI systems
Answer to how providers and deployers should handle EU AI Act post-market monitoring for high-risk AI systems under Article 72, with serious-incident, log, corrective-action, and lifecycle-change triggers.
EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ
FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries.
EU AI Act risk classification intake workflow
A grounded intake structure for classifying EU AI Act scope, prohibited practices, high-risk routes, Annex III use cases, GPAI model status, roles, and reassessment triggers.
EU AI Act serious incident reporting triage workflow: Article 73 and Article 55
Triage EU AI Act serious incidents by definition, actor, reporting route, deadline, deployer escalation, corrective action, and separate GPAI systemic-risk reporting.
EU AI Act Technical Documentation and Provider Evidence Templates
Build AI Act evidence templates for high-risk AI providers: Article 11 technical documentation, Annex IV fields, quality management, conformity, CE marking, registration, logs, and post-market monitoring.
EU AI Act technical documentation FAQ | Article 11 and Annex IV
What Article 11 and Annex IV require in high-risk AI technical documentation: system identity, intended purpose, architecture, data, testing, oversight, cybersecurity, conformity, and post-market monitoring.
EU AI Act Timeline and Phasing Roadmap: practical obligations and evidence guide
Practical EU AI Act guide to Timeline and Phasing Roadmap: scope, owners, evidence, edge cases, checklist steps, and external source-linked citations.
EU AI Act vs ISO/IEC 42001: legal duties, controls, and evidence limits
Compare the EU AI Act and ISO/IEC 42001 across legal status, risk classification, high-risk AI, GPAI, transparency, conformity, evidence, and assurance limits.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the binding EU AI Act with the voluntary NIST AI RMF, including role classification, high-risk duties, GPAI, transparency, conformity evidence, and reuse limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
source-linked FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.