AI audit log retention: how long EU AI Act, HIPAA, and DORA expect you to keep per-decision records
AI audit log retention is governed by four overlapping regimes that produce different minimum windows on the same record. The EU AI Act Article 12 expects logs across the deployment lifecycle for high-risk systems, with Article 19 fixing a 10-year period for the records the conformity-assessment file references. HIPAA 45 CFR 164.530(j) fixes six years from creation or last effective date. DORA Article 19 fixes a minimum of five years for ICT-related incident records, with longer windows where the supervisor requests them. The retention schedule has to be set to the longest applicable window per record and the storage tiering, tamper-evidence and GDPR deletion handling have to be designed against that window.
EU AI Act Article 12 requires high-risk AI providers and deployers to keep automatically generated logs for a period "appropriate to the intended purpose of the high-risk AI system," with Article 19 fixing 10 years for the technical-documentation records the conformity assessment references. HIPAA 45 CFR 164.530(j) requires six years from the date of creation or the date the document was last in effect, whichever is later. DORA Article 19 sets a five-year minimum for ICT-related incident records and grants the competent authority discretion to extend the window. Three regimes, one record, three different floors.
I want to walk through the retention windows each regime sets, why the floors differ, how to lay out hot, warm and cold storage so the cost stays sane across a 10-year window, what tamper-evidence the regulators specifically look for, and how the GDPR right to erasure reconciles against a mandatory retention schedule.
What each regime fixes as the minimum window
The four regimes touch the same per-decision record and produce four different minimums. The table below shows the floor, the trigger that starts the clock, the article reference and the artefact the regulator inspects.
(*) Article 12 does not fix a numeric floor; the EU AI Act guidance and Annex IV practice put the working minimum at six months for high-risk systems, with the 10-year Article 19 ceiling on the technical file.
The retention schedule is set against the longest applicable window per record class. A per-decision AI log generated by a HIPAA-covered hospital running a high-risk Annex III system under DORA scope is kept for 10 years, not six.
Why the floors differ and what each one is measuring
EU AI Act Article 12 is measuring traceability across the operational life of the system: the regulator wants the contemporaneous record that explains what the system decided and on what basis. Article 19 is measuring the conformity-assessment file: the regulator wants the artefact that supported the CE-marking decision to be available for the full economic life of the high-risk system, set at 10 years. HIPAA 164.530(j) is measuring the covered entity's policy and decision record: HHS Office for Civil Rights inspects the policy history during a Resolution Agreement review, which is why the floor sits at six years from the last effective date rather than the creation date.
DORA Article 19 is measuring the ICT-related incident record: the European Supervisory Authorities want to reconstruct the incident at year four if a supervisor opens a thematic review of concentration risk. SOC 2 is measuring the auditor's evidence window across the 12-month observation, with the firm's own retention policy typically extending to seven years to support multiple audit cycles.
Storage tier strategy across the 10-year window
A per-decision log generated at scale across a 10-year window is unaffordable on a single hot tier. The architecture splits across hot, warm and cold tiers with explicit promotion and demotion rules.
The promotion rule is age-based with an override for any record under an active legal hold. The demotion rule writes a Merkle root of the demoted batch to the hot tier so the chain-of-custody check at retrieval time can verify the cold-tier record against the hash that lived on the hot tier the whole time.
What tamper-evidence the regulators specifically look for
EU AI Act Article 12(2) requires the logs to be capable of identifying situations that may result in the AI system presenting a risk. Article 19 requires the technical file to be kept "for the conformity assessment authority's investigation." DORA Article 19(3) requires the incident record to be "verifiable" by the competent authority. HIPAA 45 CFR 164.530(c) requires the covered entity to apply appropriate administrative, technical and physical safeguards to the record.
The mechanism that satisfies all four regimes is a per-record cryptographic signature committed at write time, with the signing key held outside the system that generated the record. The signature is verified at read time. The verification chain is documented in the technical file. A Merkle tree over each day's batch produces a single root that the verifier inspects, which scales the verification cost down from per-record to per-day.
Deletion-on-request reconciliation under GDPR
GDPR Article 17 grants the data subject a right to erasure. EU AI Act Article 12 and HIPAA 164.530(j) impose mandatory retention. The two are reconciled at the design layer, not at the runtime layer.
The reconciliation has three moves. First, the per-decision record stores the user identifier as a pseudonymous key, with the mapping from key to natural person held in a separate identity store under shorter retention. Second, the erasure request invalidates the mapping in the identity store while the per-decision record remains intact with the pseudonymous key in place. Third, the regulator's right-of-inspection over the per-decision record persists because the record carries the decision context without the natural-person identifier. The Article 6(1)(c) lawful basis (compliance with a legal obligation) overrides the Article 17 erasure request to the extent the retention is legally required.
DeepInspect
This is the audit-log discipline DeepInspect is built to deliver across the EU AI Act, HIPAA and DORA windows. DeepInspect operates as a stateless proxy between authenticated users or agents and any LLM endpoint. The per-decision record is committed by the proxy, independent of the application that issued the request and independent of the LLM provider that returned the response. The record carries the verified identity, the role context, the data classification, the model and version, the policy version, the decision outcome and a cryptographic signature against a key held outside the proxy.
The retention schedule is configured per route. A route serving a high-risk Annex III deployment carries the 10-year Article 19 retention with the storage tiering described above. A route serving HIPAA traffic carries the six-year 164.530(j) floor. A route serving DORA-scoped financial systems carries the five-year Article 19 floor with a documented extension path for a competent-authority request. The cryptographic chain is verifiable on demand across the full retention window.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does EU AI Act Article 12 fix a numeric retention floor?
Article 12 itself does not fix a numeric floor. The text requires logs "appropriate to the intended purpose" and references Article 19 for the technical documentation file at 10 years. The European Commission guidance on Article 12 implementation, alongside the Annex IV technical-file practice, puts the working minimum for the operational log at six months for high-risk systems. A deployer running under the 10-year Article 19 technical-file obligation typically aligns the operational log to the same 10-year window so the file and the log reconcile at any inspection point.
- How does HIPAA 164.530(j) interact with the EU AI Act window?
A US hospital deploying a high-risk Annex III system that processes data of EU patients sits inside both regimes. The retention floor is set at the longer of the two: 10 years against Article 19, six years against 164.530(j). The hospital configures one schedule against the 10-year window and meets both. The six-year HIPAA floor matters where the system is HIPAA-only and not in scope for the EU AI Act.
- Where does DORA Article 19 fit alongside the EU AI Act for a bank running an AI risk model?
The bank is in scope for both. The AI risk model used in credit decisioning sits inside the EU AI Act Annex III high-risk list. The same model sits inside DORA Article 6 ICT risk management. The retention floor is 10 years against EU AI Act Article 19 for the technical file and five years against DORA Article 19 for the ICT incident record. The two records are kept separately because the ICT incident record is keyed by incident identifier and the AI Act log is keyed by decision identifier. Both records reference the same underlying API call.
- Does the SOC 2 audit window override the regulatory retention floor?
No. SOC 2 specifies the observation window (12 months for Type 2) and the auditor's evidence requirements within that window. The firm's own retention policy typically extends to seven years to support multiple audit cycles. The SOC 2 window is independent of the regulatory retention floor and does not override it. Where the regulatory floor is higher, the regulatory floor controls.
- How does the GDPR right to erasure interact with mandatory retention?
The two are reconciled through pseudonymisation at write time. The per-decision record holds a pseudonymous key, the identity mapping sits in a separate store under shorter retention, and the erasure request invalidates the mapping. The per-decision record persists because the legal-obligation basis under GDPR Article 6(1)(c) overrides the erasure request to the extent the retention is legally required. The data subject is informed of the basis under Article 13(2)(a).
- What proves to a regulator that the record was not modified after write?
The proof is a cryptographic signature committed at write time against a key held outside the system that produced the record. The signature is verifiable at read time, the verification chain is documented in the technical file, and a Merkle tree over each day's batch scales the verification cost down. The regulator inspects the verification chain alongside the record itself, and the chain-of-custody artefact closes the integrity question.