Skip to main content
Bureau of AI
Category: Privacy & Data Protection

Federated Learning

Also known as: FL, Collaborative Learning
Simply put

Federated learning is a machine learning technique that trains AI models across multiple devices or organizations without collecting their raw data in one central place. Instead of moving the data to the model, the model is trained where the data already lives, which is intended to help protect privacy and security. It allows multiple parties to contribute to a shared model while keeping their underlying data local.

Formal definition

Federated learning is a machine learning approach in which a model is trained across multiple decentralized entities (commonly called clients or nodes) that hold local data, rather than aggregating that data into a single centralized dataset. As commonly described, model updates or parameters—rather than the raw training data—are shared and combined to produce a collaboratively trained model, which is often framed as a privacy-preserving property. The specific mechanisms, aggregation protocols, and the degree of privacy or security protection vary by implementation and are not guaranteed by the technique alone; additional safeguards may be required. This entry describes the general concept as presented in the cited sources and does not address the distinct governance, validation, or model risk management controls that would apply when such models are deployed.

Why it matters

Federated learning matters because it addresses a persistent tension in AI development: the need for large, diverse training data versus the legal, competitive, and ethical constraints on centralizing that data. By training a model where the data already resides and sharing model updates rather than raw records, federated learning is commonly presented as a way for multiple parties to collaborate on a shared model while keeping their underlying data local. This is particularly relevant in sectors where data is sensitive, regulated, or held by parties who cannot or will not pool it into a single repository.

At the same time, professionals should be careful not to treat federated learning as an automatic guarantee of privacy or security. As commonly described in the cited sources, the technique is framed as privacy-preserving, but the actual degree of protection depends on the specific implementation, aggregation protocols, and additional safeguards applied. Keeping raw data local reduces certain exposure risks, but it does not by itself eliminate them; model updates can, in some circumstances, carry information about the underlying data. Describing federated learning as inherently private, without qualification, is a common overstatement.

It is also important to distinguish the technique itself from the governance and model risk management controls that would apply once a federated model is deployed. Federated learning describes how a model is trained; it does not, on its own, address validation, monitoring, accountability structures, or the identification and control of risks arising from the model's use. Organizations relying on federated learning still need to determine how such models are validated and governed under whatever frameworks apply to them.

Who it's relevant to

Data scientists and machine learning engineers
Practitioners building models across distributed or siloed data sources need to understand federated learning as an architectural option that trains where data lives rather than centralizing it. They should also recognize that the privacy-preserving characterization is implementation-dependent and that the technique alone does not guarantee a specific level of protection.
Privacy and data protection specialists
Because federated learning is commonly framed as privacy-preserving, privacy professionals are often asked to assess whether it satisfies data protection expectations. They should evaluate the specific implementation and any additional safeguards rather than relying on the general characterization of the technique, since the degree of protection varies and is not guaranteed by the approach itself.
Model risk managers and validators
Federated learning describes a training approach, not the controls governing a model's use. Those responsible for identifying, measuring, monitoring, and controlling model risk should treat the validation and governance of a federated model as separate concerns from the technique itself, applying whatever risk management framework is relevant to their context.
AI governance and compliance professionals
Those responsible for organizational oversight of AI systems need to understand that adopting federated learning does not on its own establish accountability structures, validation processes, or risk controls. Governance measures are still required to manage the risks of deploying models trained this way, and federated learning should not be presented internally as a control that eliminates privacy or security risk.

Inside FL

