The EU AI Act assigns duties to actors, not simply to products. Before asking whether an AI system is high-risk or subject to transparency rules, an organization must determine what role it has in the relevant value chain.
The most common roles are provider and deployer, but the Regulation also defines importers, distributors, product manufacturers, authorized representatives and providers of general-purpose AI models. One legal entity can hold several roles at once, and the role can change after rebranding, substantial modification or a new intended purpose.
A retailer using a third-party chatbot can be a deployer. If it puts a white-labeled version on the market under its own trademark, it may be a provider. If it imports a non-EU system, it may also be an importer. If it fine-tunes a general-purpose model significantly and makes the modified model available, a separate GPAI-provider analysis may be needed.
For the law’s complete structure, start with our EU AI Act guide. For classification after the roles are mapped, use the EU AI Act risk-categories guide.
AI Act roles at a glance
| Role | Core idea | Typical example |
| Provider of an AI system | Develops or has a system developed and markets or puts it into service under its own name or trademark | SaaS company selling an AI recruitment tool |
| Deployer | Uses an AI system under its authority for professional activity | Employer using a vendor’s CV-ranking system |
| Importer | EU-established party placing a third-country provider’s system on the EU market | European reseller importing a US-branded AI device |
| Distributor | Makes an AI system available in the EU supply chain without being provider or importer | Marketplace or reseller distributing a third-party system |
| Product manufacturer | Places a regulated product on the market with an AI system under its name or trademark | Medical-device manufacturer integrating AI diagnostics |
| Authorized representative | EU-established person mandated in writing to perform specified provider duties | EU representative for a non-EU AI provider |
| GPAI model provider | Develops or has a general-purpose AI model developed and places it on the market under its name or trademark | Company releasing a foundation model or model API |
| Affected person | Individual subject to or otherwise affected by an AI system | Applicant evaluated by an AI-assisted hiring process |
“Operator” is an umbrella term covering provider, product manufacturer, deployer, authorized representative, importer and distributor. It does not mean those actors have identical obligations.
Why the role analysis comes first
The same technology can create different responsibilities along the chain.
Consider a general-purpose model used in a recruitment application:
- The model developer may be a GPAI model provider under Chapter V.
- The company building the recruitment application may be an AI system provider.
- A European entity bringing a non-EU system to market may be an importer.
- A reseller may be a distributor.
- The employer using the application may be a deployer.
- If the employer changes the intended purpose or substantially modifies the high-risk system, it may become a provider.
- Job candidates are affected persons, although that is not an operator role.
The obligations follow these relationships. A vendor cannot allocate every statutory duty to its customer by contract, and a customer cannot assume the vendor is responsible for how the system is actually used.
Who is a provider?
A provider is a natural or legal person, public authority, agency or other body 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, whether for payment or free of charge.
This definition contains several important concepts.
You can be a provider without writing the code
A business that commissions a contractor to build an AI system and launches it under the business’s own brand can be the provider. Outsourcing development does not outsource the legal role.
Internal use can still create a provider role
“Putting into service” covers first use of an AI system in the EU for its intended purpose. A company that develops a system for its own operations can therefore be a provider as well as its deployer.
Free distribution can still count
The definition does not require a sale. Open access, free trials or no-charge deployment can still constitute market placement or service.
Branding matters, but substance matters too
Putting a system on the market under your own name or trademark is a strong provider signal. Contract language calling you “customer” or “integrator” does not control the legal analysis if your actual activity fits the definition.
Who is a deployer?
A deployer is a person or organization using an AI system under its authority, except where the system is used in the course of personal, non-professional activity.
Typical deployers include:
- an employer using an AI scheduling or recruitment tool;
- a bank using fraud detection or credit assessment;
- a hospital using clinical decision support;
- a municipality using an AI assistant;
- a retailer running a customer-service chatbot;
- and a newsroom using generative AI in editorial workflows.
The term replaced “user” in earlier legislative drafts because ordinary consumers and professional operators are not the same. A person chatting with a website bot can be the recipient of the interaction, while the company operating the bot is its deployer.
Deployers control the deployment context. Their duties can include using systems according to instructions, assigning human oversight, monitoring operation, maintaining logs under their control, informing workers or affected persons, conducting a fundamental-rights impact assessment in defined cases and meeting Article 50 disclosures.
| Question | Provider | Deployer |
| Who defines and markets the system? | Usually the provider | Usually relies on provider’s system and instructions |
| Who controls the local use case? | May define intended purpose | Chooses and operates the deployment in its process |
| Who designs compliance into the product? | Provider | Verifies local controls and use |
| Who supplies instructions and documentation? | Provider | Must understand and follow relevant instructions |
| Who monitors real-world use? | Provider through post-market processes | Deployer in its operational context |
| Who can be both? | An internal developer using its own system | The same organization may be provider and deployer |
The boundary is not “seller versus buyer.” It is the legal function performed for the specific system or model.
Importers and distributors
Importer
An importer is established or located in the EU and places an AI system on the market that bears the name or trademark of a person established outside the EU.
For high-risk systems, an importer must perform defined checks before market placement, including whether the provider completed the conformity assessment, prepared required documentation and appointed an authorized representative. It must also identify itself and cooperate with authorities.
Distributor
A distributor is a person in the supply chain—other than the provider or importer—that makes an AI system available on the EU market.
A high-risk distributor must check relevant conformity indicators and documentation, avoid making a system available where it has reason to consider it non-compliant, and cooperate on corrective action.
Importers and distributors are not passive logistics labels. The Act gives them gatekeeping responsibilities, particularly for high-risk systems.
Product manufacturers
A product manufacturer can be treated as the provider of a high-risk AI system when it places an AI system on the market or puts it into service together with its product under the manufacturer’s name or trademark.
This is particularly important for the Annex I product route. AI can be a safety component of, or itself constitute, a product covered by EU harmonization legislation. Examples can include medical devices, machinery, vehicles, toys, lifts or aviation products, depending on the exact legal framework and conformity route.
Product teams should map:
- the manufacturer of record;
- the AI-system developer;
- the component supplier;
- the sectoral conformity-assessment body;
- the technical-documentation owner;
- and the party responsible for post-market monitoring.
The high-risk AI systems guide explains the Annex I and Annex III routes separately.
Authorized representatives
A provider established outside the EU may need an authorized representative in the Union. The representative accepts a written mandate to carry out specified obligations and procedures on the provider’s behalf.
The mandate should cover matters such as:
- verifying required documentation and conformity materials;
- retaining documents for authorities;
- cooperating with competent authorities;
- providing requested information;
- and terminating the mandate where the provider acts contrary to its obligations, subject to the Act’s requirements.
An authorized representative is not a paper address that eliminates the provider’s responsibility. The provider remains responsible for compliance.
GPAI model providers are a distinct layer
The provider of a general-purpose AI model is not automatically the provider of every downstream AI system built with it.
Chapter V operates at model level. A GPAI provider can have duties concerning:
- technical documentation;
- information for downstream system providers;
- copyright policy;
- public training-content summaries;
- systemic-risk evaluation and mitigation;
- serious-incident reporting;
- and model cybersecurity.
A downstream company may simultaneously be:
- a deployer of the upstream model service;
- provider of an application built on the model;
- and, after significant model modification, provider of a modified GPAI model.
Our GPAI guide explains the thresholds, open-source treatment and model-modification rules.
When does a role change?
Role analysis must be repeated after commercial and technical changes. Article 25 is particularly important for high-risk AI systems.
A distributor, importer, deployer or other third party can become the provider of a high-risk system when it:
- puts its name or trademark on a system already placed on the market or put into service;
- makes a substantial modification to the system;
- or changes the intended purpose of a system that was not classified as high-risk in a way that makes it high-risk.
The original provider’s duties do not simply vanish. The value chain must cooperate and provide information, technical access and assistance under the applicable rules, while protecting intellectual-property rights and trade secrets.
Rebranding
A white-label arrangement can shift the provider role. Ask whose name or trademark appears on the system and who presents itself as responsible for it.
Substantial modification
A substantial modification is a change after market placement or service that was not foreseen or planned in the initial conformity assessment and affects compliance or the intended purpose.
Not every patch or configuration change is substantial. Relevant changes can include:
- replacing the underlying model;
- retraining or fine-tuning that changes performance or risk;
- removing a safety control;
- changing the decision threshold;
- adding new affected groups;
- or materially expanding autonomy.
Changed intended purpose
A general document-classification tool may be low-risk in one context. If a customer repurposes it to rank job applicants, the new employment purpose can trigger Annex III analysis and potentially a provider role.
Does using an API make you a provider?
Not automatically.
A company calling a third-party model API is often a deployer of the API service and may be the provider of the downstream application it builds. The answer depends on:
- what product or system is being placed on the market;
- whose name or trademark it carries;
- who defines its intended purpose;
- how much integration and control the company has;
- and whether the company materially modifies the model or system.
An API contract should not be treated as the role analysis. Architecture, branding, marketing, documentation and actual use all matter.
SaaS, white-label and open-source examples
| Scenario | Likely starting analysis | Questions that can change it |
| Company uses an off-the-shelf writing assistant internally | Deployer | Did it build a branded internal system or materially modify the service? |
| Vendor sells a recruitment SaaS platform | System provider | Is a third-party model provider also involved? Is the use high-risk? |
| Customer puts vendor tool under customer’s own brand | Potential provider after rebranding | Who controls documentation, conformity and updates? |
| EU reseller imports a non-EU AI device | Importer, possibly distributor | Whose trademark is on the product? Is the AI high-risk? |
| Developer releases model weights under an open license | Potential GPAI model provider | Does the model meet GPAI criteria? Do open-source exemptions apply? |
| Startup fine-tunes a foundation model and sells an API | Possible provider of downstream system and modified model | Is the modification significant under Commission guidance? |
| Employer changes a scheduling tool into worker-performance scoring | Deployer may become provider of high-risk system | Does the new purpose fall in Annex III? |
| Manufacturer embeds AI into a medical device | Product manufacturer and potentially high-risk system provider | What sectoral conformity assessment applies? |
These are starting points, not automatic conclusions.
Territorial scope: non-EU companies can be covered
Article 2 gives the Act extraterritorial reach in defined situations. It applies to, among others:
- providers placing AI systems or GPAI models on the EU market, regardless of where the provider is established;
- deployers located or established in the EU;
- and providers or deployers outside the EU where the output produced by the system is used in the EU.
It also covers importers, distributors and product manufacturers in the situations specified by the Regulation.
A non-EU company should therefore test more than whether it has an EU office. Questions include:
- Is the system offered to EU customers?
- Is a model made available in the EU?
- Is output used in an EU business process?
- Is an EU representative required?
- Which legal entity controls the deployment?
The output-use rule is not unlimited; the precise facts and exclusions matter. Document the territorial reasoning rather than relying on a website geoblock or contract choice-of-law clause.
Exclusions and special cases
The Act contains exclusions and tailored rules, including for certain military, defense and national-security uses; specified research and development; purely personal non-professional use; and some free and open-source activity. These are not blanket exemptions for an organization or sector.
A research project can move into scope when an AI system or model is placed on the market or put into service. Open-source licensing does not excuse prohibited practices or systemic-risk duties. A defense contractor can have commercial systems outside the defense exclusion.
Analyze the object, purpose, actor and lifecycle stage.
What each role should collect
Providers
- intended-purpose statement;
- system and model architecture;
- risk classification;
- technical documentation;
- instructions for use;
- quality and risk-management evidence;
- conformity-assessment materials where applicable;
- post-market monitoring plan;
- incident and corrective-action process;
- and value-chain agreements.
Deployers
- approved-use description;
- local configuration and input-data controls;
- provider instructions and limitations;
- human-oversight assignment;
- monitoring and logs under the deployer’s control;
- worker and affected-person notices;
- Article 50 disclosures;
- fundamental-rights impact assessment where required;
- and escalation procedures.
Importers and distributors
- provider identity and EU representation;
- conformity and CE evidence where required;
- instructions and documentation;
- storage and transport controls where relevant;
- non-compliance and complaint procedures;
- and authority-cooperation records.
GPAI model providers
- model-development and market-placement record;
- technical documentation;
- downstream information;
- copyright policy;
- training-content summary;
- systemic-risk assessment where applicable;
- serious-incident reporting process;
- and AI Office submissions.
Contract clauses that support role allocation
Contracts cannot rewrite statutory roles, but they can make compliance possible. Useful provisions address:
- each party’s assumed role and the facts supporting it;
- intended purpose and prohibited uses;
- model and system versions;
- documentation and information delivery;
- audit and regulator-access support;
- change and deprecation notices;
- substantial-modification governance;
- data and logging responsibilities;
- human-oversight requirements;
- performance and limitation information;
- incidents and reporting timelines;
- corrective action and recall;
- intellectual-property and trade-secret safeguards;
- subcontractors and upstream models;
- and termination or migration support.
Avoid clauses that merely say “customer is responsible for all AI Act compliance.” A provider still needs to fulfill non-transferable duties, and the deployer needs enough information to perform its own.
A practical role-assessment worksheet
For each AI system or model, record:
- Object: Is this a model, system, component or regulated product?
- Developer: Who created it, and for whom?
- Name: Under whose name or trademark is it offered or used?
- Market event: Who places it on the EU market or puts it into service?
- Operational control: Who uses it under its authority?
- Import chain: Is a non-EU provider involved, and who first places it in the EU?
- Distribution: Who makes it available downstream?
- Product integration: Is it part of a regulated product?
- Modification: Who fine-tunes, reconfigures or changes the intended purpose?
- GPAI layer: Who provides the underlying general-purpose model?
- Territorial link: Why does the Act apply?
- Evidence: Which contracts, product pages, architecture records and instructions support the conclusion?
Add a review trigger for branding, model, purpose, ownership or deployment changes.
Common role mistakes
Calling every vendor the provider of the customer’s use
The vendor may provide the system, but the customer is usually responsible as deployer for its local operation and decisions.
Assuming the buyer is only a deployer
White-labeling, substantial modification or changed intended purpose can create a provider role.
Ignoring the model layer
A model provider and downstream system provider can be different parties with different obligations.
Using contract labels as the legal answer
The Regulation looks at functions and facts. Contracts are evidence and allocation tools, not magic words.
Forgetting internal systems
An organization that develops a system for its own use can be both provider and deployer.
Treating open source as a universal exemption
Open-source treatment is conditional and does not remove every AI Act obligation.
Frequently asked questions
What is the difference between an AI provider and deployer?
The provider develops or has the system developed and places it on the market or puts it into service under its own name or trademark. The deployer uses the system under its authority for professional activity.
Can one company be both provider and deployer?
Yes. A company can develop an internal system and then use it, or provide one system while deploying several third-party tools.
Is a company using ChatGPT a deployer?
Professional use under the company’s authority can make it a deployer of the relevant AI system. The exact service, configuration and entity should be recorded.
Does fine-tuning make a company a provider?
It can. The answer depends on whether the company places a modified model or system on the market, whether the modification is significant or substantial, and whose name and intended purpose apply.
Is a reseller a distributor?
Often, but an EU reseller that first places a third-country provider’s system on the EU market may be an importer. Rebranding can create a provider role.
Does a provider remain responsible after sale?
Yes. Providers can have lifecycle duties including post-market monitoring, incident reporting, corrective action and cooperation.
Can a contract make the customer the provider?
A contract can allocate tasks, but the legal role depends on the facts and statutory definitions. It cannot erase duties imposed on the actual provider.
Are consumers deployers?
Personal, non-professional use is excluded from the deployer definition. The business operating the system may still be provider or deployer.
Does the AI Act apply to US companies?
It can, including where they place systems or GPAI models on the EU market or where system output is used in the EU under Article 2’s conditions.
Who should approve the role map?
The product or process owner, technical owner, legal/compliance, procurement and relevant risk functions should agree on a documented conclusion. High-risk and GPAI cases may require specialized advice.
Bottom line
AI Act compliance begins with a value-chain map. Identify the model, system, product, brand, market event, operational user, import route and every material modification.
Do not freeze the result at procurement. Roles can change when a system is rebranded, fine-tuned, substantially modified or repurposed—and those changes can move the most demanding provider obligations to a party that began as an ordinary customer.
byDavid Porter
Popular news
Senator Josh Hawley Launches Massive Investigation Into OpenAI After Critical Hugging Face Breach
Anthropic Researchers Warn Advanced AI Models Could Trigger Human Extinction
Andy Burnham Faces Urgent Demands to Block Artificial Superintelligence in Manchester
UK Computer Science Graduates Face a Massive Job Market Shift Driven by AI
Anthropic Researchers Issue Urgent Warning Regarding Elon Musk and Global AI Safety Risks
OpenAI Board Member Paul Christiano Warns AI Control Could Be Lost Forever
Latest comments
Loading