AI Data Retention and Deletion: Prompts to Embeddings

A single prompt to an AI application can leave copies in a provider's abuse monitoring logs, the application's conversation store, an observability platform, a vector index, an evaluation dataset and a backup, and most retention schedules only know about one of them. That matters when a user exercises the right to erasure, when a secret is pasted into a chat, when a contract ends, or when a breach exposes years of stored conversations. This guide is for data protection, security and platform teams running generative AI and agent workloads. It maps where AI data is copied, what the major providers document about their own retention, how deletion behaves in vector stores, derived data and backups, and how to build a retention schedule and deletion workflow that covers every copy. It assumes the general principles in the Data Retention and Secure Deletion Guide and concentrates on what is different for AI.

Key takeaways

Inventory copies, not systems. A retention schedule per system misses the derived copies AI creates: embeddings, traces, caches, evaluation sets and fine-tuning files.
Provider defaults are not zero. OpenAI documents abuse monitoring logs kept for up to 30 days by default and stateful objects such as vector stores kept until you delete them; Azure OpenAI stores data for stateful features in your resource until you delete it.
Embeddings are personal data when their source is. OWASP notes embedding inversion can recover significant source information, so vectors must be deleted with the documents they came from.
Models are the hard case. Data used for fine-tuning cannot be removed from a trained model by deleting the file; plan retraining or retirement, and keep personal data out of training sets in the first place.
Logs are the leak. Exposed chat logs and log tables, as at DeepSeek and McKinsey's Lilli, show that prompt retention is a security exposure, not just a compliance question.

Where AI data is copied

Map each copy for each AI application. The second column is where most organisations discover data they did not know they held.

Copy	Where it lives	Created by	Typical default retention
Conversation history	Application database, provider conversation or thread objects	Chat features, agent memory	Until deleted, often indefinitely
Provider abuse monitoring logs	Model provider	API usage	Provider defined; see the table below
Stored responses and stateful API objects	Model provider or your cloud resource	Responses, assistants, files, batch, fine-tuning APIs	Until deleted, or a provider minimum
Invocation and gateway logs	Your cloud logging (for example Bedrock model invocation logging to CloudWatch Logs or S3), AI gateway	Logging configuration	Whatever the log group or bucket is set to
Traces and observability	LLM observability platform, OpenTelemetry backend	Instrumentation capturing prompts and tool results	Vendor plan default
Embeddings and chunks	Vector database, search index	RAG ingestion	Until re-indexed or deleted
Caches	Semantic cache, prompt cache, CDN	Performance features	TTL, sometimes none
Evaluation and red team datasets	Data science storage, notebooks	Quality review, incident triage	Rarely defined
Fine-tuning data and models	Training buckets, provider fine-tuning jobs, model registry	Customisation	Until deleted; the model persists
Agent scratch and tool outputs	Sandbox file systems, tool server logs, ticket comments	Agent runs	Unmanaged
Backups and replicas	Database, bucket and index backups	Resilience	Backup schedule

Include secrets in the inventory. Users and agents paste API keys and tokens into prompts, and the DeepSeek exposure found plaintext chat history and API secrets in the same log table. See the DeepSeek database exposure.

What providers document about their own retention

Read your provider's current data controls page and contract; these change. The following is what each official page stated when checked on 28 October 2026.

Provider and feature	Documented behaviour	Controls available
OpenAI API: abuse monitoring	Prompts, responses and derived metadata kept for up to 30 days by default, longer where required by law or to protect against harm. API data not used for training since 1 March 2023 unless you opt in	Zero Data Retention or Modified Abuse Monitoring, both requiring prior approval; image and file inputs flagged by CSAM classifiers are still retained
OpenAI API: application state	Responses API retained for at least 30 days when `store` is true or omitted; assistants, threads and vector stores kept until deleted and removed 30 days after deletion; files kept until deleted unless `expires_after` is set; batches, fine-tuning jobs, evals and conversations kept until deleted	Set `store=false`; ZDR forces it for responses and chat completions; stateful endpoints such as vector stores and fine-tuning are not ZDR-eligible
Azure OpenAI in Microsoft Foundry	Models are stateless; data is stored only for files and vector stores, Responses API, assistants threads, stored completions, batch and fine-tuning, in your Foundry resource in the same geography, deletable at any time. Abuse monitoring may store flagged samples in a separate store	Modified abuse monitoring for approved customers; a `ContentLogging` capability with value `false` confirms storage is off
Amazon Bedrock	Model invocation logging is disabled by default; once enabled, logs are kept until the configuration is deleted, in CloudWatch Logs or S3 in the same account and Region, with bodies over 100 KB written to S3. Only the `bedrock-runtime` endpoint is captured	Your own log group retention and S3 lifecycle rules

