What belongs in an AI workflow audit trail

One record, not five systems

The practical test of an audit trail is a single question asked months later: what happened in this workflow on this date, and who allowed it? If answering means correlating a CI log, a chat thread, a ticket comment and a cloud audit log by timestamp, you have archaeology rather than evidence.

What belongs in the record

Trigger source and the normalized request. The requested subject and the effective subject — these differ more often than teams expect. The authorization snapshot: which resources were checked and what each check returned.

Then the resolved context, every tool call with the profile that permitted it, model usage, task and step state transitions, approval decisions with approver identity and timestamp, generated outputs, and final status.

Snapshot the context, not just the result

For AI-assisted steps, the output alone is not enough. You need what the model was working from: which knowledge documents were in scope, which tool results came back, which profile and limits were in effect.

Without that, a wrong decision cannot be distinguished from a decision that was reasonable given bad inputs — and those call for very different fixes.

Govern access to the evidence too

Audit records frequently contain sensitive operational detail, so reading them is itself a privileged action. Evidence access should follow the same authorization boundaries as the rest of the platform, and secrets must be masked in stored logs.

One more detail worth checking: accessing a log stream should be audited without copying the streamed content into the audit record, or the audit log becomes a second copy of everything it was meant to describe.