Regulators examining AI systems are not just checking that explanations exist — they are evaluating whether the audit trail can answer specific questions: Who approved this model for deployment? What was the model's performance on protected groups at the time of deployment? Has the model's behavior changed since deployment, and if so, how? Were any anomalies detected and addressed? An AI audit trail that cannot answer these questions will not survive regulatory scrutiny.
What Regulators Actually Ask For
The EU AI Act requires high-risk AI systems to maintain logs that enable post-market surveillance and the investigation of incidents. NIST AI RMF Measure 2.5 requires organizations to maintain records of AI system performance over time. The CFPB's adverse action requirements create an implicit audit obligation for consumer credit AI. In our experience working with regulators across the US and EU, the most common audit requests are: a complete decision log for a specific time period, evidence of pre-deployment bias testing, records of any fairness threshold breaches and the organization's response, and the technical documentation for the current model version.
Technical Architecture of a Compliant Audit Trail
A technically sound AI audit trail requires four components operating together. First, an immutable decision log: every prediction made by the model must be stored with its input features, output prediction, explanation, timestamp, and model version identifier. Immutability is critical — regulators must be confident that records have not been altered after the fact. Second, a model registry with versioning: every time the model changes, the change must be documented, tested, and approved through a documented change control process, and the previous version's records must remain associated with that version. Third, a fairness monitoring time series: historical fairness metrics must be stored so regulators can evaluate the model's behavior over time. Fourth, an incident and response log: any anomaly detection alerts, threshold breaches, and the organization's responses must be documented in a structured format.
Common Audit Trail Failures
The most common technical failures we see are logs that do not include model version identifiers (making it impossible to reconstruct which model version produced a specific decision), explanation records stored separately from decision records (making it impossible to associate explanations with specific decisions), and fairness metrics computed at deployment time only rather than continuously. The most common process failures are change control processes that allow model updates without documented approval and incident logs that record alerts but not the investigation or response actions taken.
AIClarum Audit Store
AIClarum's audit store is designed specifically to survive regulatory scrutiny. Every record is immutable, associated with a model version identifier, and linked to the explanation that accompanied the decision. Fairness metrics are computed continuously and stored in a time series. Change control workflows are built into the platform. The audit store exports in structured formats accepted by EU AI Act supervisory authorities and US federal financial regulators.