Two practical points follow. First, deleting a conversation in your application does not delete the provider's abuse monitoring copy, which follows the provider's schedule; record that in your privacy notice and records of processing. Second, objects you create through stateful APIs are your responsibility to delete: an assistant or vector store that is never deleted is kept indefinitely.

Deleting embeddings and RAG data

Keep a source-to-vector map: store the source document ID, chunk IDs and data subject or tenant identifiers as metadata on every vector. Without it, erasure means re-embedding the corpus.
Delete by ID or filter: vector databases support deletion by record ID and by metadata filter. Pinecone, for example, deletes up to 1,000 IDs per request, by metadata filter, or all records in a namespace.
Allow for eventual consistency: vector stores are commonly eventually consistent, so confirm deletion with a query or index statistics before recording the request as complete.
Use namespaces or indexes per tenant: deleting a whole namespace at contract end is simpler and more provable than filtered deletes in a shared index.
Re-check derived copies: caches, search indexes and evaluation sets built from the same chunks need the same deletion.
Treat vectors as sensitive: OWASP LLM08 Vector and Embedding Weaknesses notes that embedding inversion can recover significant source information, so do not argue that vectors are anonymous. See the OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide.

Models, fine-tuning and training data

Deleting a fine-tuning file removes the file, not what the model learned from it. If personal data reached a fine-tuned model and must be erased, the dependable options are to retrain without it or retire the model. Machine unlearning techniques exist in research but should not be relied on as proof of erasure without evidence the regulator accepts; the question of when a trained model contains personal data is covered in the AI and Privacy Guide. The practical controls are upstream: minimise personal data in training sets (NIST SP 800-53 SI-12(2)), keep a record of which datasets trained which model version, and set a retention period for training data separate from the model itself.

Backups, legal holds and erasure obligations

Backups: the UK ICO's position on erasure from backups is that the key issue is to put the backup data "beyond use" even if it cannot be immediately overwritten, use it for nothing else, and tell individuals what happens to their data in backups.
Timescales: the ICO says erasure requests must be answered without undue delay and at the latest within one month, extendable by two further months for complex or multiple requests, with the individual told within the first month. The ICO notes this guidance is under review following the Data (Use and Access) Act.
Recipients: where data was disclosed to others, each recipient must be told of the erasure unless impossible or disproportionate (UK GDPR Article 19). AI providers, observability vendors and agent tool services are recipients.
Storage limitation: GDPR Article 5(1)(e) requires that personal data is kept no longer than necessary, so "keep prompts in case they are useful" is not a retention justification.
Legal holds: a hold can suspend deletion for named data. Scope holds to specific users, matters and copies, record them, and lift them, so a hold on one conversation store does not freeze all AI logs.
Media sanitisation: for decommissioned storage that held AI data, follow NIST SP 800-88 Rev. 2 Guidelines for Media Sanitization (final, September 2025), which supersedes Rev. 1.

Building the retention schedule

Copy	Suggested starting point	Rationale
Conversation history shown to users	User-controlled deletion plus a maximum age set by purpose	Storage limitation; users expect to delete their chats
Prompt and response content in logs and traces	Short (days to weeks), redacted, restricted access	Needed for debugging and abuse review, high sensitivity
Metadata (token counts, tool names, IDs, timings)	Longer, aligned to security log retention	Needed for investigations without holding content
Agent action audit records	Per regulatory requirement for the sector	Accountability; see audit trail obligations
Embeddings and chunks	Same as the source document	Derived data follows its source
Evaluation datasets	Fixed review date; anonymise or synthesise where possible	Often copied from production without a schedule
Training data	Defined period after the model version is retired	Reproducibility versus minimisation

These are design starting points, not legal requirements; set the actual periods with your data protection officer and counsel. For agent audit records needed by regulators, see the AI Agent Audit Trails for Regulators Guide.

