Loading
Federated learning is a machine learning technique in which a model is trained across multiple decentralised devices or servers that each hold their own local data, without that raw data ever being pooled or centralised. Instead of moving data to a central server, only model updates, such as adjusted weights or gradients, are sent back and aggregated into a shared global model, an approach Google researchers introduced and named in 2017 and which NIST now documents as a distinct machine learning technique with specific privacy characteristics. For AI governance teams, federated learning matters because it changes where risk lives: it can reduce the exposure created by centralising sensitive data, but it does not by itself guarantee privacy, and it introduces new questions about auditability, data provenance, and model integrity across participating parties. Organisations evaluating federated learning as a privacy control need to understand both what it protects against and what it still leaves exposed.
Run the free AI Health CheckFederated Learning, a machine learning technique in which a model is trained in a decentralised fashion across multiple data sources or devices, without pooling or combining the underlying data in a central location.
Instead of copying everyone's data into one central server to train an AI model, federated learning sends the model out to where the data already sits, on phones, in hospital servers, or on separate organisations' systems, trains it locally, and combines only the resulting model updates. For governance teams, this can shrink the privacy exposure created by centralising sensitive data, but NIST research documents that shared model updates and trained models can still leak information, so federated learning needs to be paired with safeguards like differential privacy or secure aggregation rather than treated as privacy-by-default.
Source: NIST AI 100-2e2025 (NIST Computer Security Resource Center glossary)
In the foundational method, published by Google researchers H. Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson and Blaise Agüera y Arcas in "Communication-Efficient Learning of Deep Networks from Decentralized Data" (AISTATS, 2017), a central server initialises a shared model and sends it to a subset of participating devices or servers. Each participant trains the model further using only its own local data, then sends back a small model update, not the underlying data, which the server aggregates (for example through the paper's Federated Averaging algorithm) into an improved global model. This cycle repeats over many rounds until the model converges.
The original paper's experiments showed the approach was robust to unbalanced and non-identically-distributed (non-IID) data across participants, a defining feature of real-world device data, and cut the number of communication rounds needed by 10 to 100 times compared with synchronised stochastic gradient descent, since bandwidth and unreliable connections, not raw compute, were the binding constraint.
Google's companion description of the method noted a further safeguard called Secure Aggregation: a cryptographic protocol under which the server can only decrypt the *averaged* update once enough participants (hundreds or thousands) have contributed, so no individual device's update is ever inspectable on its own.
Data minimisation by design
Raw data stays on the originating device or server; only model updates travel, reducing both the volume of sensitive data in transit and the size of any single central repository.
Reduced central breach exposure
Because no single store holds all the raw training data, compromising the central aggregator does not, by itself, expose the underlying datasets.
Not privacy by default
NIST's Cybersecurity Insights blog documents reconstruction attacks (citing research by Hitaj et al. and Zhu et al.) that can recover near-exact copies of training examples from shared model updates alone, federated learning does not automatically guarantee privacy.
Trained models can still leak data
The same NIST post cites extraction-attack research (Haim et al., Carlini et al. and others) showing that deployed models, including image classifiers, diffusion models, and large language models, can memorise and leak training data, so protecting updates in transit is not sufficient on its own.
Needs complementary safeguards
NIST's guidance frames robust protection as requiring both "input privacy" (protecting updates during training, e.g. secure aggregation) and "output privacy" (protecting what the finished model reveals, e.g. differential privacy), federated learning alone addresses neither completely.
Mobile keyboards and predictive text
Google's original 2017 public deployment used federated learning to improve Gboard's on-device query-suggestion feature, the strip that suggests a search query or GIF based on what you're typing, without collecting that typing/context data centrally. Google later extended federated learning to next-word predictive-text models in Gboard in subsequent work.
Multi-institution research collaboration
Commonly discussed for settings such as multi-hospital or multi-organisation research where data is naturally distributed and sensitive, allowing shared model training without centralising the underlying records, though the actual privacy guarantee depends on which additional safeguards each deployment implements.
Distributed and edge/IoT devices
Suited to settings the original AISTATS paper identified as motivating: massively distributed, bandwidth-constrained device fleets producing unbalanced, non-IID data that is impractical or undesirable to centralise.
Verify safeguards, not just the label
"Federated learning" is sometimes marketed as inherently privacy-preserving. Procurement and AI risk teams should ask vendors which specific privacy-enhancing techniques, secure aggregation, differential privacy, trusted execution environments, are actually implemented, and request evidence rather than accepting the architecture name as proof.
Model and update integrity
Because reviewers cannot inspect participants' raw data, a malicious or compromised participant can submit corrupted or poisoned updates to degrade or backdoor the shared model. Integrity checks need to focus on validating contributions and aggregation behaviour, not data content.
Auditability across participants
Training now spans infrastructure controlled by multiple parties. Governance documentation should record who controls each data source, what aggregation method is used, and what privacy protections apply at each step, information that is harder to centrally audit than in traditional training.
Regulatory obligations still apply
Federated learning can support data-minimisation goals found in privacy regimes, but it does not by itself satisfy obligations such as lawful basis, purpose limitation, or rules on personal information that can still be inferred from model outputs; those requirements apply to the underlying data and to the trained model regardless of the training architecture used.
Does federated learning guarantee data privacy?
No. NIST's research on privacy attacks in federated learning shows that shared model updates, and even fully trained models, can still leak information about the original training data through reconstruction and extraction attacks. Federated learning reduces certain exposure but needs to be paired with additional safeguards such as differential privacy or secure aggregation for a meaningful privacy guarantee.
Who invented federated learning?
The method and the term were introduced by Google researchers H. Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson and Blaise Agüera y Arcas in their 2017 paper "Communication-Efficient Learning of Deep Networks from Decentralized Data" (AISTATS 2017), alongside a companion Google Research blog post published April 6, 2017.
How is federated learning different from traditional centralized machine learning?
In centralised machine learning, raw training data from all sources is collected and pooled in one place before training begins. In federated learning, the model is sent to where the data already resides, trains locally, and only aggregated model updates travel back centrally, the raw data itself never leaves its original location.
What is Secure Aggregation and why does it matter?
Secure Aggregation is a cryptographic protocol, described in Google's original federated learning work, that lets a central server compute the average of many participants' model updates without ever being able to see any single participant's individual update, the server only decrypts the combined result once enough participants have contributed.
Does federated learning automatically satisfy GDPR or other privacy laws?
No. Federated learning can support data-minimisation objectives by keeping raw data decentralised, but it does not on its own satisfy obligations such as lawful basis, purpose limitation, or handling of personal information that can still be inferred from model outputs. Those legal requirements apply regardless of the training architecture used.
What industries use federated learning?
It originated in Google's mobile keyboard (Gboard), where its first public deployment improved on-device query and GIF suggestions, and was later extended to next-word predictive-text models. It is commonly discussed for settings where data is naturally distributed and sensitive, such as multi-institution healthcare research and cross-organisation modelling. The strength of the resulting privacy protection depends on the specific safeguards implemented in each deployment, not on the use of federated learning alone.
Last reviewed July 2026
This page is general information about What Is Federated Learning?, not legal, regulatory, or professional advice, and does not capture every nuance or exception. Requirements change and can be fact-specific. Always verify against primary sources and your own qualified legal counsel before relying on it.