# Federated Unlearning

Removing a participant's data influence from a federated model, without ever having had the raw data centrally.

**Rests on:** Approximate Unlearning, Utility Preservation

*Machine Learning · Machine Unlearning*


## Why learn this

This topic sits at the intersection of two concepts you already know: **Machine Unlearning** (removing the effect of a specific record from a trained model) and **Federated Learning** (training a model across many devices without collecting their raw data on a central server). Understanding federated unlearning is crucial for building real-world products where users demand privacy. When a user asks to be deleted, your system must actually remove their influence from the model, even though you never stored their personal data in one place. This is a core requirement for **Data Privacy Compliance** and **AI Governance**. Regulators are increasingly asking: 'If a citizen demands erasure, can your technology truly comply?' Without federated unlearning, the answer is no, leaving both legal and technical failures.


## The intuition

Imagine a classroom where every student keeps their own diary. The teacher never sees the diaries. Instead, at the end of each week, every student writes a short 'summary note'—just a few lines capturing what they learned—and hands those notes to the teacher. The teacher blends all these notes into a single 'class summary,' which becomes the starting point for the next week. The teacher only ever sees the summaries, never the original diaries. This is federated learning: each device trains on its own data and sends only a small update (the summary) to the central server, which averages them to improve the global model.

Now, suppose one student leaves and says, 'Please remove everything I contributed from the class summary.' The teacher faces a problem: they never had access to that student’s diary, so they cannot simply delete the original entry. They only have the summary notes they collected. Their influence has been blended into the class summary over time, much like a drop of ink in a glass of water. You cannot pick the ink out; it has already soaked through the water.

The central difficulty is that each week’s summary was built on top of previous summaries. The leaving student’s influence is embedded in the entire model structure. To be absolutely certain their influence is gone, you must throw away the entire class summary and start over from zero, asking every remaining student to write new summary notes as if nothing had happened before. This 'full retraining' is correct but extremely expensive and slow because it requires contacting every device again.

To make this efficient, we change how the classroom operates. Imagine the class is split into two separate groups (let us call them Group A and Group B). The teacher maintains two separate class summaries: one for Group A and one for Group B. When a student joins, they are assigned to exactly one group and only contributes to that specific summary. If a student from Group A leaves, the teacher does not need to touch the Class Summary for Group B. They simply destroy the Class Summary for Group A and retrain it using only the remaining students in Group A. This method of dividing data into non-overlapping groups so that the removal of one member only requires retraining a small fraction of the total model is called **SISA-style sharded training**.


## An analogy

Think of a restaurant kitchen that prepares soups for large banquets. In a standard setup, all chefs add their spice blends to one giant pot. If one chef leaves and demands their recipe be forgotten, the head chef must dump the entire giant pot and start over with all the remaining chefs—a massive waste of time and ingredients.

To solve this, imagine the kitchen now has several separate, identical small pots. Each chef is assigned to stir only one specific pot for the entire duration. The soups in these pots are kept completely distinct; no spice from Pot 1 ever touches Pot 2. If Chef Smith, who was stirring Pot 1, leaves and asks for their influence to be removed, the head chef simply dumps out Pot 1. Pot 2 remains perfectly untouched and ready to serve. The head chef then re-cooks only Pot 1 with the remaining chefs assigned to it.

This separation ensures that removing one participant’s influence requires restarting only a tiny fraction of the total work. In federated unlearning, this division of labor allows systems to comply with deletion requests almost instantly for the affected part, while leaving the rest of the system running smoothly.


## Definition

Federated unlearning is the process of removing a specific participant's data influence from a machine learning model trained across distributed devices without central raw data access, typically achieved by using independent subsets of data so that deleting one member only requires retraining a small subset of the model rather than the entire system.

SISA-style sharded training is a method where the training dataset is divided into non-overlapping groups (shards), ensuring that no single piece of data belongs to more than one group, allowing independent updates and deletions within each shard.


## How it connects

