The Right to Erasure vs a Trained Model
5 min read · updated August 3, 2026
Somebody asks you to delete their data. Your database can do that. The question that stops the room is whether a model that was trained on their data can, and the honest answer is that this is unresolved — but it is unresolved in a way you can usually engineer around.
This page is engineering guidance, not legal advice, and the legal position here is genuinely in motion: regulators and courts are still working through what erasure means for a statistical model. Check the current guidance in your jurisdiction rather than relying on any summary, including this one.
Two different objects, one word
Article 17 gives a right to erasure of personal data in defined circumstances. Applied to an AI system, the request lands on two categories of object that behave nothing alike:
- Records. Stored conversations, uploaded documents, embeddings in a vector index, cached completions, log lines, analytics events, evaluation fixtures. Discrete, addressable, deletable. This is ordinary data engineering with an unusually wide blast radius.
- Parameters. If personal data was in a training corpus, its influence is diffused across billions of weights. There is no row to drop. Retraining without the record is the only unambiguous answer, and for a large model that is not a thing that happens on request.
Almost every unproductive conversation about this topic is two people arguing while one means records and the other means parameters. Name which one you are discussing and most of the disagreement evaporates.
The tractable half: every copy you made
Before worrying about weights, be sure you can actually complete the easy part. In a typical AI feature the copies of one person’s text are more numerous than in a typical CRUD app, and each needs a subject key or it is undeletable in practice:
| Store | Description |
|---|---|
| conversation table | The obvious one. Deletable if messages carry a subject reference and not just a session id you cannot resolve backwards. |
| vector index | Embeddings derived from personal data are personal data. Deletion requires the index to store the source id — decide that at ingestion, because retrofitting it means a rebuild. |
| prompt/response cache | Keyed by a hash of the input, which means it is not keyed by subject at all. Either exclude personalised prompts from caching or give the cache a shorter life than your response window. |
| application logs | The reason prompt bodies should never be logged. Log retention is normally shorter than a rights deadline, which helps, but 'it will expire' is a weak answer to give in writing. |
| evaluation fixtures | Real conversations copied into a test suite become personal data in your repository, and git history makes them durable in the least convenient way possible. |
| provider side | Governed by the DPA. This is the clause you read for exactly this moment: what they delete, when, and whether it covers backups. |
The fixture row is the one that catches good teams. Sanitised test data costs an afternoon; a customer conversation pasted into a test file costs a history rewrite.
The hard half: influence on weights
If personal data reached a training run, three things are true at once, and it is worth being able to state all three plainly.
First, a model is not a store of its training data in the way a database is: it holds a statistical summary, and most individual examples cannot be recovered from it. Second, that is not a guarantee — models do sometimes reproduce memorised sequences verbatim, and rare, distinctive, repeated content is the most likely to be reproduced, which describes personal data in a small dataset rather well. Third, machine unlearning — techniques for removing a specific example’s influence without full retraining — is an active research area rather than a shipped capability with an agreed standard of proof.
So a claim that a model has “forgotten” a person is a claim that currently comes without a widely accepted test. Do not make it, and be suspicious of anybody who does.
Design so the hard half stays empty
The tractable move is to make sure the question never applies to you. Every one of these is a decision available before the fact and unavailable after it:
- Do not fine-tune on raw production traffic. If a model must be adapted, adapt it on data that has been through the same redaction pipeline you would apply before sending anything to a third party. Pseudonymised or synthetic examples usually teach the format just as well, which is normally what fine-tuning is for.
- Keep knowledge in retrieval, not in weights. A document in a vector index can be deleted; the same document baked into a fine-tune cannot. This is the strongest single argument for retrieval over fine-tuning when personal data is involved, and it is an argument about deletability rather than about quality.
- Keep the training-set provenance. If you do train on anything derived from users, record which subjects contributed to which dataset version. Without that you cannot even answer whether an erasure request touches a model, and “we do not know” is the worst available answer.
- Confirm the provider default. Whether your traffic can reach somebody else’s training run is a contractual question covered elsewhere in this cluster, and it is the same problem seen from the other end.
What to tell the person who asked
A response that is accurate and complete looks roughly like this: which stores held their data and that those have been deleted; which derived artefacts existed — embeddings, caches — and what happened to them; what was sent to processors, and what those processors’ terms provide for; and, if any model was trained on their data, honestly, that it was, what the current state of removal techniques is, and what you have done instead.
Do not claim erasure from a model you did not retrain. An overstatement here is a statement about a technical fact that can be checked, and it is far more damaging than the awkward accurate version. If the honest answer is uncomfortable, that discomfort is information about an architecture decision you should revisit — which brings you back to the previous section, permanently.