Machine Unlearning & Right-to-Erasure for LLMs (2026)

Q: Does the right to erasure (GDPR Article 17) apply to data in model weights?

The conservative and increasingly mainstream regulatory reading is yes. Large language models demonstrably memorise and can regurgitate training data verbatim, including personal data, which means weights that encode an identifiable person's information fall within the definition of personal data and the erasure right attaches to them. Regulators across the EU under GDPR Article 17, India under the Digital Personal Data Protection Act 2023, the UAE and Saudi PDPL, Singapore PDPA, and Japan's APPI are converging on this position rather than accepting that weights are categorically exempt. Arguing that the data "isn't stored as a row, so it can't be deleted" is a weak and shrinking defence, because the demonstrable memorisation undercuts the claim that the person is no longer identifiable from the model. The defensible posture is not to seek an exemption but to architect so that erasure is actually feasible: maintain training-data lineage, use a training design that localises each record's influence, adopt a verified unlearning method, and be able to produce evidence that a given subject's data was removed. In short, treat the weights as in scope and engineer for the obligation in advance.

Q: Why can't you just delete a person's data from a trained model?

Because a trained model does not store training examples as retrievable records. Unlike a database row you can DELETE, each parameter in the model is shaped by all of the training data simultaneously through gradient descent, so a single person's contribution is diffused across billions of weights rather than localised in one place you can excise. The only method that is provably complete — retraining the model from scratch on the dataset minus that person's data — is economically impossible to run on demand, since a single full retrain of a large model can cost a hundred thousand dollars or more in compute and take days, and erasure requests arrive continuously. That leaves a set of approximate and architectural alternatives, each trading off against the others: SISA-style sharded training localises influence so you retrain only an affected shard; gradient-based and influence-function methods try to reverse a record's contribution quickly but risk damaging model quality and offer uncertain completeness; and fine-tune-toward-the-no-data-distribution methods scale but must be verified rather than assumed effective. The engineering goal is a method that is cheap enough to run per request, provably effective enough to satisfy a regulator, and minimally damaging to the model's general capability — three objectives in genuine tension, which is what makes machine unlearning the hardest open problem in AI data protection.

Q: What is SISA and how does it make unlearning affordable?

SISA — sharded, isolated, sliced, aggregated — is a training architecture designed so that the influence of any single training record is localised rather than diffused across the whole model. The dataset is partitioned into shards, a separate constituent model is trained in isolation on each shard, each shard is further divided into slices with checkpoints saved as training progresses, and the constituent models are aggregated at inference. The payoff for unlearning is decisive: when a record must be removed, you only retrain the one shard (and only from the slice checkpoint where that record first entered) instead of retraining the entire model from scratch, which cuts the cost of an erasure by roughly the number of shards. The trade-offs are that you must adopt this architecture up front — you cannot retrofit it onto an already-trained monolithic model — it increases storage because of the checkpoints and constituent models, and aggregation can slightly reduce peak model quality compared with training one model on all the data at once. For organisations that fine-tune on regulated personal data and expect a steady stream of erasure requests, designing for SISA-style sharding from the beginning converts erasure from an existential full-retrain into a routine, bounded operation, which is usually well worth the upfront cost.

Q: Is blocking the model from outputting PII the same as erasing it?

No. Output filtering or guardrails that block the model from regurgitating a name or record at inference time do not remove the data from the weights; the information is still encoded in the model and may be recoverable through paraphrased prompts, membership-inference, or future capability improvements. This makes output filtering a useful interim mitigation but not a legal answer to an erasure request: a regulator asking whether a data subject's data was erased is asking about the data's presence in the model, not about whether the model currently chooses to emit it. Presenting filtering as erasure is a meaningful compliance risk, because it can be characterised as misrepresenting the state of processing. The correct role for output filtering is as a defence-in-depth layer that reduces regurgitation risk while a genuine unlearning or shard-retrain process runs, and as protection for data you are lawfully retaining. When the obligation is actual erasure, you must change the weights — via shard retraining or a verified approximate-unlearning method — and then prove, through membership-inference and targeted regurgitation testing, that the data's influence is gone. Filtering can complement that, but it cannot substitute for it.

Q: How do you verify that machine unlearning actually worked?

