# Deletion Requests

The operational process of receiving, validating, executing and evidencing a data removal request end to end.

**Rests on:** Right to Be Forgotten

*Machine Learning · Machine Unlearning*


## Why learn this

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).


## The intuition

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.


## An analogy

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.


## Definition

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.


## How it connects

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. The evidence step here also connects to Unlearning Verification — proving to an auditor that the influence is gone.


## The mathematics

Deletion requests are not about calculus or algebra — they are about counting and comparing. The only branch of mathematics involved is arithmetic, and even then only simple operations: equality, union, and counting. Equality is checking whether two things are the same — for example, does the email address in the request match one in the database? Union is combining two sets of locations — such as the list of databases plus the list of backup tapes — to get the total list of places you must check. Counting is tallying how many records were found and how many were deleted, so you can report to the regulator. The central idea is a completeness check: after you think you've deleted everything, you re-count and re-compare to prove nothing is left. This is less about formulas and more about systematic enumeration — writing down every possible hiding place and checking each one off. The mathematics is the logic of sets: the set of all storage locations, the set of all copies of the person's data, and the set difference that must be empty after deletion.

Let S be the set of all storage locations (databases, backups, caches, derived tables). Let C be the set of locations that contain a copy of the person's data. Let D be the set of locations where deletion was executed. The completeness condition is: D = C, i.e. every location in C is in D, and the post-deletion search finds zero copies: |C'| = 0. The evidence is a record of C, D, and the timestamps.


## A worked example

```
A user 'Priya Sharma' sends a deletion request. Your company stores data in three databases (DB1, DB2, DB3), two backup tapes (B1, B2), one cache (C1), and one derived analytics table (A1). Your audit system checks each location for any record containing her email or phone number.

Step 1: Locations found with Priya's data: DB1 has 3 records, DB2 has 1 record, C1 has 2 records, B1 has 1 record, B2 has 1 record, A1 has 2 records. DB3 has 0. Total = 3+1+2+1+1+2+0 = 10 records.   # First, enumerate every location and count matches. This gives the baseline.
Step 2: Delete from live systems: DB1 (3), DB2 (1), C1 (2) — gone. Remaining: B1 (1), B2 (1), A1 (2).   # You must handle live databases and caches first. Backups and derived tables need separate steps.
Step 3: Restore from backup? After deleting from DB1, the nightly backup B2 might restore the deleted rows the next day. You must scrub B1 and B2 as well, or set a retention rule to exclude deleted records from future backups.   # This is the classic silent-restoration trap. Backup tapes are copies, so they must be edited too — or you risk the deleted data reappearing.
Step 4: Delete from derived tables: A1 (2) — remove the rows that personalise analytics. Now remaining: 0.   # Derived datasets often escape the initial search, but they are still personal data in most jurisdictions.
Step 5: Verification: re-scan all six locations. Count found = 0. Compare with initial count (10). Difference = 10 – 0 = 10, meaning all 10 copies are accounted for.   # The evidence step: you prove that the count is zero now, and that the gap equals the original count, so nothing was missed.

Result: All 10 copies deleted across live, backup, and derived locations. The verification scan finds zero remaining matches. The evidence log records the timestamps and the counts, ready for the regulator.
```


## From scratch, in Python

Let's write a small Python script that simulates the deletion process. We'll use a dictionary to represent each location, with keys as record IDs and values as data. We'll also use a list to keep track of where we find matches.

```python
# A dictionary: each location maps a record ID to a phone number (for simplicity)
db1 = {'001': '9876543210', '002': '1112223333', '003': '9876543210'}
db2 = {'004': '5556667777', '005': '9876543210'}
backup1 = {'006': '9876543210'}
cache1 = {'007': '9876543210', '008': '1234567890'}

# We'll use a list to record where we found matches
locations_found = []

# The phone number to delete
target = '9876543210'

# Check each location
def check_and_delete(location, name):
    found_any = False
    for record_id in list(location.keys()):
        if location[record_id] == target:
            found_any = True
            locations_found.append((name, record_id))
            del location[record_id]  # actual deletion
    return found_any

check_and_delete(db1, 'db1')
check_and_delete(db2, 'db2')
check_and_delete(backup1, 'backup1')
check_and_delete(cache1, 'cache1')

# Verify: re-scan all locations and count remaining matches
remaining = 0
for location in [db1, db2, backup1, cache1]:
    for value in location.values():
        if value == target:
            remaining += 1

print('Locations found:', locations_found)
print('Remaining copies after deletion:', remaining)
```

This prints:
```
Locations found: [('db1', '001'), ('db1', '003'), ('db2', '005'), ('backup1', '006'), ('cache1', '007')]
Remaining copies after deletion: 0
```

The code uses two Python building blocks: a **dictionary** (a collection that looks up values by a key — like a real-world index card) and a **for loop** (a way to repeat the same action for each item in a collection). A dictionary in Python is written with curly braces and pairs of key: value. For example, `db1 = {'001': '9876543210'}` means record ID '001' has the phone number '9876543210'. The `del` statement removes an entry from the dictionary — that's our deletion. The `for record_id in list(location.keys())` loop goes through each key in the dictionary one by one; we use `list()` to take a snapshot of the keys so we can safely delete while iterating. The function `check_and_delete` is a reusable block that does the check for any location we pass in. This is plain Python, no frameworks.


