How do we log what the AI did for auditing without creating another copy of sensitive data?

The failure this prevents

An engineering team adds request logging to debug an integration. The logs capture full prompts, which contain full transcripts, which contain customer names, addresses and whatever was said on the call. Those logs land in a monitoring tool with broad internal access, a long retention default, and none of the controls you carefully put on the primary store.

Nobody decided this. It happened because logging defaults are permissive and payloads are convenient. It is one of the most common ways a well-governed system leaks its own protections.

What an audit record should contain

• Trigger. What initiated the run — a schedule, a webhook, a user, a retry — and when.
• Input reference. An identifier or content hash pointing at the record in its proper store. Not the content.
• Configuration. Model identifier, prompt version, rubric version. Without these an old log entry cannot be interpreted.
• Output reference and action. What was produced, where it was stored, and what the system then did with it — wrote a field, queued a draft, sent nothing.
• Human involvement. Who reviewed, approved, edited or overrode, and when. This is the field that matters most in any later dispute.

Deciding where the payload lives

Sometimes you genuinely need the exact prompt and response to debug a problem. The rule is not "never store it" — it is "store it in the same protection class as the data it contains."

That means the same access rules, the same retention clock and the same deletion path as the transcript itself. If a debugging store cannot meet those, it should hold references only. This is a straightforward architectural constraint, and it is the sort of thing worth settling before code is written rather than after an audit asks.

What the log makes possible

A complete audit trail answers the three questions that actually get asked when something goes wrong: which records did the system touch during this window, what configuration produced this specific output, and did a human see it before it landed.

A team that can answer those in minutes can contain an incident. A team that cannot is reduced to guessing at scope, which is how a small error becomes a large project. Traceability is not compliance decoration — it is the thing that lets you safely let automation run against real systems, and it is a requirement we build into every integration that writes anywhere.