The EU AI Act for agent deployers

The Act distributes obligations by role, and the two that matter to most organisations running agents are provider and deployer. A provider develops an AI system and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority. If you are wiring a foundation model into an agent that answers your customers, you are almost always a deployer of that model and — depending on what you have built and how you offer it — possibly a provider of the system you assembled. That determination is a legal one about your specific arrangement, and it is the first thing to settle, because a guide written for deployers answers the wrong questions if you turn out to be a provider.

The second determination is classification. Most of the obligations discussed below attach to high-risk systems, and whether an agent of yours is high-risk depends on what it does and where it is used rather than on how it is built. This guide does not classify anything for you and no product can: a risk tier recorded in an inventory is a field carrying a decision a person made, and the value of the field is that it makes the decision reviewable rather than that it makes it.

One structural point before the article-by-article part, because getting it wrong is the thing a specialist reader spots in a sentence. Only Article 26 is a list of deployer duties. Articles 12 and 14 sit among the requirements for high-risk systems and are addressed to the provider: Article 12 says the system must be built to record events automatically, and Article 14 says it must be designed so that people can effectively oversee it. A deployer meets them from the other side — Article 26(6) says you keep the logs the system generates, and Article 26(2) says you assign the oversight to competent people. The two sides collapse into one job when you assembled the agent yourself, which is the common case for an internal agent estate, because then you are both the party that has to make the recording and the oversight exist and the party that has to keep and staff them. Cite them accordingly, and do not put Article 12 in a policy document as though a regulator would read it as your obligation.

What is worth doing regardless of how that classification lands is the evidentiary work, and the reason is practical rather than legal. The artefacts the Act asks for — an inventory, a purpose statement, automatic logs, oversight records, an integrity story — are the same artefacts you need for an ISO/IEC 42001 management system, for a NIST AI Risk Management Framework programme, for a SOC 2 evidence request about the agent estate, and for the incident you will eventually have to reconstruct. Building them once and mapping them several ways is cheaper than building them per framework, and the mapping is where most of the overclaiming happens, so map carefully.

Article 14 is about human oversight, and like Article 12 it is addressed to the provider: a high-risk system has to be designed and built so that natural persons can effectively oversee it while it is in use. Article 14(4) then lists the capabilities that design has to enable for the people oversight is assigned to — among them, at 14(4)(e), the ability to intervene in the operation or to interrupt the system through a stop button or a similar procedure. The deployer’s matching duty is Article 26(2): assign that oversight to named natural persons who have the competence, the training, the authority and the support to exercise it. Read together they are one requirement in two halves, and the operative words in both halves are about capability rather than intention. An organisation chart naming an oversight owner satisfies neither half if the owner has no button.

For agents, intervention has a natural implementation: a gate on the specific actions that matter, where the request stops, a named person decides, and their decision is recorded with a rationale. The design detail that decides whether this is a control or a rubber stamp is what the approval is bound to. An approval that authorises a refund rather than this refund of this amount on this order is a standing licence for every refund the agent proposes afterwards, and the agent proposing them is the component most likely to have been talked into it by retrieved text. Binding the approval to a hash of the exact action plus its execution context, making it single-use and giving it an expiry is what turns a queue entry into an oversight record.

The second design detail is the queue itself, and it is the one that decides whether oversight survives the first month. Gating too much produces an approval queue nobody reads, and an approval queue nobody reads is worse than no gate at all, because it converts a control into a delay with a rubber stamp on the end. Risk-tier the gates so approvals stay rare enough to be read.

Halting is the other half and it needs to be blunt. A kill switch scoped to one agent, one team or the whole estate, checked before anything else in the pipeline, engaged only by a named person with a stated reason, and written into the audit log — because the audit entry is the only account anyone will ever have of why an entire fleet stopped. What it is honest to say about any such switch is that it is an admission control: it refuses new work rather than recalling a request already dispatched to a provider.

The artefact an authority or an auditor asks to see is a bundle covering a period: the traces and their events, the approvals with approver identity, timestamp and rationale, the audit entries covering every governance-plane change, and a verification result for the chain those entries sit in. Token Observe’s compliance export carries all four plus a SHA-256 digest over the canonical JSON of the bundle body, generated at a recorded time.

Be precise about that digest, because the wording matters and it is the wording an informed auditor will test. It is a seal, not a signature. It lets a recipient confirm the file is byte-for-byte the one whose digest they were given through some other channel, and anyone who can rewrite the bundle can recompute it. Durable origin evidence does not come from the export; it comes from the keyed audit chain plus an off-box Ed25519 anchor, which is where the signature actually lives.

The verification verdict travelling inside the bundle is what distinguishes it from an exported log file, and the field to read is the protection level rather than the valid flag. Under the default unkeyed configuration the chain is plain SHA-256 and an operator with write access can rewrite an entry and recompute every downstream hash, at which point verification reports valid. That is tamper-evidence against alteration that does not also recompute the chain — which is genuinely useful and is not what an auditor will assume the word valid means. Under a keyed configuration the digests are HMACs under a key held outside the database and the head is sealed at every boot by a checkpoint, so a rewrite needs the key as well as database access. Both states are labelled in the export. Present the label, not just the flag.

The bundle is also capped: at most 200 traces, 5,000 events, 1,000 approvals and 2,000 audit entries over a default 30-day window, with a truncation flag set inside the file whenever a cap bites. Be precise about how visible those caps are, because it is the sort of detail that decides whether a partial bundle goes to a regulator described as complete. In the current console only the trace cap is repeated beside the download button, together with an instruction to narrow the dates and to check the truncation flag in the file before sending it on; the other three caps are documented rather than displayed. Nobody opens a sealed JSON file to check before forwarding it, so until every cap is on the screen the covering note is where they belong.