Deletion, Erasure, and Forgetting Are Different Claims
The subject of this series is the GDPR right to erasure as controllers implement it, and the technical question that exposes its limits: why deleting a source record does not by itself prove that a learned model has forgotten. The useful judgment is not whether a screen went blank, but what was removed, what paths remain, and what evidence supports the claim. That distinction matters whenever personal data move through ordinary databases, vendors, backups, analytics systems, or models that transform examples into learned associations.
The confusion is understandable because the visible event is often simple. A person presses “delete,” an account disappears, or a model stops returning a name. Yet those events can mean very different things. One may change an interface while leaving internal records intact. Another may satisfy a legal obligation for the data within a defined scope while leaving a lawful exception or a controlled backup path. A third may suppress one answer while preserving enough internal structure for the answer to reappear under a different question or after more training.
One deletion button can hide several different events
Consider a person who asks a service to remove photographs and profile information. The service may have a user-facing account table, copies in search indexes, records sent to processors, audit logs, disaster-recovery backups, and derived analytics. “The account is gone” describes one visible state. It does not, without more information, describe every place where the relevant personal data were processed or every recipient that received them.
The European Data Protection Board’s 2025 coordinated enforcement action makes this ordinary-systems problem concrete. Thirty-two supervisory authorities investigated how controllers implemented the right to erasure, and 764 controllers responded. The report does not claim that this sample represents every organisation, and the authorities used different procedures and target populations. Even with those limits, it identified recurring weaknesses: missing internal procedures, inadequate training, insufficient information for data subjects, uncertainty about exceptions and retention, difficulty handling backups, and confusion around anonymisation.
One of the report’s most revealing observations is that some controllers confused closing an online account, profile, or application with erasing the personal data kept in their internal systems. The interface can therefore give a person a strong impression of completion while the organisation has not yet answered the more exact question: which data were within scope, where were they stored, and what action was taken at each relevant location? The same report records better practices—mapping storage locations, assigning responsibility, generating deletion records, and monitoring response times—not as decorative bureaucracy, but as ways to make the scope of an action visible.
Backups make the difference even sharper. A backup may need to remain intact to preserve the organisation’s ability to recover from a security incident. The EDPB describes cases in which controllers retained backups but tracked an erasure request so that the request would be honoured if a system were restored. That is not the same state as deleting every byte immediately, but neither is it the same as ignoring the request. It is a controlled restoration policy whose adequacy depends on the legal decision, the technical design, the retention period, and the ability to verify what happened.
The first lesson is consequently not that deletion is futile. Deletion is often necessary and may be exactly what a legal decision requires. The lesson is that a deletion event has a scope. A responsible claim must say what that scope was and what the system does with the places that are not changed in the same moment.
The words describe different objects
The GDPR gives this problem a legal structure. Article 17 calls the right to erasure the “right to be forgotten,” but it does not make the right unconditional. Erasure is required when one of specified grounds applies, such as data no longer being necessary, unlawful processing, withdrawal of consent without another legal basis, or a successful objection. The provision also recognises exceptions, including freedom of expression, legal obligations, public-interest tasks, public health, research or archiving under safeguards, and legal claims. A request therefore begins a legal assessment; it is not itself a command whose result can be assumed in advance.
The Regulation also uses “processing” broadly. The term covers operations including collection, storage, use, disclosure, restriction, erasure, and destruction. That breadth matters because the object of a request is not limited to the table or screen most familiar to the user. The controller is the party that determines the purposes and means of processing, while a processor acts on the controller’s behalf. The controller must be able to demonstrate compliance, and the surrounding duties include appropriate measures, records where possible of erasure time limits, and assistance from processors with data-subject rights.
This is why legal erasure, ordinary deletion, anonymisation, and restriction should not be used as synonyms. Restriction marks stored data so that future processing is limited; it is a different state from erasure. Pseudonymisation separates identifying information but keeps a route to attribution through additional information, so it is not automatically permanent deletion. Anonymisation aims at a stronger break from identifiability, yet the EDPB found that controllers sometimes relied on basic masking or pseudonymisation while treating it as a substitute for deletion. The report also notes continuing uncertainty about what legally and technically constitutes anonymisation.
Machine unlearning adds another object to the vocabulary. A learned model does not normally contain a neat, addressable copy of each training example. Training changes parameters and representations so that patterns become available during inference. In the supplied research on vision-language models, the model combines a vision encoder, a text encoder, and a multimodal fusion and decoding component; practical systems can also include a path that projects image features into the language space. The paper frames unlearning as changing the model so that the influence of a designated forget set is reduced or removed while performance on retained data and general multimodal capability are preserved.
That definition is useful, but it is not a legal definition of erasure. When an unlearning method makes a model less likely to produce a target name, it has changed a behavioural path under a chosen test. It may also have changed visual representations, textual probabilities, or intermediate activations. None of those descriptions alone establishes whether a particular parameter or representation is personal data under the GDPR in a particular processing context. The supplied legal sources do not decide that question, and the technical paper does not purport to do so.
The distinction can be stated plainly. A service can delete a record without changing a model. A model can stop displaying an answer without the source record being erased. A model intervention can alter one route to an association while leaving another route available. These are related events in one system, but they are not interchangeable evidence.
The real question is what can still be recovered
A strong forgetting claim is therefore a claim about reach and recoverability. It asks what information the action addressed, where it may still travel, how restoration is handled, and what tests can reveal residual influence. This is the common structure linking the GDPR implementation problem to machine unlearning, even though the legal and technical meanings must remain separate.
The distinction is especially important for models because output suppression is easy to mistake for absence. The supplied VLM study evaluates unlearning with ordinary generative prompts, paraphrased prompts, and discriminative yes-or-no questions. It then tests three less forgiving routes. Indirect context supplies related clues without naming the target, asking whether a weakened association can be reactivated. Matched-distribution retraining uses examples from the original forget distribution to see whether the target capability returns quickly. Semantically related but out-of-distribution retraining tests whether residual structure transfers while also measuring damage to retained capabilities.
These tests do not prove that every possible prompt or training path has been covered. They do, however, change the question from “did the usual query produce the forbidden answer?” to “how stable is the claimed forgetting when the access route changes?” In the paper’s benchmark, several methods that looked effective under direct prompting were vulnerable to indirect context or renewed training. Other methods preserved forgetting more strongly in the tested setting but still faced trade-offs involving retention or general utility. Out-of-distribution retraining often harmed retained performance more than it restored the target identity. A high forgetting score could therefore reflect a model that has lost broader capability, not one that has cleanly removed one association.
The same reasoning applies to a controller’s ordinary systems. A successful test should not merely confirm that a user interface no longer shows the record. It should examine whether the defined scope was mapped, whether processors and recipients were handled, whether a backup can later restore the data, whether an exception or retention rule was documented, and whether the result can be demonstrated. The EDPB’s recommendations to verify erasure and retain proof are important precisely because an assertion after the fact is weaker than an evidence trail tied to the action.
The diagram is not a prescription that every legal request must trigger model retraining. It shows why the conclusion has to be bounded by the paths actually considered. If a request concerns only a live record, the relevant action may not include a model at all. If a model is part of the processing, the operator still needs a fact-specific analysis of the model’s role, the data involved, the applicable legal ground or exception, and the evidence required. The technical analogy helps expose hidden persistence; it does not settle those questions.
This also explains why the title is a claim about proof rather than a claim that systems can never forget. A model may be robustly changed for a defined target and evaluation set. A controller may complete an erasure process across the systems and recipients within scope. But the word “forgotten” carries more weight than “not visible here.” It suggests that the relevant information is no longer available through the paths that matter, and that the conclusion survives the tests and boundaries that have been stated.
The next question is consequently a legal one before it becomes a technical one: when does Article 17 require erasure, what can lawfully limit or delay it, and how must a controller explain and demonstrate the decision? Once that frame is clear, the model case becomes more useful. It can show how recoverability and residual influence complicate proof without pretending that a neural network and a personal-data register are the same kind of object.