FAQEU AI Act

EU AI Act Are you the provider or the deployer?

A develops or commissions AI and supplies it under its own name. A uses an AI system under its authority. One organisation can hold both roles.

Importing, distributing, rebranding or modifying a system can bring different duties. Check each system and model separately.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 21, 2026
Overview

Your role follows what you develop, commission, supply, brand or use. Article 3 defines the roles. Article 25 can make a party the of an existing high-risk system after specified branding, modification or purpose changes. Keep a record for each system and model version, including any role changes.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

How do provider and deployer roles differ?

A develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the system into service under its own name or trademark. Development, commissioning, branding and first supply or use all matter. Writing the code alone does not decide the role.

A uses an AI system under its authority, except for purely personal, non-professional use. A company using a supplier's system can be the deployer while the supplier remains the . Check who controls the use, operating process, users, relevant input data and 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 hold both roles?

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 always only a ?

No. A purchaser using a supplier system under its authority will normally be a for that use. Article 25 can shift status if the purchaser rebrands an existing high-risk system, substantially modifies it while it remains high-risk, or changes the intended purpose of a previously non-high-risk system so that it becomes high-risk.

Question 2

What do the other supply-chain roles mean?

Operator is the umbrella term for a , product manufacturer, , authorised representative, importer or distributor. Identify the specific role before assigning duties.

An authorised representative is EU-based and has a written mandate. An importer first places on the EU market a system bearing a third-country person's name or trademark. A distributor makes a system available on the EU market and is neither its provider nor importer.

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.
Question 3

When can you become the provider of an existing system?

Article 25 has three triggers for a system already on the market or in service. A party becomes the if it puts its name or trademark on a high-risk system, substantially modifies a high-risk system while it remains high-risk, or changes a non-high-risk system's intended purpose so it becomes high-risk. The last trigger also covers general-purpose AI systems. The branding trigger preserves contractual arrangements allocating obligations differently.

The initial then ceases to be the provider of that specific system for AI Act purposes. It must cooperate closely with the new provider and supply necessary information, technical access and reasonably expected assistance. That cooperation duty does not apply where the initial provider clearly said its system must not be changed into a high-risk system.

Article 25, as amended by Regulation (EU) 2026/1744, 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.

Use contracts to agree work, access, assistance, confidentiality and liability. Under amended Article 25(4), a high-risk system and a supplier of an integrated system, model, tool, service, component or process must specify the necessary information, capabilities, technical access and assistance in writing. Publicly accessible free and open-source tools, services, processes and components are excluded from that paragraph; general-purpose AI models are not.

  • Rebranding evidence: name or trademark in the user interface, packaging, app-store listing, customer contract and public materials.
  • 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 create status?

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 rebranding obligations differently?

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 the high-risk role duties 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, except Article 6(5), 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.

Question 4

Who provides the model and who provides the system?

Keep the model separate from the provider of a system built with it. A general-purpose AI model provider does not automatically provide every downstream system. Annex XII requires model information for system builders.

Commission guidance gives three examples: developing and marketing a general-purpose model; commissioning one and marketing it; or integrating a model into a system. The first two can make the organisation the model . The third can make it the system provider.

Modifying a model does not automatically make you its . Commission guidance looks for significant changes to generality, capabilities or systemic risk and gives an indicative training-compute criterion. Keep the change evidence and apply the guidance to the actual modification.

  • Keep separate records for the general-purpose AI (GPAI) model , the system provider and the using it in a specific 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.
Question 5

What proves the role decision?

Keep a role matrix for each system and model version. Record the legal role, the facts that create it and the responsibility assigned. A single AI-owner field cannot describe a supplier relationship with several model and system roles.

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 first-use evidence: first EU availability, , brand or trademark, product bundle, app or application programming interface (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.
Primary sources

References and citations

ec.europa.eu2 citations
Referenced sections
  • Template used for practical GPAI evidence fields shared with AI Office, national competent authorities, and downstream providers.
  • Template evidence source showing information intended for AI Office, national competent authorities, and downstream providers integrating GPAI models.
"downstream providers"
More quoted passages
"information documented is intended for the AI Office"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission guidance used for GPAI model provider boundaries, placing-on-the-market examples, and downstream modifier treatment.
  • Commission guidance on who is a GPAI model provider, when models are placed on the Union market, and when downstream modifiers become providers.
"clarify the scope of the obligations"
More quoted passages
"only those making significant modifications"
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"
Show all related guides (34)

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.

Common questions, clear answers | EU AI Act

Clear answers on AI Act scope, risk categories, provider and user duties, general-purpose models, disclosures, rights, assessments and deadlines.

EU AI Act deadlines and compliance calendar

Find the AI Act deadline for your system or model. Check high-risk dates, transparency duties, older-model transitions and the evidence to prepare.

EU AI Act fundamental rights impact assessments

Check who needs an Article 27 fundamental rights impact assessment, what it must contain and how DPIA reuse, notification and registration work.

EU AI Act GPAI model evidence checklist

Collect model documentation, integration information, copyright records and training summaries. Add testing, incident and security records for systemic risk.

EU AI Act monitoring and serious incidents

Set up high-risk AI monitoring, identify serious incidents and check reporting deadlines, recipients, deployer escalation and corrective action.

EU AI Act penalties and fines

Check the AI Act fine tiers, smaller-organisation caps, GPAI provider fines and the facts authorities consider when deciding a penalty.

EU AI Act serious incident reporting steps

Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Classify a tool before approval

Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.

EU AI Act: Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.