Privacy-Preserving Machine Learning: Anonymisation, Aggregation and Federated Learning
Last updated:
Most privacy problems are solved before any clever technique
When a clinic group, a lender or an HR software company asks us about privacy-preserving machine learning, they often expect a conversation about encryption and federated learning. The first conversation is usually simpler: which personal data does the model actually need?
A model predicting appointment no-shows does not need patient names, full addresses or diagnosis details. It may need age band, distance to clinic, appointment type and booking lead time. Removing everything else before data reaches the modelling environment is the cheapest and most effective privacy measure available. The regulations call it data minimisation. We call it not collecting trouble.
Anonymisation versus pseudonymisation
These two terms get used interchangeably, and the difference matters legally.
Pseudonymisation replaces direct identifiers such as names and email addresses with codes, while the key to reverse it exists somewhere. Under UK GDPR and EU GDPR, pseudonymised data is still personal data. It lowers the risk and is strongly encouraged, but all the usual obligations still apply.
True anonymisation means individuals cannot reasonably be identified by anyone, using any means likely to be used. That is harder than it sounds. A dataset with birth date, postcode and gender, even without names, can identify a large share of people. Rich behavioural data such as purchase histories or location traces is notoriously hard to anonymise properly.
Removing the name column is not anonymisation. It is a start, and regulators know the difference.
The main techniques and what they cost
| Technique | What it does | Good for | Cost to you |
|---|---|---|---|
| Minimisation | Uses only the fields the model needs | Every project | Almost nothing |
| Pseudonymisation | Replaces identifiers with codes, key kept separately | Joining data safely during development | Low; still personal data |
| Aggregation and generalisation | Age bands instead of birth dates, areas instead of addresses | Most tabular business models | Small loss of detail |
| Differential privacy | Adds calibrated noise so no individual's presence changes results much | Published statistics, shared models | Some accuracy loss, specialist skills |
| Federated learning | Trains across several sites without moving raw data | Multiple organisations that cannot pool data | Significant engineering and coordination |
| Synthetic data | Generates artificial records with similar patterns | Development, testing, sharing with suppliers | Can leak or distort if done carelessly |
Aggregation: the workhorse
For most business models, aggregation does the heavy lifting. Replace exact ages with bands, exact addresses with postcode districts or distance ranges, exact timestamps with day of week and hour, and individual transactions with monthly summaries.
The accuracy cost is often small because models rarely need the precision you are removing. A churn model gains little from knowing someone is 43 rather than 40-49. Test it: train with detailed and generalised versions and compare. If performance barely moves, keep the generalised one and enjoy a much smaller risk surface.
Federated learning: when data cannot move
Federated learning trains a model across several locations without pooling the raw data. Each site trains on its own data and sends back only model updates, which are combined centrally. It genuinely helps when, say, several independent clinics or banks want a shared model but cannot legally or commercially share records.
It is not a free lunch. You need compatible data formats at every site, computing capacity at each one, protection against updates that leak information, and a lot of coordination. Model updates can still reveal information about the training data, so federated learning is often combined with differential privacy or secure aggregation. For a single business with one database, it solves a problem you do not have.
- Worth considering: several organisations, same prediction problem, data that cannot legally be pooled
- Worth considering: data on customer devices that should stay there
- Probably not worth it: one company whose data is already in one place
- Probably not worth it: a team without experience running distributed training
On-device and self-hosted models
A trend worth noting is the growing capability of smaller models that run on a device or inside your own infrastructure. For text classification, extraction and search over sensitive documents, a self-hosted model can mean personal data never leaves your environment. That can be a simpler privacy story than elaborate techniques around an external service.
The trade-off is operational: you take on hosting, updates and monitoring. We discuss the wider options in keeping your data private in AI systems, and the UK-specific rules in AI data privacy for UK businesses.
Where to start
- List the personal data fields available and justify each one the model uses
- Pseudonymise identifiers before data reaches the modelling environment
- Generalise precise values and test the accuracy impact
- Carry out a data protection impact assessment for anything high-risk
- Restrict and log access to the training data and the models
- Only consider differential privacy or federated learning if a specific risk remains
At SpiderHunts we write the privacy design into the project plan before the first extract, because retrofitting it after a model is built means rebuilding the data. Where the EU AI Act applies to your system, data governance documentation will also be expected, which is covered in our post on data governance for machine learning in small teams. For regulated sectors, this work is part of our enterprise AI service.
Frequently asked questions
What is privacy-preserving machine learning?
Is pseudonymised data still personal data?
When should I use federated learning?
Does anonymising data reduce model accuracy?
Can a trained model leak personal data?
Want to use sensitive data without the risk?
Describe the data and what you want the model to do. We will suggest the least intrusive design that still works, and flag where you should involve your data protection lead.