# Right to Be Forgotten

The legal right to have personal data erased, which extends to models trained on that data and not merely to databases.

**Leads to:** Deletion Requests

**Rests on nothing.** A place to start.

*Machine Learning · Machine Unlearning*


## Why learn this

This concept is the legal trigger that forces technology companies to build systems capable of erasing specific data points. Without this requirement, a company could ignore an individual's wish to have their information removed from its artificial intelligence models. Understanding this right clarifies why engineers must solve difficult technical problems: they must prove to regulators that when a person asks for deletion, the system has actually deleted it, not just ignored the request. This drives the need for methods such as complete retraining from scratch, partial adjustments that approximate deletion, and structured training pipelines that isolate data into separate groups so only one group needs rebuilding, all while ensuring the remaining model stays accurate and that independent tests confirm the data is truly gone.


## The intuition

Imagine a warehouse full of cardboard boxes, each box containing a copy of a person's information. The law says that when someone asks for their data to be deleted, you must destroy every copy — not just the one in the front office, but the ones in the basement, the backups, the ones accidentally shipped to another branch. Now imagine the warehouse isn't boxes but a giant recipe book. The recipe for a model — its weights — was influenced by thousands of ingredients, including one person's data. You can't just rip out one ingredient and still have the same recipe; the cake has already been baked. The 'Right to Be Forgotten' extends to this baked cake: you must somehow make the cake as if that ingredient had never been added. That's the hard problem. The law doesn't care how hard it is — it just sets a deadline.


## An analogy

Imagine you are a chef who has prepared a large pot of soup for a banquet. The soup is the trained model. Each ingredient is a piece of personal data. A guest suddenly says, 'I didn't give you permission to use my secret spice blend — remove it.' You can't fish out the spice from the simmering pot; it has dissolved and changed the whole flavour. Your options: (1) throw out the whole pot and start over from scratch with every other ingredient — this is full retraining, the slow but correct baseline; (2) try to add another ingredient to mask the flavour — this is approximate unlearning, fast but not guaranteed to truly remove it; (3) from the beginning, cook each spice in its own tiny pot and only mix them at the end — this is a method where data is isolated into separate groups during training, so removing one person's influence means throwing away only that tiny pot and re-mixing. The analogy breaks down because in cooking you can taste the result, but for AI we can't 'taste' whether the model truly forgot — we need clever tests to check.


## Definition

The legal right to have personal data erased, which extends to models trained on that data and not merely to databases.


## How it connects

Before this page, you have operationalised the idea of a 'model' as a collection of numbers (weights). This concept connects that idea to the legal world. It is the reason the technical problem of machine unlearning exists. It sits directly above Exact Unlearning (removing influence completely), Approximate Unlearning (removing influence approximately), and Deletion Requests (the process of handling a request). It also connects to Utility Preservation (the tension between forgetting and keeping the model useful) and to Verification (the hard problem of proving forgetting happened).


## The mathematics

The mathematics behind the Right to Be Forgotten is not about new formulas — it is about a cost difference. The law demands a deletion, and the technical baseline to achieve it is full retraining: building the entire model again from scratch, using only the remaining data. The mathematics is about measuring how many operations that takes, and about proving whether a cheaper operation achieves the same result. The branch of mathematics involved is counting and cost analysis — we are comparing the number of calculations in two approaches. There is no derivative or dot product here; it is arithmetic: how many records, how many parameters, how many times you multiply and add. The cost of full retraining is roughly the number of records times the number of parameters, because each training pass touches every number. If you can design the training so that each record touches only a fraction of the model, you reduce that cost proportionally. Verification also uses probability: a membership inference attack checks whether the model's output for a particular record looks like it was trained on it or not, the way a survey might estimate a population proportion from a sample.

Let N be the total number of training records, P the number of model parameters, and E the number of training epochs. The cost of full retraining is roughly C_full = N × P × E. If the data is split into S shards, each containing N/S records, then the cost to retrain one shard is C_shard = (N/S) × P × E. The savings factor is S. For verification, a membership inference attack computes a score s for each record, and if s exceeds a threshold T, we conclude the model 'remembers' the record. The mathematics of forgetting is therefore about making s drop below T for the deleted record while keeping it above T for all others.


## A worked example

