Provider or deployer: which AI Act role is yours

When a board asks me who answers to the regulator if the agent gets it wrong, the answer starts with a word that means two different things in this field. The European framework does not hand out obligations according to who signs the invoice. It hands them out according to the role each party actually occupies: whoever places the system on the market or puts it into service under their own name carries one set of duties, and whoever uses it under their authority carries another. A company that contracts an agent-run operation is almost always in the second group. What almost nobody checks is that three specific moves push it into the first, without anyone deciding so in a meeting.

A note on method: I describe both roles and what each one owes in operational terms, using the names the framework itself uses. I do not cite numbered articles or reproduce the text, because what a board needs is to know which side it is on and what will be asked of it as a result.

”Provider” means two different things, and that is where it goes wrong

In a procurement meeting, your provider is whoever you sign with. Under the regulatory framework, a provider is whoever develops an AI system, or has one developed, and places it on the market or puts it into service under their own name or trademark. The two figures often coincide, which is exactly why the case where they do not goes unnoticed. The second role, whoever uses the system under their own authority in the course of a professional activity, is what the framework calls the deployer.

The confusion has a practical cost. I have read contracts that call the firm running the process “the provider” and assume that, since it is the provider, the regulatory duties are its problem. That is not how it works. The role is set by what each party actually does with the system. The label the contract puts on it does not move that. A third party can be your commercial provider and not be the provider under the regulation, and you can be a customer and a deployer at the same time.

What each role owes

The long list of duties switches on when the use is high-risk. For contained back-office work most of this table does not apply, and transparency plus decent governance is enough. Read it anyway, because it is the map of what will be asked of you the moment one of your uses moves up a category.

What is required	Provider	Deployer
Before it runs	Document what the system does, on what data, with what controls, and hand clear information to whoever deploys it	Check that the intended use is the one it will get, and that there is someone to assign oversight to
While it runs	Keep monitoring the system once it is on the market	Use it in line with the instructions and watch how it behaves in the operation
Human oversight	State which oversight measures the system needs	Assign it to natural persons who have the necessary competence, training and authority
Logs	Make the system generate them	Keep them for as long as they are under its control
Serious incident	Report it	Report it

Two things stand out in that right-hand column. Human oversight is not satisfied by naming someone on an org chart: it asks for competence, training and authority, and authority means being able to stop the system without asking permission from whoever sold it. And the duty to report a serious incident sits with both roles, not one. Neither is delegated by signing.

When a third party runs your process

Here is the case no legal summary covers, and it is exactly the one my clients are in. You hire a firm to run one of your processes with agents. It builds the system, maintains it and puts it into service under its name. You use it in your operation, on your data, for your customers and under your authority. The question that reaches the board is whether that takes you out of the equation.

It does not. Both roles coexist, and each drags its own duties along. Having someone else run the capability does not transfer your position as deployer, because the test is whose authority the system is used under, and that is still yours. What does change is the division of labour: documentation, instructions and monitoring of the system belong to whoever puts it into service, while oversight, use in line with instructions and keeping logs are yours. Outsourcing the operation does not shrink the duty, it splits it, which is the same thing that happens with the AI literacy obligation.

Three moves that make you a provider without deciding to

The framework contemplates that a deployer, a distributor or a third party comes to be considered the provider of a high-risk system, with the duties that carries. It happens in three cases:

• You put your name or trademark on a high-risk system already placed on the market or put into service. This is the easiest one to do without thinking: the agent goes out with your company’s identity in front of the customer. This case, and only this case, allows a contractual arrangement to allocate the obligations otherwise, so it is the one of the three where the small print buys you anything.
• You substantially modify a high-risk system already on the market or in service, in a way that keeps it high-risk.
• You change the intended purpose of a system that was not classified as high-risk, and that change makes it high-risk. The system is the same one. What you changed is what you use it for.

