EU AI Act: Are You a Provider or a Deployer?

Most compliance work stalls on a question that sounds administrative and is not: are you a provider or a deployer? Nearly every obligation in the EU AI Act attaches to one role or the other, so the answer decides whether you are writing technical documentation and arranging a conformity assessment, or assigning human oversight and keeping logs. Companies that skip the question tend to plan for the lighter role and discover the heavier one late.

This guide sets out what each role carries, the three situations in which a deployer silently becomes a provider, and how to establish which role you hold for each system you run. It is technical and organisational guidance rather than legal advice: the formal determination for a specific system belongs with your counsel.

What is the difference between a provider and a deployer under the EU AI Act?

A provider develops an AI system, or has one developed, and places it on the EU market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity. The definitions sit in Article 3 of Regulation (EU) 2024/1689, and the practical test is simpler than it looks: if your name is on the system as the one offering it, you are the provider; if you are using someone else's system to run your business, you are the deployer. A hospital buying triage software is a deployer. The company that built and sells that software is the provider. Crucially, the roles are per system rather than per company. A medical software firm is a provider of the product it sells and a deployer of the recruitment tool it uses for its own hiring, and both sets of obligations apply at once, to different systems.

Why the distinction carries so much weight

Provider obligations are front-loaded and heavy: they govern how a system is designed, tested, documented and assessed before it reaches the market. Deployer obligations are operational and continuous: how the system is used, watched and recorded in daily practice. Mistaking one for the other does not reduce your exposure, it just means you prepared the wrong evidence.

Which obligations does a provider of a high-risk system carry?

A provider of a high-risk AI system carries the full design-and-evidence burden, set out in Article 16 and detailed across the chapter that follows it. In practice that means a risk management system maintained across the lifecycle (Article 9), data governance covering training, validation and testing data (Article 10), technical documentation to the standard of Annex IV (Article 11), automatic logging built into the system (Article 12), instructions for use that let a deployer comply with its own duties (Article 13), human oversight designed in rather than assumed (Article 14), and appropriate accuracy, robustness and cybersecurity (Article 15). On top of the engineering, there is the paperwork of market access: a quality management system, conformity assessment, the CE marking, registration in the EU database for Annex III systems, post-market monitoring, and reporting of serious incidents. Providers established outside the EU must also appoint an authorised representative inside it.

The obligation teams underestimate

Instructions for use are treated as documentation and are actually a control. A deployer can only meet its duties if the provider states the intended purpose, the known limitations, the conditions the system was validated under and what human oversight requires. Vague instructions push risk downstream and tend to come back as a support burden and a liability argument.

Which obligations does a deployer of a high-risk system carry?

A deployer of a high-risk AI system carries operational duties set out in Article 26, and they are lighter than a provider's but far from nothing. You must use the system in accordance with the instructions for use, assign human oversight to people with the competence, training and authority to actually intervene, and make sure input data is relevant and sufficiently representative for the intended purpose where you control that data. You must monitor operation, suspend use and inform the provider when a system presents a risk, and keep the logs the system generates for at least six months. Where the system is used in a workplace, you must inform workers' representatives and affected employees before putting it into service. Some deployers, including public bodies, private entities providing public services, and deployers of certain credit and insurance systems, must also carry out a fundamental rights impact assessment under Article 27.

Logs are the obligation that fails quietly

Keeping logs for at least six months sounds trivial until someone checks whether the logs are actually retained, whether they survive a vendor's default retention window, and whether anyone could reconstruct a specific decision from them. This is the deployer duty most often discovered to be unmet during an incident, which is the worst moment to find out. Our guide to what to keep and for how long covers the tension with data minimisation.

When does a deployer become a provider without meaning to?

A deployer becomes a provider of a high-risk system in three situations set out in Article 25, and all three are easy to trigger without a decision ever being made. First, if you put your name or trademark on a high-risk system already on the market, you own it as a provider, whatever your contract with the original supplier says. Second, if you make a substantial modification to a high-risk system that remains high-risk. Third, if you modify the intended purpose of a system, including a general-purpose one, in a way that makes it high-risk when it was not. Each of these transfers the entire provider obligation set to you, and the original provider is required to cooperate but is no longer the one on the hook. White-labelling a vendor's system under your own brand is the common path, and it is usually a commercial decision taken without anyone reading Article 25.

