Retention Periods for AI Prompts, Outputs and Audit Logs Under the AI Act

You must now set out a documented retention policy for AI prompts, outputs and audit logs, distinguishing between data categories and justifying each period against the AI Act, GDPR and any sectoral rules that apply to your sector.

The prompt is an analysis of 5 August 2026 of retention periods for AI logs under Articles 12 and 19 of the EU AI Act, which argues that retention has shifted from a technical default to an explicit governance obligation. The concrete case is high-risk AI systems, where the AI Act sets a floor of six months' log retention whilst the GDPR's storage limitation principle demands shorter periods for logs containing personal data. In our assessment, this tension means you can no longer leave retention to a service's default settings; you must make an active choice per data category and be able to defend it.

What does the AI Act now require you to retain?

Articles 12 and 19 of the AI Act establish that high-risk AI systems must enable automatic logging throughout their operational lifetime. Those logs must record the period of use, which reference database was consulted, which input data were processed and which natural persons were involved. The purpose is traceability and post-market monitoring. This makes audit log retention a legal requirement, not a best practice.

For high-risk systems, a minimum retention period of six months has emerged as the de facto standard across most categories. This window reflects the timeframe within which oversight and investigation typically occur. However, technical documentation and training records for general-purpose AI models must be retained considerably longer. The retention period is therefore not uniform; it depends on the type of data and the regime under which it falls.

Where does the GDPR create a tension with the AI Act floor?

The GDPR's storage limitation principle in Article 5(1)(e) does not prescribe fixed periods, but anchors a requirement that personal data be kept only as long as necessary for the processing purpose. This creates a ceiling where the AI Act sets a floor. Prompt logs containing personal data, for example, must be retained for shorter periods than the AI Act's six-month minimum would suggest—often thirty days or less—because the lawful basis for keeping them expires sooner.

This is not a conflict to be resolved by choosing one rule over the other. Instead, you must apply both: the AI Act sets the lower bound for audit logs of high-risk systems, and the GDPR sets the upper bound for any data that can identify individuals. A single log may therefore fall under both regimes, and you must satisfy the more restrictive requirement.

Which concrete retention periods should your policy establish?

No single uniform period applies across all data categories. A workable policy distinguishes at least three tracks:

1. Prompt logs containing personal data — retain for the minimum period necessary under the GDPR, typically thirty days or less, unless a specific lawful basis justifies longer retention.
2. Bias audit records and model performance logs — retain for periods linked to concrete obligations such as data protection impact assessments or algorithmic impact assessments, typically two years.
3. High-risk AI system audit logs — retain for at least six months as required by the AI Act, unless sectoral regulation demands longer retention.

For regulated sectors, a further layer is added. Financial services, for instance, often face statutory retention obligations of five to seven years. In that context, "as long as necessary" is partly determined by sectoral rules, so AI logs must be retained far longer than the AI Act minimum.

How do you demonstrate compliance with retention periods you have set?

The difficulty lies in execution. You must retain traceability and at the same time be able to demonstrate that you do not keep data longer than necessary. This requires maintaining a view per workflow of which prompts, outputs and logs are still present, and being able to record in an auditable way when data have been anonymised or erased.

You should be able to show:

1. Document your retention policy per data category — set out which data types you retain, for how long, and on the basis of which legal obligation.
2. Record the lawful basis for each retention period — link each period to the AI Act, GDPR, sectoral rules or a combination of these.
3. Maintain an inventory of what is retained and where — track which prompts, outputs and logs exist in each system and storage location.
4. Demonstrate deletion or anonymisation — record when data have been removed or rendered non-identifiable, with timestamps and method.
5. Audit the workflow end-to-end — verify that only data meeting your retention criteria remain in logs and that nothing is kept beyond the justified period.

Those who set this up in advance do not have to reconstruct afterwards why a prompt still existed or an audit log had already disappeared. The new guidance does not change what you assess on substance—that judgement remains yours. What does change is the expectation that you can explain your retention periods explicitly: how long, for which data category, and on the basis of which combination of rules.

Tooling can help limit the amount of identifying data that ends up in logs at all and make visible per workflow which steps have been taken. But the choice of what to retain, for how long, and why remains a professional judgement that no system can make for you.