# EU AI Act roles: Provider, deployer, importer – Who owes what?

> Under the EU AI Act, a provider develops and places an AI system on the market; a deployer uses a high-risk system in a professional context; an importer brings a non-EU system into the EU market. Each role carries a distinct set of legal obligations under Regulation (EU) 2024/1689.

**Author:** Maarten Stolk  
**Last reviewed:** 31 July 2026  
**Source:** https://deeploy.ai/eu-ai-act-hub/articles/eu-ai-act-roles-provider-deployer-importer/

The EU AI Act does not impose a single set of rules on everyone who touches an AI system. Instead, it assigns obligations based on role, and the role that applies to your organisation depends on what you actually do with the system, not merely what you call yourself.

Three roles matter most for the majority of organisations: provider, deployer, and importer. Providers develop AI systems and bear the heaviest compliance burden. Deployers use AI systems in a professional context and carry a meaningful but narrower set of obligations. Importers bring non-EU systems onto the EU market and sit between the two.

Getting the role wrong has practical consequences. An organisation that treats itself as a deployer when it has actually become a provider may be building the wrong documentation, running the wrong assessments, and missing obligations that could attract fines of up to €15 million or 3% of global annual turnover for high-risk violations.

This page sets out what each role means, which obligations attach to it, and how to determine which role(s) apply to your organisation.

## How the EU AI Act defines each role