Fine-tuning and integration

Fine-tuning a model on your own data, or wiring a general-purpose model into a workflow that decides something consequential about a person, is exactly the territory where the intended purpose shifts. The question to ask is not how much code you wrote, but whether the system now does something the original was not placed on the market to do.

Do the same roles apply to general-purpose AI models?

General-purpose AI models have their own provider obligations, separate from the high-risk regime and already in force since 2 August 2025. A provider of a GPAI model must maintain technical documentation, supply information to downstream providers who integrate the model, put a copyright policy in place, and publish a sufficiently detailed summary of training content. Models judged to present systemic risk carry further duties including model evaluation and incident reporting. For most companies reading this, the relevant point is the downstream position: if you build an AI system on top of someone else's general-purpose model and place that system on the market under your own name, you are the provider of that system, even though you did not train the model. The model provider's obligations do not transfer to you, and yours do not transfer to them.

Does either role change the deadlines you are working to?

Neither role changes the dates, because the EU AI Act sets deadlines by obligation rather than by who holds it. The prohibitions on unacceptable practices have applied since 2 February 2025, and the general-purpose AI rules since 2 August 2025. The Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, deferred the high-risk deadlines: standalone high-risk systems under Annex III now apply from 2 December 2027, and high-risk AI embedded in products already covered by EU product-safety law under Annex I from 2 August 2028. Article 4 on AI literacy applies to providers and deployers alike and has been in force since February 2025. What the role does change is how much work sits between you and those dates: a provider facing a conformity assessment needs considerably more lead time than a deployer arranging oversight and logging.

How do you establish which role you hold?

Establish the role system by system, in writing, before you plan any compliance work, because the answer determines everything downstream. The sequence that works:

1. Inventory every AI system, including bought-in tools and AI features embedded in software you already license. Most inventories surface systems nobody had counted as AI.
2. For each one, ask whose name is on it as offered to the market or put into service. That single question resolves most cases.
3. Check the Article 25 triggers: branding, substantial modification, changed intended purpose. These are what turn an assumed deployer into a provider.
4. Classify the risk level for each system, since the obligations only bite once a system is high-risk or carries transparency duties. Our guide to classifying under the risk framework walks through it, and the risk classifier gives a first indication.
5. Record the reasoning, not just the conclusion. When a classification is challenged, by a customer's procurement team or an authority, the reasoning is the thing that has to hold up.

Sector specifics matter at this point: the route is different for healthcare AI systems, where the medical device regime runs alongside, and for manufacturing SMEs, where machinery rules do. If you are outside the EU entirely, the extraterritorial reach is the place to start.

Frequently asked questions

Can a company be both a provider and a deployer?

Yes, and most are. The roles attach per system, not per company. A software vendor is the provider of the product it sells and the deployer of the HR and support tools it uses internally. Both obligation sets apply simultaneously, to different systems, and the compliance evidence for each is different.

Does using a vendor's AI system make us responsible for its documentation?

No. The provider produces the technical documentation and the conformity assessment. As deployer you are responsible for using the system according to its instructions, assigning competent human oversight, monitoring it, and keeping logs. You should, however, verify that the provider's documentation exists before you buy, because your duties depend on it.

Does putting our logo on a bought-in AI tool change anything?

If the system is high-risk, yes, substantially. Placing your name or trademark on it makes you its provider under Article 25, with the full design, documentation and conformity burden. This catches white-label arrangements routinely, because the branding decision is usually commercial and the regulatory consequence is not considered.

We only use AI internally, never with customers. Are we still a deployer?

Yes. Deployer status follows from using an AI system under your own authority in a professional capacity, regardless of whether the output is customer-facing. Internal use in hiring, worker management or access to services is specifically within the high-risk categories, and workplace deployments carry their own duty to inform employee representatives.

Who is responsible if a system causes harm, the provider or the deployer?

It depends on which duty was breached, which is exactly why the role question matters. A design or documentation failure points at the provider; using a system outside its instructions, without competent oversight, or on unsuitable input data points at the deployer. Establishing and recording your role in advance is what makes that separation defensible.