Analysis

Deployer or Provider? Why this label completely determines your AI liability

The EU AI Act is not generic legislation that imposes equal obligations on every market participant. The rules, responsibilities and sanctions are entirely dependent on the role your organisation occupies in the AI value chain. Yet in practice we see that many organisations — from municipalities to medium-sized enterprises — have no clear answer to the question: are we a provider or a deployer?

That is not an innocent gap. The legal qualification determines not only which regime of obligations applies to you, but also when you — sometimes without realising it — switch roles and thereby take on new, heavy liabilities. In this article we analyse both roles, the associated obligations, and the mechanism by which a deployer unintentionally becomes a provider.

The legal definitions: what the law says

The EU AI Act uses two key concepts (Art. 3):

A provider is a natural or legal person, public authority, agency or other body that develops or has developed an AI system or a general-purpose AI model, and places that system on the market or puts it into service under its own name or brand — whether or not for remuneration.

A deployer is a natural or legal person, public authority, agency or other body that uses an AI system under its own responsibility — with the exception of use in a personal, non-professional context.

Most organisations are deployers. They purchase AI systems from commercial providers — Microsoft Copilot, a recruitment SaaS, a credit scoring model — and deploy those systems in their business processes. They build nothing themselves. That is the classic deployer profile.

The Provider: the heaviest compliance burdens

Because the provider stands at the origin of the technology, the AI Act places the heaviest obligations with this party. Art. 16 lists the obligations of providers; for high-risk AI systems they are substantial:

Quality management system (Art. 17) — A documented, continuous system for risk management, data quality, technical documentation, incident follow-up and post-market monitoring. ISO 42001 offers a recognised management framework for this.
Technical documentation (Art. 11 jo. Annex IV) — A comprehensive technical dossier describing the operation, training data, validation methodology, performance boundaries and security measures of the system. This dossier must be retained for at least ten years after first deployment.
Logging and traceability (Art. 12) — Built-in automatic logging that records the use of the system throughout its entire lifecycle — including input data, decisions and oversight interventions.
Conformity assessment (Art. 43) — Before a high-risk AI system is placed on the market, a conformity assessment must be completed. For systems in Annex III (the most common deployer context) self-assessment with internal control generally applies; for systems covered by Annex I product legislation (medical devices, aviation) involvement of a notified body is mandatory.
EU database registration (Art. 49) — High-risk AI systems must be registered in the European AI database before deployment.
Post-market monitoring (Art. 72) — An active system to monitor the operation of the system in practice and to detect and report incidents.

These obligations are substantial. They presuppose access to the technical architecture of the system, insight into the training data, and the capacity to set up and maintain a quality management system. That is precisely why the provider is the party that builds or has the system built — not the party that purchases it.

The Deployer: not a bystander, but not an engineer either

A persistent misconception is that deployers can delegate compliance to their supplier. "We purchased the software from a reputable provider — their CE documentation covers us" is a line of reasoning that does not hold legally. Art. 26 imposes on deployers an independent series of obligations, separate from what the provider has done:

Following instructions (Art. 26.1) — Deployers are obliged to use the AI system in accordance with the provider's instructions for use. Deviant use — even if commercially attractive — falls outside the covered conformity and creates an independent liability.
Human oversight (Art. 26.2) — Deployers must ensure that the persons charged with human oversight have the authority, capacity and training to understand the operation of the system and to override decisions or shut down the system if necessary. This requires a designation decision, a training programme and an oversight protocol.
Input data (Art. 26.4) — To the extent that the deployer has control over the input data supplied to the system, they are responsible for the relevance and representativeness of that data.
Monitoring and incident reporting (Art. 26.5 and Art. 73) — Deployers must actively monitor the operation of the system for risks in their own organisational context. Serious incidents — unexpected harm, discriminatory outcomes, system failures affecting persons — must be reported to the provider and to the national supervisory authority (in the Netherlands: the ACM).
Fundamental Rights Impact Assessment — FRIA (Art. 27) — For certain categories of deployers, the FRIA is legally mandatory: public authorities and private organisations deploying high-risk AI for the applications listed in Annex III in the public sphere (biometric identification, credit scoring, employment, education). The FRIA is an ex-ante assessment of the fundamental rights impact of the intended use — similar in structure to a DPIA, but broader in scope.
Transparency to data subjects (Art. 50 jo. Art. 26.3) — Deployers are obliged to inform data subjects when they are exposed to a high-risk AI system, unless this is already clear from the context. From 2 August 2026, this also applies to systems that interact with people without this being directly visible.
AI Literacy (Art. 4) — Already in force since 2 February 2025: deployers must make demonstrable efforts to bring the AI literacy of their employees up to standard. This concerns not only technicians, but all employees who use AI systems in their work.

