Article 12 logs: what an AI agent's record must capture

To satisfy Article 12 for an AI agent, each log entry should capture what triggered the action, which agent version and capability acted, what sources it read and where they came from, what it proposed, which bound allowed, held or refused it, who approved it, and what changed as a result, in a record nobody can edit.

What does Article 12 require, in plain words?

Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires high-risk AI systems to be built so that they automatically record events, or logs, over their lifetime. The logs must make it possible to identify situations where the system may present a risk or has been substantially modified, to support the provider's monitoring after release, and to let deployers monitor how the system operates.

The Article is short and deliberately general. It says what logs are for, not which fields they hold. For most systems it leaves the content to the provider. That is reasonable for a scoring model, where an input and an output tell most of the story, and inadequate for an agent, where the story has many steps. Our longer guide to Article 12 record-keeping for agents covers the duty itself.

Who has to keep these logs?

The provider must design the system so it can log. The deployer, under Article 26, must keep the logs that are under its control for a period the Act sets, and use them to monitor the system. So a bank deploying a vendor's credit agent relies on the vendor to make logging possible and is itself responsible for keeping what is generated in its environment.

The duty attaches to high-risk systems, such as agents used in creditworthiness assessment of individuals. Whether yours is in scope is covered in does Article 12 require AI agents to keep logs. Our view is that any agent that acts should keep this record anyway, because without it you cannot answer a complaint.

Why does an acting agent need a richer record?

A model that scores an application produces one output from one input. An agent reads several sources, calls tools, drafts something, may be held for approval, and then changes a system. A log that captures only the final output cannot explain why the agent did what it did, or whether it was allowed to.

Two questions decide whether a record is good enough. Can you reconstruct the decision a year later, including the version of the agent and the facts it saw? And can you prove the action was within the agent's authority at that moment? We argue in Article 12 logging is not enough for agents that the second question is the one most logs fail.

Which fields should an agent's action record capture?

Capture these for every action, including actions that were refused:

1. Action identifier and links to the parent and child actions, so multi-step work can be followed.
2. Timestamp from a trusted clock.
3. Agent identity and version, including the brief and the underlying model version.
4. Capability used and the depth the agent held for it at that moment.
5. Certificate in force for that capability, with its expiry.
6. Trigger: the instruction, event or request that started the action, and who or what sent it.
7. Sources read, each with its provenance: sealed, signed, declared or external.
8. Tool calls and their parameters.
9. Proposed action in full, before any edits.
10. Verdict: allowed, held, refused or withheld, and the bound that decided it.
11. Approver identity, decision, any edits made and the time taken.
12. Effect: what changed in which system, with a reference that system can confirm.
13. Disclosures made to the person affected, such as an AI notice under Article 50 transparency.

How do you meet Article 12 with that record?

Do not let the agent write its own log. If logging depends on the agent choosing to record, a failure or an injected instruction can erase the evidence you need most. The practical setup is described in how to keep automatic logs for an AI agent.

What will a supervisor or auditor ask?

• Pick a decision from last quarter. Show us everything the agent saw and did.
• Which version of the agent and model made it?
• Was the agent permitted to take that action at that moment, and how do you know?
• Show us actions the agent proposed but was not allowed to take.
• Who can delete or change log entries?
• How long do you keep records, and why that period?

What does Article 12 not cover?

It does not set a retention period on its own; deployer retention sits in Article 26 and in sector law, which may require longer. It does not resolve the tension with data minimisation under GDPR Article 5, so keep personal data in the record to what reconstruction needs. It does not apply to systems outside the high-risk category, although the same record will serve complaints, audits and incident reporting there too. For how logging fits the wider set of controls, see AI agent regulation mapped to controls.

This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

Where Pryme fits

Pryme files every verdict, including refusals, in an append-only record outside the agent. Each entry carries the capability, depth, certificate, the provenance of every fact the agent used and the bound that decided, so a decision can be reconstructed and its authority shown at once.