Right to erasure now reaches into model memory

You must now document how personal data flows through your AI systems and demonstrate what you do when someone asks for it to be deleted, including from the trained model itself. This is no longer optional.

The prompt is an analysis of 4 August 2026 of the right to erasure reaching into model memory, which argues that deletion requests under data protection law now extend beyond training databases into the weights and parameters of deployed models. The European Data Protection Board's Guidelines 03/2026 on web scraping in generative AI, adopted in July 2026, establish that personal data processed during model training falls under the GDPR and cannot be easily removed once training is complete. In our assessment, this shifts the practical burden from your data retention policies to your model architecture itself. You can no longer treat a trained model as a static artefact; you must treat it as a system that holds personal data subject to deletion requests.

What does the EDPB now require when someone asks for their data back?

The Guidelines 03/2026 and supporting research establish that deletion requests can extend into model memory. A technically relevant passage in the guidelines states that once a model is trained, personal data cannot be easily deleted from it. This means your deletion workflow must account for the model itself, not just your training database. The supervisory analysis describes a practical workflow: when you receive a request, you conduct an impact analysis on the model, then execute a planned response. In serious cases, supervisory authorities see model deletion or retraining as a possible measure. You need to be able to show which measures you take before training, during training, and after a deletion request arrives.

Which failure modes must your deletion policy address?

• Residual influence of deleted data — unlearning techniques may leave traces of training data in model outputs even after deletion is attempted.
• Incomplete audit trails — you cannot demonstrate which personal data entered the model or verify that deletion was effective.
• Reliance on unproven techniques — machine unlearning is relatively young and approximate; audit tests have been validated mainly on synthetic data and smaller models, not large language models.
• Scope creep into external models — personal data flows into third-party AI systems where you have limited visibility or control over deletion.
• Absence of pre-training controls — personal data is scraped and processed without documented safeguards before it reaches the model.

What concrete controls must you be able to demonstrate?

1. Document your data sources and scraping practices — record which personal data you collect, from where, and under which lawful basis before it enters your training pipeline.
2. Implement quarantine and preprocessing layers — establish a documented workflow that limits which personal data reaches external models and logs each step.
3. Maintain an auditable deletion log — record each deletion request, the impact analysis you conducted, the method you used (retraining, unlearning, or other), and the date of completion.
4. Define your deletion method in advance — decide whether you will use full retraining with excluded data, machine unlearning, or another approach, and document why you chose it.
5. Test your deletion effectiveness — conduct or commission audit tests to verify that deleted data no longer influences model outputs, and retain the results.

Why is retraining the most reliable option right now?

The research commissioned by the EDPB, Effective implementation of data subjects' rights, examines how rectification and erasure can be applied to AI systems trained on personal data. Full retraining with excluded data is described as the most effective and complete known way to reduce the influence of specific data from a model. Machine unlearning techniques are characterised as relatively young and approximate, with cited analyses pointing to possible privacy and bias risks. Recent validation work shows that unlearning procedures on large models leave residual imprints, and audit tests for forgetting have largely been validated on synthetic data and smaller models, not on large language models. This does not mean unlearning cannot work; it means you cannot yet claim with certainty that it has worked. If you choose unlearning, you must be prepared to explain why you believe it is sufficient in your specific case, and you must have audit evidence to support that claim.

How should you approach this as a workflow rather than a one-off decision?

The tension between the legal requirement to delete personal data and the technical difficulty of doing so completely means that intention alone will not satisfy a supervisory authority or a data subject. You need a demonstrable process. Design your deletion and retention policy now as a documented workflow, not as a reactive measure you invent when a request arrives. Map the entire trajectory from data collection through scraping, preprocessing, training, deployment, and deletion. Identify the points at which personal data enters your systems and the points at which you can control or remove it. Assign responsibility for each step. Test your workflow before you need it. This is precisely the point at which a verification layer—a controllable workflow that logs preprocessing and anonymisation steps—can add value by making your processing steps visible and auditable.

No tool can promise that your outputs will be correct or that hallucinations will not occur. No tool can rule out all privacy risks. What a well-designed workflow can do is make your processing steps visible, so that your professional judgement remains yours and your decisions remain defensible. The new guidelines underline that model memory should be approached as a controlled, documented risk factor. You are now accountable for showing how you manage it.