The danger zone: when a deployer unintentionally becomes a provider

This is the most critical, and most underestimated, part of the AI Act for many organisations. Art. 25 contains a transition rule that determines when the full set of provider obligations shifts to a deployer. This concerns three situations:

1. Change of name (Art. 25.1.a)

Your organisation purchases an AI system and places it on the market or puts it into service under your own name or brand — also known as white-labelling. From that moment you are legally the provider of that system, with all associated obligations. The original builder steps back; you take over. This also applies when the product is deployed internally (put into service), not only when it is commercially distributed.

2. Substantial modification (Art. 25.1.b)

Your organisation makes a substantial modification to a high-risk AI system. The AI Act defines this as a modification that takes the system outside its original conformity assessment — because the performance, risk profiles or intended use domain fundamentally change.

Concrete examples: you take a general language model via an API and fine-tune this model with your own domain-specific data for a high-risk application (e.g. automated credit selection or candidate assessment). Or you integrate a system in a way that structurally changes the input data compared to the originally validated use. In both cases you are no longer a deployer — you have become a provider of the modified system.

3. Change of intended purpose (Art. 25.1.c)

You deploy an AI system for a purpose other than the intended use for which the provider established conformity. If that other purpose falls under a high-risk category in Annex III, you bear provider liability for that use — even if the system itself is unchanged.

This scenario is particularly treacherous in practice. An organisation purchases a chatbot for general customer service (low-risk use), but then deploys it to guide recruitment processes or assess credit applications. The system is the same; the purpose has changed radically — and with it the legal position of the organisation.

What this means for your compliance strategy

The practical consequence of Art. 25 is that the legal label 'deployer' is not static. It is a status that can change as a result of decisions typically made in the IT department, by a product manager or in an innovation team — far from the legal or compliance function. That makes awareness and process integration essential.

Concretely, this means that every organisation that purchases, modifies or repurposes AI systems needs an internal assessment process that asks at every relevant change: does this change our legal role? That assessment process must be embedded in change management, the procurement process and the software development process — not only in the compliance department.

The fines: what is at stake?

Art. 99 of the AI Act links fines to the severity of the violation. For providers deploying a prohibited AI practice (Art. 5), the maximum fine is €35 million or 7% of global annual turnover. For violations of high-risk obligations by providers or deployers — including failure to carry out a FRIA, absence of human oversight, or failure to report incidents — the maximum fine is €15 million or 3% of global annual turnover.

For a deployer that has unintentionally assumed the role of provider, without the associated obligations being fulfilled, the entire provider sanctions regime may apply — on top of the deployer obligations that already applied. That is the double risk of a misunderstood division of roles.

Practical first steps

Your compliance strategy begins with clarity about your role per AI system. That requires a structured inventory:

Map all AI systems — per department, per supplier, per intended use. Also register informal use (Shadow AI): tools that employees use independently outside the IT organisation.
Determine your role per system — are you a pure deployer, or have you made modifications or pursued a purpose other than the original? Document that assessment including the rationale.
Classify the risk level — only for high-risk systems (Annex III) do the heaviest obligations apply. Classify conservatively in cases of doubt: the law requires this (recital 84).
Establish the assessment process for future modifications — every API use, every fine-tuning, every integration must be tested against the criteria of Art. 25. That is a process, not a one-time check.
Document continuously — the burden of proof in a supervisory investigation lies with you. Every decision, every assessment, every oversight action must be dated and retained.

Conclusion

The dividing line between deployer and provider is not merely a legal label — it is the pivot around which your entire compliance strategy must be built. A wrong assumption about your role leads to blind spots: deployers who are unaware of the heavier provider obligations, and providers who overlook the specific deployer obligations for human oversight and impact assessments.

The mechanism of Art. 25 makes that division of roles dynamic. Every technical change, every repurposing of an AI system and every white-label decision can immediately change your legal position. Organisations that understand this — and establish an internal assessment process around it — stand on solid legal ground. Organisations that ignore it are building up risks that only become visible when a supervisory authority comes knocking.