Retention periods for AI prompts, outputs and audit logs under the AI Act and the GDPR

There is no single retention period for everything an AI system produces. Under the EU AI Act, providers and deployers of high-risk AI systems keep the automatically generated logs under their control for a period appropriate to the system's purpose, of at least six months, unless other Union or national law, in particular data protection law, provides otherwise. Under the GDPR, prompts, outputs and logs that identify people may be kept no longer than their purpose requires, and the controller must be able to demonstrate that. Public archives in Australia and the United States reach the same conclusion from a records perspective: keep what documents a decision, and dispose of the rest under an approved rule. In our analysis, the defensible answer is a retention matrix per data category, with a purpose, a legal basis, a period, a trigger and proof of deletion for each.

Why is there no single retention period for AI prompts, outputs and logs?

Because an AI workflow produces several different kinds of information, and each falls under its own rules. A prompt may contain personal data or privileged client information. An output may become part of a file, a decision or advice to a client. A log may be the only evidence of how a high-risk system behaved. Technical documentation describes how the system was built.

Each of these categories answers to a different regime. The AI Act sets minimum retention for logs of high-risk systems and for provider documentation. The GDPR sets a maximum for anything that identifies a person. Records and archives law decides what counts as a record of official business. Sector rules, such as financial services law, add their own obligations.

In our analysis, most retention disputes start when an organisation treats all of this as one "AI data" bucket with one default period, usually the setting the vendor shipped with. That default is a technical choice, not a legal assessment.

What does the EU AI Act require for logs of high-risk AI systems?

Article 12 of the AI Act requires that high-risk AI systems technically allow for the automatic recording of events (logs) over the lifetime of the system. The logging must enable the recording of events relevant for identifying situations that may result in a risk or a substantial modification, for post-market monitoring under Article 72, and for the deployer's monitoring of the system's operation under Article 26(5).

For one category, remote biometric identification systems listed in point 1(a) of Annex III, Article 12(3) specifies the minimum content: the period of each use, the reference database checked, the input data that led to a match, and the identification of the natural persons involved in verifying the results. Those detailed items apply to that category; for other high-risk systems the content follows from the purposes in Article 12(2).

Retention itself is set in two places. Article 19 obliges providers to keep the automatically generated logs under their control "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", unless applicable Union or national law, in particular on personal data protection, provides otherwise. Article 26(6) places the same obligation, with the same six-month floor, on deployers for the logs under their control.

Two details matter for decision-makers. First, the obligation attaches to logs "under their control": if a vendor holds the logs, the contract decides whether you can meet it. Second, financial institutions that are subject to internal governance requirements under Union financial services law keep these logs as part of the documentation required by that law, which usually means longer periods.

The AI Act also sets a much longer period for provider documentation. Under Article 18, providers keep the technical documentation, the quality management system documentation, decisions of notified bodies and the EU declaration of conformity available to the authorities for ten years after the system is placed on the market or put into service.

These duties apply to high-risk systems from the dates the high-risk rules take effect for each category, as set out in our analysis of the AI Act after the Digital Omnibus.

How does the GDPR limit how long AI prompts and logs may be kept?

Article 5(1)(e) GDPR requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed". Article 5(2) adds that the controller must be responsible for, and be able to demonstrate, compliance with that principle.

The GDPR does not set a number of days. It sets a test: is there still a purpose that requires this data in identifiable form? For AI workflows that test applies separately to each category. A prompt with a client's name that was used once to draft a letter has a different purpose, and a shorter justified life, than an audit log that documents a decision about that client.

The AI Act and the GDPR are written to fit together here. Articles 19 and 26(6) set their six-month floor "unless provided otherwise" in Union law on the protection of personal data. In our reading, that means the floor does not override data protection law, and that the period above the floor still has to be justified by the purpose of the system. Keeping identifiable logs for years "because the AI Act requires logging" is not a defensible reading of either regulation.

A practical consequence: the less personal data enters prompts and logs in the first place, the easier both obligations become. Pseudonymising identifying values before they reach a model, and logging references instead of full content where the purpose allows, reduces what has to be justified later.

What do public archives say about keeping AI records?

Two national archives have issued guidance that is useful well beyond the public sector, because it answers the question every organisation faces: which of these AI materials is a record?

Australia (Commonwealth agencies). The National Archives of Australia states that agencies "do not need to retain every AI output, prompt, input or chat log". They should apply existing records authorities and a consistent, risk-based approach. Outputs are retained where they are final records, substantially contribute to a significant record, provide evidence of a high-risk or sensitive activity, or are relied on as evidence of a recommendation or decision. Prompts, inputs, source data and metadata are retained "where they are necessary to provide context to support a retained AI output or demonstrate how a decision was reached". Prompt and response logs will generally be low value and eligible for disposal, but agencies need to set an appropriate retention period. Minor drafts, unused research and reference-only outputs can generally be destroyed under normal administrative practice.

