Deletion Requests

This is the operational heart of the Right to Be Forgotten. Without a clean deletion process, no amount of model unlearning satisfies a regulator. Master this and you can build the pipeline that audits, executes and evidences erasure requests — the skill that turns a legal obligation into a working system. It directly feeds your later work on Machine Unlearning (the technical side) and Data Privacy Compliance (the legal side).

A deletion request is a real, often time-bound, legal demand: 'remove my data and prove you did.' In practice, this is a mini-project with three phases. First, you must verify that the person asking is actually the person the data belongs to — otherwise anyone could delete anyone's information. Second, you execute the deletion: find every copy of that person's data in your live databases, your backups, your caches, and any derived datasets (like training sets or analytics tables). Third, you produce evidence — logs, timestamps, integrity hashes — that proves the deletion happened, because the regulator will ask. The hard part is scope: it's not one delete statement, it's a hunt across everywhere data legitimately lives. Think of it as a trace: one source row can spawn dozens of copies through joins, exports, and model training.

Imagine a physical archive office. You receive a letter: 'Under the Right to be Forgotten, please delete all records about me.' The office has a main file room (live database), a backup vault (backups), a shredding bin that hasn't been emptied in months (caches), and a research wing that made statistical summaries from the files (derived datasets). The clerk's job is to find every single mention of that person — in the main files, in the backup tapes (even though they're in a different building), in the shredding bin (must still be gone), and in any published reports (even though they'd need to be revised). The clerk must verify the requester's identity first — checking their ID against the file — because if you deleted on a vague request, you'd be leaking data to impostors. Finally, the clerk writes an affidavit: 'I searched these locations on this date, and here are the logs showing deletion.' The analogy breaks because digital copies are silent and automated — a backup might restore overnight a record you deleted yesterday. That's why you must have a retention policy that excludes deleted records from future backups, and why your evidence must include not just the deletion, but the absence of future restoration. The office's careful stack of paper is easier to audit than the silent spread of digital copies.

A deletion request is an operational process that verifies the requester's identity, locates every copy of the person's personal data across all storage and derived sources, executes the removal (including from backups and caches), and produces verifiable evidence of completion.

This is the operational layer beneath Machine Unlearning. The Right to Be Forgotten extends deletion to trained model weights — a deletion request must trigger not just database deletes but also unlearning in any model trained on that data. Your library notes link this to Exact Unlearning (full retraining as the baseline), Approximate Unlearning (fast but with bounded guarantees), and SISA Sharded Training (structuring training so deletion touches only one shard). The evidence step here also connects to Unlearning Verification — proving to an auditor that the influence is gone. Start with this process, then you'll see why model unlearning is the hard technical problem underneath.