How long must AI logs be retained?
Under the EU AI Act, the automatically generated logs of a high-risk AI system must be kept for at least six months — by the provider under Article 19 and by the deployer under Article 26(6), each to the extent the logs are under their control, for a period appropriate to the system's intended purpose. Six months is a floor, not a schedule: other Union or national law can require longer, financial institutions keep logs under their sector's record-keeping rules, and the period must fit the purpose — which for many systems means years.
Last updated: 2026-06-10 · Regulation (EU) 2024/1689 and the Digital Omnibus provisional agreement of 7 May 2026
The duty
Who keeps what
What gets retained. The logs in question are the ones Article 12 requires high-risk AI systems to be capable of producing: automatic recording of events over the system's lifetime, sufficient to trace its functioning, identify risk situations, and support post-market monitoring. Retention is downstream of record-keeping — if the Article 12 logs are thin, retaining them faithfully preserves thin evidence. See Article 12, explained.
Providers (Article 19). Keep the automatically generated logs to the extent the logs are under their control, for a period appropriate to the intended purpose — at least six months, unless Union or national law (data-protection law in particular) provides otherwise.
Deployers (Article 26(6)). A parallel duty for the organization operating the system: keep the logs under your control, same six-month floor. In practice the deployer often holds most of the operational logs, so the duty lands on the team running the system, not just the vendor that shipped it.
Financial institutions maintain the logs as part of the documentation kept under their financial-services law, whose record-keeping periods are typically multi-year — in practice the six-month floor is academic for them.
Timeline
When the duties start applying
Under the Digital Omnibus provisional agreement of 7 May 2026 (pending formal adoption), the high-risk obligations — including Article 12 record-keeping and the retention duties that depend on it — are expected to apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for high-risk AI embedded in regulated products. The practical consequence of a retention duty plus a deadline: logs a deployer will need to produce in 2027 have to start accumulating before 2027, in a form worth retaining. The full timeline and article-by-article mapping live on the EU AI Act crosswalk.
The other direction
The GDPR pulls retention the other way
Retention duties say keep the logs; the GDPR's storage limitation principle says keep personal data no longer than necessary. Article 19 itself defers to Union data-protection law. For AI-agent logs — which can easily capture names, account identifiers, and free-text content — the two obligations collide head-on.
The practical resolution is log design rather than a legal trick: keep the accountability record — record identifiers, hashes, signatures, state transitions — long-lived, and keep personal-data payloads under your GDPR retention schedule, referenced from the record by identifier or hash rather than embedded in it. A record that stores a hash of a deliverable can outlive the deliverable: the evidence of what was recorded survives; the personal data does not have to. Where record fields are themselves personal data, the Article 19 duty is the documented retention basis — the design minimizes what needs one, it does not exempt the record.
The catch
Retention is the floor, not the point
A retention duty is satisfied by keeping bytes. But the reason regulators want logs kept is so the logs can settle questions later — and a log only settles questions to the degree it is tamper-evident, attributable, and verifiable by someone who does not trust the operator that kept it. Six months of self-attested, operator-controlled logs proves six months of storage discipline, nothing more. The properties that make retained logs worth retaining are the subject of AI accountability; how plain retention infrastructure compares to a signed record is covered in the SIEM + Object Lock comparison.
Implementation
Meeting the floor, and the years past it
Any durable store can hold logs for six months; the harder requirements are appropriate-to-purpose periods measured in years, GDPR deletion of payloads that does not silently erase the evidence they existed, and records that remain verifiable at the end of the window. AGLedger is one implementation built for that shape: records live in an append-only audit vault where nothing is deleted or overwritten, so the six-month floor is exceeded by default; deliverables referenced by hash can be deleted under a GDPR schedule while the signed record of them survives; optional anchored checkpoints in write-once storage carry their own object-lock retention window (default roughly seven years, configurable); and the chain can be exported and verified offline at any point in the window, including after the system that wrote it is gone.
FAQ
Common questions
How long must AI logs be kept under the EU AI Act?
At least six months, for the automatically generated logs of high-risk AI systems. Article 19 places the duty on providers and Article 26(6) places a parallel duty on deployers, each to the extent the logs are under their control, for a period appropriate to the intended purpose of the system — with six months as the floor, unless other Union or national law provides otherwise.
Does the six-month rule apply to every AI system?
No. Articles 12, 19, and 26(6) attach to high-risk AI systems as classified by the Act. Systems outside the high-risk categories carry no AI Act logging or retention duty, though sector rules, contracts, or litigation holds may still require keeping records.
When do the logging and retention duties start applying?
Under the Digital Omnibus provisional agreement of 7 May 2026 (pending formal adoption), the high-risk obligations — including Article 12 record-keeping and the retention duties that depend on it — are expected to apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for high-risk AI embedded in regulated products. Evidence a deployer will need then has to start accumulating earlier.
Does GDPR conflict with keeping AI logs?
There is a real tension. GDPR storage limitation says personal data is kept no longer than necessary; the AI Act says logs are kept at least six months. Article 19 itself defers to Union data-protection law. The practical resolution is log design: keep the accountability record — record identifiers, hashes, signatures, state transitions — long-lived, and keep personal-data payloads governed by your GDPR retention schedule, referenced from the record by identifier or hash rather than embedded in it. Where record fields are themselves personal data, the Article 19 duty is the documented retention basis; the design minimizes what needs one, it does not exempt the record.
Is keeping logs in WORM storage enough to satisfy retention duties?
For the letter of a retention duty, often yes — WORM storage demonstrates the logs were kept and not deleted. But retention is the weakest property a log can have: it does not show the logs were authentic when written, who or what the actions are attributable to, or give an outside reviewer a way to verify any of it without trusting your account. Where the evidence has to persuade a skeptical party, retention needs tamper-evidence and attribution on top.
Go deeper
Article-by-article mapping, including the Article 19 retention row and the full timeline.
The record-keeping obligation the retention duty depends on.
The mechanisms that make retained logs worth retaining.
The category definition: integrity, attribution, independent verifiability.
Retention versus authenticity, against the most common way retention duties are met today.
What the Article 12 logs should actually contain.