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 organization occupies in the AI value chainvalue chainThe sequence of actors from model development through provision to deployment and use, along which responsibilities and AI-Act obligations move.Open full entry →. Yet in practice we see that many organizations, from municipalities to medium-sized enterprises, have no clear answer to the question: are we a providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → or a deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →?

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 realizing 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 systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → or a general-purpose AI modelgeneral-purpose AI modelEU AI Act term for a model displaying significant generality and capable of many distinct tasks, typically integrated into downstream systems; carries its own obligation set, with extra duties for models posing systemic risk.Open full entry →, 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 organizations 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-riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → AI systems they are substantial:

• Quality management system (Art. 17), A documented, continuous system for risk management, data quality, technical documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry →, incident follow-up and post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use — the product-regulation half of continuous monitoring.Open full entry →. ISO 42001 offers a recognized management framework for this.
• Technical documentation (Art. 11 jo. Annex IV), A comprehensive technical dossier describing the operation, training datatraining dataThe data used to fit an AI model's parameters; its quality, lawful rights and representativeness are central governance concerns.Open full entry →, 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 assessmentconformity assessmentThe pre-market process demonstrating a high-risk AI system meets the EU AI Act's requirements, leading to CE marking and registration.Open full entry → (Art. 43), Before a high-risk AI system is placed on the market, a conformity assessment must be completed. For systems in Annex IIIAnnex IIIThe EU AI Act's list of high-risk use-case areas — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.Open full entry → (the most common deployer context) self-assessment with internal controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → generally applies; for systems covered by Annex I product legislation (medical devices, aviation) involvement of a notified bodynotified bodyAn independent conformity-assessment organization designated to verify that a high-risk AI system meets the AI Act before it reaches the market.Open full entry → 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 oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry → (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 program 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 representativenessrepresentativenessHow well training data reflects the population and conditions the system will face in deployment — the fitness-for-purpose core of AI data quality.Open full entry → 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 organizational context. Serious incidents, unexpected harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry →, 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 Assessmentfundamental rights impact assessmentAn assessment that certain deployers of high-risk AI must perform to identify and mitigate the system's risks to people's fundamental rights.Open full entry →, FRIAFRIAFundamental Rights Impact Assessment — required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry → (Art. 27), For certain categories of deployers, the FRIA is legally mandatory: public authorities and private organizations 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 DPIADPIAData Protection Impact Assessment — required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry →, but broader in scope.
• TransparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry → 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 LiteracyAI literacySufficient understanding of AI's workings, capabilities and risks for one's role — an explicit expectation for provider and deployer staff under the EU AI Act.Open full entry → (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 organizations. 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 organization 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 organization makes a substantial modificationsubstantial modificationA change to a deployed AI system that materially alters its function or purpose — capable of shifting provider obligations onto the modifier.Open full entry → 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 organization 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 organization.

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 organization 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 managementchange managementControlled handling of updates to models, data and configurations — every material change re-passes validation before redeployment.Open full entry →, 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:

1. Map all AI systems, per department, per supplier, per intended use. Also register informal use (Shadow AIshadow AIAI tools adopted by staff or business units outside official channels and governance — the predictable product of processes that are too heavy or too slow.Open full entry →): tools that employees use independently outside the IT organization.
2. 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.
3. 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).
4. Establish the assessment process for future modifications, every API use, every fine-tuningfine-tuningFurther training of an existing model on your own data to adapt its behavior — which makes you responsible for the modification, potentially up to provider level.Open full entry →, every integration must be tested against the criteria of Art. 25. That is a process, not a one-time check.
5. 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 repurposingrepurposingUsing an AI system for a purpose other than the one it was built and assessed for, which can change its risk classification and the obligations that apply.Open full entry → of an AI system and every white-label decision can immediately change your legal position. Organizations that understand this, and establish an internal assessment process around it, stand on solid legal ground. Organizations that ignore it are building up risks that only become visible when a supervisory authority comes knocking.