The Act defines roles under Article 3 and elaborates obligations across [Chapter III (high-risk AI systems)](https://deeploy.ai/eu-ai-act-hub/articles/high-risk-ai-systems-annex-iii-list/) and Chapter V (GPAI models). Six operator categories exist in total: providers, deployers, authorised representatives, importers, distributors, and product manufacturers.

For most organisations, three are immediately relevant; provider, deployer and importer.

### Provider

A provider is any natural or legal person, public authority, agency, or other body that develops an AI system (or has one developed) and places it on the market or puts it into service under their own name or trademark.

That includes commercial sale, licensing, API access, or internal deployment at scale.

**What determines provider status:**

- You developed the AI system, or commissioned its development
- You place it on the market under your own name or brand
- The system is used within the EU, regardless of where you are based

Geography is not a defence. A company headquartered outside the EU is a provider if its AI system's outputs reach EU users.

**Provider obligations for high-risk AI systems (Article 16):**

- Establish and maintain a quality management system (Article 17)
- Prepare technical documentation per Annex IV before market placement
- Implement a data governance and management framework (Article 10)
- Design the system with appropriate human oversight measures (Article 14)
- Ensure accuracy, robustness, and cybersecurity requirements are met (Article 15)
- Register the system in the EU database (Article 49)
- Affix CE marking and issue an EU declaration of conformity (Articles 47, 48)
- [Complete a conformity assessment](https://deeploy.ai/eu-ai-act-hub/articles/eu-ai-act-conformity-self-assessment-vs-notified-body-review-explained/); either self-assessment or via a notified body (Article 43)
- Establish a [post-market monitoring plan](https://deeploy.ai/eu-ai-act-hub/topics/post-market-monitoring/) (Article 72)
- Report serious incidents and malfunctions to national authorities (Article 73)
- Cooperate with market surveillance authorities (Article 21)

This is the heaviest obligation set in the Act. Providers of general-purpose AI (GPAI) models face additional requirements under Chapter V, including technical documentation, copyright compliance policies, and (for models with systemic risk) adversarial testing and incident reporting obligations.

### Deployer

A deployer (referred to as a "user" in the original legislative text, though "deployer" has become the standard practical term) is any natural or legal person, public authority, agency, or body that uses an AI system under their own authority in a professional context.

The key phrase is "under their own authority." A deployer makes the decision to use the system, selects how and where it is applied, and determines the context in which it operates. End users who interact with a system as members of the public (customers using a chatbot, for example) are not deployers under the EU AI Act.

**What determines deployer status:**

- You use an AI system in a professional context
- You apply it under your own authority; you choose to deploy it
- You are not a natural person acting in a purely personal capacity

**Deployer obligations for high-risk AI systems (Articles 26, 29):**

- Use the system only in accordance with the provider's instructions for use
- Assign human oversight to competent, trained individuals with actual authority to intervene (Article 26(2))
- Monitor the system's operation for risks not anticipated by the provider (Article 26(5))
- Ensure input data is relevant and sufficiently representative where you control it (Article 26(4))
- Conduct a Fundamental Rights Impact Assessment (FRIA) before first deployment, where required (Article 27)
- Suspend or interrupt the system if a serious risk is identified
- Notify the provider and relevant authorities of serious incidents (Article 73(4))
- Maintain logs of operation where the system generates them automatically (Article 26(6))
- Inform workers where AI systems affect them (Article 26(7))
- Cooperate with market surveillance authorities (Article 26(12))

**What deployers are not required to do:** Deployers are not responsible for conformity assessments, CE marking, or technical documentation; those belong to the provider. Deployers rely on the provider's instructions for use, and if those instructions are inadequate, the obligation to notify the provider and potentially suspend use applies.

### Importer

An importer is any natural or legal person established in the EU that places a high-risk AI system on the EU market where that system bears the name or trademark of a person established outside the EU.

In practice, this role exists to ensure that AI systems developed in third countries (the United States, the United Kingdom, Canada, or elsewhere) have an EU-based actor who can be held accountable under the regulation.

**Importer obligations for high-risk AI systems (Article 23):**

- Verify the system has the required CE marking and declaration of conformity before placing it on the market
- Verify the provider has completed the required conformity assessment
- Ensure the provider's technical documentation and instructions for use are available and adequate
- Ensure contact details are affixed to the system or its packaging
- Keep a copy of the declaration of conformity for ten years from market placement
- Take appropriate action (including withdrawal from the market) if the system poses serious risk
- Cooperate with market surveillance authorities

Importers must not place a system on the market if they have reason to believe it does not conform to the regulation's requirements. Acting on the provider's word alone, without checking the conformity documentation, does not relieve an importer of liability.

## When roles shift: Article 25 and the provider trigger

One of the most practically important (and most overlooked) provisions in the Act is Article 25. It states that any deployer, distributor, importer, or other third party automatically becomes a provider of a high-risk AI system, and assumes all provider obligations, in any of three circumstances:

- **They put their name or trademark on the system.** If you take a third-party AI system and rebrand it as your own product, you become the provider.
- **They make a substantial modification.** If you make changes to a high-risk AI system that are significant enough to alter its risk profile or change how it meets the conformity requirements, the modified system is treated as a new system placed on the market, and you are now its provider.
- **They change the intended purpose to create a high-risk system.** If you take an AI system not originally classified as high-risk and deploy it in a way that makes it high-risk (say, repurposing a general-purpose tool for CV screening), you become the provider of a high-risk system and must meet all provider obligations accordingly.

When Article 25 applies, the original provider's obligations for that specific system end but they must cooperate with the new provider, providing documentation and technical access to help them meet their obligations.

**Practical implications:**

- Substantial customisation of a vendor's AI system may trigger provider obligations. Document any modifications carefully and assess their significance before deployment.
- Fine-tuning a GPAI model on proprietary data may or may not constitute a substantial modification, depending on whether it alters the high-risk characteristics of the resulting system. The threshold is not defined numerically in the Act; it requires a documented assessment.
- Contracts with AI vendors should clearly address the Article 25 question; specifically, which party bears provider obligations if modifications occur, and what cooperation the original provider will provide.

## Dual-role organisations

Many organisations hold both provider and deployer status simultaneously. The two most common scenarios:

**In-house AI development for internal use:** If you build an AI system (training a model, developing a pipeline, assembling components into a working system) and then use it in your own operations, you are both the provider and the deployer. You owe the full provider obligation set and the full deployer obligation set. There is no consolidation: the obligations are cumulative.

**SaaS companies that use their own product:** A company that develops an AI-powered product and uses it internally for its own HR, credit, or operational decisions holds both roles. The fact that you also sell the system externally does not reduce your deployer obligations for internal use.

In dual-role situations, the compliance programme must address both obligation sets. In practice, the provider obligations typically subsume most of the deployer obligations; if your QMS, documentation, and monitoring plan are complete, deployer obligations such as maintaining logs and assigning human oversight are generally covered.

## What this means if you use third-party AI tools

If your organisation uses AI systems built and provided by a third party (a vendor's model, an API, a SaaS product with an AI component) you are a deployer. You are not responsible for the provider's conformity assessment or technical documentation, but you cannot simply assume the provider has done everything correctly.

Your obligations as a deployer include:

- Confirming the system is used within its intended purpose and within the instructions for use provided
- Maintaining the human oversight that the provider has designed into the system
- Monitoring performance for unexpected risks in your specific operational context
- Conducting a FRIA if your use case and organisation type requires one
- Reporting serious incidents to the provider and, where required, to market surveillance authorities

If the provider's instructions for use are absent, unclear, or inadequate for your use case, that is not a defence in the event of a compliance failure. It is, however, a signal to pause deployment and resolve the gap; either with the provider or, if necessary, by deciding not to use the system in that context.

[Deeploy](https://deeploy.ai) is designed for organisations in exactly this position: deployers that need to monitor AI system performance, maintain audit-ready logs, manage documentation, and demonstrate ongoing compliance without building the infrastructure from scratch.

## Roles for limited-risk and minimal-risk systems

The obligations above apply primarily to high-risk AI systems under Annex III and Article 6. For systems [classified as limited risk](https://deeploy.ai/eu-ai-act-hub/articles/eu-ai-act-risk-classification-4-tier-system/) (mainly those that interact directly with natural persons, such as chatbots, emotion recognition tools, and deepfake generators) the obligations are narrower and fall under Article 50.

**Article 50 transparency obligations:**

- Providers of chatbot systems must ensure users are informed they are interacting with an AI, unless it is obvious from context
- Providers of deepfake-generating systems must label the content as AI-generated
- Deployers using emotion recognition or biometric categorisation systems in professional contexts must inform the individuals concerned

For minimal-risk systems (e.g. spam filters, AI in video games, recommendation systems outside regulated contexts) there are no mandatory obligations under the Act, though providers may voluntarily adhere to codes of conduct.

## Frequently asked questions

## Frequently asked questions

### What is the difference between a provider and a deployer in the EU AI Act?

A provider is any organisation that develops an AI system and places it on the market, or has it developed under its direction. Providers carry the heaviest obligations: technical documentation, risk management system, conformity assessment, CE marking, and post-market monitoring. A deployer is any organisation that uses an AI system in a professional context under its own authority. Deployers must use systems as intended, ensure human oversight, monitor operation, and report serious incidents.

### We build a tool on top of the OpenAI API. Are we a provider or a deployer?

You are a deployer of OpenAI's GPAI model, but a provider of your own AI system built on top of it. If your system is classified as high-risk, you carry provider obligations for that system, including conformity assessment and technical documentation, even though you did not train the underlying model yourself.

### What happens if we fine-tune a foundation model? Does that make us a provider?

Potentially. If your fine-tuning constitutes a "substantial modification" to the original model, you may be reclassified as a provider and take on the associated obligations. The AI Office has provided partial guidance on this boundary but it remains a grey area. Extensive fine-tuning that changes the system's intended purpose or performance profile carries the higher risk of triggering provider status.

### Can we be both a provider and a deployer at the same time within the EU AI Act?

Yes, and many organisations are. A company that builds an AI-powered HR tool for internal use is both the provider (it developed the system) and the deployer (it operates the system). In that case, the full set of obligations from both roles applies.

### What are our obligations as a deployer of a high-risk AI system?

Under Article 26, deployers must: use the system in accordance with the provider's instructions for use; assign a human oversight person with the authority and capability to intervene; monitor the system's operation; inform employees or their representatives where AI is used in the workplace; conduct a Fundamental Rights Impact Assessment where required; keep logs for the periods specified; and report serious incidents to the relevant authority.

### What must providers give us as deployers?

Providers of high-risk AI systems must supply instructions for use covering the system's intended purpose, performance characteristics, limitations, maintenance requirements, and the level of human oversight required. Without adequate documentation from your provider, you cannot demonstrate compliance with your own deployer obligations. This is a contractual point worth addressing before deployment.