```
Assume you have 1,000 training records and a model with 100 parameters. Full retraining means running the training algorithm over all 1,000 records, say 10 times (epochs). We count the number of parameter updates.

Step 1: 1,000 records × 100 parameters = 100,000 updates per epoch   # Each record, when processed, updates every parameter once.
Step 2: 100,000 updates × 10 epochs = 1,000,000 updates for full retraining   # Multiply by the number of passes through the whole dataset.
Step 3: Now suppose SISA: split data into 10 shards, each with 100 records, and each shard trains its own model of 100 parameters.   # Each record touches only its own shard's model.
Step 4: To delete one record from one shard: retrain only that shard: 100 records × 100 parameters × 10 epochs = 100,000 updates   # Ten times cheaper than full retraining.
Step 5: Total across all shards for a single deletion: 100,000 updates (since only one shard is retrained)   # The cost is bounded by the shard size, not the whole dataset.

Result: Full retraining cost = 1,000,000 updates; SISA deletion cost = 100,000 updates. The savings factor is 10×, but the cost is still not zero. The law doesn't care about this arithmetic — it only sets the deadline.
```


## From scratch, in Python

```python
# Building blocks we will use:
# - list: an ordered collection of numbers, e.g. [1, 2, 3]
# - for loop: repeats a block of code for each item in a list
# - function: a named block of code that can be reused

# We will simulate a tiny model as a list of weights, and a tiny dataset as
# a list of (input, label) pairs.  The 'model' here is just a sum of
# weights times inputs — not a real neural net, but enough to show the cost.

# Simulate a dataset of N records, each with 2 features
dataset = [
    ([2, 3], 1),   # record 1: input [2,3], label 1
    ([4, 1], 0),   # record 2: input [4,1], label 0
    ([1, 5], 1),   # record 3: input [1,5], label 1
    ([3, 2], 0),   # record 4: input [3,2], label 0
]

# Simulate a model with 2 weights and 1 bias (initialised to 0)
weights = [0, 0]
bias = 0

# A training step: loop over each record, adjust weights slightly
def train_one_epoch(dataset, weights, bias):
    for x, y in dataset:
        # compute raw score (this is just a weighted sum)
        raw = bias
        for i in range(len(x)):
            raw = raw + weights[i] * x[i]
        # simple update: move weights a tiny step toward the target
        error = y - raw
        for i in range(len(x)):
            weights[i] = weights[i] + 0.1 * error * x[i]
        bias = bias + 0.1 * error
    return weights, bias

# Full retraining from scratch
# Reset weights to zero, then train 3 epochs
weights_full = [0, 0]
bias_full = 0
for epoch in range(3):
    weights_full, bias_full = train_one_epoch(dataset, weights_full, bias_full)
print("Full retraining weights:", weights_full, "bias:", bias_full)

# Now simulate SISA: split the dataset into two shards (lists)
shard1 = dataset[:2]   # first two records
shard2 = dataset[2:]   # last two records

# Train separate models for each shard
w1, b1 = [0,0], 0
w2, b2 = [0,0], 0
for epoch in range(3):
    w1, b1 = train_one_epoch(shard1, w1, b1)
    w2, b2 = train_one_epoch(shard2, w2, b2)
print("Shard1 weights:", w1, "bias:", b1)
print("Shard2 weights:", w2, "bias:", b2)

# Delete a record from shard1 (say the first record)
# Simply re-train shard1 without that record
shard1_remaining = shard1[1:]  # remove first record
w1_new, b1_new = [0,0], 0
for epoch in range(3):
    w1_new, b1_new = train_one_epoch(shard1_remaining, w1_new, b1_new)
print("After deletion, shard1 weights:", w1_new, "bias:", b1_new)

# The point: we did NOT touch shard2's model, so the cost of forgetting
# was only the cost of retraining one shard, not the whole dataset.

# Verification (very simplified membership inference)
# For each record, compute the raw score from the model.
# If the score is above a threshold, we say the model 'remembers' it.
def membership_score(model_weights, bias, x):
    raw = bias
    for i in range(len(x)):
        raw = raw + model_weights[i] * x[i]
    return raw

# Test on the deleted record (from shard1, now removed)
deleted_x = shard1[0][0]  # the input part of the deleted record
score = membership_score(w1_new, b1_new, deleted_x)
print("Score for deleted record after removal:", score, "(should be low)")

```


## The same thing, with a framework

