AI Audit Log Retention Requirements: How Long to Keep Model Call Records

The EU AI Act's Article 12 requires the automatic recording of events over the lifetime of a high-risk AI system, which sets a retention floor measured in the years a system stays in production rather than the days most application logs survive. That single requirement collides with how AI traffic is logged today, where model calls run under a shared key and land in an application log rotated out after 30 or 90 days. When a regulator or an auditor asks for the record of a decision an AI system made eighteen months ago, the log is already gone.

I want to walk through what the retention obligations behind AI records actually ask for across the regimes an enterprise faces, and what a per-decision model call record has to carry so it still answers questions years after the request it documents.

The retention floor is set by whichever regime reaches furthest back

Retention is not one number. EU AI Act Article 12 ties record-keeping to the lifetime of the system for high-risk deployments, so the relevant window is the operational life of that AI, not a fixed calendar period. SOC 2 examinations observe controls across a defined period, commonly twelve months, and expect the evidence for that period to be intact and sampleable at audit time. Financial-sector rules layered on top, from record-keeping expectations under DORA to sector supervisors reviewing AI use, extend the window further for regulated firms.

The practical rule is that you retain to the longest applicable obligation, because a record purged to satisfy a short internal policy cannot be recovered when a longer obligation applies. My view is that most teams set AI log retention by copying their generic application-log policy, which is the wrong reference point once a high-risk system brings Article 12 into scope.

A record only counts if it is still complete years later

A retained log is worth keeping only if it still answers the question that made it evidence. That means each record has to be self-contained at write time. If the record names a user by an internal ID that maps to a directory entry since deleted, the identity is gone even though the log survived. If it stores a request without the policy version in force at the time, you can retain it for a decade and still fail to show which rule governed the call.

So retention is a schema problem before it is a storage problem. A per-decision record has to carry the resolved identity, the role, the data classification, the policy version, the model and destination, the outcome, and the timestamp, all captured at the moment of the call. Records that thin out their context to save space become unreadable exactly when a late-arriving audit needs them, and what to log for AI compliance covers that field set in detail.

Retention and tamper-evidence travel together

A record kept for years invites the question of whether it was altered in those years. Retention obligations imply integrity: the point of keeping the record is to trust it later. Logs written by the application that made the call, into a store that application controls, weaken over a long window because nobody can rule out edits across that span. A record produced by an independent enforcement point and committed before the model responds, with a tamper-evident chain, holds its evidentiary weight across the retention period. That independence, described in audit logging best practices for LLM traffic, is what makes long retention meaningful rather than a compliance checkbox.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect runs as a stateless proxy between your applications, staff, agents, and any LLM, and writes a tamper-evident per-decision record for every model call. Each record is self-contained at write time: identity, role, policy version, data classification, model and destination, outcome, and timestamp, so it still answers questions after the directory entry, the application, or the policy has changed.

Because DeepInspect holds no long-lived state in the request path and emits records to your own retention store, you set the retention window to the longest obligation that applies, whether that is an EU AI Act lifetime record or a financial supervisor's multi-year expectation, and the records stay complete and verifiable across it. To align your AI log retention with the regimes you answer to, book a compliance mapping session.