How long may you keep an AI prompt? And how long must you actually retain an audit log? For a long time these were mainly technical configuration questions, determined by the default settings of the tools in use. A series of guidance and practical guides from 2026 shows that this non-committal approach is disappearing. In an analysis dated 3 July 2026, AI Audit Log Retention Under the EU AI Act, DeepInspect translates Articles 12 and 19 of the EU AI Act into a concrete retention policy. The core: for high-risk AI systems a hard lower limit emerges of at least six months of log retention, while at the same time the storage limitation principle in the GDPR calls for shorter periods for logs containing personal data.
That tension makes retention periods an explicit policy decision. Anyone working with confidential information can no longer leave retention to a service's default, but must set out per data category — prompts, model output and audit logs — what applies and why.
The AI Act sets a floor beneath audit logs
The official guidance from the AI Act Service Desk on Article 12 confirms the legal foundation. High-risk AI systems must enable automatic logging throughout their entire lifetime. Those logs must record, among other things, the period of use, which reference database was used, which input data were processed and which natural persons were involved. The purpose of that recording is traceability and support for post-market monitoring. This makes the retention of audit logs not a best practice, but a requirement.
The developer guide from Sota.io, EU AI Act Art.12 Logging & Record-Keeping of 10 April 2026, makes this concrete for log and retention architecture. The guide describes six months as the explicit minimum period for biometric identification systems and as the de facto standard for other high-risk categories, via the windows within which oversight and investigation take place. At the same time Sota.io points out that technical documentation and training records for GPAI models must be retained considerably longer. There is therefore no single uniform period: it depends on the type of data and the regime under which it falls.
The GDPR pushes the other way: no longer than necessary
Where the AI Act sets a floor, the GDPR acts as a ceiling for data that can identify individuals. The retention guide from AI Policy Desk, AI Data Retention Policy Template for 2026 of 29 May 2026, explains that Article 5(1)(e) GDPR does not prescribe fixed periods, but anchors the principle of storage limitation: personal data in, for example, prompt logs may only be kept for as long as is necessary for the processing purpose.
In the schema proposed by AI Policy Desk, those data categories are given different periods. Prompt logs with personal data are set at thirty days, for instance, while bias audit records are given two years and high-risk AI logs adhere to the minimum six months from the AI Act. Longer retention periods are explicitly linked to concrete other obligations, such as DPIA requirements or rules like NYC LL144. The message is that every period must have a justified basis, per category.
For regulated sectors a further layer is added. The checklist from Kognitos, AI Audit Trail Requirements: A 2026 Checklist for Finance of 4 August 2026, shows that sectoral regulation — for example in the financial world — often imposes retention periods of five to seven years. In that context "as long as necessary" is partly determined by statutory retention obligations, so that AI logs in fact have to be retained far longer than the AI Act minimum.
Retention as a demonstrable policy per data category
Taken together, these sources point in the same direction. Retention periods for AI data are no longer a technical default, but a governance choice that must be set out per category. A workable policy therefore distinguishes at least three tracks:
- Prompts and outputs with personal data: keep briefly under the GDPR storage limitation, with an explicitly documented period and a clear processing purpose.
- Audit logs of high-risk AI systems: at least six months, linked to Article 12 and post-market monitoring.
- Sector- and documentation-bound records: longer periods where financial, GPAI or other statutory retention obligations require this.
The difficulty lies in the execution. You must retain traceability and at the same time be able to demonstrate that you do not keep data longer than necessary. That means 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.
For a privacy-focused verification console like I am Vera, the relevance lies precisely in that verifiable execution. Vera is not a language model and not a chatbot, but a verification layer: the pre-processing and anonymisation take place on EU infrastructure via the Semantic Privacy Shield, and the workflow is designed to send only anonymised content to the selected AI models. If a privacy check fails, nothing is forwarded. Such a set-up 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.
The new guidance on Articles 12 and 19 does not change what professionals assess on substance — that judgement remains with the user. 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 the AI Act, GDPR and sectoral rules. 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.