Implementing deletion end to end

Inventory: for each AI application, list every copy in the table above with owner, location, retention and deletion method. Include vendor-held copies from contracts and data controls pages.
Tag at creation: carry user, tenant and source document identifiers through prompts, logs, traces and vector metadata so a deletion can find every copy.
Minimise at source: turn off content capture where it is not needed (OpenTelemetry GenAI content attributes are opt-in), set store=false where stored responses are not used, and redact secrets and identifiers before logging.
Automate expiry: log group retention, bucket lifecycle rules, cache TTLs, file expires_after settings and scheduled deletion of stale provider objects.
Build the erasure workflow: one request triggers deletion across all copies, including provider API objects and vector records, and records the result per copy.
Test: create a synthetic user, generate data through every feature, request erasure, and search every store, including backups, for remnants.
Roll back safely: run new automated expiry in report-only mode first, listing what would be deleted, before switching it on; deletion cannot be undone.

Where identity fits

Deletion jobs are non-human identities with destructive rights across many stores. Give each its own identity, scoped to delete rather than read where the platform allows, with its credential in a vault and its actions logged. Provider API keys used by deletion jobs should be separate from inference keys so they can be rotated without outages. See the Secrets Management Guide.

Detection and measurement

Percentage of AI applications with a complete copy inventory and named owner for each copy.
Erasure requests completed across all copies within the statutory period, and median completion time.
Count of stale provider objects (assistants, vector stores, files) older than their retention, found by a scheduled scan.
Percentage of prompt and trace stores with redaction and a defined retention below your maximum.
Secrets detected in prompt logs per month, and time to purge and rotate them.

Monitor for the failure itself: alert on log groups or buckets holding AI content with retention set to never expire, and on vector indexes whose record count only grows.

Framework mapping

Framework	Reference	How it applies
NIST CSF 2.0	ID.AM-07, PR.DS-01, PR.DS-11, GV.OC-03	Data inventories, protection at rest, backups, legal and privacy requirements
NIST SP 800-53 Rev. 5	SI-12, SI-12(2), SI-12(3), AU-11, MP-6, PM-5(1), CM-12, SA-9	Retention, minimising PII in training, disposal, log retention, sanitisation, PII inventory, information location, external services
UK GDPR and EU GDPR	Articles 5(1)(e), 17, 19, 28	Storage limitation, erasure, notifying recipients, processor terms
OWASP Top 10 for LLM Applications 2025	LLM02 Sensitive Information Disclosure, LLM08 Vector and Embedding Weaknesses	Retention and deletion policies; embedding inversion risk

Common failure patterns

Deleting the chat, keeping the trace: user-facing deletion works while the observability platform keeps full prompt content for its plan default.
Orphaned provider objects: vector stores, files and assistants created in experiments and never deleted, retained indefinitely under the provider's documented behaviour.
No source mapping in vectors: erasure becomes impossible to prove without re-indexing everything.
Plaintext conversation stores: years of chats in an unencrypted production database become the breach. In the McKinsey Lilli case, researchers reported 46.5 million chat messages stored in plaintext alongside 3.68 million RAG chunks, figures McKinsey's forensic review did not confirm as accessed.
Logs as a data store: analytics tables holding raw prompts and secrets with no authentication or retention, as in the DeepSeek exposure.
Forgetting agent side effects: agents copy prompt content into tickets, emails, documents and tool server logs. Those systems have their own retention and must be in the erasure workflow, or the deleted conversation survives in the records the agent wrote.
Fine-tuning on production chats: personal data copied into a model that cannot be selectively erased.

Practitioner checklist

Build a copy inventory for every AI application, including provider-held and vendor-held copies.
Record each provider's documented retention and the controls you have enabled, with the date checked.
Set store=false and disable content capture wherever stored content is not needed.
Tag prompts, logs and vectors with user, tenant and source identifiers.
Automate expiry for logs, traces, caches, files and stale provider objects.
Run one erasure workflow that covers every copy and records the result for each.
Keep personal data out of fine-tuning sets and record dataset lineage per model version.
Test erasure with a synthetic user each quarter, including a backup restore check.

AI Data Retention and Deletion: Finding and Erasing Every Copy of Prompts, Logs and Embeddings