This concept relies on your notes about **Machine Unlearning** and **Federated Learning**. Machine Unlearning provides the goal: erasing specific data's effect. Federated Learning provides the constraint: no central raw data. This topic bridges them by introducing a structural solution (**SISA-style sharded training**) that makes unlearning feasible within the federated constraint. It also connects directly to **Deletion Requests** and the **Right to Be Forgotten**, as these legal frameworks mandate that models must be able to 'forget' individuals, which federated unlearning technically enables.


## The mathematics

Federated unlearning draws on **arithmetic** and **basic algebra** — nothing more. You need to understand what an average is: if you have three numbers, you add them and divide by three. That's it. The model's weights are just lists of numbers, and federated learning updates them by averaging contributions from many clients.

The key mathematical idea is **averaging and its reverse**. When you average numbers, each number contributes a fraction to the total. To remove one number from the average, you can subtract its contribution and re-average. But in federated learning, the average is not a simple sum of client updates — it is a weighted combination, and the model evolves over many rounds. Each round's update builds on the previous round's model, so the influence of one client's data gets entangled with all subsequent updates.

The mathematics you need is **how to compute a weighted average** and **how to reverse it**. If you have three numbers and you know the total, removing one number means subtracting it and dividing by the remaining count. That is the essence of exact unlearning in a single step. But because the model changes over time, you cannot simply subtract the client's last update — you would need to subtract its influence at every round, which is the hard part.

Let the server have a current model weight \(w_t\) at round \(t\). Each client \(i\) sends an update \(\Delta_i\). The server computes the average update \(\bar{\Delta} = \frac{1}{n} \sum_{i=1}^n \Delta_i\), and updates the weight to \(w_{t+1} = w_t + \bar{\Delta}\).