Verification is mandatory because the entire risk of an approximate unlearning method is that the data might still be recoverable, so unverified unlearning is theatre. The standard approach reuses the privacy attacks developed for embeddings and models: after running the unlearning procedure, execute a membership-inference probe against the erased records to test whether the model still betrays that those records were part of training, and run a targeted regurgitation test that prompts the model in ways designed to elicit the specific data, including paraphrased and indirect prompts. If the model still reveals membership or can reproduce the data, the unlearning failed and you escalate to a stronger method or a shard retrain. When the tests pass, you record an erasure certificate capturing the subject, the model artifacts that were touched, the method used, the verification outcome and metrics, and the timestamp — this is the evidence a regulator will request to confirm the obligation was met. Crucially, verification must also cover derived copies: caches, evaluation datasets, logs, prompt stores, and any downstream models fine-tuned from the affected model, because data erased from the headline model but surviving in a derivative is not erased. Building verification and certification into the pipeline is what separates defensible compliance from a hopeful gesture.

Q: What data lineage do you need to make erasure tractable?

You need to be able to answer, for any data subject, which datasets, training shards, model checkpoints, and downstream artifacts their data influenced — and that linkage must be established at ingestion, not reconstructed at request time when it is usually impossible. Concretely, this means tagging training records with stable subject and source identifiers, recording which shard and slice each record entered for SISA-style architectures, tracking which model versions and fine-tunes were trained on which dataset snapshots, and maintaining a map of derived copies including caches, eval sets, logs, prompt stores, and child models. With this lineage in place, an erasure request becomes a lookup that scopes the work precisely: delete the source rows and vectors, identify the specific shard to retrain or the artifacts to run approximate unlearning against, and enumerate the derived copies to sweep. Without it, every erasure request collapses into one of two bad options — retrain the entire model from scratch, which is economically impossible at scale, or make an unprovable guess that exposes you to regulatory and litigation risk. Lineage is therefore the true prerequisite for an erasure program; the unlearning technique is downstream of being able to say what to unlearn from where.

Q: What are the common anti-patterns in an LLM erasure program?

Seven recur. Treating weights as out of scope by arguing the data is not stored as rows — a losing position given demonstrated memorisation and regurgitation; architect for feasibility instead. Selling output filtering as erasure, which leaves the data in the weights and misrepresents the state of processing; filtering is mitigation, not erasure. Having no data lineage, so you cannot map a subject to the shards and artifacts their data influenced, turning every request into a full retrain or an unprovable guess; lineage is the prerequisite. Running approximate unlearning without verification, which is theatre because the data may still be recoverable; always run membership-inference and regurgitation tests afterward. Treating retrain-from-scratch as the only plan, which is economically impossible per request at large-model scale; design SISA sharding or a verified approximate path in advance. Forgetting derived copies — caches, eval sets, logs, prompt stores, and downstream fine-tunes — so data erased from the headline model survives elsewhere. And producing no erasure certificate, leaving you unable to demonstrate compliance even when you did the work correctly. Each maps to a concrete fix, and together they convert erasure from a crisis into a routine, provable workflow.

Q: How does an erasure obligation map across GDPR, DPDP, PDPL, and APPI?

The obligation is substantively similar across regimes, which means a single well-designed erasure pipeline can satisfy all of them — design once, attest many. EU GDPR Article 17 grants the right to erasure and, read against model memorisation, reaches data in weights; India's Digital Personal Data Protection Act 2023 imposes comparable erasure and data-fiduciary duties; the UAE and Saudi PDPL, Singapore PDPA, and Japan's APPI each provide data-subject deletion rights and cross-border constraints. The common technical requirements they impose are the same four capabilities: data lineage to scope what must be erased, a feasible unlearning or shard-retrain method to actually remove influence from the model, verification through membership-inference and regurgitation testing to prove removal, and an erasure certificate plus derived-copy sweep to evidence completeness. Building the union of these requirements into one pipeline, integrated with your cross-jurisdiction compliance control plane, means a data-subject erasure request is handled by a routine workflow that produces consistent evidence regardless of which regulator asks. The practical implication is to avoid bespoke per-jurisdiction processes and instead implement the strictest common denominator — lineage, verified unlearning, certification — so that adding a new market is a mapping exercise rather than a re-engineering one.