Provider or deployer: which role are you under the EU AI Act?

The most consequential question in EU AI Act compliance is also the first one: which role do you hold? Almost every obligation in the regulation is allocated to either the 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 the 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 →, and the two sets of duties differ in weight by a wide margin. Get the role wrong and you either build a heavy compliance apparatus you do not need, or you miss the obligations that apply to you. Worse, the answer is not the same for every 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 → an organisation runs. One organisation is routinely a deployer of some systems and a provider of others, and occasionally both for the same system.

This article sets out the distinction, the obligations each role carries, the situations where the line is hard to draw, and how to determine your role on a per-system basis. It is the orientation step that should precede every other piece of EU AI Act work, because the role determines which articles you read next.

The two roles, defined

The definitions sit in Art. 3 of the EU AI Act.

A provider is a natural or legal person that develops an AI system 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 →, or has one developed, 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 defining acts are developing and placing on the market under your own name. A provider is the party that brings the system into existence as a product.

A deployer is a natural or legal person using an AI system under its authority, except where the use is a personal, non-professional activity. The defining act is use in a professional context. A deployer is the party that takes an existing system and puts it to work.

The distinction is between making and using. The provider makes the system; the deployer uses it. That sounds clean, and for most cases it is, but the EU AI Act adds situations where a deployer's actions convert it into a provider, which is where the difficulty lies.

Why the role matters so much: the weight of the obligations

The two roles do not carry comparable burdens. The provider obligations are substantially heavier, because the provider is the party in the best position to build safety and compliance into the system itself.

A provider of a high-risk AI system carries the full technical apparatus: a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), automatic logging capability (Art. 12), 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 → and instructions for use (Art. 13), 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 → by design (Art. 14), accuracy, robustnessrobustnessA system's ability to perform reliably under realistic conditions including noise, edge cases and adversarial pressure — the engineering core of the safety-and-reliability principle.Open full entry → and cybersecurity (Art. 15), a quality management system (Art. 17), log retention (Art. 19), 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), the EU declaration of conformity and CE markingCE markingThe mark affixed to products (including high-risk AI systems) indicating conformity with applicable EU requirements.Open full entry → (Art. 47, 48), registration in the EU database (Art. 49), 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 → (Art. 72). This is the heavy end of the regulation.

A deployer of the same high-risk system carries a lighter, operational set: use the system in accordance with the instructions (Art. 26.1), ensure human oversight (Art. 26.2), ensure input data is relevant (Art. 26.4), monitor operation (Art. 26.5), keep the logs (Art. 26.6), inform affected individuals (Art. 26.7), and, for certain deployers, conduct a Fundamental Rights Impact Assessmentimpact assessmentThe design-time discipline of describing a system, mapping stakeholders, identifying harms, rating probability × severity, choosing mitigations and documenting a signed decision — the skeleton under DPIAs, FRIAs and AIAs.Open full entry → (Art. 27). These are real obligations, but they are operational rather than constructional, and they are achievable without building the system.

The gap is roughly three to four times the volume of work. This is why determining the role correctly is not a formality: it is the difference between a manageable operational programme and a full product-conformity effort.

When a deployer becomes a provider

The hardest part of the distinction is the set of situations where a deployer crosses the line and takes on provider obligations. Art. 25 sets these out. A deployer (or other third party) becomes a provider of a high-risk system if it:

• Puts its own name or trademark on a high-risk AI system already on the market. If you rebrand someone else's system as your own, you become its provider.
• 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 system in a way that it remains high-risk. Significant changes to how the system works can make you the provider of the modified system.
• Modifies the intended purpose of an AI system, including a general-purpose one, such that it becomes high-risk. If you take a general system and deploy it for a high-risk purpose it was not placed on the market for, you can become the provider of that high-risk use.

This last route is the one that catches organisations integrating general-purpose AI. Building an application on a general-purpose model and deploying it for a high-risk use case, such as CV screening or credit assessment, can make you the provider of a high-risk AI system, with all the provider obligations that entails, even though you did not train the underlying model. The original model provider remains responsible for the model; you become responsible for the high-risk application you built on it.

The dual-role reality

Most organisations of any size are both providers and deployers, across their AI portfolio. The pattern is common: a company is a deployer of Microsoft Copilot, a deployer of a third-party CV-screening tool, and a provider of the customer-facing chatbot it built on a general-purpose model. Three systems, two roles, one organisation.

This is why the role question is answered per system, not per organisation. There is no single correct answer to "are we a provider or a deployer"; there is only a correct answer to "what is our role for this specific system". An AI inventoryAI inventoryA register of all AI systems an organization builds, buys or embeds, with owners and risk tiers — the prerequisite for governing any of them.Open full entry → that does not record the role for each system is missing the field that determines which obligations apply.

Determining your role: a per-system test

For each AI system in your inventory, work through the questions in order:

1. Did we develop this system, or have it developed, and place it on the market or into service under our own name? If yes, you are the provider.
2. Did we put our name or trademark on a system someone else placed on the market? If yes, you are the provider (Art. 25).
3. Did we substantially modify a high-risk system, or repurpose a system for a high-risk use it was not intended for? If yes, you are likely the provider of the modified or repurposed system (Art. 25).
4. Are we using a system developed and placed on the market by someone else, in our professional capacity, without the above? If yes, you are the deployer.

The output is a role label for each system, which then points to the obligations that apply. Record it in the inventory alongside the risk classification, because the two together determine the entire compliance scope for that system.

Why this is the orientation step

Every other piece of EU AI Act work depends on the role. The risk classification under Art. 6 tells you whether the obligations are heavy or light; the role tells you which set of obligations they are. A deployer reads the Art. 26 series; a provider reads Art. 9 through 15 and the conformity articles. Reading the wrong set is wasted effort at best and a compliance gap at worst.

This is also why the provider articles and the deployer articles in this knowledge base are tagged by role. Once you know your role for a system, the role label tells you which articles are yours. Determining the role is not a preliminary to compliance work; it is the first act of it.