Who carries the obligations for a procured AI agent?
On the allocation of roles under the EU AI Act when you did not build the AI agent yourself.
Last reviewed: 4 September 2026
The market is shifting from chatbots to agents: systems that take steps independently, drive other software and carry out actions without a human approving each step. Almost no organisation builds these itself. They come from a supplier, out of a platform, or they are assembled by an external agency.
The question rarely asked in advance: where do the obligations sit.
What makes an agent different
Two characteristics make agents legally harder than ordinary software.
They act independently. Where a chatbot answers, an agent sends a message, amends a record or places an order. There is no intermediate step at which a human assesses the outcome, unless that step has been deliberately built in.
And their behaviour is not deterministic: the same input does not always produce the same output. That makes testing different from classical software, where a successful test means the case has been dealt with.
Your role determines your obligations
The EU AI Act allocates responsibility across the chain. The two roles that matter to you are provider and deployer.
If you procure a system and use it within the purpose the supplier has fixed, you are the deployer. Your obligations are set out in Article 26: use in accordance with the instructions for use, organise appropriate human oversight, manage the input data with care, monitor operation, keep the logs to the extent they fall under your control, and report serious incidents.
Article 25 describes three situations in which that role shifts and you become a provider yourself, with the full obligations of Article 16.
- You put your name or trade mark on an existing high-risk system. In this case, and only in this case, the Regulation expressly allows contractual arrangements to allocate the obligations differently.
- You make a substantial modification to a high-risk system already in use, such that the original conformity assessment no longer covers what is running.
- You change the intended purpose of a system that was not classified as high-risk, so that it becomes so. The textbook example: deploying a general-purpose chatbot to screen job applicants.
In the latter two, a contract is no remedy. The role follows from the factual circumstances, not from what the parties have agreed about it.
The difference is considerable. As a deployer you use a system the provider has already assessed and documented. As a provider you must be able to demonstrate yourself that the system meets the requirements: conformity assessment, technical documentation, EU declaration of conformity.
With agents, that role shifts more readily than with ordinary software. You give the agent an additional task, you connect it to another system, you have it prepare a decision it did not previously prepare. Each of those steps can move the intended purpose.
The role is moreover determined per application, not once for the organisation as a whole. With one agent you are the deployer, with another the provider.
When an agent falls into the heaviest category
The category follows from what the agent does, not from who built it. A selection from Annex III relevant to agents: analysing and filtering job applications or evaluating candidates, deciding on the allocation of tasks or on the continuation of an employment relationship, evaluating the creditworthiness of natural persons, determining risks and pricing in life and health insurance, and deciding on access to essential public services.
What already applies today is a different matter from what comes later. The obligations for high-risk systems have been moved by the Digital Omnibus to 2 December 2027 for standalone systems and 2 August 2028 for AI in regulated products. Three things apply now: the prohibition on certain practices, including the inference of emotions in the workplace; the AI literacy obligation since 2 February 2025; and the transparency obligation of Article 50 since 2 August 2026, which applies as soon as a person communicates directly with an AI system.
That last one touches almost every customer-facing agent.
Where it goes wrong in practice
Four points that recur in an audit. We describe the mechanism, not how you address it.
- The agent draws no distinction between instruction and data. Everything it receives is text to it: your instruction, but equally the contents of an email, a document or a web page. Whoever can determine what the agent reads can thereby influence its behaviour. That is not a fault in one product but a structural characteristic, and it calls for constraining what the agent is permitted to do rather than for better instructions.
- The output is passed on unchecked. If the output goes straight into a database or to a web page without an intervening check, the receiving system inherits everything the agent produces.
- Human oversight exists on paper. Article 26 requires appropriate human oversight. The question at an audit is not whether there is an approval step in the process, but whether the member of staff has the time and the information to genuinely depart from it, or clicks through because the process has to run its course.
- Costs scale with use. With agents charged per action, cost grows with volume rather than with the number of users. That is not a legal point, but it does determine whether a pilot is sustainable.
What to ask before you sign
Six questions for your supplier, the answers to which should be in writing.
- What is the intended purpose of this system, as you have defined it? Anything we do outside that shifts the allocation of roles.
- Are you the provider within the meaning of the Regulation, and under which legal entity?
- Does a third party's model or infrastructure run beneath your service, and where does the processing take place?
- Which logs does the system generate, which of those reach us, and how long are they retained?
- Which changes to the configuration do you regard as substantial?
- What will you supply when a supervisory authority asks us for technical documentation?
Anyone who does not get a concrete answer to questions 1 and 5 does not yet know which role they will turn out to have.