🤖 AI

Privacy Preserving Machine Learning Workflow: from Anonymization to Personalized Differential Privacy Budgets in Federated Learning

This paper proposes a comprehensive privacy-preserving federated learning workflow for sensitive tabular data that integrates anonymization, client drift detection for poisoning mitigation, and a novel methodology for assigning personalized differential privacy budgets based on re-identification risk, demonstrating superior model performance compared to fixed-budget approaches on medical records.

Original authors: Judith Sáinz-Pardo Díaz, Álvaro López García

Published 2026-05-06

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Judith Sáinz-Pardo Díaz, Álvaro López García

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a group of hospitals, each sitting in a different country, wanting to build a super-smart AI doctor to predict how severe a patient's cancer might be. They all have valuable patient data, but none of them can share their actual patient records with each other or a central server. Why? Because of strict privacy laws (like GDPR) and the fear that sensitive medical secrets could get stolen.

This paper proposes a clever way to solve this problem using a system called Federated Learning, combined with a few layers of "privacy magic." Here is the workflow explained in simple terms:

1. The Setup: The "Secret Recipe" Contest

Think of the central server as a contest judge, and the hospitals as chefs.

The Goal: The judge wants to create the best possible recipe (the AI model) for predicting cancer severity.
The Rule: Chefs cannot send their secret ingredient lists (patient data) to the judge. Instead, they cook a little bit of the recipe locally, send back only the changes they made to the recipe (the model updates), and the judge mixes them all together to make a better global recipe.

2. Step One: Hiding the Identity (Anonymization)

Before the chefs even start cooking, they need to make sure their ingredients can't be traced back to a specific person.

The Analogy: Imagine a chef has a list of customers with their names, ages, and favorite foods. To protect them, the chef removes the names and groups the ages into buckets (e.g., "30–39 years old" instead of "34").
The Paper's Method: The hospitals use a tool to generalize their data so that no single person can be identified. Crucially, the paper ensures that all hospitals generalize their data in the exact same way (e.g., everyone uses 10-year age buckets) so the recipes can still be compared fairly.

3. Step Two: Checking for "Drunk Chefs" (Client Drift Detection)

Sometimes, a chef might accidentally use the wrong ingredients, or a malicious chef might try to sabotage the recipe on purpose.

The Problem: If one hospital's data is totally different from the others (maybe they use different equipment or have a different patient population), their recipe changes will look weird. This is called "Client Drift."
The Paper's Solution: The judge looks at the recipe changes before mixing them. If a chef's changes are wildly different from everyone else's (like a chef trying to add "chocolate" to a soup recipe), the judge flags them. This helps catch both accidental errors and malicious attacks without ever seeing the actual ingredients.

4. Step Three: The "Privacy Budget" (Differential Privacy)

Even if the chefs send back recipe changes, a clever hacker might be able to reverse-engineer the original ingredients from those changes. To stop this, the paper adds "noise" (static) to the recipe changes.

The Old Way (Global Budget): Imagine the judge adds the exact same amount of static to every single recipe change, regardless of who sent it. It's a "one-size-fits-all" approach.
The Paper's New Way (Personalized Budgets): The paper suggests a smarter approach. It asks: How risky is it to reveal this specific chef's data?
- If a hospital has a very small, unique group of patients, their data is easier to guess. They get more static (more privacy protection).
- If a hospital has a huge, diverse group of patients, their data is harder to guess. They get less static (less privacy protection, meaning the recipe stays more accurate).
The Metric: They calculate a "Re-identification Risk Score" (ARIREC) for each hospital. The higher the risk, the more noise is added to their contribution.

5. The Results: Does It Work?

The authors tested this system using a fake dataset of 50,000 cancer patient records, split into 10 different "countries" (hospitals). They compared three scenarios:

Standard Federated Learning: No extra privacy steps.
Global Privacy: Adding the same amount of static to everyone.
Personalized Privacy: Adding custom amounts of static based on risk.

The Finding:
The "Personalized Privacy" approach worked better than the "Global Privacy" approach. By tailoring the amount of noise to the specific risk of each hospital, the final AI model was more accurate (lower error rates) while still keeping everyone's data safe.

Summary

This paper presents a complete workflow for training AI on sensitive medical data without ever moving the data itself. It combines:

Anonymization to hide identities.
Drift Detection to spot bad actors or weird data.
Personalized Privacy to add just the right amount of "static" to protect each hospital based on how vulnerable their data is.

The result is a system that protects privacy effectively while keeping the AI model smart and accurate.

