EU AI Act: Provider vs Deployer — Roles, Obligations, and When the Lines Blur
EU AI Act provider vs deployer: role definitions, obligation comparison, the Article 25 role-shift, and a decision aid. High-risk deadline: 2 Dec 2027.
The EU AI Act does not impose the same rules on everyone who touches an AI system. It assigns specific roles — provider, deployer, importer, distributor — and attaches a distinct obligation set to each. Getting your role wrong is not a paperwork problem. A company that misidentifies itself as a deployer when it is actually a provider skips conformity assessment, technical documentation, and registration — and faces a fine ceiling of €15 million or 3% of worldwide annual turnover (Article 99) when a regulator disagrees.
This page maps both roles side by side, shows where Article 25 can flip a deployer into a provider overnight, and provides a decision aid for organisations that occupy both positions at once.
Definitions: What the Act Actually Says
Provider (Article 16)
A provider develops an AI system and places it on the market or puts it into service under its own name or trademark — whether sold, licensed, or given away free. The definition in Article 3(3) turns on two elements: (1) the system was developed or commissioned by the entity, and (2) the entity's name or brand appears on it when it reaches the market or an end-user.
A 25-person HR-tech company that trains a resume-screening model and sells it as a SaaS tool is a provider. A consultancy that builds a custom demand-forecasting model for internal use, without selling it externally, is also a provider — because it develops and deploys the system under its own authority. The critical trigger is attribution and control, not revenue.
Deployer (Article 26)
A deployer uses an AI system in a professional capacity under its own authority, without having developed or placed it on the market. A bank that licenses a credit-scoring tool from a third-party vendor is a deployer. An HR department running a vendor's applicant-tracking system is a deployer. Article 3(4) excludes purely personal, non-professional use — an employee using a general-purpose tool for private correspondence does not create deployer obligations for the employer.
Most companies that buy AI tools off the shelf are deployers. The Act expects them to use systems responsibly, not to certify them.
Importer (Article 23) and Distributor (Article 24)
Importers bring high-risk AI systems developed outside the EU into the EU market under their own name. They must verify that the provider has completed conformity assessment, that technical documentation exists, and that the system carries a CE mark. They cannot place a non-compliant system on the market.
Distributors make systems available in the EU market without placing them under their own name. They check that the CE mark is affixed, that the EU declaration of conformity exists, and that instructions for use accompany the product. If a distributor finds a system is not compliant, it cannot distribute it and must alert the provider and competent authority.
Both roles are lighter than the provider role but not passive. Importers and distributors that fail their verification duties face the same €15 million / 3% fine exposure under Article 99.
Obligation Comparison: Provider vs Deployer
| Obligation area | Provider (Art 16) | Deployer (Art 26) |
|---|---|---|
| Risk management system | Yes — Article 9, continuous and iterative | No statutory duty, but must monitor in operation |
| Training data governance | Yes — Article 10 | No |
| Technical documentation | Yes — Article 11 + Annex IV, retained 10 years | No (must receive and review it from provider) |
| Record-keeping / logging | Yes — Article 12 (provider keeps logs it controls ≥6 months) | Yes — Article 26, logs of operation ≥6 months |
| Transparency to deployers | Yes — Article 13 instructions for use | No (recipient of this information) |
| Human oversight | Yes — must design it in (Article 14) | Yes — must implement and operate it (Article 26) |
| Accuracy, robustness, cybersecurity | Yes — Article 15 | No |
| Quality management system | Yes — Article 17 | No |
| EU declaration of conformity | Yes — Article 47 + Annex V | No |
| CE marking | Yes — Article 48 | No |
| EU database registration | Yes — Article 49 | No (public bodies must register under Article 49) |
| Conformity assessment | Yes — Article 43, before market placement | No (must verify provider has done it) |
| Post-market monitoring | Yes — Article 72, active data collection | Yes — Article 26, monitor and flag to provider |
| Serious incident reporting to authority | Yes — Article 73, with strict timelines | No — must notify provider; provider reports to authority |
| Fundamental Rights Impact Assessment | Not applicable as such | Yes (Article 27) — public bodies and certain private deployers in high-risk domains |
| Worker notification | No | Yes — Article 26 requires notifying worker representatives before deploying systems that monitor workers |
| Fine exposure on breach | Up to €15M or 3% worldwide turnover (Art 99) | Up to €15M or 3% worldwide turnover (Art 99) |
A note on log retention: Article 26 requires deployers to retain logs of operation for at least six months. Technical documentation for providers is retained for ten years (Article 18). These are distinct obligations — do not conflate them.
Provider Obligations in Detail
The provider stack is the heavier of the two. For a high-risk AI system (one listed in Annex III, or a safety component of an Annex I product), providers must clear the following before launch.
Risk management system (Article 9). This is not a one-time risk assessment — it is a continuous, iterative system that operates from design through decommissioning. It identifies known and reasonably foreseeable risks to health, safety, and fundamental rights; evaluates risks emerging from post-market data; adopts suitable mitigation measures; and tests the system before market placement. Residual risks must be acceptable given the state of the art.
Data and data governance (Article 10). Training, validation, and testing datasets must meet quality criteria — relevance, representativeness, freedom from errors and completeness to the extent possible. Article 10 is about data, not about staff training; staff competence falls under Article 4 (AI literacy), which has applied to all providers and deployers since 2 February 2025.
Technical documentation (Article 11 + Annex IV). Nine mandatory content areas, including system description and intended purpose, design choices and architecture, performance metrics and their justification, risk management documentation, and post-market monitoring plan. Retained for ten years after market placement (Article 18).
Transparency and instructions for use (Article 13). Before a deployer can use a high-risk system, the provider must supply instructions that cover the system's capabilities and limitations, accuracy and robustness properties (Article 15), human oversight requirements, and foreseeable misuse scenarios. Incomplete instructions shift liability toward the provider if harm results.
Human oversight by design (Article 14). The system must be designed so that a human can understand its outputs, monitor its operation, detect anomalies, and intervene or override. The provider either builds these capabilities into the system or specifies the organisational measures the deployer must implement.
Conformity assessment (Article 43). The formal pre-market check. For Annex III point 1 systems (biometrics), this generally requires a notified body (Annex VII route). For most other Annex III categories, internal self-assessment (Annex VI route) is available. Conformity assessment must be complete before the system is placed on the market — not after.
EU declaration of conformity (Article 47) and CE marking (Article 48). The signed declaration (Annex V format) accompanies the system. CE marking signals conformity to market surveillance authorities and deployers.
EU database registration (Article 49). High-risk systems must be registered in the EU database (the database itself is established under Article 71) before market placement. Providers claiming the Article 6(3) non-high-risk exemption must also document that assessment and register it.
Quality management system (Article 17). A documented QMS covering design and development procedures, data standards, testing protocols, incident escalation, and post-market monitoring. Proportionate to the organisation's size and the system's risk profile — a 15-person startup does not need the same QMS architecture as an enterprise.
Post-market monitoring (Article 72). Active, documented data collection from deployers and users throughout the system's lifetime. When new risks emerge, the provider updates technical documentation and risk management records accordingly.
Serious incident reporting (Article 73). Providers report to the market-surveillance authority of the member state where the incident occurred. Timelines: 15 days from awareness for most serious incidents; 10 days where a person has died; 2 days for widespread infringements or serious and irreversible disruption to critical infrastructure. The deployer's role is to notify the provider — reporting to the authority is the provider's statutory duty.
Deployer Obligations in Detail
Deployer obligations under Article 26 are lighter, but they are not trivial. The parts that actually bite in practice are human oversight, monitoring, and the six-month log retention — areas where many companies assume the vendor has handled everything.
Follow the provider's instructions. Article 26 requires deployers to use the system in accordance with the instructions of use provided under Article 13. If the instructions say the system must not be used to make final hiring decisions without human review, that is a legal obligation on the deployer, not a vendor suggestion.
Ensure human oversight. Where human oversight is required by Article 14 and specified in the instructions, the deployer must implement it operationally — trained personnel, documented override procedures, logged interventions. Oversight that exists on paper but is never exercised does not discharge the obligation.
Monitor and report to the provider. Article 26 requires deployers to monitor the system's performance in operation, detect risks or serious incidents, and notify the provider. If the deployer also has reason to believe a serious incident should be brought directly to the competent authority, Article 26 permits that as well.
Retain operation logs for at least six months. Article 26 imposes this directly. The logs must be available to competent authorities on request. Six months is the floor; sector-specific regulation (financial services, healthcare) may require longer.
Notify worker representatives. Before deploying a high-risk AI system that monitors workers, the deployer must notify the worker representatives. This is an Article 26 obligation that frequently surprises HR teams — it is not optional and it applies before deployment, not after.
Fundamental Rights Impact Assessment (Article 27). Not every deployer runs a FRIA. It applies to: public bodies deploying any high-risk AI system; and private deployers using systems in creditworthiness assessment (Annex III point 5(b)) or life and health insurance (Annex III point 5(c)). Private employers deploying recruitment or performance-monitoring AI do not automatically owe a FRIA — though they may choose to run one and the Article 27(4) mechanism lets them build on an existing GDPR DPIA.
The Article 25 Role Shift: When a Deployer Becomes a Provider
Article 25 is the provision that catches organisations off guard. A deployer, importer, or distributor becomes the provider of a high-risk AI system — and inherits the full provider obligation stack — in three situations:
-
Rebrand. You put your own name or trademark on a system developed by another entity and place it on the market. Even if you did not modify the underlying model, affixing your brand makes you the provider.
-
Substantial modification (Article 3(23)). You modify a high-risk AI system in a way that affects its performance or its intended purpose, or changes its risk classification. Fine-tuning a licensed model on proprietary data for a different use case will typically qualify as a substantial modification. Configuration changes within the documented scope of the original system generally do not.
-
Repurpose. You take a non-high-risk system and deploy it for a purpose that brings it into the scope of Annex III — for example, taking a general analytics tool and using it to score creditworthiness of individuals. The system's classification follows its actual use, and the deployer who redirects it bears the provider obligations from that point.
When Article 25 applies, you must conduct conformity assessment, prepare technical documentation, issue the EU declaration of conformity, and register the system in the EU database — regardless of whether the original provider already did all of this for the unmodified version.
"Which Am I?" Decision Aid
Work through these questions for each AI system separately. Role follows the system, not the organisation.
1. Did your organisation develop this system, or commission it to be developed under your name? Yes → you are at minimum a provider. Continue to step 2. No → go to step 3.
2. Does your organisation place the system on the EU market or put it into service under its own name or trademark? Yes → you are a provider under Article 16. Apply the full provider stack if the system is high-risk. No (internal tool, not branded as yours) → you may still be a provider if you control and deploy it internally; check whether the system is high-risk and whether Article 9 obligations attach.
3. Did you receive the system from a third party and use it professionally, without modifying it or putting your name on it? Yes → you are a deployer under Article 26. Apply deployer obligations if the system is high-risk.
4. Have you since rebranded it, substantially modified it, or repurposed it for a new Annex III use case? Yes → Article 25 applies. You are now the provider of the modified/rebranded system. No → you remain a deployer.
5. Did you bring it into the EU from outside, under your own name? Yes → you are an importer under Article 23 in addition to any deployer role.
6. Do you make it available to others in the EU without placing your name on it? Yes → you are a distributor under Article 24.
Most companies that buy SaaS tools and use them in their operations land at step 3: deployer. Most SaaS companies that build AI features into their product and sell it land at step 2: provider.
The Both-at-Once Reality
It is common, not exceptional, for a company to be both provider and deployer simultaneously. The obligation sets do not merge — they run in parallel, one per system.
A 40-person fintech that builds its own credit-assessment model (Annex III point 5(b), high-risk) is the provider of that system. It must run conformity assessment under Article 43, prepare technical documentation under Article 11, and register under Article 49. At the same time, the same company uses a third-party document-verification tool from a vendor. For that tool, it is the deployer — it must follow the vendor's instructions under Article 26, implement human oversight, retain logs for six months, and run a FRIA because creditworthiness assessment is in scope of Article 27.
A software house that builds a custom recruitment AI for a client is the provider; the client is the deployer. The software house must complete conformity assessment before delivery. The client must ensure human oversight, monitor the system's operation, and notify the software house if something goes wrong. If the client then adds features, rebrands the tool as its own product, and sells it to other companies, Article 25 fires: the client is now a provider of the modified system.
The Act does not let parties contractually transfer these obligations to each other. You can agree commercially on who does what, but Article 25 determines who is legally responsible to the regulator.
Deadline: 2 December 2027
The high-risk obligations — the full provider and deployer stacks described above — apply from 2 December 2027 for stand-alone Annex III systems. This date was established under the Digital Omnibus, the amendment proposal agreed between the Parliament and Council in May 2026, which deferred the original 2 August 2026 deadline. For high-risk AI systems that are safety components of Annex I regulated products (medical devices, machinery, etc.), the date is 2 August 2028.
Article 5 prohibitions have applied since 2 February 2025. AI literacy obligations (Article 4) have also applied since that date. GPAI obligations under Chapter V have applied since 2 August 2025. December 2027 is the relevant date for the provider and deployer stacks on Annex III systems, and documentation work alone typically takes months to assemble correctly.
How Confir Helps
Confir derives your role from plain-English scenarios. You answer questions about how the system was built, whether your name appears on it, and what it does — and Confir's rule-based engine maps the answer to Provider (Article 16), Deployer (Article 26), Importer (Article 23), or Distributor (Article 24). It then surfaces only the obligation controls that apply to your combination of role and risk tier.
For providers, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 / Annex V EU Declaration of Conformity. For deployers that owe a FRIA, it runs the Article 27 assessment workflow. The classification logic is deterministic and rule-based — same intake, same finding, human-readable reasoning — which matters for a compliance output that a regulator may scrutinise.
Frequently Asked Questions
What is the difference between a provider and a deployer under the EU AI Act?
A provider develops an AI system and places it on the EU market or puts it into service under its own name (Article 3(3) and Article 16). A deployer uses a third-party or internally developed system in a professional context under its own authority, without placing it on the market under its name (Article 3(4) and Article 26). Providers bear the heaviest pre-market obligations — conformity assessment, technical documentation, registration. Deployers bear operational duties: following instructions, human oversight, log retention, and monitoring.
Can a company be both a provider and a deployer?
Yes, and this is common. A company is a provider for every AI system it develops and deploys under its own name, and a deployer for every third-party AI tool it uses professionally. The obligations run in parallel — the provider stack applies to the systems you built; the deployer stack applies to the systems you bought. Each system is classified separately.
When does a deployer become a provider under Article 25?
Article 25 converts a deployer, importer, or distributor into a provider in three situations: putting your own name or trademark on a system you did not develop; substantially modifying a high-risk system (defined in Article 3(23)) in a way that changes its performance or intended purpose; or repurposing a system for an Annex III use case it was not originally designed for. In each case, the full provider obligation stack — conformity assessment under Article 43, technical documentation under Article 11, registration under Article 49 — applies from that point.
Do deployers of high-risk AI always need to run a Fundamental Rights Impact Assessment?
No. Article 27 applies to: (a) public bodies deploying any high-risk AI system; and (b) private deployers using systems that fall under Annex III point 5(b) (creditworthiness assessment) or 5(c) (life and health insurance risk and pricing). Private employers deploying recruitment or performance-monitoring AI do not automatically owe a FRIA, though Article 27(4) lets any deployer build a FRIA on an existing GDPR data protection impact assessment if they choose to run one.
What logs must a deployer keep, and for how long?
Article 26 requires deployers to retain operation logs for at least six months. These logs must be available to competent authorities on request. This is the minimum — sector regulation (financial services, healthcare) may require longer retention. Provider technical documentation has a separate ten-year retention period under Article 18.
What is the penalty if a company misclassifies its role?
Non-compliance with provider or deployer obligations (Articles 16, 26) falls under the €15 million or 3% of total worldwide annual turnover tier (Article 99) — whichever is higher. For companies that qualify as SMEs or start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount, providing proportionality protection. The same ceiling applies to importers and distributors who fail their verification duties under Articles 23 and 24.
Does Article 26 apply to systems that are not high-risk?
The substantive deployer obligations — human oversight, log retention, worker notification, FRIA — apply only to high-risk AI systems. AI literacy under Article 4 applies to all companies regardless of risk tier and has been live since 2 February 2025. The limited-risk transparency obligations of Article 50 apply to specific system types (chatbots, synthetic media, emotion-recognition outputs) from 2 August 2026 — those are not deployer-specific; they apply to whoever operates the system toward end-users.
Related guides
- Article 26 deployer obligations
- Article 13 transparency requirements
- SaaS provider compliance guide
- AI risk management frameworks
- Article 3 AI definitions
- Article 16 provider requirements
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →