Why erasure requests don't require model retraining: Governance that is defensible

Once personal data enters a training pipeline, questions about whether the training was lawful matter. But the harder, more practical issue is what erasure looks like once the model exists. 

When someone submits an erasure request, privacy teams delete the source data everywhere it is stored and exclude the requester from future training runs, fine-tuning jobs and feedback loops. They do not retrain models that already learned from that data. 

That is not a dodge; it is the most honest answer based on how these systems work, what regulators have said so far and what good-faith compliance looks like in practice. 

The position has not been tested in enforcement, which is exactly why the scaffolding around it matters more than the position itself. Privacy, legal, machine learning engineering and product teams all have to agree, or it falls apart the first time someone pushes.

Why is retraining usually the wrong answer for an individual request? Once personal data enters a training pipeline, it shapes gradient updates across millions or billions of parameters. The model holds patterns across the corpus but can memorize specific examples, which is why evaluation matters. Two ideas get conflated. 

Machine unlearning is the research attempt to remove a specific record's influence from an already-trained model. Prospective exclusion is the operational practice of dropping that record from every future run. Exclusion can be guaranteed and audited today; unlearning is not yet reliable or verifiable enough to anchor compliance. 

So why not retrain from scratch? When training is lawful, the request comes from a single person and evaluation already shows the model is not memorizing or leaking data, retraining is unlikely to materially improve that individual's privacy. Their influence is already diluted across billions of parameters. If any condition fails, a planned refresh is back on the table.