Honouring an erasure request for an AI agent means deleting the person's data everywhere the agent copied it, not only in the source system. That includes long-term memory, embeddings in the vector index, conversation and tool logs, caches and evaluation sets. Tag every stored item with its data subject so deletion becomes a lookup, not a search.
Why AI agents make erasure harder
A traditional application usually keeps a customer's data in a few known tables. An AI agent spreads it out. It reads a support ticket, summarises it into memory, embeds chunks of it for retrieval, writes the conversation to a log and may pass it to a model provider. Each step creates a new copy that the original deletion process never knew about.
Data protection law does not care which copy the request reaches first. Under the GDPR right to erasure, and under similar rights in India's Digital Personal Data Protection Act, the organisation has to remove the personal data it no longer has grounds to keep. Regulators have also said that derived data is not automatically anonymous. The European Data Protection Board's opinion on AI models treats anonymity as a case-by-case question, so an embedding built from someone's message should be handled as personal data unless you can show otherwise.
Map every place the agent stores personal data
Start with an inventory, because you cannot delete what you have not found. For each agent, list:
- Source systems the agent reads from, such as the CRM, ticketing tool or document store.
- Long-term memory, including user profiles, preferences and summaries of past sessions.
- Vector indexes holding embeddings of documents, messages or notes.
- Logs and traces: prompts, model responses, tool calls and their arguments.
- Caches for prompts, retrieval results or tool output.
- Evaluation and fine-tuning sets built from real conversations.
- Third parties, such as the model provider or a hosted memory service, and what they retain.
Our guide to keeping personal data out of AI agent logs covers how to shrink the logging part of this list before it grows.
Memory: make deletion a lookup, not a search
Agent memory is often written as free text: "The customer prefers email and is moving house next month." If that text has no link back to the person, finding it later means searching everything.
Fix this at write time. Every memory record should carry the data subject's identifier, the source it came from and the date it was written. Keep memory per user or per tenant where you can, so one request maps to one partition. Then an erasure request becomes a query for that identifier followed by a delete, and the same query lets you confirm nothing is left.
Embeddings: delete the vectors and the chunks
Removing a document from the source system does not remove its embeddings. The vectors, and usually the text chunks stored beside them, stay in the index and can still be retrieved.
Keep a mapping from every vector ID back to the source record and the data subject. When a request arrives, delete the vectors and their stored text, not just the pointer to them. Check how your vector database handles deletion: some mark records as deleted and only remove them during a later compaction, so the data still sits on disk until that runs. Know when that happens, and record it. If personal data was embedded into a shared index with no mapping, plan a rebuild of that index from cleaned sources.
What about the model itself?
If you only call a hosted model through an API and the provider does not train on your data, the model holds nothing to erase. Fine-tuning on real conversations is different: removing one person from trained weights is not practical today, so the safer path is to keep personal data out of fine-tuning sets in the first place, or to retrain from a cleaned set when you must.
Logs and traces: keep the record, drop the person
Logs are where erasure collides with accountability. You need an audit trail of what the agent did, but the trail should not need the person's raw details to be useful.
Split the two. Store identifiers and action records in the audit trail, and keep message content in a separate store with a short retention period. On an erasure request, delete or redact the content and keep the action record, which now shows that something happened without showing who it was about. Where the law requires you to keep certain records, note the legal ground in the request file so the decision is visible.
Prove the deletion happened
An erasure process is only as good as its evidence. For every request, record:
- when it arrived and who verified the requester's identity
- which stores were checked and what was deleted from each
- anything kept, with the legal reason
- when deletion completed, including any delayed compaction or backup expiry
- confirmation sent to the person
Run the same identifier search again after deletion and keep the empty result. Test the whole process with a dummy customer before a real request arrives, and repeat that test whenever the agent gains a new store, tool or provider.
Where CodeDTX helps
We build agents with erasure designed in: subject-tagged memory, mapped vector indexes, split audit and content logs and a tested deletion runbook. If your agent already holds personal data in places you cannot fully list, we can map it and fix the gaps without a rewrite. Read how we approach enterprise AI product engineering or talk to us.
Frequently asked questions
Does deleting the source record remove the data from the AI agent?
Usually not. Deleting the source record removes the original, but the agent may still hold summaries in memory, embeddings and text chunks in a vector index, copies in logs and cached retrieval results. Each of those needs its own deletion step. The reliable way to cover them is to tag every stored item with the data subject's identifier when it is written, so one query finds every copy.
Are embeddings personal data?
They can be. An embedding built from a customer's message or document can often be linked back to that person, especially when the original text chunk is stored next to it. European regulators treat anonymity of AI-derived data as a case-by-case question rather than a default. The practical stance is to handle embeddings of personal content as personal data and include them in every erasure request.
Can we keep audit logs after an erasure request?
Often yes, if the logs are designed for it. Keep action records with identifiers in the audit trail and store message content separately with short retention. On a request, remove the content and keep the record of what the agent did. Where a legal obligation requires you to keep specific details, record that reason in the request file so reviewers can see why that data stayed.
What if personal data was used to fine-tune a model?
Removing one person's influence from trained model weights is not practical with today's methods. The workable options are to avoid fine-tuning on raw personal data, to anonymise or filter training sets before use, or to retrain from a cleaned dataset when a request makes that necessary. Agents that only call a hosted model through an API, with provider training switched off, avoid this problem entirely.
