Provider or deployer? Working out your role under the EU AI Act

Before the EU AI Act asks whether your AI is high-risk, it asks a more basic question: what is your role? The Act assigns obligations to operators, and which obligations land on you depend almost entirely on whether you are a provider or a deployer of a given system. Get the role wrong and you will either take on duties that are not yours or, more dangerously, miss the ones that are.

Most organisations have never actually worked this out. Here is how to do it, why it matters, and the trap that quietly turns a deployer into a provider.

The two roles, in plain terms

The Act defines several operators, but for most organisations two matter.

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, whether for payment or free. Providers build and supply AI.

A deployer uses an AI system under its own authority in a professional context. Deployers use AI. If your staff use a third-party tool for work, your organisation is that tool’s deployer.

There are other roles, importers, distributors, product manufacturers and authorised representatives, but provider and deployer are the two that cover most real situations.

The quick test

Ask one question of each AI system: did we make it and put our name on it, or are we using someone else’s?

• If you built it, or rebadged it and sell or supply it under your brand, you are the provider.
• If you are using a tool someone else supplies, ChatGPT, Microsoft Copilot, a vendor’s AI feature, you are the deployer.

For the large majority of businesses adopting AI, most systems fall on the deployer side. You are using tools, not shipping models. That is worth knowing, because deployer obligations are real but far lighter than a provider’s.

Why the role matters so much

The two roles carry very different weight.

Providers shoulder the bulk of the Act, especially for high-risk systems: a risk management system, technical documentation, data governance, conformity assessment, CE marking, registration, and post-market monitoring. It is a substantial programme of work.

Deployers have a lighter but genuine set of duties, largely in Article 26: use the system in line with the provider’s instructions, ensure meaningful human oversight, keep the logs the system generates, monitor how it performs, and inform affected people where required. Some deployers of certain high-risk systems must also complete a fundamental rights impact assessment.

And some duties fall on both. The Article 50 transparency obligations apply to providers and deployers alike, in different ways: providers mark AI-generated content, deployers disclose things like deepfakes, emotion recognition and AI chatbots. We covered the wider timetable in the Digital Omnibus update.

Because the obligations diverge this much, mislabelling a system is not a paperwork error. It changes what you are actually required to do.

The trap: becoming a provider without building anything

Here is the part organisations miss most often. You can be pulled into provider obligations without ever developing an AI system.

Under Article 25, a deployer of a high-risk system is reclassified as its provider, and inherits the provider obligations, if it does any of three things:

1. Rebrands it by putting its own name or trademark on a high-risk system already on the market.
2. Substantially modifies it, in a way not foreseen in the original conformity assessment that affects the system’s compliance. In practice this can include fine-tuning on your own data, restructuring a retrieval pipeline, or custom training.
3. Changes its intended purpose so that a system, including a general-purpose AI system, becomes high-risk under the Act.

This is the sharp edge. A company that assumes “we did not build the model, so we are only a deployer” can cross into full provider territory the moment it starts meaningfully adapting a high-risk system. The Commission is expected to issue guidance on exactly what counts as a substantial modification, so if you are adapting high-risk AI, treat it carefully and take advice rather than assuming you are safe on the deployer side.

Most organisations are both

The final thing to hold onto: role is determined per system, not per company.

A typical mid-sized organisation is a deployer of many third-party tools and, increasingly, a provider of the one or two AI features it has built into its own product. Both can be true at once. That is why the useful unit of analysis is the individual AI system, not the organisation.

Which is exactly why this starts with an inventory: list every AI system, assign it a role, then classify its risk and map the obligations that follow. Role first, because everything downstream depends on it.

The short version

The EU AI Act hands out obligations by role. A provider makes and supplies AI; a deployer uses it; and most organisations are deployers of many systems and providers of a few. Work it out per system, not per company. And watch Article 25: rebrand, substantially modify or repurpose a high-risk system and you can become its provider without having built a thing. Once the roles are right, the rest of your obligations fall into place.

Working out your role across every system, and what follows from it, is the first thing our EU AI Act Baseline does: one defensible table of systems, roles, risk categories, obligations and actions. If you are not sure where you stand, talk to us.