GDPR Right to Erasure Applied to LLMs, in depth: Article 17 across stores, corpora and model weights

What Article 17 requires

Article 17(1) lists the grounds on which a controller must erase personal data without undue delay. They include data no longer needed for its purpose, consent withdrawn where consent was the lawful basis, an objection under Article 21 with no overriding legitimate grounds, unlawful processing, and a legal obligation to erase. Article 17(3) lists exceptions, among them freedom of expression and information, compliance with a legal obligation, public health, archiving and research where erasure would seriously impair the purpose, and legal claims. Whether a request must be honoured is a legal assessment, made per request.

Three procedural rules shape the engineering. Article 12(3) requires a response without undue delay and within one month, extendable by two further months for complex or numerous requests, with the person told why. Article 19 requires you to tell each recipient to whom the data was disclosed, unless that proves impossible or involves disproportionate effort. Article 17(2) adds that where data was made public, you take reasonable steps, including technical measures, to inform other controllers processing it. Model providers acting as your processors, fine-tuning vendors and downstream customers who received a model are all candidates for those notices.

Do model weights hold personal data?

Whether trained weights contain personal data decides how far Article 17 reaches into them. The European Data Protection Board addressed this in Opinion 28/2024, adopted in December 2024. Its position, in short, is that a model trained on personal data cannot be assumed anonymous. Supervisory authorities assess it case by case, and for the model to count as anonymous, the likelihood of extracting personal data about training subjects directly from the model, and of obtaining it through queries, should be insignificant. At least one national authority, Hamburg's, published a 2024 discussion paper taking the view that LLMs as such do not store personal data. The positions differ, which means the defensible engineering stance is evidential: measure whether your model can produce the person's data, and act on the measurement.

That measurement is possible because memorisation is real and testable. Research on extracting training data from language models has shown that models can reproduce verbatim sequences seen in training, especially ones that appear many times, and that larger models memorise more. A name appearing once in a crawl is unlikely to be reproducible. A support transcript repeated across a fine-tuning set, or an address in a widely mirrored document, may well be. The risks on the output side are covered in PII leakage from LLMs.

Four tiers of erasure

The four tiers differ in cost and certainty. Tier 1 is everything outside the weights: conversation logs, agent memory, retrieval indexes and their embeddings, caches, analytics and backups. Deletion there is exact and should happen within days; the fan-out across stores is worked through for one framework in the ADK Java right to be forgotten. Retrieval is the best place to hold personal data precisely because it is erasable, so prefer RAG over fine-tuning for facts about individuals. Tier 2 is training corpora you still hold: delete the records and add the person's identifiers to a blocklist applied to every future data pipeline run, so a fresh crawl does not reintroduce them. Tiers 3 and 4 are weights.

Retrain, shard, unlearn or suppress

SISA, from Bourtoule and colleagues' 2021 work on machine unlearning, splits training data into disjoint shards and trains a separate model on each, so erasing a record means retraining only one shard. For LLMs the practical form is fine-tuning one adapter per data shard and routing or merging at inference. It fits fine-tuning on customer data well and base-model pretraining poorly.

Approximate unlearning is an active research area with benchmarks such as TOFU, which fine-tunes models on fictitious author profiles and measures how well methods forget them. Published evaluations keep finding the same two problems: methods that forget thoroughly degrade the model's general ability, and information that appears forgotten can often be elicited again by rephrased prompts or a small amount of further fine-tuning. Treat it as a mitigation that lowers extraction risk, not as erasure, and say so in your records.

Verifying erasure with extraction tests

Verification turns a claim into evidence. For tiers 1 and 2 it is a lookup: query each store by the person's identifiers and expect zero rows. For weights it is an extraction test. Build prompts that give the model the context in which the data appeared, sample many completions, and check whether the person's identifiers appear. Run it before and after remediation, against the same prompts, so the result is a comparison rather than an anecdote.

import re, unicodedata

def norm(s):
    s = unicodedata.normalize("NFKC", s).casefold()
    return re.sub(r"[^a-z0-9@.+]", "", s)

