Keep AI chat data only as long as you can justify, and set a separate period for each place it lands. A chat tool creates transcripts, application logs, caches, embeddings, feedback records and sometimes provider-side copies. The GDPR storage limitation principle is a good default test: no longer than necessary for the purpose.
Where does chat data actually live?
Teams usually think of one store, the chat history. Map the rest.
- Transcripts: prompts and responses, often tied to a user.
- Application logs: request payloads logged for debugging, which can contain the whole prompt.
- Retrieval indexes: documents and chunks embedded for search, plus the embeddings themselves.
- Caches and queues: short term, but easy to forget.
- Feedback and evaluation sets: conversations copied for review or tuning.
- Provider side: the model provider's own retention for abuse monitoring or service operation, which is set by contract and settings.
- Backups: copies of all of the above.
Chat content often includes personal data, credentials pasted by mistake, and customer confidential material. That mix is why the retention decision matters.
What principle applies?
Article 5 of the GDPR requires personal data be kept in identifiable form no longer than necessary for the purposes for which it is processed, with exceptions for archiving, research and statistics under safeguards. It also requires appropriate security. Even outside the EU, the principle gives you an auditable logic: state the purpose, set the shortest period that serves it, and delete on schedule.
How do you pick periods?
Tie each store to a purpose and pick a number you can defend.
A constructed example for an internal assistant: transcripts shown to the user for continuity, 30 days then deleted unless the user pins them; debug logs with payloads redacted or off by default, 7 days; embeddings follow their source documents and are deleted when the source is; evaluation sets contain only de-identified conversations with approval, reviewed every quarter; provider side retention set to the shortest option the contract allows. Your numbers will differ. The point is that each has a reason.
What about deletion requests and legal holds?
A deletion request must reach every store holding that person's data, including embeddings derived from their uploads. Test it. Legal holds pause deletion for specific data, so build a way to flag items and suspend deletion for them without suspending everything. Document who can apply and release a hold.
Backups are the hard case. Decide how long they live, and what you do when a request touches data in an older backup, for example by restoring and re-applying deletions.
What should you tell users?
State in plain words what is kept, where, and for how long, including any provider copy. Warn against pasting secrets or regulated data where the tool is not approved for it. If employees use consumer chat tools outside your control, your retention settings do not apply, so decide which tools are allowed.
How to check or apply this
- Map every store that receives chat content, including logs and provider side.
- Assign a purpose and a retention period to each.
- Redact or stop logging full prompts in application logs.
- Automate deletion and test it with a real request.
- Add hold flags and a documented release process.
- Check provider contracts and settings for their retention and training use of your data.
- Publish a user-facing summary and review it twice a year.
Quick check
Do embeddings count as personal data?
They can, if derived from content that identifies people. Treat them like their source documents and delete them together.
Is turning logging off the safest option?
It reduces exposure but removes evidence for incident response. Prefer redacted logs with a short retention period.
Sources
- GDPR Article 5, principles
- GDPR Article 32, security of processing
- OWASP Top 10 for LLM applications
Last reviewed: 18 October 2026.