```python
In practice, you would use a machine learning library like PyTorch. The framework call would be something like `model.load_state_dict(...)` for retraining, but the key difference is you would need to implement SISA yourself — there is no 'forget' button in PyTorch. A library like `torch.utils.data` helps split data into shards, but the unlearning logic is custom.
```


## What the code does

The code starts with a tiny dataset: a list of records, each a tuple of (input_list, label). A tuple is like a list but immutable. The `train_one_epoch` function is defined and then reused. It loops over each record, computes a raw score by multiplying weights and inputs, and adjusts weights based on the error. This simulates training. Then we run full retraining: we reset weights and train for 3 epochs. Next we simulate SISA: we slice the dataset into two shards using list slicing, train separate models on each shard, and then delete a record by re-training only the affected shard. Finally, we show a crude membership inference: we compute the raw score for the deleted record and observe that it changed after removal. This illustrates the cost difference and the verification problem.


## Common misconceptions

**Deleting the database is enough** — If I delete the user's row from my database, I've complied with the Right to Be Forgotten.

The law and regulators have extended the right to models trained on that data. The model's weights were adjusted by that row, so the model 'remembers' the information and can potentially leak it. In fact: You must also ensure the model no longer contains learnable traces of the deleted data — either by retraining the model or by using an unlearning technique.

**Retraining is always feasible** — If someone asks for deletion, we can just retrain the model from scratch — it's just a matter of time.

For modern LLMs with billions of parameters, full retraining costs millions of dollars in compute and months of time. The response deadline in regulations is fixed (e.g., 30 days), so retraining is often not viable. In fact: That's why research into approximate and sharded unlearning exists — to make deletion possible within the deadline.

**The model 'stores' the data** — The model contains a copy of each person's data like a database row, so I can just find and delete it.

Models store compressed, distributed representations. A single person's data influences thousands of weights; it is not stored as a discrete entry. In fact: Unlearning is about removing influence, not deleting a stored instance.

**Once forgotten, always forgotten** — After I apply an approximate unlearning method, the model has fully forgotten the record.

Approximate methods reduce influence but do not guarantee exact removal. A robust membership inference attack might still detect traces. In fact: Exact unlearning requires special training structures like SISA. Otherwise, you need verification and possibly retraining.


## In short

The Right to Be Forgotten is the legal obligation that forces AI systems to forget personal data — not just from databases but from trained models. Full retraining is the gold standard but often too expensive. Techniques like SISA make forgetting affordable by limiting what each data record touches. The hard parts are proof (verification) and utility (not degrading the model).


## Where this is used

The Right to Be Forgotten appears across the AI stack. In large language models, a model's weights have been trained on billions of documents scraped from the web, which include private personal information. If a person requests deletion, you cannot easily remove just that text — the model's weights were adjusted by it during training. Companies like OpenAI and Google face this; they must either retrain (impractical), attempt approximate unlearning, or claim the information is not 'personal data' — a legal workaround. In small language models running on phones (e.g., on-device assistants), the model is downloaded once and runs locally. A deletion request might target the source dataset used to train that model, but the model on the phone cannot be updated without pushing a new version — so the practical approach is to design training so that it doesn't use personal data in the first place. In retrieval-augmented generation (RAG), the model doesn't store data directly — it retrieves documents from an external database at inference time. This makes forgetting easier: you can simply delete the document from the database, and the model will never retrieve it again. For agentic systems that plan and call tools, the system might have memory of past interactions stored in a vector database; forgetting means deleting embeddings from that store, but the agent's policy model has also been fine-tuned on those interactions, so you must handle both. In everyday applied machine learning (recommendation, fraud detection), the model is trained on user data. A deletion request means removing that user's records from the training set and retraining or updating the model. Developers often use SISA sharding to bound the cost: they split the data into shards, train separate models per shard, and on deletion re-train only the affected shard. They must also delete from backups and caches. Verification is usually the hardest part: they must run membership inference attacks on the model to show that the deleted record's score is indistinguishable from a record never seen. In practice, they write scripts that (1) receive the request, (2) verify the user's identity, (3) locate all copies of the data, (4) execute the deletion (retraining or shard retraining), and (5) log evidence for the regulator. The library they reach for is PyTorch or TensorFlow, along with custom unlearning libraries. What breaks when done badly: the model still leaks private information through membership inference, or the model degrades in performance on other users — the utility preservation tension.


---

Read this on the web: https://basavapurushottam.com/learn-ai/right-to-be-forgotten
