EU AI Act Provider vs Deployer: Obligations, Differences, and the Article 25 Trap

The EU AI Act does not assign compliance obligations by industry. It assigns them by role. Whether you are a fintech startup, a healthcare provider, an HR technology company, or a multinational deploying AI across your operations, the obligations that apply to your organization depend on a single question: are you a provider, a deployer, or both?

Getting this wrong in either direction is a compliance failure. Organizations that underestimate their provider obligations face potential fines of up to EUR 15 million or 3% of global annual turnover for high-risk system violations. Organizations that misidentify themselves as providers when they are deployers build compliance programs against the wrong set of requirements, wasting resources and missing the actual obligations that apply to them.

This guide covers both roles precisely, their full obligation sets for high-risk AI systems, how both can apply simultaneously, and the three Article 25 scenarios that convert deployer status to full provider obligations.

Provider — definition and scope

Article 3(3) of the EU AI Act defines a provider as any natural or legal person, public authority, agency, or other body that develops an AI system or a general-purpose AI model and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

The phrase "under its own name or trademark" is the critical element. If your organization develops an AI system and releases it into use with your organization's name attached — whether as a commercial product, a licensed service, or an internal deployment at scale — you are a provider. The word "develops" is also interpreted broadly. You do not need to build the underlying model to be a provider. If you fine-tune a foundation model, integrate components into a new system, and release the result under your own name, you are a provider of that system.

Provider status is not limited to organizations selling AI commercially. An organization that builds an AI system for internal use and deploys it across its operations is a provider for that system under the AI Act. The threshold is placing the system in service, not commercial sale.

Deployer — definition and scope

Article 3(4) defines a deployer as any natural or legal person, public authority, agency, or other body that uses an AI system under its own authority in a professional context, except where the AI system is used in the course of personal, non-professional activity.

The deployer is the entity that puts an AI system to work in a business context using a system built by someone else. If your organization buys, licenses, or accesses an AI system built by a vendor — including AI services accessed via API — and uses it in your operations, you are a deployer. The defining characteristic is that you are not responsible for the system's design and do not place it on the market. You operate it.

Most mid-market and enterprise organizations using AI tools are deployers for the majority of their AI systems. An organization using a third-party AI recruitment tool, a cloud-based credit scoring service, or a vendor-provided clinical decision support system is a deployer for each of those systems.

Many organizations hold both roles simultaneously

The provider and deployer roles are not mutually exclusive. A single organization can be a provider for one system and a deployer for another. More importantly, an organization can be both a provider and a deployer for the same system when that system incorporates third-party AI components.

A common scenario: a company builds a recruitment screening product using a third-party LLM. For the end-user employer, that company is the provider of the recruitment AI. For the LLM, that same company is the deployer. Each role brings distinct obligations. Understanding which hat you are wearing for which system is a prerequisite for building an accurate compliance program.

Provider obligations for high-risk AI systems

Providers of high-risk AI systems face the full compliance burden under the EU AI Act. All of the following apply before the system is placed on the market or put into service, with a compliance deadline of December 2, 2027 for most Annex III systems.

Risk management system — Article 9: A documented, iterative risk management system operating throughout the entire lifecycle of the system. This is not a one-time assessment — it is a continuous process that includes identifying foreseeable risks, estimating and evaluating those risks, adopting risk management measures, and testing their effectiveness.

Data governance — Article 10: Training, validation, and testing datasets must be subject to documented data governance practices. Datasets must be relevant, sufficiently representative, and examined for biases that could lead to discriminatory outcomes. Data sources, preparation methodologies, and known limitations must be documented.

Technical documentation — Article 11 and Annex IV: Technical documentation covering all eight elements in Annex IV must be drawn up before market placement and kept up to date throughout the lifecycle. Elements include system design and architecture, training methodology and data, validation results, risk management description, applicable harmonized standards, and the EU Declaration of Conformity.

Automatic logging — Article 12: The system must be capable of automatically generating event logs sufficient to enable monitoring of its operation. Logs must record at minimum the periods of use, reference databases used where applicable, and input data where technically feasible.

Transparency and instructions for use — Article 13: Systems must be sufficiently transparent to enable deployers to understand and use them correctly. Instructions for use must include the system's intended purpose, performance characteristics, known limitations, human oversight measures, and expected operational lifetime.

Human oversight — Article 14: High-risk AI systems must be designed to allow effective human oversight during use. The system must technically enable humans to understand the system's capabilities and limitations, properly interpret outputs, decide not to use or to override outputs, and intervene in or halt operation. This is a design requirement, not merely a policy requirement.

Accuracy, robustness, and cybersecurity — Article 15: Systems must achieve appropriate levels of accuracy for the intended purpose. Accuracy metrics must be declared in technical documentation and instructions for use. Systems must be resilient against errors and resistant to adversarial attacks including data poisoning.