## The same thing, with a framework

```python
In practice, you'd use a database query (like SQL) to find and delete matching rows, not Python dicts. But the logic is the same: `SELECT * FROM users WHERE email = ?` to find, `DELETE FROM users WHERE email = ?` to remove. For derived datasets, you'd use Pandas to filter and drop rows. For example, in Pandas: `df = df[df['email'] != target]`. The underlying mechanism is still the loop-and-compare you wrote by hand.
```


## What the code does

The script defines a target phone number and four dictionaries representing different storage locations (two live databases, a backup, and a cache). The function `check_and_delete` iterates over the keys of a dictionary, checks whether the value equals the target, records the location and record ID in the `locations_found` list, and deletes the entry with `del`. It returns True if any match was found, but we ignore that. After all locations are processed, we run a second pass over all dictionaries to count any remaining entries with the target value. The print statement shows the list of deleted locations and the remaining count (should be zero). This mirrors the real-world process: locate, delete, then verify by re-scanning.


## Common misconceptions

**Deleting from the main database is enough** — If I delete the row from the users table, the data is gone. I don't need to worry about backups or caches.

Backups and caches are exact copies. If you delete only the live table, the next backup restore will bring the data back. Also, derived tables and model weights may still contain the data. In fact: You must delete from all live systems, all backups, all caches, and all derived datasets. A complete deletion requires a scope that includes every copy.

**Deletion requests are just a technical problem** — It's just a `DELETE` statement. All I have to do is run it.

The process begins with identity verification — you must confirm the requester is who they say they are. Otherwise you could delete someone else's data. Additionally, you must document everything for legal compliance. In fact: It's a full operational process: verify the requester, locate all copies, execute deletion, and produce evidence of completion.

**After deletion, the data is irretrievably gone** — Once I delete the file, it's erased from the hard drive. No one can recover it.

Ordinary deletion removes the index entry, but the data may still exist on the disk until overwritten. Backups and server logs may retain copies. The only way to ensure erasure is to overwrite or destroy the medium, or to confirm no copies exist elsewhere. In fact: Deletion in a system context means removing all references and copies. True physical erasure is a separate cryptographic and hardware problem.

**Evidence is a nice-to-have** — As long as I delete the data, I don't need to keep logs. The regulator will just trust me.

Regulators (like India's DPDP Act, GDPR) require demonstrable proof of compliance. Without logs and audit trails, you cannot prove you did anything. In fact: You must keep a tamper-evident log of what you searched, what you found, what you deleted, and when. The evidence is half the job.

**Deleting data from the database also removes it from the trained model** — If I delete the training data from my database, the model that was trained on it forgets it automatically.

Models are trained on data and store that information implicitly in their weights. Deleting the database doesn't touch the weights. In fact: You need a separate unlearning step — either full retraining, approximate unlearning, or a deletion-aware architecture like SISA — to remove the influence from the model.


## In short

A deletion request is a runbook: verify identity, enumerate every location (live, backup, cache, derived), delete from all, then re-scan to prove zero remain. The evidence log is as important as the deletion itself. The hard part is scope and the silent restoration of copies. This process hooks directly into machine unlearning because model weights are just another derived dataset.


## Where this is used

Deletion requests show up in every part of modern AI, and the mechanism is always the same: you must remove data from wherever it is stored, and that includes the models. In **large language models** (like ChatGPT), a user may request deletion of their chat history. The company must delete the stored conversation logs (the database copies) and also consider whether the model itself has memorised snippets of that conversation. Full retraining is too expensive, so they rely on approximate unlearning or on the fact that most conversations are not memorised. In practice, the developer writes a pipeline that (1) identifies the user's records in the conversation log, (2) deletes them, (3) re-trains a 'filtering' layer to suppress any residual influence, and (4) logs the evidence. **Small language models** on phones or laptops (TinyML) might store user data locally. A deletion request means clearing the local cache and any on-device model updates. The developer writes code that wipes the local user profile and re-runs an on-device unlearning step if the model was personalised. **Retrieval-augmented generation** (RAG) systems store documents in a vector database. A deletion request must remove the document from the vector store. The developer writes a query to delete by document ID, and also re-generates embeddings for any chunk that remains, to avoid stale vectors. **Agentic systems** that plan and call tools — like a chatbot that books appointments — might store user preferences across a memory store and tool-call logs. A deletion request must purge both the memory store and the logs of tool calls. The developer implements a service that finds all records with the user ID and deletes them, then verifies. **Ordinary applied ML** — recommendation, vision, forecasting, fraud detection — often stores raw training data and features in data lakes. A deletion request requires removing rows from the training set, and because the model was trained on that data, retraining or using a deletion-aware algorithm (SISA) is necessary. The developer writes an ETL script that deletes the rows and a retraining job. In all cases, the evidence log is critical: a regulator will ask for timestamps, scope of search, and the method of deletion. The library notes and books (like "Machine Unlearning") emphasise that deletion is not just a database `DELETE` — it must extend to any model that was trained on the data, which is exactly the unlearning problem. The failure mode is when a deleted record reappears via a backup restore or a stale derived table. That's why the evidence step is non-optional: you re-scan after deletion, and you record the zero count.


---

Read this on the web: https://basavapurushottam.com/learn-ai/deletion-requests