Technical Summary: Privacy Preserving Machine Learning Workflow

Problem Statement
The rapid development of artificial intelligence, particularly in sensitive domains like healthcare, necessitates training models on large datasets while adhering to strict privacy regulations such as the General Data Protection Regulation (GDPR). While Federated Learning (FL) offers a decentralized alternative to centralized data training, it introduces specific vulnerabilities. Even without data centralization, FL architectures remain susceptible to privacy breaches (e.g., reconstruction, model inference, and membership inference attacks) and integrity threats (e.g., poisoning attacks and client drift). Furthermore, existing approaches often apply uniform privacy measures (such as a fixed global differential privacy budget) to all clients, failing to account for the varying re-identification risks inherent in different local datasets.

Methodology
The paper proposes a comprehensive workflow for privacy-preserving machine learning on sensitive tabular data, integrating four key stages:

Data Anonymization: Before federated training, clients locally apply anonymization techniques (e.g., $k$ -anonymity, $\ell$ -diversity) to their tabular data. To ensure compatibility for model training, a server coordinates a harmonization process where clients exchange their applied transformation hierarchies. The server determines the maximum hierarchy level required to satisfy all clients' privacy constraints, ensuring all datasets are generalized to the same level within a latent space.
Client Drift Detection: To mitigate poisoning attacks (both intentional and unintentional), the authors formally define "client drift" as a significant shift in the distribution of a client's data relative to the system. Instead of accessing raw data, the server detects drift by analyzing the divergence between model weights using a symmetric metric based on the Frobenius norm (Equation 2). Clients exhibiting significant divergence can be excluded from the aggregation process.
Differential Privacy (DP) with Personalized Budgets: The core contribution is a methodology for assigning personalized privacy budgets.
- Risk Metric: The authors define the Average Re-Identification Risk of Equivalence Classes (ARIREC) for each client based on their anonymized data.
- Budget Allocation: A global noise multiplier ( $n_\epsilon$ ) is established. For each client $i$ , a personalized noise multiplier ( $n_{\epsilon,i}$ ) is calculated by scaling the global multiplier according to the client's normalized ARIREC metric ( $\tilde{A}_i$ ).
- Implementation: Gaussian noise is added to the local model weights of each client before aggregation, with the noise magnitude proportional to the client's specific re-identification risk. This contrasts with Global DP (GDP), where noise is added only to the aggregated weights.
Federated Aggregation: The workflow utilizes a trusted server to aggregate the noisy weights (using FedAvg) and update the global model.

Key Contributions

Formal Definition of Client Drift: The paper provides a formal definition of client drift in FL and proposes a privacy-preserving detection mechanism based on weight divergence, eliminating the need for raw data access.
Personalized Privacy Budgets: It introduces a methodology to assign personalized differential privacy budgets based on a calculated re-identification risk metric (ARIREC), allowing for adaptive noise injection that reflects the specific vulnerability of each client's dataset.
Integrated Workflow: The paper details a complete, reproducible pipeline combining anonymization, drift detection, and personalized DP within an FL architecture.

Experimental Results
The methodology was evaluated using a synthetic dataset of 50,000 medical records for cancer severity prediction, simulated across 10 clients representing different countries. The study compared three scenarios:

Vanilla FL (no privacy).
FL with Global DP (fixed budget added to aggregated weights).
FL with Personalized DP (customized budgets added to local weights).

Results indicated that the Personalized DP approach achieved better model performance than the Global DP approach. Specifically, the Personalized DP scenario yielded lower Mean Absolute Error (MAE: 0.836 vs. 0.847) and Mean Relative Error (MRE: 0.177 vs. 0.182) compared to Global DP, while maintaining privacy protections. The authors note that while both DP methods degrade performance compared to Vanilla FL, the personalized approach minimizes this degradation by tailoring noise to risk levels.

Significance and Claims
The authors position this work as a methodological framework rather than a definitive solution for all real-world scenarios. They claim the primary significance lies in demonstrating that personalized privacy budgets, derived from re-identification risk metrics, can improve model utility compared to fixed global budgets in a federated setting.

The paper explicitly states that the study is a "preliminary" proof of concept using a synthetic, reproducible use case. It acknowledges limitations, noting that the current implementation assumes a trusted server and does not yet provide rigorous $\epsilon$ and $\delta$ accounting for the composition of privacy loss across rounds. The authors suggest that future work will focus on extending this workflow to untrusted server scenarios (potentially using homomorphic encryption) and non-IID client distributions.