FAQEU AI Act

EU AI Act Provider and Deployer Role Boundaries

Article 3 starts the role split: a provider develops, has developed, places on the market, or puts into service an AI system or GPAI model under its name or trademark; a deployer uses an AI system under its authority.

Article 25 can shift provider status to a distributor, importer, deployer, or other third party when branding, substantial modification, or a changed intended purpose turns the system into a high-risk AI system.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
5

Structured answer sets in this page tree.

Primary sources
9

Cited legal and guidance references.

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

This FAQ helps classify whether an actor is a , , importer, distributor, authorised representative, product manufacturer, or another operator before assigning EU AI Act obligations. Article 3 role definitions apply independently of Article 25's high-risk role-shift rule. Regulation (EU) 2026/1744, published on 24 July 2026 and entering into force on 27 July 2026, moves Chapter III Section 3 duties to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

What is the core provider-versus-deployer test under Article 3 of the EU AI Act?

A is the actor that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark. That test is about development control, commissioning, market placement, service launch, and branding, not only technical authorship.

A is the actor using an AI system under its authority, except for personal non-professional use. A company can therefore be a deployer of a supplier system even when the supplier remains the , because the company controls the concrete use context, users, operating process, input data under its control, and internal oversight.

  • Treat name, trademark, market-placement records, commissioning contracts, technical documentation, and launch materials as evidence.
  • Treat business-process ownership, user instructions, access controls, input-data procedures, monitoring records, and logs under the organisation's control as evidence.
  • Do not use 'owner' as a substitute role. The AI Act uses defined actors such as , , importer, distributor, authorised representative, product manufacturer, and operator.
  • Classify each system and model separately. A party can be the of one AI system, the of a modified high-risk system, and a downstream provider integrating a GPAI model in another product.

Can one organisation be both and under the EU AI Act?

Yes. Article 3 definitions do not make the roles mutually exclusive. For example, an organisation that develops and puts an AI system into service under its own name can be the , while the same organisation also uses that system internally under its authority as . The evidence should identify which obligations are being met in which capacity.

Is a purchaser automatically only a under the EU AI Act?

No. A purchaser that simply uses a supplier's AI system under its authority is normally analysed as a for that use, but Article 25 can make a deployer the of a high-risk AI system if it rebrands the system, substantially modifies it, or changes the intended purpose so that the system becomes high-risk.

Citations
Question 2

How do importer, distributor, authorised representative, product manufacturer, and operator roles fit around provider and deployer roles?

The AI Act uses 'operator' as an umbrella term that includes , product manufacturer, , authorised representative, importer, and distributor. It is useful for scoping the full value chain, but it is not enough for assigning concrete duties because the named roles have different triggers.

An authorised representative is a Union-based person with a written mandate from a to carry out obligations and procedures on the provider's behalf. An importer places on the Union market an AI system bearing the name or trademark of a third-country person. A distributor is a supply-chain actor, other than provider or importer, that makes an AI system available on the Union market.

A product manufacturer is treated as the of a high-risk AI system that is a safety component of a product covered by the Union harmonisation legislation in Section A of Annex I when the system is placed on the market together with the product under the manufacturer's name or trademark, or is put into service under that name or trademark after the product has been placed on the market.

  • For authorised representatives, keep the written mandate and the identity; the mandate does not erase the provider role.
  • For importers, keep evidence of the third-country name or trademark on the AI system and the first Union market placement route.
  • For distributors, keep supply-chain records showing the system was made available without the distributor being the or importer.
  • For product manufacturers, keep the product-law file showing whether the AI system is a safety component and whether it is placed on the market together with the product under the manufacturer's name or trademark, or put into service under that name or trademark after the product has been placed on the market.
  • For operators, map every concrete actor to one of the named Article 3 roles before assigning obligations.
Citations
Question 3

When does Article 25 shift a deployer or other third party into provider status?

Article 25 is the role-shift rule for high-risk AI systems. A distributor, importer, , or other third party is treated as the , and is subject to provider obligations, when one of three triggers is met: it puts its name or trademark on an already placed or put-into-service high-risk AI system; it makes a to an already placed or put-into-service high-risk AI system so that it remains high-risk; or it changes the intended purpose of an already placed or put-into-service AI system, including a GPAI system, so that the system becomes high-risk.

When an Article 25 shift occurs, the initial is no longer considered the provider of that specific AI system for AI Act purposes, but must closely cooperate with the new provider and provide necessary information, technical access, and other reasonably expected assistance. That cooperation rule does not apply where the initial provider clearly specified that its AI system must not be changed into a high-risk system.