def extraction_rate(generate, probes, identifiers, samples=20, temperature=1.0):
    # probes: prefixes that preceded the data in training, plus paraphrased questions
    targets = [norm(i) for i in identifiers]
    hits = total = 0
    for prompt in probes:
        for _ in range(samples):
            out = norm(generate(prompt, temperature=temperature, max_tokens=64))
            total += 1
            hits += any(t and t in out for t in targets)
    return hits / total

# Example gate: before = 0.18 on the fine-tuned adapter; after retraining the shard
# the same probes must score 0.0, and a control set of other people's data must not move.

Two refinements make the test honest. Include probes the person never appeared in, so you learn the base rate at which the model produces a common name by chance. And for high-risk cases plant canaries: unique synthetic strings inserted into fine-tuning data at known frequencies, whose extractability tells you how much exposure a real record at that frequency would have. The canary idea comes from the Secret Sharer work on measuring unintended memorisation.

Output suppression done carefully

Output suppression is the only option that takes effect the same day for a base model you cannot retrain, so most teams need one. It checks every generation against a list of erased identifiers and redacts or blocks matches. Keep the list as salted hashes of normalised identifiers, and match on normalised token windows so formatting differences do not slip through.

import hashlib

SALT = load_secret("erasure-suppression-salt")
BLOCKED = load_hash_set()   # sha256(SALT + norm(identifier)) for each erased identifier

def h(s):
    return hashlib.sha256(SALT + s.encode()).hexdigest()

def suppress(text, max_window=6):
    words = text.split()
    for n in range(max_window, 0, -1):
        for i in range(len(words) - n + 1):
            if h(norm(" ".join(words[i:i + n]))) in BLOCKED:
                return "[removed: this response referenced data that has been erased]"
    return text

Be clear about what this is. A hash list is still personal data, retained so that you can keep honouring the erasure; document that purpose, minimise it to identifiers, and restrict access. It does not catch paraphrase or inference, and it blocks other people who share a name, so pair common names with a second identifier. Combine it with the PII filtering you already run; see PII protection for LLMs.

Worked example

A company runs a support assistant: a third-party base model, a LoRA adapter fine-tuned monthly on redacted transcripts, and a retrieval index over past tickets. A former customer asks for erasure, citing withdrawn consent. The privacy team confirms the ground applies and no exception does.

Day 1: tickets, conversation logs, memory rows and their embeddings are deleted, and the backup keys for the customer's records are scheduled for destruction. Day 2: the transcripts are removed from the fine-tuning corpus and the customer's email, phone number and name-plus-postcode are added to the pipeline blocklist and the suppression list. An extraction test against the current adapter with 40 probes and 20 samples each finds the phone number in 3 of 800 completions, because redaction had missed a transcript where it was spelled out in words. Day 5: the adapter is retrained on the cleaned corpus, since adapters here take hours, not months. The same test now scores zero and the control set is unchanged. The base model's provider is notified as a recipient; it produced no hits on its own. Day 6: a receipt records each tier's action and test result, and the customer is told the erasure is complete, well inside one month.

Failure modes

Trade-offs

The cheapest erasure is the one you designed for. Keeping facts about individuals in retrieval instead of weights, redacting before fine-tuning, deduplicating training data to reduce memorisation, and sharding fine-tuning data all cost something up front and make later requests routine. The alternative is paying at request time with retraining you did not plan, or with suppression that leaves the weights unchanged. Data governance for AI covers the inventory and lineage those design choices depend on.

What to do next

1. Map every store that holds personal data, including embeddings, caches, corpora, adapters and backups.
2. Write the legal assessment step into the workflow: ground, exceptions, deadline, recipients.
3. Move facts about individuals from fine-tuning data into retrieval, where deletion is exact.
4. Add a pipeline-wide blocklist so erased identifiers never re-enter training data.
5. Deploy output suppression with salted hashes and a documented retention purpose.
6. Build the extraction test with control probes, and run it before and after every remediation.
7. Shard fine-tuning data so one request retrains one adapter, not the whole model.
8. Issue a per-tier receipt and Article 19 notices for every completed request.