To unlearn client \(k\)'s contribution from that single round, you would need to compute \(w_{t+1}' = w_t + \frac{1}{n-1} \sum_{i \neq k} \Delta_i\). The difference \(w_{t+1}' - w_{t+1}\) is the correction you would apply to the model to remove that client's influence, assuming no other rounds have occurred.


## A worked example

```
Suppose a federated model has a single weight, and three clients (A, B, C) each send an update. After one round, the server averages their updates to get the new weight. Let the current weight be 10. A sends +3, B sends -1, C sends +4. The average update is (3 + (-1) + 4) / 3 = 6 / 3 = 2. So the new weight is 10 + 2 = 12.

Step 1: A: +3, B: -1, C: +4   # Each client sends a small number representing how much they think the weight should change.
Step 2: Sum of updates = 3 + (-1) + 4 = 6   # Add the three updates together.
Step 3: Average update = 6 / 3 = 2   # Divide by the number of clients to get the average.
Step 4: New weight = 10 + 2 = 12   # Add the average update to the current weight to get the new weight.

Result: The new weight after one round is 12. Now, if client B asks to be forgotten, we need to remove B's influence. B's contribution to the average was -1/3 (since -1 divided by 3). The average without B would be (3 + 4) / 2 = 7 / 2 = 3.5. So if we could redo the round without B, the new weight would be 10 + 3.5 = 13.5, not 12. Removing B's influence changes the weight by (13.5 - 12) = 1.5. That is the 'correction' you would need to apply to unlearn B.
```


## From scratch, in Python

```python
# Federated unlearning - a tiny numerical example
# We have 3 clients, each sends an update to a single weight.

# Current weight before the round
current_weight = 10.0

# Updates from clients A, B, C
updates = [3.0, -1.0, 4.0]  # a list of numbers

# Step 1: compute the average update
n = len(updates)  # len() gives the number of items in the list
sum_updates = 0.0
for u in updates:  # a loop: repeat for each item in the list
    sum_updates = sum_updates + u

average_update = sum_updates / n

# Step 2: update the weight
new_weight = current_weight + average_update

print("Average update:", average_update)
print("New weight:", new_weight)

# Now suppose client B (index 1) asks to be forgotten.
# We want to compute what the weight would have been without B.

# Create a new list without B's update
remaining_updates = []  # an empty list
for i in range(len(updates)):  # loop over indices 0, 1, 2
    if i != 1:  # skip index 1 (B)
        remaining_updates.append(updates[i])  # add to the new list

# Compute the average without B
n_remaining = len(remaining_updates)
sum_remaining = 0.0
for u in remaining_updates:
    sum_remaining = sum_remaining + u

average_no_B = sum_remaining / n_remaining

# What the weight would have been without B
weight_no_B = current_weight + average_no_B

# The correction we would need to apply to the current weight
difference = weight_no_B - new_weight

print("Average without B:", average_no_B)
print("Weight without B:", weight_no_B)
print("Correction to apply to current weight:", difference)
```


## The same thing, with a framework

```python
In practice, federated unlearning is implemented using frameworks like **TensorFlow Federated** or **PyTorch** with federated extensions. The server-side code would involve aggregating client updates (using something like `tff.learning.build_federated_averaging_process`), and for unlearning, you might use a library that supports 'unlearning utilities' or you would manually compute the correction using the same principle as above but for thousands of weights. The underlying arithmetic is the same: you need to recompute the aggregate without the deleted client's update. In TensorFlow Federated, you would typically not have direct access to each client's raw data, but you might store the last updates each client sent, and use those to compute a correction.
```


## What the code does

The code starts with a **list** of updates from three clients. A list is a container that holds items in order, and you can change it. The `len()` function tells you how many items are in the list. We then use a **for loop** to go through each update and add it to a running total. This is the 'sum' step. Then we divide by the number of clients to get the average.

Next, we simulate the deletion request: we create a new empty list, loop over the indices (0, 1, 2) using `range(len(updates))`, and skip index 1 (client B). We append the others to the new list. Then we compute the average again. The difference between the two averages tells us how much the weight would have changed if B had never participated. That difference is the correction we would apply to the model to 'unlearn' B in a single round.

This is a simplified single-weight example, but real models have millions of weights. The same principle applies: you would store each client's updates (or a summary) and compute a correction for each weight.


## Common misconceptions

**Federated unlearning is just deleting the client's data from the server** — Since the server never had the raw data, I can just delete the client's update and that's it.

The server stores the aggregated model, and the client's influence is mixed into the model weights. Deleting the update record does not remove the influence already baked into the model weights. In fact: Federated unlearning requires adjusting the model's weights to counteract the contribution of the deleted client's updates, not just removing records from storage.

**Retraining from scratch is the only correct way** — You have to retrain the whole model from scratch to truly forget someone.

Retraining is the gold standard, but approximate methods exist that are faster and often sufficient, especially if the influence is small. Exact methods with sharding can also avoid full retraining. In fact: Retraining is the baseline, but techniques like SISA sharding or gradient correction can achieve effective unlearning with less cost.

**The model cannot be unlearned because we never had the data** — Since we never had the raw data, the model is immune to deletion requests.

The model's weights encode patterns from the data, even if the raw data was never centrally stored. The influence is present in the model, and it must be removed to comply with deletion requests. In fact: The model must be modified to remove the influence, using the updates that were sent, which are a proxy for the raw data.


## In short

Federated unlearning is the process of removing a participant's data influence from a model trained across many devices, without ever having the raw data centrally. The core challenge is that the participant's updates are mixed into the model's weights, so you must compute a correction or use structured training (like SISA) to make deletion feasible. The central trade-off is between exactness and cost: full retraining is the gold standard but expensive, while approximate methods are cheaper but less guaranteed. In practice, you store client updates (not raw data), and when a deletion request comes, you either subtract a computed correction or retrain only a shard. This is essential for complying with privacy laws like the Right to Be Forgotten in federated systems.


## Where this is used

Federated unlearning is used in real-world systems wherever federated learning is deployed and deletion requests must be honoured. Here is how it plays out in different contexts:

- **Large language models (LLMs):** LLMs are often trained on massive datasets, and federated learning is proposed for on-device fine-tuning (e.g., learning from user interactions on their phones without sending the text to a server). When a user asks to be forgotten, the server must remove their influence from the model. In practice, this is extremely difficult because the model is huge and the user's data is tiny relative to the whole. A developer might use an approximate method: they store the user's last few updates (the gradient vectors) and subtract a scaled version of them from the model weights. But this only removes the immediate influence, not the long-term effects on other weights. Some research suggests using influence functions to estimate the effect and correct it, but it is computationally heavy. A developer would write code to load the model, apply a correction vector, and then save the model. The key is that the raw data never leaves the device, so the unlearning must be done on the server using only the updates.

- **Small models on devices (TinyML):** Imagine a smart keyboard that learns your typing habits on your phone via federated learning. If you request deletion, the server needs to remove your update from the global model. Since the model is small (a few hundred kilobytes), it might be feasible to retrain the model on a server using other clients' data (but you don't have the raw data of others either). Alternatively, the server can keep a log of all client updates (not raw data) and recompute the aggregate without yours. This is more tractable because the model is small, and the updates are small. A developer might implement a simple 'rollback and replay' approach: keep the model weights from several checkpoints, and when a deletion request comes, revert to a checkpoint before the deleted client joined, then replay all subsequent updates except that client's. This is exact if you have the updates stored, but it is costly in storage.

