Audit and Evidence

AI workloads generate a different audit profile than human ones: far higher volume, longer causal chains, and principals that are not people. The Immutable Ledger records them under the same guarantees as everything else, but the questions you will ask of those records are different.

This page covers what is recorded, and how to configure for the questions that actually get asked.

AI-specific identifiers

Every AI decision record carries the standard fields (tenant, principal, artifact identity, action, policy version, decision, timestamp) plus identifiers that make an AI causal chain reconstructable:

Configure your SIEM ingestion mappings for these before you generate volume. Retrofitting them means reprocessing, and the volume makes that expensive.

What is never recorded

The ledger records decisions, not content. Specifically absent:

• Prompt or completion text. No plaintext model input or output.
• Retrieved content. The artifact identity and the decision, never the payload.
• Key material. No data encryption keys, wrapped or otherwise.
• Credentials or tokens. The tenant-scoped principal identifier, not the originating credential.
• Sensitive attribute values where policy marks them as such. The decision records that an attribute was evaluated and the outcome, not necessarily the value.

This is a deliberate constraint and occasionally an inconvenient one, you cannot reconstruct a conversation from the ledger. That is the correct trade. An audit store containing prompt and completion text is a copy of every sensitive thing your AI system ever touched, in a system built for retention rather than for confidentiality.

Where you need conversation content for debugging, that belongs in an application-tier store with its own classification and retention, governed like any other protected data.

Questions to configure for

Confirm you can answer each of these before you consider the AI surface production-ready. Each maps to identifiers above, and each will be asked eventually.

"What did this agent access last Tuesday?"

Query by agent role and time window. This is the routine one, and the one that establishes whether your identity configuration was done correctly, if agents share an identity or authenticate as users, this question has no clean answer. See Workload Identity.

"Which human authorized this?"

Query the delegation chain on the decision record. For an unattended scheduled task there is no human in the chain, and the answer is the agent's own configured authority plus the administrator who granted it. Both are legitimate answers; make sure you can distinguish them.

"Was customer X's data used for training?"

Query admission records by source artifact and purpose. This is the deletion-request and data-subject question, and it is the one where an incomplete answer is most costly. It depends on training data configuration being in place before the corpus was built, it cannot be answered retroactively for content admitted without records.

"Why was this denied?"

Every denial records a reason. Confirm the reasons are legible to the people who will read them: an operator seeing a denial should be able to determine whether it was a missing attribute, a stale decision, a classification mismatch, a destination rule, or a scope violation, without escalating.

This is worth checking during rollout rather than after. Illegible denial reasons generate support load and, worse, generate pressure to loosen controls that were working correctly.

"Did this output have a source?"

Query the output decision record for the provenance outcome and the source artifacts in the authorized context. For workflows where you required provenance, this is the record that establishes a generated claim was grounded. See Output Controls.

"What was in effect when this happened?"

Query the policy version and the control set on the decision record, then the validation record and approval for that control set. This is the chain that lets you state what rules applied at a moment in the past, not what rules apply now. Historical policy versions are retained for exactly this. See Verified Controls.

Volume

AI workloads produce substantially more decision records than human workflows. A single agent task can generate hundreds. Plan for it:

Set retention against the requirement, not the volume. Reducing retention to manage volume trades a compliance obligation for a storage bill. Size the storage.

Aggregate for monitoring, retain in full for evidence. Dashboards and alerts run against aggregates. The full record set is for investigation and audit. Do not sample the record set to make the dashboards cheaper — a sampled ledger cannot answer the questions above.

Alert on rates, not events. A single denial is normal operation. A denial rate change, a new denial reason appearing, or one agent's volume departing from its baseline are the signals worth waking someone for.

Evidence integrity

The properties the ledger provides, and what they mean for AI records specifically:

• Tamper evidence. Records cannot be altered after the fact without detection.
• Bidirectional proof. The presence of a record proves an access occurred; the absence proves it did not. For any tenant-bounded window, the decision set for a given artifact is enumerable and complete. This is what makes "customer X's data was not used for training" a provable statement rather than an assertion.
• Durability before distribution. A decision is committed durably before it is distributed to consumers. The distribution path is transport and replay, it is never the record of authority. A downstream outage delays your SIEM; it does not lose evidence.
• Independent verification. Evidence exports can be verified without trusting the exporting system.

Related

• Immutable Ledger, the underlying guarantees.
• Audit configuration, export and SIEM integration.
• Generate evidence events for a regulated data flow, a worked spec.
• Incident readiness, using this during an incident.