AI Evidence Retention Schedules for UK Firms

The audit trail for AI is being created before most firms have decided what it is. Prompts, logs and retrieved documents need retention rules before they become a liability.

Your AI log is already a business record

Most UK firms are now creating a new class of evidence without naming it properly. Every customer prompt, system prompt, retrieved document, tool call, model response, human override and incident note can become part of the story of how an AI assisted decision was made. Treating that material as temporary technical exhaust is convenient, but it is also risky. The better framing is simpler: if the artefact helps prove what the system did, why it did it, what data it used, who approved it, or how a complaint should be investigated, it belongs in an AI evidence retention schedule.

The UK GDPR does not give firms a universal number of days for AI logs. The ICO says organisations must not keep personal data for longer than they need it, must justify retention by purpose, and should use retention policies or schedules wherever possible. That matters because AI prompts and retrieval traces often contain personal data, confidential business information, special category hints, customer complaints, staff names or commercially sensitive documents. A prompt history in Microsoft Copilot, ChatGPT Enterprise, Azure OpenAI, Gemini, Claude, ServiceNow, Salesforce Einstein or a custom RAG tool can quickly become a mixed record containing operational evidence and data protection risk.

What this means in practice is that the question is not, "Should we keep everything or delete everything?" It is, "Which AI artefacts are needed for security, audit, complaints, quality assurance, regulatory assurance and model improvement, and how long is each category justified?" A short lived debug trace might only need days. A customer affecting decision trace may need to align with complaint, contract or regulated record periods. A retrieved document copy may not need to be retained if the source document is already controlled in SharePoint, iManage, NetDocuments, Confluence, Google Drive or a records management platform. The schedule should separate these categories explicitly rather than hiding them in a generic IT logging policy.

The starting point is the ICO storage limitation guidance, which says retention periods should be documented where possible and that old personal data should be erased or anonymised when no longer needed. See the ICO guidance on storage limitation and, for broader AI programmes, its guidance on AI security and data minimisation. Firms that have already built acceptable use policies should extend the same discipline into evidence design. A useful companion is our note on AI input provenance logs for automated decisions, because provenance and retention are two halves of the same control.

If the artefact helps prove what the AI system did, it belongs in an AI evidence retention schedule.

The schedule needs more than one clock

A common mistake is to set one AI logging period and apply it everywhere. That feels tidy, but it rarely survives contact with real operations. Prompts, logs and retrieved documents serve different purposes. They also carry different privacy, confidentiality and evidential risks. A mature schedule should therefore have several clocks running at once: transient observability logs, security investigation logs, user activity records, evaluation evidence, customer decision evidence, incident evidence, model change evidence and source document records.

For example, raw prompt and completion logs used to debug a new internal assistant may only need a short retention period, especially if they contain free text entered by staff. Aggregated evaluation metrics can often be retained longer because they are less identifying and help show the system is improving. Security logs may need longer if they are used to detect prompt injection, credential misuse, unusual retrieval patterns or repeated probing. Customer complaint evidence may need to be retained for the life of the complaint and any related limitation period. Retrieved documents should be treated carefully: if the AI system stores the full document chunk, you may have duplicated the retention obligation. If it stores only a source identifier, version ID and retrieval score, the evidential value may be preserved without keeping a second copy of the underlying content.

NCSC guidance makes the security case clearly. Its machine learning security principles say organisations should be able to audit system use, inputs and outputs, and have appropriate log data to investigate a compromise even if it is not identified immediately. It also links repeated querying and unusual input behaviour to attacks such as prompt injection and model evasion. See NCSC guidance on monitoring and logging user activity and its broader guidance on secure AI operation and maintenance.

What this means in practice is that a retention schedule should be designed with your security, legal, compliance, records, product and operational teams in the room. The policy owner may be data protection or records management, but the retention purpose comes from the workflow. A helpdesk agent copilot, a credit decision assistant, a legal research tool, a board paper summariser and a production code agent do not need the same evidence package. Each use case should state the artefacts retained, the purpose, the retention trigger, the period, the deletion method, the owner, the access controls and the exception process for legal hold or incident preservation.