United States (federal agencies). A memorandum from the National Archives and Records Administration on applying the Federal Records Act to AI materials makes the same distinction. The use of an AI platform does not, in and of itself, create federal records. Whether an AI material is a record depends on how it is used: whether the agency relies on it in decision-making, uses it to conduct official business, circulates it or incorporates it into an agency system. Prompts captured in an agency system and used for official purposes, meeting summaries that serve as the official record, audit trails used for official business such as investigations, and outputs used for official business are likely records. AI records may only be disposed of under a NARA-approved records schedule; some will be transitory or intermediary records that can be destroyed when no longer needed.

In our analysis, both archives arrive at the same principle from a different legal starting point: retention follows reliance. The more a decision rests on an AI output, the more of its context (prompt, sources, model, reviewer) has to survive with it.

What do regulated sectors add to the picture?

Sector regulators increasingly expect records of how AI was used, even where they have not written a specific retention rule for it.

United States (broker-dealers). FINRA's 2026 Annual Regulatory Oversight Report notes that the use of generative AI "can implicate rules regarding supervision, communications, recordkeeping and fair dealing", and cites FINRA Rule 3110 on supervision. Among the practices it describes are storing prompt and output logs for accountability and troubleshooting, tracking which model version was used and when, and considering how to track the actions and decisions of AI agents. These are presented as considerations rather than a new retention period; the firm's existing recordkeeping obligations determine how long such records are kept.

European Union (financial institutions). As noted above, the AI Act itself routes the logs of high-risk systems used by financial institutions into the documentation kept under Union financial services law.

For lawyers, notaries and other professions with confidentiality duties, professional-secrecy and confidentiality rules may impose additional restrictions on the handling and retention of prompts containing privileged or confidential material; the applicable rules depend on the profession and jurisdiction.

How do you build a defensible retention schedule for AI data?

In our analysis, a retention schedule for AI data holds up when every line in it answers the same eight questions. That turns a vague policy into something a supervisor, auditor or court can test.

1. Category. Prompts and inputs; source documents supplied to the model; outputs; human review and approval records; system logs; model and configuration metadata (model version, settings); technical documentation.
2. Purpose. Why this category is kept at all: documenting a decision, post-market monitoring, troubleshooting, supervision, a legal claim.
3. Legal basis and regime. AI Act (Article 19 or 26(6), Article 18), GDPR purpose and lawful basis, records law, sector law, professional rules.
4. Period. A number, with the regime that sets its floor and the purpose that justifies anything above it.
5. Trigger. When the period starts: creation, closure of the file or matter, end of the system's use, end of a contractual relationship.
6. Location and control. Which system holds it, and whether it is under your control or the vendor's. This decides whether you can meet Articles 19 and 26(6) at all.
7. Deletion method and proof. How it is deleted or pseudonymised at the end of the period, and what record shows that this happened.
8. Owner and exceptions. Who is accountable, and how a legal hold suspends deletion when litigation, an investigation or an access request is pending.

Three distinctions make the schedule workable in practice. Separate what documents a decision from what merely helped someone think: the Australian and US guidance both allow the second to be disposed of early. Keep the context of a relied-on output together with it, so that the prompt, the sources, the model version and the human reviewer can be reconstructed. And keep identifying content out of long-lived logs where a reference or a pseudonymised value serves the same purpose.

For agentic AI the same logic applies with more weight, because an agent's actions can have effects that a single answer does not. How to keep a verifiable timeline of autonomous actions is covered in our guide to logging and reconstructing the actions of AI agents.

What should a board, DPO or CISO be able to show?

In our analysis, an organisation is in a defensible position when it can produce, on request:

• the retention schedule itself, with the eight elements above for every AI data category in use;
• for each high-risk AI system, evidence that its logs are kept for at least six months and where they are kept, including the contractual position where a vendor holds them;
• for each category containing personal data, the purpose that justifies the period and evidence that data is deleted or pseudonymised when the period ends;
• for a sample of decisions that relied on AI output, the retained context: prompt, sources, model version and the person who reviewed and approved it;
• the legal-hold procedure, and evidence that it was applied the last time it was needed.

Human oversight of high-risk decisions needs its own evidence layer, which we describe in our article on logging human oversight per decision.

What should decision-makers ask their AI vendors about retention?

Because the AI Act obligations attach to logs under your control, vendor terms are part of compliance. Before relying on an AI service for work that falls under these rules, it is reasonable to ask:

• Which prompts, outputs and logs does the service keep, for how long, and where?
• Can retention be configured per workspace or per matter, including shorter periods for personal data and longer ones for decision records?
• Can logs be exported in full, so that you can meet a six-month or longer obligation yourself?
• Is customer content used to train or improve models, and can that be excluded?
• What evidence does the vendor provide when data is deleted at the end of a period or on request?
• How does the service support a legal hold?

Retention is not a setting to discover after an incident. It is a decision the organisation takes in advance, per category, with a reason it can explain, and that decision remains with the people accountable for the work.

More articles on this subject are collected in the EU AI Act and compliance overview.

Sources: Retention duties are drawn from the EU AI Act Articles 12, 18, 19 and 26 and GDPR Article 5 on EUR-Lex, with records guidance from the National Archives of Australia and the US National Archives and Records Administration, and sector context from FINRA.