Provider and deployer (AI Act)

What is a provider and what is a deployer under the AI Act?

The AI Act does not ask what kind of company you are. It asks what you did with one specific AI system, and hands you a role based on the answer. Two roles carry nearly all the weight.

Article 3(3) defines a provider as a person or body that "develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge". Three fragments there decide real cases. "Has developed" means you never have to write a line of code, because ordering the build is enough. "Under its own name or trademark" points at the label on the product, not at who paid the invoice. "Whether for payment or free of charge" shuts the door on giving something away to escape the role.

Article 3(4) defines a deployer as a person or body "using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity". "Under its authority" is the whole test: you decided to switch it on, on your data, for your purposes. The exception only covers private life, so an accountant who runs an AI assistant over client files is a deployer and the same person asking it for a recipe on a Sunday is not.

The role attaches to the system, not to the company. In the same week and the same building you can be the deployer of a CV screening tool you bought and the provider of a quoting tool you had built and now sell on.

Why almost every company is a deployer

You buy a licence, you point it at your own data, and you let it do work for you. The vendors are the providers, the buyers are deployers, and most companies buy rather than build.

Deployer is not an empty role. For a high-risk system, Article 26 asks you to:

• Use the system in line with the provider's instructions for use.

• Assign human oversight to natural persons "who have the necessary competence, training and authority, as well as the necessary support".

• Keep the input data "relevant and sufficiently representative in view of the intended purpose", to the extent you control it. Feeding a screening tool a candidate pool that looks nothing like the job is your problem, not the vendor's.

• Keep the logs the system generates automatically for at least six months, where they are under your control.

• Inform the workers' representatives and the affected workers before a high-risk system goes into use at work, and tell anyone the system makes or helps make a decision about.

Article 25: how a deployer becomes a provider

This is the part that catches companies out. Article 25(1) says a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system in three situations, and from that moment the full provider regime lands on them.

You put your name or trademark on it. A payroll office that white-labels a supplier's worker-evaluation tool as its own product has done exactly this, and Annex III point 4 puts systems that monitor and evaluate the performance of workers in the high-risk bracket. The article adds "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated", so a contract can move duties around, but the name on the box is where a regulator starts reading.

You make a substantial modification. A change after the system went on the market that the provider's conformity assessment never planned for, and that either affects compliance or changes the intended purpose. Retraining a supplied model on ten years of your own decisions is a candidate. Moving a setting the vendor documented as adjustable is not.

You change what it is for. You modify the intended purpose of a system, "including a general-purpose AI system", that was not high-risk, so that it becomes high-risk. Buying a general text assistant and pointing it at ranking job applicants is the textbook version. Nothing about the software changed. The purpose did, and Annex III lists employment.

Article 25(2) then says the initial provider "shall no longer be considered to be a provider of that specific AI system". The duty does not get shared, it moves. That provider does owe you cooperation, documentation and technical access, with one exception worth reading twice: it "shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system". If that sentence sits in the vendor's terms and you change the purpose anyway, you become the provider and get nothing to work with.

What changes the moment you flip

A deployer keeps a handful of operational duties. A provider of a high-risk system carries Article 16, which is a different order of work: a quality management system, technical documentation, the conformity assessment before the system goes on the market, an EU declaration of conformity, CE marking, registration in the EU database, and your name and contact address on the system. That assessment has to happen before the system is placed on the market, so the day you work out that you crossed the line is already too late to do it in the right order.

A worked example: the tool you rebranded

An HR services firm of forty people licenses a candidate-matching tool from a Dutch software vendor. The vendor is the provider and supplies instructions for use. The firm is a deployer.

Then three things happen over eighteen months, each sensible on its own. The firm fine-tunes the matching model on ten years of its own placement outcomes, because generic matching underperforms in its niche. It puts its own brand on the interface clients log into, because that is what clients pay for. And it sells access to that interface to client companies as its own subscription.

Together those steps hit the first two triggers of Article 25, without anyone in the firm ever deciding to become a provider. Candidate matching for recruitment sits in Annex III, so the system is high-risk. The firm now owes a conformity assessment on something it has been selling for a year, technical documentation for a model it fine-tuned without recording what it trained on, and a registration it never made.

The cheap fix sits upstream. Before a rebrand or a retrain, ask the vendor in writing whether the change touches the intended purpose or goes beyond what their documentation says you may adjust.

Importer, distributor, and the model behind your assistant

Two more roles turn up in supply chains. An importer is established in the Union and places on the market a system carrying the name or trademark of a company outside the EU. A distributor is anyone else in the chain who makes a system available on the Union market. Their duties are checking duties: CE marking, the EU declaration of conformity, the instructions for use, and whether the provider met its own obligations. Reselling an American HR tool in Belgium without touching it lands you here.

Buying an assistant built on someone else's model does not make you the provider of that model. That stays with whoever developed it and put it on the market. The Commission's guidelines of July 2025 say a company that modifies a general-purpose model only becomes the provider of a model when the change is significant enough in generality or capability, weighing the training compute spent on the modification against the compute behind the original model. Fine-tuning on your own documents is nowhere near that. Article 25 is about the system, though, and that is far easier to trip.

Provider versus deployer: who answers when something goes wrong

A rejected candidate asks why. The dimension that separates the two roles is which company has to have the answer ready.

The provider answers for the system. Was it designed and tested for this purpose, what data was it trained on, does the documentation describe its limits, was oversight built in. Those answers are in the technical documentation or they do not exist at all, and no deployer can produce them after the fact.

The deployer answers for the use. Was it used the way the instructions say, who was watching, did that person have the authority to override, what went in as input data, are the logs still there, were the people involved told. Buying a fully compliant system answers none of those.

Both can be wrong at the same time, and both are fined in their own right. Crossing the Article 25 line does not add a bit of paperwork to your deployer duties, it makes you the party that has to have the system answers as well as the use answers.

On timing: the high-risk obligations these roles hang on have moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, pushed stand-alone Annex III high-risk systems to 2 December 2027 and AI embedded in products under Annex I to 2 August 2028. Article 3 and Article 25 were not rewritten. What moved is the date from which the duties attached to those roles start to bite.