What is an AI audit trail?

An AI audit trail is a per-decision record of what an AI system did with a specific request: who initiated it, what data was involved, what policy governed the decision, what the outcome was, and when it happened. It is different from an application log, which records that a request was processed from the application's own point of view. The audit trail is meant to reconstruct and defend a decision to a third party, so it needs identity context, policy state, and integrity protection that a routine log usually lacks. Regulators across several regimes now require this record for high-risk or regulated AI use, and they expect it to be independent of the system that made the decision.

Which regulations require an AI audit trail?

The EU AI Act requires automatic record-keeping for high-risk systems under Articles 12 and 19. Fannie Mae LL-2026-04 and Freddie Mac Section 1302.8 require audit trails for AI-assisted mortgage decisions. NIST's agent identity and authorization framework specifies action lineage as a control. HIPAA's accounting-of-disclosures obligation applies when AI touches PHI. DORA requires traceable ICT event logging for financial entities using third-party AI services. State laws including the Texas Responsible AI Governance Act add their own record expectations. The vocabulary differs across these regimes, but the underlying record they each need overlaps almost entirely, which is why one well-designed audit architecture can address several at once.

How long do AI audit logs need to be retained?

The EU AI Act sets a floor of at least six months under Article 19, but the operative retention period for a given deployer is the longer of that floor and any other applicable law. Financial institutions in most jurisdictions face record-keeping obligations of five to ten years under existing financial regulation, and healthcare deployers face HIPAA-driven retention tied to the data type. The practical answer for most regulated organizations is that six months is the minimum exposure and the real retention period runs much longer. Designing the audit architecture to support seven years of retention, with the option to extend, keeps a deployment inside the widest set of these obligations rather than the narrowest.

Why do application logs fail audit requirements?

Because the system that makes the AI decision also writes the log, which is the self-attestation problem: the audited system generates its own evidence. That arrangement has three failure modes. Selective logging can omit edge-case failures. The same runtime can wipe or alter its record after a failed action. A process crash can also lose evidence after the model responds and before the application commits the log. Regulators and courts treat a record the audited system can modify as a convenience artifact, not a system of record. Meeting audit requirements needs a record that is independent of the application and committed before the response returns, so the evidence exists and cannot be reshaped after the fact.

AI Audit Trail Requirements: EU AI Act, HIPAA, DORA

AI audit trail requirements converge on one reviewable event: an AI request, the identity or system context behind it, the decision or output, and the evidence needed to reconstruct that event later. The EU AI Act calls for automatic event logging in Article 12. HIPAA's accounting of disclosures and DORA's ICT event records serve different legal purposes. Together, they make a generic application log a poor answer when an auditor asks who sent which data to which model and under which control.

I want to map what each regime asks for, then show why the record they assume is not the log most applications produce.

TL;DR

The EU AI Act, HIPAA, DORA, NIST guidance, and mortgage oversight ask different questions of an AI record. A defensible design preserves the request context, policy state, outcome, integrity controls, and the retention evidence relevant to the deployment.

EU AI Act: automatic recording over the system lifetime

Article 12 of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events over their lifetime. Article 12(3) identifies the event-recording capability needed for traceability, including operational periods and reference databases checked where applicable. Providers keep generated logs under Article 19. Deployers retain the automatically generated logs for at least six months under Article 26(6), unless another law requires longer retention.

Three properties fall out of the text. The recording is automatic, so an operator toggle cannot control it. Coverage extends across the system lifetime, so application state cannot determine whether evidence persists. High-risk obligations have a staged application schedule after Regulation (EU) 2026/1744; teams should check the applicable system category and date in the consolidated text before treating a logging date as universal.

Fannie Mae LL-2026-04: audit trails for AI-assisted mortgage decisions

Fannie Mae issued Lender Letter LL-2026-04, a governance framework for AI and ML in mortgage origination and servicing, with an effective date in August 2026. It requires lenders to maintain audit trails for AI-assisted decisions and to disclose the tools, providers, and safeguards on demand.

The letter holds lenders liable for AI mistakes made by their subcontractors and vendors, which extends the audit-trail obligation past the lender's own systems to every embedded-AI tool in the pipeline. Freddie Mac's parallel requirement under Section 1302.8 has been enforced since March 3, 2026. A lender whose quality-control vendor uses a model to flag loan defects still owns the disclosure obligation for that model's decisions, even though the prompt and response never touched the lender's environment. The audit trail has to reach traffic the lender does not directly control.

NIST, HIPAA, and DORA: the same record under three more names

NIST's AI agent identity and authorization framework names the record directly. Pillar 3 is action lineage: a structured record of who authorized an action, under which policy, at what moment, with what outcome. That is an audit trail described from the controls side rather than the compliance side.

HIPAA's accounting-of-disclosures obligation applies when an AI system touches PHI, and it requires knowing which requests exposed which records to whom. DORA's ICT event-logging regime treats LLM providers as third-party services whose interactions must be traceable for financial entities. I covered the financial-sector reading in DORA AI compliance for banks. Each regime uses different vocabulary for the same infrastructure requirement. The record that satisfies one satisfies the others, because the fields they need overlap almost entirely.

Where application logs fail every regime at once

Most AI deployments produce application logs, and application logs fail the independence test all five regimes assume. When the system that makes the AI decision also writes the record of that decision, you have the self-attestation problem: the system under audit is generating its own audit evidence. I argued this at length in due diligence is not due care.

Application-controlled logs carry three failure modes. Selective logging can record successes while omitting edge-case failures. The same runtime can suppress or alter its own record after a failed action. A process crash can also drop evidence after the model responds and before the application commits the log. A regulator, an auditor, or a court will probe the controls that protect the record, not merely the fact that a log line exists.

What a record that satisfies all of them contains

The intersection of these regimes produces a concrete field list. For every AI request, the trail needs a verified identity for the natural person or agent behind it, the role and authorization context in effect, the data classification applied to the input, the policy version that governed the decision, the outcome, a timestamp precise enough to correlate across systems, and an integrity mechanism preventing post-hoc modification.

Two structural properties make that record defensible. It is independent of the application that made the request, following audit-log immutability practice. And it commits before the model response returns to the application, so the record exists whether or not the application survives the transaction. A record with those properties answers the EU AI Act, Fannie Mae, NIST, HIPAA, and DORA from one artifact.

DeepInspect

This is the record DeepInspect produces. DeepInspect is a stateless proxy between your authenticated users and agents and any HTTP-based LLM endpoint. For every request it evaluates identity, role, data classification, and policy, then writes a signed, per-decision audit record containing all of it. The record commits before the response returns to the application, and it lives independent of the application that made the call.

Because the field set is the intersection of what these regimes require, one audit architecture maps to the EU AI Act, Fannie Mae LL-2026-04, NIST action lineage, HIPAA, and DORA at once, rather than a separate logging project per regulation.

Let's talk today.

Yes, because the field sets these regimes require overlap heavily. A record containing verified identity, role and authorization context, data classification, policy version, outcome, timestamp, and an integrity mechanism satisfies the EU AI Act's Article 19 contents, Fannie Mae's audit-trail expectation, NIST's action lineage, HIPAA's disclosure accounting, and DORA's event logging. The differences between regimes are mostly retention periods and which deployments are in scope, not the shape of the record itself. Building one independent, per-decision audit layer and mapping its fields to each regulation is more defensible and less costly than running a separate logging project per framework, and it produces a consistent format an auditor can read across all of them.