The answer is at least six months. The article people cite for it is the wrong one, and the article they confuse it with sets a period five times longer for a completely different set of records. Getting those three provisions apart is most of the work.
Where the period is actually written
Article 12 of Regulation (EU) 2024/1689 is titled record-keeping, and it is the provision that requires a high-risk AI system to “technically allow for the automatic recording of events (logs) over the lifetime of the system”. That is a capability requirement on the product. It says what the system must be able to do. It contains no retention period at all, and reading it looking for one is why so many summaries end up guessing.
The periods live in two other articles, and which one binds you depends on which role you are in:
- Providers — Article 19. A provider of a high-risk AI system shall keep the logs referred to in Article 12(1) that its systems generate automatically, to the extent those logs are under its control, for a period appropriate to the intended purpose, of at least six months, unless Union or national law provides otherwise, in particular Union data protection law.
- Deployers — Article 26(6). Substantively the same duty, in the same words, on whoever puts the system to use under their own authority: at least six months, to the extent the logs are under their control.
Both texts are in the Official Journal version of the Regulation — EUR-Lex publishes Regulation (EU) 2024/1689 in full and Articles 12, 18, 19 and 26 are worth reading side by side once rather than through anyone’s summary, including this one.
This page is a reading of the published text, not legal advice. Whether a given system is high-risk at all, which role you occupy, and whether sector law lengthens the period for you are all questions about your facts — take advice on them rather than adopting six months because a page said so.
The six-month floor, and what it is a floor on
Three qualifications in that sentence do real work, and each one is a place where a compliance rule that says only “keep logs six months” goes wrong.
“Appropriate to the intended purpose” comes first. Six months is the minimum, not the answer. The Regulation asks for a period appropriate to what the system is for, and then refuses to let that period fall below six months. A system whose consequential decisions are reviewed annually, or one whose harms only become visible over a full cycle of applications, has an intended purpose that argues for longer, and a regulator reading your retention policy will read the first half of the sentence as well as the second.
“To the extent such logs are under their control” is a real limit, and a trap. A provider whose system is deployed on a customer’s infrastructure genuinely does not control the logs it emits there. But control is a factual question, not a contractual one: if the logs flow back to you by default, they are under your control whether or not your terms describe them as the customer’s. This is the clause that makes log architecture a legal decision. Where the logs land decides which party carries the duty.
“Unless otherwise provided in Union or national law” can cut both ways. The explicit cross-reference is to data protection law, and the Regulation names it because the obvious tension is with the GDPR’s storage-limitation principle in Article 5(1)(e). Logs of a high-risk system very often contain personal data — inputs, outputs, the identity of the person operating it. Six months of retention is not a lawful basis for keeping personal data for six months; it is a floor the AI Act imposes, which you then have to reconcile with a separate instrument that requires you to justify the period and minimise what is in it. The usual reconciliation is to keep the log but reduce its contents: hold the fields Article 12 requires, and stop treating the log as a convenient archive of everything else.
The ten-year period is a different obligation
Article 18 is where the ten-year figure comes from, and it is not about logs. It requires a provider to keep, at the disposal of national competent authorities for ten years after the system is placed on the market or put into service: the technical documentation under Article 11, the quality management system documentation under Article 17, any documentation of changes approved by a notified body, the decisions and other documents issued by a notified body, and the EU declaration of conformity under Article 47.
The distinction is between the file that describes the system and the record of the system running. The file is static, it is what a conformity assessment was done against, and it has to outlive the product by a decade. The logs are operational, they are generated continuously, and their floor is six months. Article 18 also asks Member States to determine what happens to the documentation if the provider goes insolvent before the ten years are up — there is no equivalent provision for logs, which is a small sign of how differently the two are treated.
Financial institutions and other sector law
Article 19(2) carves out providers that are financial institutions subject to internal governance requirements under Union financial services law: they maintain the automatically generated logs as part of the documentation they already keep under that law. Article 26(6) makes the mirror-image provision for deployers that are financial institutions, and Article 18 does the same for technical documentation.
This is not an exemption. It is a routing rule. The effect is that a bank does not run a second, parallel retention regime for its AI logs; it folds them into the record-keeping obligations it is already examined against, which are frequently longer than six months. If you are in a supervised sector, the AI Act’s number is unlikely to be the binding one, and the practical question is which of your existing retention schedules the AI logs belong in.
When the duty starts applying
The Regulation entered into force on 1 August 2024, but Chapter III — where Articles 12, 18, 19 and 26 sit — applies later, and the date moved in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, adopted on 8 July 2026 and published in the Official Journal on 24 July 2026, amended Article 113 so that the high-risk requirements apply from 2 December 2027 for stand-alone Annex III systems and from 2 August 2028 for high-risk systems that are products or safety components of products covered by the Annex I legislation.
The amending regulation is on EUR-Lex, and it is the text to check rather than any secondary timeline, because it also adjusts the transitional treatment in Article 111 for systems already on the market. Read the two together before concluding that a system you shipped in 2025 is inside or outside the grace period.
Dates in this area have already been amended once and the amending instrument is recent. Before relying on 2 December 2027, confirm it against the consolidated text of Regulation (EU) 2024/1689 on EUR-Lex as at the day you are reading.
Designing a retention rule you can defend
A defensible rule has four parts, and only one of them is a number. Write down which role you are in for each system, because the duty attaches to the role and a company can be provider of one system and deployer of another — the provider and deployer split is the first thing to settle. Write down which logs are under your control and why, in factual terms. Write down the period and the reason it is appropriate to the intended purpose, which is the part that answers a regulator rather than a checklist. And write down the minimisation decision: what the log contains, what it deliberately does not, and how that reconciles with your data protection retention analysis.
The failure mode worth naming is deleting on schedule during an investigation. Nothing in Article 19 suspends your retention rule when a market surveillance authority opens a file, but a routine deletion that lands after you knew about the inquiry is a fact you will be asked about, and it will be read as something other than routine. The practical answer is a documented legal-hold switch that stops expiry — and evidence that it was thrown promptly. What the authority can then demand is covered separately in how audit logs are used in a market surveillance probe.
If your system calls several model providers, the per-provider consoles each hold a partial record with different fields and different retention windows, and none of them is the record of what your system decided. Multigrid keeps one request log across providers, which is the layer where a retention period is actually enforceable.
Top comments (0)