A single AI log retention period is usually a sign that the firm has not separated debug, security, audit and customer evidence.

UK rules reward purpose, not hoarding

The strongest argument for retaining AI evidence is accountability. The strongest argument against retaining it is also accountability. UK firms have to prove they used AI responsibly, but they also have to prove they did not keep personal data, confidential records or sensitive prompt histories for vague future convenience. That is the tension at the centre of AI evidence retention. It cannot be resolved by saying "logs are useful". It has to be resolved by matching each evidence type to a lawful, documented purpose.

The ICO is explicit that UK GDPR does not set fixed retention periods for different types of personal data. The organisation has to justify the period based on purpose, document standard retention periods where possible, review data, and erase or anonymise personal data when it is no longer needed. It also warns that holding more personal data than needed creates storage, security and subject access request burdens. For AI systems, this is not theoretical. Prompt logs can contain more sensitive material than the business intended to collect because users paste emails, contracts, case notes, screenshots, customer identifiers, HR details or medical information into tools that were never designed as records repositories.

Public sector records guidance points in the same direction. The section 46 Code of Practice under the Freedom of Information Act says public authorities should know what information they hold, why they hold it, how sensitive it is and how it should be managed. It also says information can become a liability if not properly managed, and that records provide evidence of activities. Although many private firms are outside the Code, the principles are useful for any organisation that expects to defend an AI assisted process to a regulator, auditor, client, insurer or court. See the statutory Code of Practice on records management and GOV.UK guidance on using AI to manage the digital heap.

The practical implication is that AI retention schedules should use purpose labels that a non-technical reviewer can understand. "LLM trace retained for 30 days" is weak. "Prompt, response and retrieval metadata retained for 90 days to investigate misuse, security events and quality defects" is stronger. "Decision evidence retained for six years because it forms part of a regulated customer file" may be stronger still, if the business has mapped the relevant obligation. The point is not to invent legal certainty where none exists. The point is to make the decision traceable, reviewable and proportionate.

UK GDPR does not set a fixed AI log period, so the firm has to justify each period by purpose.

Financial services shows why evidence design is urgent

Financial services is a useful stress test because adoption is high, the consequences are tangible and regulators already expect evidence. The Bank of England and FCA 2024 survey found that 75 percent of responding firms were already using AI, with another 10 percent planning to use it over the next three years. Foundation models accounted for 17 percent of all AI use cases. Respondents also expected the median number of AI use cases to rise from 9 to 21 over three years. That is not a lab experiment. It is operational infrastructure spreading through firms that already have conduct, resilience, outsourcing, data protection and senior manager accountability obligations.

The same survey found that four of the top five current AI risks identified by respondents were data related, including data privacy and protection, data quality and data security. The FCA has also said it does not plan to introduce a separate AI rulebook, and will rely on existing frameworks, while taking an evidence based view of benefits and risks. See the Bank of England and FCA report on AI in UK financial services and the FCA page on its approach to AI. In January 2026, the House of Commons Treasury Committee went further, recommending that the FCA publish practical guidance by the end of 2026 on consumer protection rules, accountability and assurance expected from senior managers for AI harms.

This is where evidence retention becomes a board issue rather than a logging decision. If an AI assisted workflow affects affordability assessment, fraud investigation, complaints triage, vulnerable customer handling, suitability review or claims processing, the firm will need more than screenshots and good intentions. It will need to reconstruct which model version was used, which policy or knowledge article was retrieved, whether the retrieved source was current, what the system prompt required, what the user asked, what the model returned, what the human accepted or rejected, and which control failed if harm occurred.

The leading misconception is that retaining less is always safer because it reduces breach impact. Sometimes it does. But over deletion can also destroy the evidence needed to investigate a customer complaint, detect systemic bias, prove a human reviewed a recommendation, or show a regulator that the firm had control. The answer is evidence minimisation, not evidence avoidance. Keep the minimum artefacts needed to prove the control worked, protect them properly, and delete or anonymise the rest on schedule.

The Bank of England and FCA found 75 percent of responding financial services firms were already using AI, with use cases expected to more than double.

Retrieved documents need their own retention logic

