Federated learning is a machine learning approach in which a shared model is trained across many devices or organizations that each keep their own data locally and send only model updates, not raw records, to a coordinating server. In AI privacy, federated learning is a data minimization technique: it reduces the need to centralize personal data, although it does not by itself guarantee privacy, because model updates can still leak information.
The approach is used where data is sensitive, regulated or too large to move, for example keyboard prediction on phones, medical imaging across hospitals and fraud detection across banks.
How federated learning trains a shared model
Federated learning runs in repeated training rounds coordinated by a central server. The most common baseline algorithm is federated averaging, in which clients train locally for a few steps and the server averages their resulting model weights, usually weighted by the amount of local data.
- The server selects a subset of clients and sends them the current global model.
- Each client trains on its local data for one or more epochs.
- Clients send back weight updates or gradients, never the training examples.
- The server aggregates the updates into a new global model.
- The cycle repeats, often for hundreds or thousands of rounds, until the model converges.
Because clients train on different data, the global model must cope with non-IID data, meaning that each client’s data follows a different distribution. This statistical heterogeneity slows convergence and can bias the model toward clients that participate most often.
Cross-device and cross-silo federated learning
Federated learning deployments fall into two broad settings that differ in scale, reliability and trust. The setting determines which privacy protections and engineering choices are realistic.
| Property | Cross-device | Cross-silo |
|---|---|---|
| Participants | Phones, browsers, sensors | Hospitals, banks, companies |
| Number of clients | Thousands to millions | Typically two to about one hundred |
| Availability | Intermittent, often only when charging on Wi-Fi | Stable, scheduled |
| Data per client | Small | Large |
| Client identity | Anonymous, sampled per round | Known, contractually bound |
| Main challenge | Dropouts, bandwidth, device limits | Governance, legal agreements, data alignment |
A further distinction concerns how data is split. In horizontal federated learning, clients hold the same features for different people; in vertical federated learning, organizations hold different features about the same people, which requires secure entity matching before training.
Privacy risks that remain in federated learning
Keeping data local removes the risk of a central breach of raw records, but model updates are derived from personal data and can reveal it. Research has demonstrated several attack classes that apply directly to federated systems.
| Attack | What the attacker learns or does | Who can attempt it |
|---|---|---|
| Gradient inversion | Reconstructs training examples from updates | Server or eavesdropper |
| Membership inference | Whether a record was in the training data | Server or model user |
| Property inference | Attributes of a client’s data set | Server or other clients |
| Model poisoning | Plants backdoors or degrades accuracy | Malicious clients |
| Model memorization | Final model reproduces rare training data | Anyone querying the model |
These risks explain why regulators and privacy engineers treat federated learning as one layer in a defense in depth, not as anonymization. Under the GDPR, model updates linked to a device or person are generally still personal data processing.
Protections combined with federated learning
Production systems add cryptographic and statistical protections on top of the basic protocol. Each protection addresses a different threat and carries a different cost.
| Technique | What it protects against | Main cost |
|---|---|---|
| Secure aggregation | Server seeing individual updates | Extra communication and dropout handling |
| Differential privacy | Inference about any single person | Lower accuracy as noise increases |
| Trusted execution environments | Inspection of updates on the server | Hardware trust and side-channel risk |
| Homomorphic encryption | Exposure of updates during computation | High computational overhead |
| Robust aggregation | Poisoned updates from malicious clients | Some loss of accuracy |
Differential privacy is controlled by a privacy budget, epsilon. Smaller values give stronger guarantees but require more noise; values used in deployed systems vary widely, and a reported epsilon is only meaningful together with the unit it protects, such as a single example or a whole user.
When federated learning is the right choice
Federated learning is worth its complexity when data cannot or should not be centralized and a shared model brings clear value. It is a poor fit when data could be lawfully pooled, when clients are few and unreliable, or when local data is too small to contribute useful signal.
| Situation | Recommendation | Reason |
|---|---|---|
| On-device personalization | Cross-device federated learning | Data is generated and kept on the device |
| Several hospitals, shared diagnosis model | Cross-silo with secure aggregation | Legal limits on sharing health records |
| Single organization, central data lake | Centralized training with access control | Federation adds cost without benefit |
| Need for formal privacy guarantees | Federated learning plus differential privacy | Locality alone gives no guarantee |
Teams should also plan for training data consent, documentation of what updates contain, and evaluation of the final model for memorization before release, because the model itself is the artifact that leaves the federation.
The idea in brief
Federated learning lets many people or organizations teach one shared model without handing over their data. Instead of sending information to a central computer, each participant improves the model at home and sends back only the lessons learned.
Imagine many cooks improving a shared recipe. Each cook tries it in their own kitchen and reports how to adjust the salt or timing, but nobody ships their groceries to a central kitchen. The reports can still hint at what is in each pantry, which is why extra safeguards are added.
A practical scenario
Five regional hospitals want a model that detects a lung condition on chest X-rays, but none may transfer patient images to another institution. They agree on a cross-silo federation: each hospital trains the model on its own servers, and a coordinator aggregates the updates using secure aggregation, so it never sees any single hospital’s contribution.
Because one hospital has far more pediatric cases than the others, the team monitors accuracy per site and adjusts weighting to avoid a model that serves only the largest partner. Before deployment, the final model is tested for memorization of rare cases.
The resulting model performs better than any hospital could achieve alone, while patient images never leave their original hospital.