Decentralized model training
A machine learning approach in which a model is trained across multiple devices or servers holding local data samples, without the raw data being centrally aggregated. Model updates (such as gradients or parameter changes), rather than the underlying data, are typically shared.
Central coordination or aggregation
A coordinating process, often called a server or aggregator, that combines the locally computed model updates into a shared global model. Aggregation methods vary, and the coordinating party's exact role and trust assumptions differ across implementations.
Local data retention
Training data typically remains on the participating node (for example, a mobile device or an institution's own environment) and is not transferred to a central repository, which is a defining characteristic distinguishing this approach from conventional centralized training.
Communication of model updates
Participants exchange model parameters or update signals with the coordinating process over multiple rounds. This exchange is a distinct surface from the data itself and carries its own privacy and security considerations.
Complementary privacy and security techniques
Federated learning is often combined with additional techniques (such as secure aggregation or differential privacy) intended to reduce information leakage from shared updates. These are separate methods and are not inherent to the base federated approach itself.

Common questions

Answers to the questions practitioners most commonly ask about FL.

Does federated learning guarantee data privacy because raw data never leaves the local device or node?
Not on its own. Federated learning is a training approach in which model updates, rather than raw data, are shared with a central coordinator or aggregated across participants, so the underlying data typically remains local. However, keeping raw data in place is not the same as guaranteeing privacy. Model updates can, in some settings, leak information about the training data, which is why federated learning is often combined with additional techniques such as differential privacy or secure aggregation. As commonly framed, federated learning reduces certain data-movement and centralization risks but does not by itself eliminate privacy risk.
Is federated learning the same as distributed or decentralized training?
Not necessarily. Distributed training generally refers to splitting a training workload across multiple compute resources, often over data that is centrally accessible and partitioned for performance. Federated learning is distinguished by the constraint that data is held locally by participants and typically not centralized, with coordination happening through the exchange of model updates rather than data. The two concepts overlap in that both distribute computation, but professionals often err by treating them as interchangeable; the defining feature of federated learning is the data-locality and privacy-motivated setup rather than the distribution of compute alone.
How should model risk and governance responsibilities be assigned across participants in a federated learning arrangement?
Roles typically need to be defined for the party coordinating aggregation and the parties contributing local updates, since accountability can otherwise become ambiguous. In many governance frameworks, responsibilities for data quality, update integrity, and the resulting model's performance may be shared or split across participants, which can complicate the usual mapping of first, second, and third lines of defense. Organizations commonly document who owns aggregation logic, who validates local contributions, and who is accountable for the deployed model. The specific allocation is contested and arrangement-dependent, so this should be treated as a design decision rather than a settled standard.
What validation challenges arise when a model is trained through federated learning?
A central challenge is that validators may not have direct access to the underlying training data held by participants, which can constrain the usual data-review steps in model validation. This can affect assessment of data representativeness, quality, and potential bias sources. Validation may therefore rely more heavily on evaluating the aggregation process, the integrity of contributed updates, and model behavior on available test data. These constraints do not remove the need for validation but change how it is conducted, and the appropriate approach can vary by sector and framework.
How can performance degradation be monitored when participants hold heterogeneous local data?
Because local data distributions can differ across participants, aggregate performance metrics may mask uneven or degrading performance for particular participants or subpopulations. Monitoring commonly considers both overall and participant-level or segment-level performance where feasible, while recognizing that data-locality constraints may limit visibility. This is a matter of tracking model performance over time, which is distinct from model risk more broadly; degradation monitoring informs, but does not by itself constitute, a complete model risk assessment.
What controls are often considered to address the integrity of contributed model updates?
Where model updates are contributed by multiple parties, organizations often consider controls addressing the authenticity and integrity of those updates, since compromised or manipulated contributions could affect the aggregated model. Techniques discussed in this context include secure aggregation and mechanisms to detect anomalous updates, sometimes alongside privacy-preserving methods. Such controls are measures that reduce or manage risk rather than eliminate it, and their suitability depends on the threat model and the specific federated learning arrangement.

Common misconceptions

Federated learning guarantees data privacy because raw data never leaves the device.
Keeping raw data local reduces certain exposure but does not by itself guarantee privacy. Shared model updates can, in some circumstances, leak information about the underlying data. Privacy protection typically depends on additional techniques and safeguards rather than the federated architecture alone, and no control eliminates risk entirely.
Federated learning removes the need for governance or model risk oversight.
Distributing training does not remove the need for oversight. The resulting model still requires validation, monitoring, and accountability structures. If anything, decentralization can introduce additional considerations around data heterogeneity, participant trust, and update integrity that governance and model risk functions must address.
Federated learning is a single standardized method with one fixed definition.
The term covers a range of architectures and design choices, including how aggregation is performed, which parties are trusted, and whether additional privacy techniques are applied. Definitions and implementations vary by context, so the specifics should be documented rather than assumed.

Best practices

Document the specific federated architecture in use, including the role of any central coordinator, aggregation method, and the trust assumptions among participants, so that reviewers can assess the actual design rather than a generic label.
Treat shared model updates as a distinct risk surface and evaluate whether complementary techniques, such as secure aggregation or differential privacy, are warranted rather than assuming local data retention alone provides adequate protection.
Apply model validation and ongoing monitoring to the resulting global model, accounting for data heterogeneity across participants and its potential effect on performance and reliability.
Establish clear accountability and oversight for the coordinating process and participating nodes, defining who is responsible for update integrity, aggregation, and the deployed model.
Assess and document limitations explicitly, noting that federated approaches reduce but do not eliminate privacy and security risk, and that safeguards are measures to manage risk rather than guarantees.
Align the design with applicable governance policies and any relevant regulatory expectations for the operating jurisdiction and sector, without assuming that a single framework or standard applies universally.