What to log for an AI agent audit trail

The EU AI Act's high-risk obligations became enforceable on 2 August 2026 — Articles 8 through 17, 26, 27 and 73, with Article 12 requiring logs kept for a minimum of six months. Most teams running an agent that takes real actions don't have this yet, regardless of whether the Act applies to them. I run one that writes to a CRM in production, and the logging pattern below is what I'd want in place either way.

Who this is for: an engineer whose agent does something real — sends an email, updates a record, closes a ticket — and who currently logs it the way you'd log an API request. That's not enough, and the gap doesn't show up until someone asks what the agent did and why.

An audit trail for an agent isn't a request log

A web server's log answers "what was requested and what came back." That's not the question anyone asks about an agent. The question is "why did it do that" — which means the log has to capture a decision, not a request.

The difference matters because a request is deterministic given its inputs; a decision isn't. The same CRM-write agent, given the same lead, can take a different action tomorrow because the model changed, the prompt changed, or a retrieved document changed. If your log doesn't distinguish those, "why did it do that" has no answer six weeks later — you have the output, not the reasoning that produced it.

The minimum schema

Five fields, all present on every logged action, none of them optional:

• Action taken. What actually happened downstream — the CRM field that changed, the message that sent, the ticket that closed. Not "agent completed successfully."
• Inputs. The full context the model saw: the user's message, retrieved documents, prior turns. Without this you can't reproduce the decision, only the outcome.
• Model and prompt version. Both, pinned exactly. A prompt is an interface, and an unversioned one means you can't tell whether last week's incident was the model's fault or a prompt edit that shipped Tuesday.
• Confidence or reasoning trace. Whatever signal the model gave for why — a confidence score, a chain-of-thought summary, the tool calls it made and in what order. This is the field that turns "it did X" into "it did X because Y," which is the only version of the log anyone can act on.
• The human-override point. If a person could have stepped in and didn't, or did, that's part of the record. An agent with no override path logged is an agent nobody can show was ever actually supervised.

Retrieval and tool calls deserve the same treatment as the final action — not summarized after the fact, but logged as they happen, the same discipline multi-tenant RAG already needs at the retrieval boundary for a different reason.

Retention and replay

Six months is the Article 12 floor, not a target worth optimizing toward. The practical reason to keep more: an agent incident rarely gets investigated the week it happens. It gets investigated when a customer disputes something months later, and the log is the only surviving account of what the agent was told and why it acted.

Replay is the feature retention is actually for. Given the five fields above, you should be able to re-run the exact input against the exact model-and-prompt version and get the same decision — not because you need to re-execute the action, but because "we can reproduce this" is the only way to distinguish a real bug from a one-off model quirk. A log you can't replay is a transcript. A log you can replay is evidence.

The schema above is deliberately vendor- and stack-agnostic — it's the shape I'd want regardless of which CRM, which model provider, or which orchestration framework is underneath. If you're implementing it, the fastest way to find the field you're missing is to pick one real agent action from last week and try to fill in all five columns for it by hand. Whichever one you can't fill in is the gap.

What this doesn't solve

Logging is an engineering deliverable. Compliance sign-off is a legal one, and conflating them is how a team ships a technically-complete log and still fails an audit — the schema above doesn't make anyone compliant, it makes the question "what did the agent do and why" answerable, which is the precondition for compliance rather than the substance of it.

It also doesn't make the agent safer. A perfectly logged agent that acts wrongly is still an agent that acted wrongly — the log just means you'll know, and know fast, instead of finding out from the person it affected. Knowing fast matters because most agent failures don't look like bugs until the log is what surfaces them.

If you're standing up an agent that takes real actions and the logging is the part you keep meaning to get to, it's usually the first thing I check.

Sources: What the EU AI Act requires for AI agent logging, EU AI Act Compliance 2026