GDPR Article 17 and LLMs: what “erasure” actually means
Under UK GDPR Article 17, individuals can ask you to erase their personal data in certain circumstances. For an LLM application, the hard part is not the request. It is knowing where the personal data has gone, and proving it was removed. This guide maps where personal data lives in an inference stack, explains why overwriting is not erasure, and describes cryptographic erasure and what an erasure certificate can and cannot show.
This is general information, not legal advice. The ICO’s guidance on the right to erasure is the primary source, and you should take advice on your own obligations.
What the right actually requires
The ICO explains that the right applies to personal data you hold when the request arrives, and that it is not absolute. It applies in certain circumstances, for example where consent is withdrawn with no other lawful basis, where data is no longer needed for its purpose, or where it has been processed unlawfully. There are exemptions. You also need to respond without undue delay and within one month, and to consider whether to tell recipients of the data about the erasure.
Where personal data lives in an inference stack
| Location | What personal data looks like there | Erasure question |
|---|---|---|
| Prompts and inputs | Names, emails, case notes and other context users paste in | Can you find every prompt that contains this person’s data? |
| Responses and outputs | Generated text that repeats or infers personal details | Are stored outputs covered, and are they kept at all? |
| Application logs | Request bodies, debugging traces, error reports | Are full prompts logged, and for how long? |
| KV cache | The attention keys and values built from every prompt, held in GPU memory and offload tiers | Can you remove every copy, including cached prefixes shared between requests? |
| Fine-tuning data | Datasets used to train adapters or weights | Can you remove a person’s records and retrain or re-evaluate? |
| Backups and analytics | Copies made for recovery, reporting or product analysis | Do they hold the same data, and do they follow the same deletion? |
The KV cache is the one teams forget. It is a faithful working copy of the prompt, and on shared serving stacks it can persist and be reused across requests. It deserves the same erasure process as the prompt log.
Why overwriting is not erasure
A common answer to an erasure request is “the data will be overwritten eventually.” That is not an answer you can defend. Overwriting depends on memory being reused in a predictable way, and it does not reach every copy. Data can persist in offload tiers, in snapshots, in backups and in logs, and you may not know where all the copies are. Without a complete inventory and a way to reach each copy, you cannot show that the data is gone.
Cryptographic erasure, explained
Cryptographic erasure removes the ability to read data rather than trying to find every copy of it. The data is encrypted under a key, and when the key is destroyed, the ciphertext everywhere becomes unreadable, even copies you never found.
- Encrypt each block of data with a key that belongs to one session or one data subject.
- Keep the ciphertext wherever it needs to be: GPU memory, host memory, disk or object storage.
- When the erasure request is valid, destroy the key. Every copy of the ciphertext is now unreadable at once.
- Record the destruction, so there is evidence that the key existed and was removed.
This works only if the key is genuinely destroyed, and not held in a backup that still decrypts the data. The key hierarchy, key storage and key destruction all need design and evidence. kvrun uses AES-256-GCM with per-workspace and per-session keys, and erasing a session destroys its keys, which makes every copy on every tier unreadable at once.
What an erasure certificate evidences
A certificate is a record, and it should be read as one. A good erasure certificate evidences:
- Scope: which session or data subject the erasure covered.
- Action: that the keys for that scope were destroyed, and when.
- Trail: an entry in the append-only audit log for the erasure.
A certificate does not, on its own, prove that personal data was never copied anywhere else. It proves what the system did about the copies it controls. Where you have data outside the platform, such as your own prompt logs, exports or fine-tuned weights, you need to cover those separately.
Fine-tuning and the model itself
Erasing a prompt is one question. Erasing personal data that was used to train a model is harder. Adapter weights trained on personal data may need retraining or a documented decision that the data cannot be recovered from the model. Treat fine-tune datasets as personal data, keep them in one place you can erase from, and record each training run with its evaluation, so you can show what was used.
A practical process
- Log each erasure request, with the date received and the deadline for response.
- Confirm the request is valid, and whether an exemption applies.
- Identify the sessions, prompts, datasets and logs that hold the person’s data.
- Erase each location, using key destruction where the data is encrypted.
- Record what was erased, keep the certificate, and tell any recipients where required.
Questions
- Is an LLM output personal data?
- It can be, if it refers to an identifiable person. Treat outputs that contain personal data the same way as prompts.
- Does erasing the prompt remove the model’s knowledge?
- Not necessarily. Erasing inference data is different from erasing training data. Check what the model was trained on and whether that training data is in scope.
- Where should I start?
- Map your data, identify the copies you cannot find, and fix those first. The UK GDPR checklist for LLM hosting gives the wider picture.