Federated Learning
Also known as: federated ML, collaborative learning, privacy-preserving ML, decentralised learning
Federated learning is a machine learning approach in which a model is trained collaboratively across many devices or data silos without the raw training data ever leaving those devices.
Each participating device trains a local version of the model on its own data, then sends only the model updates (not the raw data) to a central server. The server aggregates the updates from all devices to improve the shared model, then distributes the updated model back. The raw data (which may be personal, sensitive, or commercially confidential) never leaves the device where it was generated.
Federated Learning, explained at three levels
At home
Federated learning is a way to teach an AI by having lots of people's devices contribute to the learning without any personal data leaving those devices. Instead of a company collecting millions of people's texts to teach a keyboard to predict words, each phone learns from that person's own typing, then sends only a summary of what it learned (not the texts themselves) to the company. The company combines the summaries from all phones to improve the overall model. Your texts never leave your phone.
At work
Federated learning is used when training data is too sensitive, too distributed, or too voluminous to centralise. Hospitals might each have patient records that are too sensitive to share, but could each train a model locally and contribute updates to a shared diagnostic model without sharing a single patient record. Banks might each have transaction patterns that are commercially confidential, but could jointly train a fraud detection model by contributing model updates rather than transaction data.
At home
In federated learning, the central server coordinates the training process but never sees raw data. The typical federated learning round works as follows: the central server sends the current global model to a selected set of participating devices; each device trains the model on its local data for a few iterations; each device sends its updated model weights (or the difference from the starting weights: called a gradient update) back to the server; the server aggregates the updates (typically by averaging) to produce an improved global model; the cycle repeats. This process continues until the global model reaches target performance.
At work
Federated learning faces several technical challenges not present in centralised training. Communication efficiency is key: sending full model updates between thousands of devices and a server is expensive, so compression techniques (quantization, sparsification) reduce the size of updates without significantly degrading model quality. Statistical heterogeneity is another challenge: the data on different devices may have very different distributions (some users type mostly in French, others in English; some patients have rare conditions that appear only in one hospital). Non-IID (non-independent and identically distributed) data requires special federated training algorithms to prevent the global model from being dominated by the most common data distributions.
At home
Federated learning can be combined with differential privacy (adding mathematical noise to model updates before they are sent to the server) to provide stronger privacy guarantees. Even model updates, not just raw data, can potentially leak information about the training data through reconstruction attacks. Differential privacy on model updates ensures that no individual data point can be reconstructed from an update. This combination (federated learning + differential privacy) is the standard approach for privacy-preserving collaborative model training in regulated industries.
At work
From a practitioner standpoint, federated learning adds significant engineering complexity compared to centralised training. The training infrastructure must be designed to work reliably with heterogeneous devices, intermittent connectivity, and devices that may drop out of a training round partway through. The data pipeline for federated learning is fundamentally different from centralised ML: there is no central data warehouse to query. For projects where federated learning is mandated by privacy requirements, these engineering challenges should be surfaced early in the project scope and timeline planning.
Real-world examples
At home
Sophie notices that her phone's keyboard is gradually learning her personal abbreviations and unusual word choices without her ever uploading her messages anywhere. This is federated learning in action: her phone is contributing to improving the keyboard model by sharing only what it learned from her typing patterns, not the content of her messages.
At work
Five hospitals in a research consortium wanted to build a shared model to detect rare paediatric conditions from imaging data, but none could share patient records under HIPAA. Using a federated learning framework, each hospital trained a local model on its own patient cohort and contributed only model updates to the consortium's shared model: allowing the combined model to learn from 50,000 patient cases across all hospitals without a single record being shared.
Common confusions
- Federated learning is not the same as on-device AI. On-device AI means running a trained model locally on a device for inference. Federated learning is about training a model across many devices without centralising data. These are different phases of the ML lifecycle: training vs. inference. A model trained using federated learning might then be deployed for on-device inference, but the two concepts are independent.
- Federated learning does not eliminate all privacy risk. Model updates can potentially leak information about training data through 'gradient inversion attacks': mathematical techniques that can partially reconstruct what data a model was trained on from its gradient updates. Adding differential privacy noise to updates mitigates this risk but does not eliminate it completely. Federated learning is a significant privacy improvement over centralised training but should not be described as perfectly private.
- Federated learning is not always the right solution for data sharing challenges. If the privacy concern is about institutional data-sharing agreements rather than individual privacy (e.g., two companies do not want to share proprietary data), federated learning addresses the concern only partially: model updates can still reveal statistical properties of the training data. Legal and contractual review should accompany any federated learning implementation where data sensitivity is the primary driver.
For analysts
In BA artefacts, federated learning surfaces as a technical approach for meeting privacy requirements on AI training projects. When documenting requirements for an AI system that will be trained on sensitive data, specify whether federated learning is required (as a constraint) or preferred (as an approach) for privacy compliance. Privacy NFR: 'The model training process must not require centralisation of raw patient records; training must use a federated approach where model updates are computed locally at each participating hospital, combined using secure aggregation, and protected with differential privacy with epsilon ≤ 2.0.' Flag the additional infrastructure complexity as a project risk.
History & origin
Federated learning was introduced in a 2016 paper by Google researchers (McMahan et al., 'Communication-Efficient Learning of Deep Networks from Decentralized Data'). Google's initial application was improving the Gboard keyboard's next-word prediction using data from users' phones without collecting their typing data. The technique attracted significant industry attention as a privacy-preserving alternative to centralised ML training, particularly after GDPR (2018) made the legal risks of centralising personal data more salient. Apple adopted federated learning for keyboard and Siri improvements; research groups extended it to healthcare (multi-hospital models without sharing patient records) and financial services (cross-bank fraud models without sharing transaction data).