Quality management system — Article 17: A documented quality management system covering all aspects of compliance — regulatory strategy, design and development controls, data management, risk management, post-market monitoring, and incident reporting procedures. QMS documentation must be retained for ten years after market placement.

Conformity assessment — Article 43: Most Annex III systems use the internal control procedure in Annex VI. Systems involving real-time biometric identification in public spaces require third-party notified body assessment under Annex VII.

EU Declaration of Conformity — Article 47: A signed EU Declaration of Conformity must be drawn up using the Annex V template before market placement and retained for ten years.

CE marking — Article 48: The CE conformity marking must be affixed to the system before market placement.

EU database registration — Article 49: High-risk AI systems must be registered in the EU database managed by the European Commission before market placement.

Post-market monitoring — Article 72: A documented post-market monitoring plan must be established before market placement and implemented throughout the operational life of the system.

Serious incident reporting — Article 73: Procedures must be in place to report serious incidents to market surveillance authorities without undue delay — within fifteen days for incidents resulting in death or serious harm.

Deployer obligations for high-risk AI systems

Deployer obligations under Article 26 are lighter than provider obligations but remain substantial for high-risk systems. The following apply from December 2, 2027 for most Annex III systems.

Use the system only in accordance with the provider instructions for use and only for its intended purpose. Assign human oversight to natural persons with the necessary competence, training, and authority — and ensure those persons have the time and resources to exercise oversight effectively. Take technical and organizational measures to implement human oversight as specified in the instructions. Monitor operation of the system based on the instructions for use. Retain automatically generated logs for a minimum of six months. Before deploying a high-risk system that affects employees, inform employees and their representatives. Inform affected individuals that they are subject to a high-risk AI system where required by the instructions for use.

Additionally, deployers that are public bodies or private entities providing services of general public interest — including banking, insurance, healthcare, education, and utilities — must conduct a Fundamental Rights Impact Assessment under Article 27 before deploying each high-risk AI system. The FRIA must cover deployment purpose, period of use, affected person categories, specific risks of harm, human oversight measures, and risk mitigation actions.

Deployers also share the AI literacy obligation under Article 4, active since February 2, 2025. All persons operating or overseeing AI systems must have sufficient AI literacy appropriate to their role and the context of the system's use.

The Article 25 trap — three ways deployers become providers

Article 25 sets out three specific scenarios in which a deployer acquires provider obligations. Organizations need to understand these scenarios because they are common in practice and the consequences of crossing into provider territory without recognizing it are significant.

Placing on the market under your own name: If a deployer takes a vendor's AI system and makes it available on the EU market under its own name or trademark, that deployer becomes the provider for that system. White-labeling an AI product — reselling or licensing it under a different brand — triggers full provider obligations. The organization that white-labels inherits the complete provider compliance burden even if it had nothing to do with the original system's development.

Substantial modification: If a deployer makes a substantial modification to a high-risk AI system, that deployer becomes the provider for the modified system. A substantial modification is any change to the system that affects its compliance with the EU AI Act requirements or its intended purpose. Adding new functionality, retraining the model on new data, or changing the system's use context in a way that creates new risks can all constitute substantial modification.

Placing on the market for general-purpose use: Where a deployer puts a general-purpose AI system into service for a use that classifies as high-risk under Annex III — and the provider has not specifically intended the system for high-risk use — the deployer assumes provider obligations for that high-risk use. This scenario is particularly relevant for organizations building applications on top of general-purpose foundation models for contexts that fall within Annex III categories.

A practical approach to role classification

For every AI system your organization is involved with, work through this sequence. First, determine whether the system is a high-risk AI system under Annex III or Article 6(1). If it is not high-risk, your obligations are primarily the transparency requirements of Article 50 and the AI literacy obligation of Article 4. If it is high-risk, proceed to role classification.

Second, determine your role. Did your organization develop this system and place it on the market or put it into service under your name? If yes, you are a provider. Do you use a system built by another organization in your operations? If yes, you are a deployer. Are both true in some way — for example, do you build on top of a third-party model? If yes, you may hold both roles for different parts of the system.

Third, check the Article 25 scenarios. Have you white-labeled the system? Have you made substantial modifications? Are you deploying a general-purpose AI for a specific high-risk use that the original provider did not intend? If any of these apply, you have provider obligations.

Fourth, document the assessment. The role classification decision and the reasoning behind it should be documented. This creates a defensible record and supports any subsequent conformity assessment or regulatory engagement.

---

Based on Regulation (EU) 2024/1689, Official Journal version 13 June 2024. This article does not constitute legal advice. For formal compliance assessments, consult qualified legal counsel.