Per-decision audit record

A per-decision audit record is a single signed log entry produced for every AI request, capturing the identity that called, the data classification on the payload, the policy state at the moment of decision, and the pass-or-block outcome. EU AI Act Article 12 references this granularity as traceability and event logging. Fannie Mae Lender Letter LL-2026-04 (effective August 8, 2026) requires disclosure on demand. NIST AI RMF Pillar 3 calls the same primitive action lineage.

How a per-decision audit record stays defensible under review

Aggregate AI logs (one entry per session, daily counts) fail under regulator review because the regulator wants the specific decision, the specific identity, and the specific policy version that produced the outcome. A per-decision audit record carries those fields per request: subject claim, route, prompt classification verdict, policy version hash, decision reason code, outcome, latency, model destination.

Write-path independence is the architectural property that makes the record trustworthy. When the same application that makes the AI request also writes the audit log, the log inherits the application's blind spots. An external policy decision point with its own write path produces audit records the application cannot rewrite. The record gets cryptographically signed at write time so any later mutation is detectable. The DeepInspect format spec implements this pattern; the EU AI Act, DORA, and Fannie Mae review all reference the same underlying obligation under different vocabulary.

Related reading

  • AI Audit Logs: The Format Spec That Survives EU AI Act, DORA, and Fannie Mae Review

    AI audit logs that survive regulatory review carry a specific set of fields the EU AI Act Article 12, DORA Article 19, Fannie Mae LL-2026-04, NIST AI RMF, and HIPAA all expect on the same record. The fields cover identity, decision provenance, model identity, policy state, and integrity metadata. The format has to support per-record retrieval and per-series replay. The write path has to sit outside the application so the application cannot modify the record. This piece walks through the field-level format specification, the integrity model, the storage characteristics, and the deployment pattern that produces records the regulator and the customer auditor will accept.

  • Signed Audit Logs for AI Requests: Per-Decision Signing and What Regulators Will Accept

    A signed audit log binds a cryptographic signature to each record at the moment the record is committed. For AI requests, the signature ties the record to the inspection layer that produced it and lets a verifier confirm authenticity without trusting the storage layer. The technique is the cryptographic foundation under tamper-evident audit trails the EU AI Act Article 12, Fannie Mae LL-2026-04, HIPAA, DORA, and NIST AI agent identity framework all expect. This piece walks through the signing schemes, the key management, and the verification flow that auditors and regulators will accept.

  • Tamper-Evident Audit Logs for AI: What Cryptographic Integrity Brings to Compliance Records

    Tamper-evident audit logs make any post-hoc modification of a record detectable through cryptographic integrity. For AI compliance records, the property closes the self-attestation gap that application-controlled logs cannot. The technique combines per-record signing, hash chaining, and external anchoring. EU AI Act Article 12, Fannie Mae LL-2026-04, HIPAA, DORA, and NIST AI RMF all expect records that an auditor can rely on as evidence. Application logs that the application can modify do not meet that standard. This piece walks through the cryptographic mechanisms, the operational characteristics, and the architectural placement.

← Back to glossary