Prompts and model outputs get most of the attention, but retrieved documents are often the bigger governance problem. A retrieval augmented generation system can surface HR policies, customer files, support tickets, board papers, contract clauses, product specifications, medical notes, source code, risk registers or regulatory manuals. The user may see only a neat answer, but the system may have stored chunks, embeddings, snippets, citations, document IDs, access control context and reranking data. Each of those artefacts has a different evidential value and a different retention risk.

The first design question is whether the AI platform needs to keep a copy of retrieved content at all. In many cases, the better evidence record is metadata: source system, document ID, version, timestamp, chunk ID, retrieval score, access decision and user identity. That can prove which material influenced the answer without creating a shadow archive of sensitive documents. If the answer itself includes extracted text, then the output may still contain personal or confidential data and must be scheduled accordingly. If the retrieval layer writes full chunks into logs for debugging, those logs should normally have a shorter, tightly controlled retention period and masking rules.

GOV.UK guidance on managing the digital heap is useful here because it reminds organisations that unstructured data includes documents, posts, chat messages, emails, images and recordings, and that repositories often contain some material that should be retained and some that should be deleted. HMRC records policy is also a practical example of lifecycle thinking: records managed by third parties are in scope, owners should be designated, and digital records need metadata that documents authority, status, structure and integrity. See the GOV.UK material on content lifecycle management and HMRC retention and disposal policy.

What this means in practice is that a RAG evidence schedule should distinguish source records from retrieval traces. The source record remains governed by its original system of record. The retrieval trace proves how the AI used it. The generated answer becomes a new record if it is relied on in a business process. That distinction helps firms avoid two bad outcomes: deleting all traces and being unable to explain an answer, or retaining every chunk forever and creating an uncontrolled evidence lake.

For RAG systems, the source record, the retrieval trace and the generated answer should not share the same retention rule by default.

A workable schedule starts with seven fields

The schedule does not need to start as a 60 page policy. It can start as a control table that the business can actually maintain. The first field is evidence category: prompt, completion, system prompt, retrieval metadata, retrieved content copy, tool call, human review, model configuration, evaluation result, incident record or complaint record. The second is use case: customer support copilot, adviser assistant, HR policy bot, legal research assistant, coding agent, finance reconciliation workflow or board pack summariser. The third is purpose: security monitoring, audit trail, quality improvement, complaint handling, legal defence, regulated record, incident response or model evaluation.

The fourth field is retention period and trigger. Be specific: 30 days from creation, 90 days from session close, one year from model retirement, six years from customer relationship end, or until legal hold release. The fifth is content minimisation: store full prompt, redacted prompt, hash, metadata only, sampled output, source ID only or aggregated metric. The sixth is access and location: who can view it, whether it sits in Datadog, Splunk, Azure Monitor, Microsoft Purview, Google Cloud Logging, AWS CloudTrail, OpenTelemetry, LangSmith, Langfuse, Arize Phoenix, Humanloop, Giskard, Galileo or an internal evidence store. The seventh is disposal: automatic deletion, anonymisation, backup expiry, vendor deletion certification or records review.

The counterargument is that this slows teams down. Product teams want observability, engineers want traces, compliance wants assurance and support teams want replay. All fair. But a schedule actually makes deployment faster once the pattern exists. It gives procurement something to ask vendors. It gives engineering default logging profiles. It gives DPOs a basis for DPIAs. It gives security a reason to retain the traces that matter. It gives records teams a bridge between traditional schedules and AI artefacts. It also reduces the number of awkward late questions after a pilot has already filled a vendor console with customer data.

A good first implementation is to choose three live AI workflows and classify every artefact they create. Then write default retention profiles: low risk internal assistant, confidential internal assistant, customer affecting assistant and regulated decision support. Review those profiles against the ICO, NCSC and sector rules, then put them into vendor configuration and operational runbooks. If you need a broader governance wrapper, connect the schedule to your AI register, DPIA, vendor risk review and incident response playbook. Our guide to AI evidence logs as a compliance layer covers the adjacent evidence pack that boards usually need.

A useful AI retention schedule can begin as seven fields: category, use case, purpose, period, minimisation, access and disposal.