Record every decision as the agent reaches it, generated by the platform, not the agent: the request, sources and their provenance, the action proposed, each bound checked, the verdict, the deciding bound and the versions in force. Store logs append-only, test that you can reconstruct a decision, and refuse the action if the log cannot be written.
Why automatic logs, and what does the law expect?
Article 12 of the EU AI Act requires high-risk AI systems to allow automatic recording of events, logs, over their lifetime, so that their operation can be traced. Deployers of high-risk systems also have duties to keep the logs under their control, under Article 26. Whether your agent's capabilities are high-risk is a separate question; the detail is in does Article 12 of the EU AI Act require AI agents to keep logs?.
Even where the Act does not apply, logs are how you answer every later question: why did the agent do this, on what information, under whose authority? Supervisors, auditors, complaint handlers and customers will ask. The overview of how the rules map to controls is in AI agent regulation, mapped to controls.
The head of agent operations owns the logging standard. The platform or engineering team implements it. Data protection owns the rules on personal data in logs. Records management owns retention.
What are the steps?
- Head of agent operations: defines the log record. For every decision: time, agent and capability, the request or trigger, references to each source used with its provenance class, the action proposed, each bound checked and its result, the verdict, the deciding bound, the brief, sources and model versions, and any person's decision on a held item.
- Platform team: generates the record automatically at the moment the verdict is reached, outside the agent's own control. The agent does not write its own log.
- Platform team: makes the store append-only. Records can be added, not changed or deleted, and tampering is detectable.
- Platform team: synchronises time across the agent, the platform and the target systems, so sequences can be reconstructed.
- Platform team: fails closed. If the log cannot be written, the action does not proceed.
- Data protection: sets the personal data rules: store references to customer records rather than copies where possible, restrict access, and mask fields not needed for reconstruction. Guidance is in how to handle personal data in AI agent logs.
- Records management: sets retention per log type, aligned with the underlying records and with any legal minimum; see how long to keep AI agent logs under the EU AI Act.
- Agent, depth 1: answers retrieval requests by assembling the log entries for a case, customer or period.
- Head of agent operations: tests reconstruction each quarter: pick past decisions at random and rebuild them from the logs alone.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Define record | Nothing | none | Head of agent operations |
| Generate | Nothing; the platform logs it | none | Platform team |
| Append-only | Nothing | none | Platform team |
| Time sync | Nothing | none | Platform team |
| Fail closed | Its action is refused if logging fails | none | Configuring |
| Personal data | Nothing | none | Data protection |
| Retention | Nothing | none | Records management |
| Retrieval | Assembles entries | 1 | Checking completeness |
| Reconstruction test | Nothing | none | Running and signing |
Why must the agent not write its own logs?
A log written by the agent is the agent's account of what it did. If the agent is wrong about what it did, or has been manipulated, its log will be wrong in the same way. The log must be produced by the layer that enforces the bounds, at the point where the action is allowed, held or refused. That record describes what actually happened, not what the agent believed.
Which controls make logging safe, and what evidence do they leave?
Platform-generated records. Evidence: the logging architecture and a test showing records exist for actions the agent did not report.
Append-only storage. Evidence: the storage configuration and tamper-detection results.
Fail-closed behaviour. Evidence: a test in which logging is blocked and the action is refused.
Complete fields. Evidence: a periodic check that no required field is empty.
Reconstruction tested. Evidence: the quarterly test results, signed.
Access controlled and logged. Evidence: who read the logs and when.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What about data subject requests?
Logs that mention a customer contain personal data about them. Under GDPR, that customer can ask for access to it. Design logs so that entries for one person can be found and produced without exposing others; the approach is in GDPR data subject access requests and AI agent logs. Logging references rather than copies helps both minimisation and retrieval.
What are the signs logging is going wrong?
Logs record prompts but not verdicts. You can see what the model was asked, not what the system allowed. The verdict and the deciding bound are the parts auditors need.
Gaps appear. Actions in target systems have no matching log entry. That means something bypassed the platform, or logging failed open.
Logs can be edited. An administrator can correct an entry. Then no entry can be trusted.
Reconstruction takes days. If rebuilding one decision needs engineers and several systems, the logs are not fit for purpose.
Versions are missing. You know what the agent did but not which brief or sources were in force. A complaint about a decision months ago cannot be answered.
Retention is undefined. Logs are kept forever, or deleted when storage fills. Neither is a policy.
What do logs not cover?
Logs record what happened; they do not show it was right. Quality still needs sampling and review. Logs also do not replace the records your other rules require, such as complaint files or transaction records; they sit alongside them.
Where Pryme fits
In Pryme, every verdict is filed in an append-only record by the layer that enforces the minimum chain, with the deciding bound named and the provenance of each fact recorded. The agent cannot write or alter that record, and it continues unbroken through every depth change.
Questions people ask
Should logs include the full text the model produced?
For drafts and messages, yes, because the output is part of what happened. For internal reasoning, keep what you need to explain the decision, within your data rules.
Who should be able to read the logs?
Agent operations, risk, audit and data protection, with access logged. Agent owners for their own agents. Not the agent itself, except through controlled retrieval.
Do refused actions need logging?
Yes. Refusals show the bounds working, and attempted actions are often the most important entries in an investigation.