Federated learning
Federated learning is a machine-learning approach where devices or organizations train a shared model while keeping raw training data local. Participants send model updates for aggregation, not full datasets, which can reduce data movement but does not remove privacy, security, or fairness risks by itself.
What federated learning is
Federated learning, often shortened to FL, is a way to train machine-learning models across many data holders without first copying all of their raw data into one central dataset. A central coordinator sends a model to participating devices, hospitals, companies, sensors, or other clients. Each client trains on its own local data, then sends back an update to the model. The coordinator aggregates those updates into a new global model and sends the improved model back out for another round. The raw examples stay where they were collected, but the learning process is shared.
The basic training loop
A simple round starts when the server chooses a set of clients and sends them the current model. Each client trains locally for a small number of steps or epochs. The client then returns a model update, such as changed parameters or gradients. The server combines the updates, commonly with a weighted average, and produces the next global model. Federated Averaging, or FedAvg, is the best-known baseline for this loop. Production systems add scheduling, client sampling, retry rules, update compression, secure aggregation, and monitoring because real clients are slow, unevenly connected, and rarely identical.
Cross-device and cross-silo settings
Cross-device federated learning involves large numbers of small clients, such as phones, browsers, vehicles, or consumer devices. These clients may appear briefly, disconnect often, and have limited battery, bandwidth, and compute. The system usually samples only a fraction of eligible devices in each round. Cross-silo federated learning involves fewer but more stable participants, such as hospitals, banks, research labs, manufacturers, or government agencies. The privacy and governance questions can be harder because every participant may have legal duties, audit requirements, and different data definitions.
Why data stays local
Federated learning is attractive when raw data is sensitive, expensive to move, regulated, or too distributed to centralize cleanly. It can support data minimization because the training examples do not need to be copied into a central training warehouse just to improve a model. That does not mean the system has no data flow. Updates, metrics, eligibility signals, and operational logs may still move through the coordinator. A well-designed federated system limits what is collected, aggregates early, retains little, and documents what signals leave each client.
Privacy and security layers
Federated learning is not automatically private. Model updates can sometimes reveal information about local data, especially across repeated rounds or small participant groups. Attackers may also try membership inference, property inference, update reconstruction, backdoor insertion, or model poisoning. Common protections include secure aggregation, which hides individual updates from the server while still allowing an aggregate; differential privacy, which adds calibrated noise or clipping; encrypted communication; anomaly detection; participant attestation; and strict access controls. These protections involve tradeoffs among accuracy, latency, auditability, and privacy guarantees.
Non-IID data and fairness
Federated data is usually non-IID, meaning each client has a different local distribution. A phone keyboard sees one person's language habits. A hospital sees its region, equipment, and patient mix. A factory sensor sees one machine environment. These differences can make the global model unstable or biased toward larger and more frequently available clients. Good evaluation should look beyond average accuracy. Teams need subgroup checks, client-level performance, long-tail behavior, temporal splits, and failure analysis for clients that rarely participate. Without that work, federated learning can make a model look broadly improved while quietly worsening service for smaller groups.
Where it is used
Federated learning is often discussed for mobile keyboard prediction, speech and text models, healthcare collaboration, financial fraud detection, industrial sensors, vehicles, personalization, and edge AI. The strongest use cases have three ingredients: useful local data, a reason not to centralize it, and a model that can improve from aggregated updates. It is less helpful when the data can be centralized responsibly, when clients cannot run training reliably, when labels are poor, or when the model needs fast debugging from full examples. Sometimes a simpler privacy-preserving analytics pipeline is a better fit than federated training.
Why it matters
Federated learning changes the default question from 'How do we gather all the data?' to 'Can useful learning happen where the data already lives?' That shift matters for privacy-sensitive AI, medical research, regulated industries, and edge devices. Its promise is collaborative model improvement with less raw-data movement. Its challenge is that privacy, security, fairness, and accountability still have to be engineered and governed, not assumed from the word federated.