All three share a logic: the moment the decision about what the system is and what it is for becomes yours, the role follows you. And when that happens, the initial provider stops being considered the provider of that particular system. It does not vanish from the map, since it still has to cooperate with you and hand over information and technical access, but the party that has to stand behind the documentation in front of the authority becomes you.

The third is the one I have most often seen happen quietly. An agent that started out sorting email is one day screening job applications, because it looked like the natural next step to somebody. Nothing was signed, the board was not told, and the intended purpose has changed. That is why the inventory of uses I argue for in the EU AI Act and AI agents has to record what each agent is used for today, not what it was bought for.

One note on currency, and I give it because it changes how the above should be read. The Commission’s official explorer warns that the provisions on definitions and on responsibilities along the value chain have been amended by the Digital Omnibus on AI, and that its text does not yet reflect those changes. The logic of the three cases is the one I describe and the one I work from, but before resting a specific decision on the exact wording it is worth checking it against the consolidated text.

First, check which category your use falls into

There is an order to all this. Classify the use, then look at the role, and only then read off the list of duties. Classifying by use rather than by technology is the first job, and I cover it in the framework article. Most of the back-office agents I work with do not land in the high category, but that has to be established case by case: the difference between a contained use and one that touches a person’s access to a job, credit or an essential service changes the whole conversation.

It is also worth not mixing this up with data protection. Controller and processor are roles from a different regulation answering a different question, which is who decides about personal data, and I cover them in AI agents and data privacy. A company can be a controller and a deployer at once without either implying the other.

The clause your contract is missing

A contract does not change your role, but it does decide whether you will be able to meet it. When I review the contract for a managed operation I usually find measurable outcome, permissions, traces and a clean exit, and I do not find this one. What needs writing is short:

• Which role each party takes for each system and each intended purpose, named in regulatory terms and not only commercial ones.
• What the other side hands you so you can comply: the instructions for use, which oversight measures the system requires, and what logs it generates.
• How those logs reach you and in what format, because keeping them is your duty and you cannot keep what you never receive.
• Who tells whom, and how fast, when a serious incident happens that both of you have to report.
• What happens if you change the purpose: that a change of use forces a review of the classification before it goes live, not after.

That is the sixth clause I would add to the ones I already review in AI managed services, and the question missing from choosing an AI agent provider. Who absorbs the financial cost when the damage happens anyway is a separate argument, the civil liability one, and it lives in who pays when an AI agent makes a mistake. That one is about the money. This one is about the duty.

All of it sits inside the frame of AI agent governance, rests on the traces I describe in auditing AI agent decisions, and belongs to the wider picture in AI agents for business.

Frequently Asked Questions

Is my company a provider or a deployer?

If you contract an AI system and use it in your operation under your authority, you are a deployer. You are a provider if you develop the system, or have it developed, and place it on the market or put it into service under your name or trademark. Both figures can appear in the same chain, and the role is set by the facts of the operation over whatever the contract calls it.

Can I transfer my obligations to the provider by contract?

Not the ones that fall to you because you use the system under your authority. A contract splits work, cost and civil liability between the parties, and you need it in order to comply at all, but it does not change who occupies which role before the authority. There is one narrow exception, the branding case, where the framework does contemplate a contractual arrangement allocating the obligations otherwise. Outside that, what the contract should do is guarantee you what you need from the other side: instructions, oversight measures and logs.

Do these obligations apply to an agent that only reconciles invoices?

The demanding list switches on with high-risk uses, and a contained back-office agent is usually not there. What applies in every case is decent governance: knowing what you have, what it is used for, and disclosing where required. The expensive mistake comes from never having classified the use and finding out late that it had moved up a category.

What happens if I put my brand on an agent a third party runs?

Putting your name or trademark on a high-risk system already on the market or in service makes you its provider, with the duties that carries, and the initial provider stops being one for that system although it still has to cooperate with you. It is the only one of the three cases where the framework allows a contractual arrangement to allocate the obligations otherwise, so here the small print does decide. Before releasing an agent with your company’s identity in front, it is worth knowing which category it falls into and what documentation you would have to stand behind.