- **Retrieval-augmented generation (RAG):** In RAG systems, a model retrieves relevant documents from a database and uses them to generate an answer. If user data is used to personalise the retrieval (e.g., a personal knowledge base that is fine-tuned via federated learning), then unlearning a user means removing their documents from the retrieval index and adjusting the model that ranks documents. This is easier because the retrieval index is a separate database that can be deleted directly. The model part still needs federated unlearning. A developer would delete the user's vectors from the vector database, and then apply a model correction. The mechanism is straightforward: the index is not part of the model weights, so deletion is exact. The model correction might be approximate, but because the model's influence on retrieval is secondary, the risk is lower.

- **Agentic systems that plan and call tools:** Imagine an AI assistant that uses tools (e.g., calendar, email) and is fine-tuned on user data via federated learning. If a user wants to be forgotten, the assistant's behavior should no longer reflect their preferences. The server needs to remove the user's updates from the model that decides which tools to call. This is similar to the LLM case. A developer might maintain a per-user 'influence vector' that is added to the model's weights at inference time, and to unlearn, they would simply remove that vector. This is an efficient approximate method: instead of altering the base model, you keep a small per-user adjustment that can be zeroed out. This technique is used in some production systems to implement 'right to be forgotten' without retraining.

- **Everyday applied machine learning (recommendation, vision, forecasting, fraud detection, speech):** In recommendation systems, federated learning trains a model on user interactions across devices. When a user deletes their account, you must remove their influence. A common approach is to store a per-user 'embedding' that is added to the global model. Unlearning then means removing that embedding from the model, either by subtracting it or by retraining only the final layer. In vision applications (e.g., photo classification on your phone), federated learning might train a model on your photos without uploading them. If you delete a photo, the model should forget it. This is hard because the influence is distributed across all weights. A practical mechanism is to keep a 'shadow model' for each user that is trained on their data and then blended into the global model only after aggregation, allowing you to subtract the shadow model's contribution. For forecasting or fraud detection, where data is sensitive (financial records), federated unlearning is crucial. A developer might use SISA-style sharding: each client trains a separate submodel, and the final prediction is an ensemble. When a client requests deletion, you simply drop that submodel and retrain the ensemble without it. This is exact and cheap.

**What a developer actually writes:** In practice, a developer implementing federated unlearning would use a framework like TensorFlow Federated or PySyft. They would write code to:
- Store client updates (as tensors) in a secure database, not raw data.
- When a deletion request comes, they would compute a correction using the stored updates (as shown in the code above) and apply it to the global model.
- Alternatively, they would trigger a 'recompute' process that re-aggregates all updates except the deleted client's, if the updates are stored.
- For exact unlearning, they would use a sharded architecture: the model is a collection of submodels, and they only retrain the submodel that the deleted client contributed to.

**What breaks when done badly:** If the correction is crude, the model may still retain significant information about the deleted user, leading to privacy leaks (e.g., a membership inference attack can detect that the user's data was in the training set). If the correction is too aggressive, it can degrade the model's performance on other users (the utility preservation problem). If the server does not keep a log of updates, it cannot compute a correction at all, and must retrain from scratch, which is expensive. If the deletion request is not validated first, a malicious user could cause the server to remove another user's influence, damaging the model for everyone.


---

Read this on the web: https://basavapurushottam.com/learn-ai/federated-unlearning