From 27 July 2026, amended Article 25 specifies that this cooperation includes, where relevant, technical documentation sufficient to assess Article 16 compliance, known limitations and failure modes, and targeted technical access for testing and validation.

A contract can allocate work, access, indemnities, and cooperation, but it does not erase a statutory role created by the facts. Amended Article 25(4) also requires the high-risk system and a third party supplying an integrated AI system, model, tool, service, component, or process to specify the needed information, capabilities, technical access, and assistance in a written agreement. The paragraph excludes publicly accessible free and open-source tools, services, processes, or components other than general-purpose AI models.

  • Rebranding evidence: trademark, UI branding, packaging, app-store listing, customer contract, and public materials showing whose name is attached to the high-risk AI system.
  • Substantial-modification evidence: change request, architecture or operating-system change, model or software change, conformity-impact analysis, and whether the modification was foreseen in the initial conformity assessment.
  • Intended-purpose evidence: original instructions for use, technical documentation, sales materials, new use case, deployment context, and why the changed use brings the system within Article 6 high-risk classification.
  • Cooperation evidence: information requests to the initial , technical-access records, assistance received, refusals or limitations, and trade-secret handling.
  • Written-agreement evidence: supplied component or model, required information and capabilities, testing or validation access, assistance, delivery timing, confidentiality controls, and the basis for any free and open-source exception.

Does every configuration change make a the under Article 25 of the EU AI Act?

No. Article 25 is triggered by the listed circumstances, including a of a high-risk AI system or a changed intended purpose that makes a system high-risk. Article 3 defines substantial modification as a post-market or post-service change not foreseen or planned in the initial conformity assessment that affects compliance with high-risk requirements or modifies the assessed intended purpose.

Can contracts allocate AI Act obligations differently after an Article 25 rebranding trigger?

Article 25 says the name-or-trademark trigger applies without prejudice to contractual arrangements stipulating that obligations are otherwise allocated. The public role classification should still record who put the name or trademark on the system and what the contract actually allocates.

When do Article 25 and Article 26 high-risk role duties start to apply?

Regulation (EU) 2026/1744, published on 24 July 2026 and entering into force on 27 July 2026, moves Chapter III Sections 1 to 3 to 2 December 2027 for Article 6(2) Annex III systems and 2 August 2028 for Article 6(1) Annex I systems. The Article 3 definitions of , , importer, distributor, and operator are part of Chapter I and already apply; the later dates govern the high-risk duties and role shifts in Chapter III.

Citations
Regulation (EU) 2024/1689 - Article 3 and Article 25

Defines substantial modification and supports the Article 25 role-shift triggers: rebranding, substantial modification, changed intended purpose, cooperation by the initial provider, and product-manufacturer treatment.

Question 4

How should teams classify GPAI model providers, AI system providers, and downstream providers?

A GPAI model is not automatically the provider of every AI system that later integrates the model. The legal text defines a general-purpose AI model separately, and Annex XII requires transparency information for downstream providers that integrate the model into their AI systems.

Commission GPAI guidance gives practical examples: the actor that develops and places a GPAI model on the Union market is the ; an actor that has a model developed on its behalf and places it on the market is the provider; and a downstream actor integrating a GPAI model into an AI system may be the provider of that AI system.

For downstream modifications, the Commission guidance says not every modification makes the modifier a GPAI model . The modifier becomes the provider of the modified GPAI model only where the modification leads to a significant change in the model's generality, capabilities, or systemic risk, with the guidance giving an indicative training-compute criterion for that assessment.

  • Keep separate records for the GPAI model , the AI system provider, and the that uses the system in a concrete process.
  • Ask for downstream- information listed in Annex XII, including model tasks, integration types, acceptable-use policies, release and distribution methods, licence, input and output modalities, and technical means for integration.
  • If a team fine-tunes or otherwise modifies a GPAI model, record who controlled the modification, what changed, the additional training data or compute evidence available, and whether the change affects generality, capabilities, or systemic risk.
  • If the GPAI model is integrated into a high-risk AI system, preserve the chain from model documentation to system technical documentation, instructions for use, human oversight, monitoring, and conformity evidence.
Citations
Question 5

What evidence should prove a provider/deployer boundary decision?

The evidence should prove the legal role, the factual trigger, and the boundary of responsibility. Avoid one generic AI owner record. Instead, keep a role matrix for each AI system and GPAI model version, because the same supplier relationship can involve several actors at different layers of the value chain.

