AI Agent Audit Log Requirements: What to Record and Why

Somebody asks what your agent did on 14 March for one specific customer. AI agent audit log requirements are really one question: can you rebuild a single decision months later, from records nobody edited? Most teams discover the answer is no, and they discover it on the day the question is asked rather than the day the log was designed.

What does an audit log actually have to contain?#

Enough to reconstruct one decision without the person who built the system. That means the inputs as they were, the model and version that ran, the tools it called, the output it produced before anything downstream touched it, and who approved it. Aggregates and averages answer a different question entirely.

The field people leave out is the model version, and it is the one that makes historical records interpretable. Six months later, explaining an odd output is impossible if you cannot say which version produced it, because the current one behaves differently and reproducing the call proves nothing about what happened in March.

The second omission is the retrieved context. An agent that looked up 4 documents and answered from them cannot be assessed on the prompt alone, since the prompt was fine and the retrieval was wrong. Storing document identifiers and versions rather than full text keeps this affordable.

The middle column is the test. A field nobody can name a use for is storage rather than evidence.

Write the output before downstream processing, not after. A record showing the final value in the destination system tells you what was saved, not what the agent said, and the gap between those two is exactly where an integration bug hides.

How is this different from your observability traces?#

Different consumers, different guarantees. Traces exist so an engineer can debug latency and errors this week, so they sample, expire quickly and are edited freely. An audit record exists so somebody can answer a question about one case much later, which requires completeness, immutability and a retention period nobody can casually shorten.

Sampling is the incompatibility that catches teams. A tracing setup keeping 1 percent of requests is a sensible engineering choice and a useless audit record, because the case you will be asked about is chosen by a complainant rather than by your sampler. Audit records cannot be sampled.

Coverage is the incompatibility. Everything below it follows from who is going to read the record.

The practical answer is two sinks rather than one system doing both badly. Emit the audit record to append-only storage on every decision, and let tracing stay sampled and cheap for its own purpose. Trying to make one pipeline satisfy both usually produces a trace store that is too expensive and an audit trail with holes in it.

How long do you have to keep it?#

At least 6 months for automatically generated logs of high-risk systems under the AI Act, and longer where other law says so. That figure is a floor rather than a target, and data protection rules, sector regulation and your own contracts routinely push the real number higher.

The word doing the work is high-risk. The Act's record-keeping duties attach to systems in defined high-risk categories, and a lot of internal automation is not one. Establish which side of that line you are on before you commit to the obligations, because copying them unnecessarily is expensive and ignoring them when they apply is worse.

Three periods interact and the longest wins. The Act's floor is one input. Your sector may set another, and limitation periods for the claims somebody could actually bring against you set a third, often measured in years rather than months. A record that expires before the claim window closes was never a defence, only a cost.

Pick a retention period deliberately either way. The failure mode is having no policy, which in practice means logs live until a storage bill is questioned and are then deleted by whoever was asked to reduce it, usually a few weeks before somebody needs them.

The longest of the three wins. A record expiring before the claim window closes was only ever a cost.

What breaks when the log itself holds personal data?#

Your erasure obligations collide with your retention obligations. Prompts contain whatever the customer typed, which is frequently personal data, so the audit trail you built as a defence becomes a data protection liability with its own deletion duties pointing the opposite way.

The workable resolution is to separate identity from content. Store the record with a stable subject reference rather than the personal data itself, keep the personal fields in a store you can actually delete from, and accept that a redacted record still proves the decision was made, which is the point.

Each of these passes every day until the day somebody asks about one specific case.

Test the deletion path before you need it. A subject erasure request against an append-only store is a genuinely hard problem if nobody designed for it, and discovering that during a 30 day statutory window is a bad time to start. Redacting personal data in the pipeline is the upstream half of this.

What does this cost to run?#

Less than people fear, because the expensive part is text and most of it is unnecessary. Storing document identifiers rather than retrieved passages, and hashes rather than full prompts where the prompt is reconstructable, cuts the volume sharply while keeping the record able to answer the question it exists for.

Completeness comes before immutability. An append-only store with gaps is still a store with gaps.

The same record pays for itself three ways: training data, a dispute shield, and a fix ticket. Volume is worth estimating rather than assuming. An agent handling 2,000 decisions a day writes 730,000 records in a year, and at a few kilobytes each that is single-digit gigabytes, which is unremarkable. The number only becomes alarming when every record embeds full retrieved passages, which is the design choice to avoid rather than a reason to log less.

The cost that does bite is engineering, not storage. Append-only guarantees, a deletion path that does not break immutability, and a retrieval interface somebody can use under pressure are real work, and they are much cheaper before the log has 6 months of data in the wrong shape. Tracing at the call level gives you the plumbing; the guarantees are what you add on top.