How long must you keep AI decision logs under the EU AI Act, DORA and GDPR?

The EU AI Act sets a floor: providers of high-risk AI systems must keep automatically generated logs for at least six months under Article 19, and deployers must do the same under Article 26(6), with sector law able to extend both. DORA sets no single retention number: financial entities must maintain records of ICT incidents and their register of contractual arrangements to the standard their supervisors require. GDPR sets no fixed period at all: storage limitation means personal data in logs may be kept only as long as a documented purpose justifies.

The mapping matters in 2026 because organisations are writing retention schedules now. DORA has been in force since 17 January 2025, the AI Act's high-risk logging duties bite on the deferred timeline, and the schedules written today are the ones that will eventually be tested.

What exactly does the EU AI Act require?

Article 19 obliges providers of high-risk systems to keep the logs their systems generate automatically, for at least six months, to the extent the logs are under their control. Article 26(6) places a parallel duty on deployers, again at least six months. Both are floors, not ceilings: Union or national law, notably in financial services and employment, can require longer, and for most regulated deployers it will. Building a retention architecture to the bare minimum is rarely the prudent reading of a floor.

When do these logging duties take effect?

On the deferred high-risk timeline. The obligations for stand-alone Annex III high-risk systems, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with high-risk systems embedded in regulated products under Annex I moving to 2 August 2028. The prohibitions have applied since 2 February 2025, the general-purpose model obligations since August 2025, and Article 50 transparency is largely unchanged. We read the deferral as a build window: a logging pipeline and its retention schedule take longer than a compliance quarter to build well.

What does DORA require financial entities to keep?

DORA, in force since 17 January 2025, approaches records through operational resilience rather than a single retention clock. Financial entities must record and classify ICT-related incidents and report the significant ones, and must maintain a register of information covering their contractual arrangements with ICT third-party providers, available to supervisors on request. Retention length is driven by supervisory expectations and national rules rather than by one fixed number in the regulation itself, which in practice means records must remain complete, retrievable and credible for as long as a supervisor might reasonably reach back.

How does GDPR cut the other way?

GDPR pulls against indefinite retention. Storage limitation requires that personal data be kept no longer than necessary for its purpose, and AI decision logs very often contain personal data: the applicant scored, the customer flagged, the employee assessed. Keeping everything forever because a log might one day be useful creates its own compliance risk. The defensible position is a documented retention schedule that names the purpose, the period and the justification for each class of log, and that distinguishes the decision record from the personal data inside it.

How do you reconcile keep-long with delete-soon?

By designing the log, not just the deadline. The workable pattern separates two layers. An integrity layer proves what happened: hashes, versions, timestamps and signatures, holding no personal data. A content layer holds the personal data the decision touched, and follows the GDPR schedule, minimised or deleted when its purpose expires. The integrity layer can then be retained for the long horizons the AI Act and sector law contemplate, and deletion itself should leave a sealed record, so the organisation can show afterwards what was removed, when, and under which schedule.

What is the retention picture in one view?

• EU AI Act: at least six months of automatically generated logs for providers under Article 19 and deployers under Article 26(6), extendable by sector law, applying on the deferred high-risk timeline.
• DORA: incident records and the register of contractual arrangements maintained for supervisors, with length set by supervisory and national rules rather than one fixed number.
• GDPR: no fixed period; personal data in logs held only as long as a documented purpose justifies, under a written retention schedule.

Why must logs be tamper-evident for their whole life?

Because retention without integrity is storage, not evidence. A log that could have been altered proves nothing at year five, whatever the schedule said. On Mickai, a Sovereign Intelligence Operating System that runs offline on operator-owned hardware, every action is sealed into a post-quantum signed audit ledger: FIPS 204 (ML-DSA) is the primary signature standard sealing the ledger, FIPS 205 (SLH-DSA) stands alongside it, and FIPS 203 (ML-KEM) is a key encapsulation standard that plays no signing role. Entries chain to hardware-attested identity, and the ledger verifies offline, so a supervisor, court or auditor can check its integrity without trusting the operator or us. The sealing architecture forms part of the estate described in our 104 filed UK patent applications, which contain 2,340 claims and are owned by Mickai LTD.

“A log you cannot prove intact proves nothing, however long you kept it.”

How the whole system fits together is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Do the six month log duties under the EU AI Act apply now?

Not yet for Annex III systems. The high-risk obligations, including Article 19 and Article 26(6) logging, apply from 2 December 2027 after the Digital Omnibus deferral, and from 2 August 2028 for high-risk systems embedded in Annex I regulated products. GDPR and sector record-keeping duties apply on their own timelines today.

Does GDPR stop me keeping AI logs for six years?

No, provided the purpose is documented. Storage limitation forbids keeping personal data without justification, not keeping it for a long time. A written schedule tying each log class to a legal duty or a defence purpose supports long retention, and separating integrity data from personal data lets the proof outlive the personal data it once contained.

What counts as a log under Article 19 of the AI Act?

The events a high-risk system generates automatically in the course of running: periods of use, the inputs considered and the operational records the system produces. The Act ties the duty to logs within the provider's or deployer's control, which is why architectures keeping logs inside the operator's own perimeter make the duty straightforward to discharge.

How should a bank set one retention period across the AI Act, DORA and GDPR?

It should not set one number. The defensible approach is a schedule per log class: the AI Act floor of six months extended where sector rules require, DORA records held to supervisory expectation, and personal data minimised on its own clock. Tamper-evident sealing is what makes the long periods safe to hold.

What makes an AI decision log tamper-evident?

Cryptographic sealing at write time, chained entries so removal is detectable, signatures under the post-quantum standards FIPS 204 and FIPS 205, identity bound to attested hardware, and verification that works offline. A log copied into ordinary storage and edited leaves no proof either way, which is precisely the weakness sealing exists to remove.