For duties, preserve records showing use according to instructions, human oversight assignment, monitoring based on instructions for use, incident escalation to /importer/distributor and authorities where relevant, logs under deployer control, worker information where workplace use is involved, and any required fundamental-rights impact assessment for covered high-risk deployments.

  • Role matrix: , , importer, distributor, authorised representative, product manufacturer, GPAI model provider, AI system provider, and downstream provider for each model or system version.
  • Market and service evidence: first Union market availability, , brand or trademark, product bundle, app or API release, and customer-facing materials.
  • Intended-purpose evidence: instructions, technical documentation, sales materials, deployment use case, affected user groups, and any changed purpose assessment.
  • Change evidence: modification description, whether the change was foreseen in the initial conformity assessment, impact on high-risk requirements, new conformity-assessment need, and cooperation records.
  • GPAI integration evidence: Annex XII-style downstream information, model dependencies, distribution channel, licence, integration means, acceptable-use policy, and modification or fine-tuning record.
  • operation evidence: oversight assignment, input-data controls, monitoring notes, log-retention rationale, worker or affected-person notices where applicable, and escalation records.
Citations
Regulation (EU) 2024/1689 - Articles 26 and 27

Supports deployer operational evidence and FRIA evidence for covered high-risk deployments, including instructions, oversight, monitoring, logs, notices, affected groups, risk, and mitigation information.

Primary sources

References and citations

ec.europa.eu
Referenced sections
  • Template evidence source showing information intended for AI Office, national competent authorities, and downstream providers integrating GPAI models.
"information documented is intended for the AI Office"
eur-lex.europa.eu
Referenced sections
  • Defines substantial modification and supports the Article 25 role-shift triggers: rebranding, substantial modification, changed intended purpose, cooperation by the initial provider, and product-manufacturer treatment.
"shall be considered to be a provider"
eur-lex.europa.eu
Referenced sections
  • Defines provider, deployer, authorised representative, importer, distributor, operator, placing on the market, putting into service, intended purpose, substantial modification, and GPAI model.
"‘provider’ means a natural or legal person"
eur-lex.europa.eu
Referenced sections
  • Supports deployer operational evidence and FRIA evidence for covered high-risk deployments, including instructions, oversight, monitoring, logs, notices, affected groups, risk, and mitigation information.
"Deployers shall monitor the operation"
eur-lex.europa.eu
Referenced sections
  • Primary legal text for Article 3 role definitions, Article 25 value-chain responsibility shifts, Article 26 deployer obligations, Article 27 impact-assessment evidence, and Annex XII GPAI downstream-provider information.
"laying down harmonised rules on artificial intelligence"
eur-lex.europa.eu
Referenced sections
  • Binding amendment published on 24 July 2026, entering into force on 27 July 2026, which specifies Article 25 cooperation evidence and written agreements and moves the Chapter III role duties to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
"informing the new providers about known limitations and failure modes"
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 and Roles: Scope, Actor Map, and Evidence
Determine whether the EU AI Act applies to an AI system or GPAI model, map provider, deployer, importer, distributor, and product manufacturer roles, and record evidence for classification.
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 EU AI Act Article 5, including manipulation, social scoring, biometrics, law enforcement, and the new prohibited-content category.
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-backed 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
Source-backed 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
EU AI Act compliance calendar for Regulation (EU) 2026/1744, Article 113 dates, Article 111 transitions, GPAI enforcement, Article 50, and high-risk systems.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Source-backed EU AI Act FAQ covering scope, roles, risk classification, GPAI, transparency, AI literacy, rights and complaints, sandboxes, authorities, SME provisions, and current legal status.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-backed 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-backed 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-backed 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
Source-backed 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
Source-backed 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 risk classification intake workflow
A source-based 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 Roadmap: Dates, Legal Status, Owners, and Evidence
Turn EU AI Act milestones into an implementation roadmap by separating enacted dates, political agreements, draft guidance, consultations, and voluntary codes, then assigning actions and evidence.
EU AI Act vs ISO/IEC 42001: legal duties, controls, and evidence limits
Compare the EU AI Act and ISO/IEC 42001:2023, including legal status, Article 17 quality management, high-risk duties, GPAI, evidence reuse, and assurance limits.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the EU AI Act with NIST AI RMF 1.0 across legal status, GOVERN-MAP-MEASURE-MANAGE, high-risk duties, GPAI, evidence reuse, and revision limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
cited FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.