TL;DR
Use federated learning when data cannot move between sites, and train centrally when it can. A coordinator sends the model to each site, and each site trains it on local records. Only model updates travel back, where they are averaged into a better shared model. It applies best to hospitals, banks, phones, vehicle fleets and private language-model tuning. It fits poorly when data can be pooled legally or when sites lack compatible data or compute. Updates can still leak information, so add secure aggregation and differential privacy.
Key Takeaways
Federated learning moves the model to the data, so each site trains locally and shares only model updates, never raw records.
Federated averaging (FedAvg) merges those updates while weighting each site by how many training examples it holds.
The type follows the data: horizontal when sites share features, vertical when they share customers, transfer when they share little.
It fits regulated, distributed data in healthcare, banking, mobile keyboards, fleets and private LLM tuning, but data that can be pooled legally rarely needs it.
Before committing, test five questions: can the data move, is it compatible, does pooling help, can sites train, and is governance agreed?
Model updates can still leak training data, so production systems add secure aggregation, differential privacy and outlier-resistant aggregation.
Watch on YouTube
How Enterprise AI Handles Complex Data Across Multiple Systems
A short Kanerika video on how enterprise AI works with data spread across many systems and owners, the same situation that makes training without moving data worth considering.
Four Hospitals, One Model, and Data That Cannot Leave Each Site
Picture four regional hospitals that want to spot a rare lung condition on CT scans. Each one holds only a few hundred confirmed cases, so none has enough to train a reliable model alone.
Pooling the scans would fix the sample problem, but every privacy officer says no. The scans hold patient data, the hospitals sit under different rules, and one central copy would become a single breach target.
That leaves two poor options: four weak models trained on small samples, or a data-sharing agreement that could take a year to sign. Federated learning is the third option.
Instead of moving the scans, the hospitals move the model. Each site trains it on local scans and then sends back only what the model learned.
A coordinator merges those lessons into one stronger model. This guide explains how that loop works, where it applies, and where it is the wrong tool.
What Is Federated Learning?
Federated learning (FL) is a way to train one machine learning model across many data holders without collecting their data in one place.
In ordinary training, every record is copied to a central server so the model can learn from the full pile. With FL, the model travels to where the data sits instead. Each participant trains a copy on its own records and then returns only the change in the model’s weights.
Google researchers defined the approach in a 2016 paper and brought it to a wide audience in an April 2017 research post . That post described testing it in Gboard, its Android keyboard. Phones learned from what people typed, while the typing itself stayed on the device.
The coordinator never sees a raw record. Instead, it sees numbers that describe how the model should shift, and it averages them into a new global version. That is why the approach suits data that is sensitive, regulated, or simply too large to move.
Components of a Federated Learning System
Every federated setup, from four hospitals to millions of phones, is built from the same five parts. IBM’s overview of federated learning describes them in much the same terms.
Coordinator: a central server that holds the global model, picks the participants for each round and merges their updates.Clients: the data holders, which can be servers inside separate organizations or edge devices such as phones and IoT sensors.Local data: the records each client trains on, which never leave that client.Training configuration: the hyperparameters and number of local epochs that travel with the model.Model updates: the changed parameters or gradients each client returns, never raw records.
Benefits of Federated Learning
Those five parts explain the three benefits teams usually cite. Because only updates travel, nobody has to copy a large dataset, which saves bandwidth and time. Sensitive records also stay where they were collected, so there is no central copy to breach. Keeping data local can help banks and hospitals meet data protection rules. Each benefit has limits, which the risk and challenge sections below spell out.
Federated vs Centralized Training
The difference is easiest to see side by side. Both approaches can produce the same kind of model, but they differ in where the data lives and what travels over the network.
Aspect Centralized training Federated training
Where data sits Copied to one server or data lake Stays at each site or device What moves Raw records, once and in bulk Model weights and updates, every round Main cost Storage and transfer, plus a data-sharing agreement Compute at each site, plus repeated communication Debugging Engineers can inspect every record Engineers see metrics and updates instead of records Best when When data can be pooled legally and cheaply When data cannot move, or moving it is too slow or risky
The debugging row matters more than it looks. When the central team cannot open a site’s records, a data-quality problem shows up only as a strange update. Projects therefore need agreed data checks at every site before the first round.
What Federated Learning Does Not Solve
Keeping raw data local is not the same as keeping it private. In their 2019 paper Deep Leakage from Gradients , Zhu, Liu and Han showed that shared gradients can reveal training images and text.
NIST and the UK’s Centre for Data Ethics and Innovation reached a similar view in a January 2024 joint post . It is often possible, they wrote, to extract raw training data from model updates. So FL minimizes how much data moves, which is a narrower promise than anonymization.
It also does not fix biased data, weak labels, or a site that sends bad updates on purpose. Those need the added controls covered in the risk section below, while our guide to AI privacy risks covers the same problem outside a federated setup.
Datasheet
Elevate Data Governance , Compliance and Security
See how Kanerika applies governance, compliance and security controls with automation and real-time monitoring, the layer that keeps distributed data protected.
View the Datasheet → How Federated Learning Works, Step by Step
Every federated project runs the same loop, round after round, until the shared model stops improving. The steps below follow the four hospitals through one complete cycle.
Define the task and the participants: the hospitals agree on the prediction target, the input features, the label definitions and who coordinates, because mismatched schemas cannot be combined.Send the global model: the coordinator sends the current model weights and the training settings to every site.Train locally: each hospital trains the model on its own scans for a few passes, on its own hardware, behind its own firewall.Protect and send the update: each site clips or adds noise to its weight changes when the design calls for it, then encrypts and returns them.Aggregate: the coordinator combines the updates into a new global model, usually with federated averaging.Evaluate and repeat: each site tests the new model on its own held-out data and reports the scores, then the next round starts.
One round can take minutes on a fast network, or hours when servers are busy and links are slow. Because a project usually needs many rounds, the loop design matters as much as the model itself.
Notice what never appears in the loop: a copy of a scan. Only weights go out and only weight changes come back, which is the whole privacy and bandwidth argument in one line.
What Federated Averaging (FedAvg) Actually Averages
Federated averaging, usually shortened to FedAvg, is the default way to merge the updates. McMahan and colleagues at Google defined it in their 2016 paper Communication-Efficient Learning of Deep Networks from Decentralized Data .
The average is weighted by data size. A hospital with 900 training scans counts three times as much as one with 300. So a small site cannot pull the model off course alone, and the weighting fits in a few lines of Python:
import numpy as np
def fed_avg(site_updates):
"""site_updates: list of (weights, n_samples), one per site.
weights is a list of numpy arrays, one per model layer."""
total = sum(n for _, n in site_updates)
n_layers = len(site_updates[0][0])
return [
sum(weights[i] * (n / total) for weights, n in site_updates)
for i in range(n_layers)
]Each site also trains for several local passes before it reports, and that is where the savings come from. In the paper’s experiments, the method needed 10 to 100 times fewer communication rounds than synchronized stochastic gradient descent.
Three settings control that trade. The paper calls them C, the fraction of clients picked each round; E, the number of local epochs; and B, the local batch size. Flower’s FedAvg strategy exposes the same choices in release 1.42, out on October 22, 2026. Its fraction_train setting defaults to 1.0, so every connected site trains each round. The min_train_nodes and min_available_nodes settings both default to 2, and updates are weighted by each site’s reported example count.
The classic failure is raising E to save rounds. In the paper’s Shakespeare tests, very large numbers of local epochs made FedAvg plateau or diverge. The authors suggest reducing local work in later rounds. For the four hospitals, setting min_train_nodes to 4 also matters, because a round averaged from only two sites leans toward those two patient groups.
FedAvg works best when the sites’ data look roughly alike. When they do not, a variant called FedProx keeps each local model close to the global one. That steadies training across uneven sites.
Types of Federated Learning
Federated projects differ mainly in how the participants’ data overlap, and that overlap decides the type. Two banks holding the same columns for different customers is horizontal FL. A bank and a retailer holding different columns for the same customers is vertical FL.
Horizontal FL is the common case, so most frameworks support it first. Vertical FL, by contrast, needs extra work to match records across parties without revealing who is in each dataset.
Federated transfer learning covers the remaining case, when the parties share few records and few features. A model trained by one party carries general knowledge that the other can then adapt to its own data.
Type Worked example Main technical hurdle
Horizontal (sample-based) Four hospitals with the same scan format train one diagnostic model Uneven data across sites, so training converges more slowly Vertical (feature-based) A bank and a retailer combine payment and purchase features for shared customers Matching customers privately before training a split model Federated transfer learning A model built for one market is adapted for a partner with a different customer base Deciding which learned features carry over when markets differ
Cross-Device vs Cross-Silo
A second split depends on who the participants are. Cross-device FL spreads training across huge numbers of phones, wearables or sensors. Each device holds a little data, and devices drop in and out as they go offline.
Cross-silo FL, on the other hand, connects a handful of organizations such as hospitals, banks or plants. Each holds large datasets on reliable servers, and the sites stay online under a contract. Most enterprise work is cross-silo, so the rest of this guide assumes that setting unless it says otherwise.
Server-Coordinated vs Decentralized
Most deployments use a central coordinator that sends models out and aggregates the returns. It is simple to run and audit, but the coordinator is a single point of failure that every party must trust.
Decentralized designs let participants exchange updates peer to peer, with no central server. They remove that trust bottleneck, though they cost more traffic and harder debugging. The trade-offs overlap with wider work on decentralized AI .
For a consortium of a few organizations, a neutral coordinator is usually the practical choice. One member or a third party can run it, as long as every site can audit it.
Where Federated Learning Applies
Federated learning earns its overhead where useful data is split across owners who cannot or will not pool it. The table maps the main sectors, while the short sections after it give one concrete scenario each.
Sector What stays local Usual type Example
Healthcare and life sciences Scans, patient records, trial data Horizontal, cross-silo Hospitals train a shared imaging model while scans stay on site Banking and insurance Transactions, customer profiles Horizontal or vertical Banks learn fraud patterns that no bank sees alone Mobile and consumer devices Typing, voice and usage data Horizontal, cross-device Gboard next-word suggestions on Android Manufacturing, fleets and the edge Sensor and telematics streams Horizontal, cross-silo or cross-device Fleets predict part failures before they happen Language models on private data Internal documents, chats, tickets Horizontal, cross-silo Business units tune one shared assistant while documents stay local
Healthcare and Life Sciences
Hospitals are the textbook case because patient data is sensitive and each site’s sample is small. A federated model for a rare condition can learn from every hospital’s cases while each scan stays on its home network.
FL does not replace the usual approvals: each hospital’s review board still signs off, and sound data governance in healthcare decides which records are eligible.
Banking and Insurance
Fraud and money-laundering patterns often span institutions, while each bank sees only its own slice. A federated model therefore lets several banks learn shared fraud signals without exchanging customer records.
Vertical FL can also link a bank’s features with a partner’s for the same customers. That extends the AI fraud detection a single institution can run on its own data, and it broadens the uses of machine learning in fintech .
Watch on YouTube
Your AI Models Are a Commodity. Your Data Isn’t.
A short Kanerika talk on why proprietary data is the real asset of an AI program, which is exactly why data owners hesitate to pool it.
Mobile and Consumer Devices
Phones generate personal data that users do not want uploaded. Google’s Gboard test was the first public example, since the keyboard improved its suggestions from local typing and sent only model updates back. Google’s post also describes a Secure Aggregation protocol, where the server can decrypt only the average update once hundreds or thousands of users take part.
Manufacturing, Fleets and the Edge
Factories and vehicle fleets produce sensor streams that are large, continuous, and often owned by different partners. Sending every reading to the cloud is expensive, and partners may also refuse to share raw telematics.
Training at the edge keeps those streams local while still building one model. Tasks such as AI in predictive maintenance fit well, because each plant or fleet sees only part of the failure history.
Fine-Tuning Language Models on Private Data
Some teams want a language model tuned on internal documents that cannot leave a region or business unit. For that case, Flower’s documentation includes FlowerTune LLM examples for federated fine-tuning.
Parameter-efficient fine-tuning makes this practical: each unit trains a small adapter, such as LoRA, and sends back only those adapter weights. That is a small fraction of the full model, which matters for the traffic estimate later in this post. The tuned model can then sit alongside the private LLMs a company already runs.
Kanerika Service
AI Consulting Services: Strategy to Implementation
Kanerika designs and builds machine learning systems on distributed and sensitive data, from feasibility checks to production models with per-site monitoring.
Explore AI Services Federated Learning vs Other Privacy-Preserving Approaches
FL is one of several ways to learn from data you cannot simply copy. Each approach protects something different, so the right pick depends on what you need to hide and from whom.
A data clean room, for example, lets two parties run approved queries on joined data while neither side sees the other’s rows. Our guide to data clean rooms shows how Snowflake implements one.
Differential privacy adds calibrated noise so outputs reveal little about any one person. Synthetic data instead replaces real records with generated ones that keep the statistical patterns.
Two heavier options sit further along the scale. With split learning, each site runs the first model layers and sends the activations, not weights, to a server that runs the rest. Secure multi-party computation lets parties compute one joint result on encrypted inputs, which is exact but very costly.
What Each Approach Protects
Approach What it protects Effort and cost Pick it when
Centralized training Nothing beyond normal security Lowest When data can be pooled legally Federated learning Where raw data lives High, because of site compute and many rounds When data cannot move but sites can train Data clean room Each party’s rows in joint analysis Medium When partners need joint queries or simple models Differential privacy Individuals in outputs or models Low to medium, but with some accuracy loss When results or models will be shared widely Synthetic data Real records, replaced by generated ones Medium When teams need realistic test or training data Split learning Raw data and the first model layers High When sites can run only part of the model Secure multi-party computation Inputs during a joint computation Very high When a few parties need one exact joint result
These methods combine well. A strong setup often uses FL to keep data local, then adds secure aggregation to hide each site’s update. Differential privacy then limits what the final model reveals.
Should You Use Federated Learning? A Five-Question Test
The honest answer is often no, because FL adds cost that pays off only under specific conditions. Five questions settle most cases, and the first three decide whether the idea is viable at all.
Is moving the data forbidden, too slow, or too risky? If a data-sharing agreement or a secure central copy is realistic, centralized training is cheaper.Do the sites hold compatible features and labels? When each site defines “fraud” or “readmission” differently, harmonize the definitions first.Would pooled training beat each site alone? If one site already has enough data, collaboration adds little.Can every site run training compute? Each participant needs servers or devices that can train the model, so check hardware early.Is there a governance agreement on the shared model? Someone must own it, set access rules, and decide what happens when a site leaves.
A “no” on any of the first three usually ends the case. Questions four and five are about readiness, so a “no” there means preparation work rather than a dead end.
Wrong-choice cases are common: a single company with all its data in one cloud tenant gains nothing from FL. Two partners who only need a joint report are better served by a clean room. A team with small models and fast networks may likewise find a governed central copy simpler and cheaper.
Running the Four Hospitals Through the Test
Back to the opening scenario. Here is how the consortium answers each question before it commits budget.
Question What the four hospitals found Answer
1. Can the data move? Scans cannot leave any hospital under current agreements No, so FL is needed 2. Compatible data? Same CT protocol; label rules agreed after a joint review Yes, once labels are harmonized 3. Does pooling help? Each site has only a few hundred confirmed cases Yes, because no site has enough cases alone 4. Compute at every site? Three have a GPU server, but one does not Partly, since one site needs hardware 5. Governance agreed? Consortium agreement names a coordinator and model owner In draft, so it must be signed before the pilot
The verdict is go, with two preparation tasks before the pilot. That is the usual pattern: the viability questions pass, and the readiness questions become the project plan.
AI Assessment
How Ready Is Your Organization for Shared AI Models?
Take Kanerika’s AI Maturity Assessment to see where your data, infrastructure and governance stand before you commit to a federated or centralized model project.
Start Your AI Assessment → Privacy and Security Risks, and the Control for Each
Spreading training across many parties opens attacks that a central pipeline does not face. Each attack has a matching control, so most production systems layer several of them.
The risks come from two directions. A curious coordinator or eavesdropper may try to learn about a site’s data from its updates. A dishonest participant, by contrast, may try to corrupt the shared model.
Both belong in a broader AI security framework , and both need planning before the first round. Our guide to data security in AI covers the controls that apply outside a federated setup.
Attack What it does Main control
Gradient inversion (reconstruction) Rebuilds training records from a site’s update Secure aggregation plus differential privacy Membership inference Reveals whether a specific record was used in training Differential privacy and limited model access Data or model poisoning, backdoors Corrupts the shared model or plants hidden triggers Outlier-resistant aggregation and update validation Free-riding participants Takes the model but contributes little or fake work Contribution audits and participation agreements
Outlier-resistant aggregation replaces the plain average with rules that limit the pull of any single update, such as trimming the most extreme values. Update validation also checks each return against simple bounds, so a wildly wrong update never reaches the global model.
Secure Aggregation vs Differential Privacy
These two controls are often confused because both protect updates. Secure aggregation is a cryptographic protocol that lets the server learn only the sum of many updates. It never reveals any single site’s contribution, and Bonawitz and colleagues described a practical version in 2017.
Differential privacy works differently. It adds calibrated noise, either at each site or at the server, so the finished model reveals little about any one record.
Put simply, secure aggregation hides individual updates from the server, while differential privacy limits what the final model can leak to anyone. Most serious deployments use both, and Flower’s example library includes each.
Challenges of Running Federated Learning in Production
The hard problems in production are rarely the algorithm. Instead, they are uneven data, network cost, mismatched hardware, and the question of who owns the result.
Non-IID data: each site’s data reflects its own population, so local models pull in different directions and convergence slows. Test variants such as FedProx.Communication cost: every round moves updates both ways, and model size times rounds times sites grows quickly, so traffic, not compute, often sets the budget.System heterogeneity: sites differ in GPUs, network speed and maintenance windows, so the slowest one sets the pace of each round.Per-site versus global accuracy: a global model can score well on average but poorly at one site, so report results site by site.Ownership: participants must agree who owns the model, who may use it, and what a departing site takes with it.
The accuracy point catches teams out most often. A hospital joins a consortium expecting a model that works on its own patients, not on the average patient. Plan local fine-tuning or per-site acceptance checks from the start, before results disappoint.
A Worked Communication Estimate
Network traffic is easy to underestimate, so here is an illustrative estimate. The numbers are assumptions chosen to show the arithmetic rather than measurements from a real project.
Assume a model with 25 million parameters stored as 32-bit floats, which take 4 bytes each. One full update is then 25,000,000 × 4 bytes, or 100 MB.
Now assume 10 sites, two transfers per site per round (model out, update back) and 200 rounds. Traffic is then 100 MB × 10 × 2 × 200 = 400,000 MB, or about 400 GB.
Two levers shrink that total. Compressing both transfers to 8 bits makes each one a quarter of the size, so the run drops to 100 GB. Halving the rounds to 100 brings it to 200 GB, while doing both brings it to 50 GB. Parameter-efficient fine-tuning helps further when only a small share of the weights changes.
Federated Learning Frameworks in 2026
You do not need to build the federated loop from scratch. Several open-source frameworks handle model distribution, aggregation and security features. They differ in focus as well as in upkeep, so match the framework to your setting before you check its release history.
Framework License Latest release as of October 2026 Maintenance status
Flower Apache-2.0 1.42.0, October 22, 2026 Active, and also ships LLM fine-tuning, differential privacy and secure aggregation examples NVIDIA FLARE Apache-2.0 2.9.0, September 4, 2026 (2.9.1 in release candidates) Active TensorFlow Federated Apache-2.0 v0.88.0, September 26, 2024 Commits continue under google-parfait, but no new release since 2024 OpenFL Apache-2.0 v1.9, June 23, 2025 Still maintained after a repository rename; last push August 2026 FATE Apache-2.0 v2.2.0, July 31, 2024 Low activity since the last push in November 2024
What Each Framework Is Built For
Flower works with any machine learning library and grew out of University of Oxford research. Its examples run from quick simulations to federated fine-tuning of language models. NVIDIA FLARE, by contrast, is a domain-agnostic SDK built to carry a workflow from research and simulation into real-world production.
TensorFlow Federated suits experiments inside the TensorFlow stack, since its bundled runtime is a single-machine simulation. OpenFL began as the backend for a medical-imaging collaboration between Intel and the University of Pennsylvania. Its README, read in October 2026, says it now targets any industry. FATE, an industrial-grade framework hosted by the Linux Foundation, builds its secure computation on homomorphic encryption and multi-party computation.
Release dates only signal maintenance activity. For a system you plan to run for years, note that TensorFlow Federated and FATE have had no new release since 2024.
Choose the way you would compare any ML frameworks , then add three federated-specific checks:
Match the team’s stack: pick a framework that wraps the libraries your data scientists already use, so local training code barely changes.Match the setting: cross-silo pilots need deployment, identity and audit features, while research needs fast local simulation.Check security and upkeep: confirm support for secure aggregation and differential privacy, then review release cadence and open issues.
Running Federated Learning Alongside MLOps and Governance
A federated model is still a model, so it needs the same operating discipline as any other. The loop adds sites and rounds, but versioning, testing, monitoring and rollback do not go away.
Each round produces a new global version, so log every version with the participating sites, their sample counts and the evaluation scores. Standard MLOps practices cover that pipeline, while model registry and versioning keep every global model traceable and reversible.
Monitoring gets harder because no one can inspect the sites’ data directly. Drift tends to show up first in per-site scores, so alerts should track each site separately.
Take the four hospitals again. Suppose round 40 lifts the pooled score, yet one hospital’s own held-out score falls after it installs a new CT scanner. A per-site alert flags the drop, and the registry lets that hospital keep the round 39 model while the team checks the new scans.
Bias reviews, approvals and accountability belong to machine learning governance , which also applies here unchanged.
Checklist
Enterprise AI Checklist
Download the Enterprise AI Checklist to assess AI readiness, strengthen governance, improve data foundations and plan how a model moves into production.
Get the Checklist → Compliance: What Federated Learning Helps With
FL supports compliance, but it does not guarantee it. Under GDPR, Article 5(1)(c) requires personal data to be “adequate, relevant and limited to what is necessary”.
Keeping raw records at their source supports that data-minimization principle. Our overview of GDPR and CCPA compliance then covers the wider duties.
Health data rules such as HIPAA in the US still apply at each site, because local training is still processing. Article 10 of the EU AI Act sets data governance requirements for training, validation and testing data in high-risk AI systems. A federated design still has to show how that data was chosen and checked at every site.
FL can also serve data sovereignty goals, since records stay in their country of origin. That makes it one building block of a sovereign AI strategy, though never the whole of one.
How Kanerika Helps Enterprises Train Models on Distributed Data
Kanerika builds machine learning systems for enterprises whose data is spread across systems, partners and regions. Our AI consulting services work in stages on a federated project, so each investment is tested before the next one starts.
Feasibility and baseline: we run the five-question test with your teams and measure what each site’s model achieves alone, so the case for collaboration is a number.Architecture and controls: we choose the framework, the type of FL and the controls that match your risks, such as secure aggregation and differential privacy.Controlled pilot with exit criteria: we run a pilot on two or three sites with agreed targets for accuracy, round time and cost, then stop if the targets are missed.Production with MLOps: we connect the loop to versioning, the model registry, per-site monitoring and rollback.Expand participants: we add sites in waves, then recheck per-site accuracy and fairness after each wave.
Our closest delivered work is not a federated project, so we will not present it as one. For a GPS fleet-tracking provider, we built a predictive maintenance model on real-time sensor data from many vehicle makes. It also drew on maintenance records and driving patterns from partners whose datasets differed.
The results were 26% fewer accidents, 16% lower maintenance costs and 20% better fleet performance. That project pooled the data centrally. Had partners refused to hand over raw telematics, a federated design is how the same model could still have been trained.
Case Study
26% Fewer Fleet Accidents with Predictive AI Maintenance
A GPS fleet-tracking provider combined real-time sensor data from many vehicle makes with partner maintenance and driving records. The predictive model cut accidents 26%, lowered maintenance costs 16% and lifted fleet performance 20%.
Read the Case Study → Where Federated Learning Fits: The Short Answer
FL works by sending a shared model to each data holder, training it locally, and then averaging only the returned updates. Raw records never leave home, though the updates still need protecting.
It applies where useful data is split across owners who cannot pool it, such as hospitals, banks, phones, fleets and private language-model teams. The approach does not fit when data can be centralized legally and cheaply. It also fails when sites lack compatible data or compute, or when a clean room answers the question.
Before funding a pilot, run the five-question test: if your project passes, federated learning applies, and the model can travel where your data cannot.
Frequently Asked Questions
What is federated learning?
Federated learning is a way to train one machine learning model across many data holders without collecting their data in one place. A coordinator sends the model to each site, each site trains it on local records, and only the model updates come back. Those updates are averaged into a better shared model while raw data stays put.
What is the difference between federated learning and machine learning?
Federated learning is a form of machine learning, not a rival to it. Ordinary machine learning, including most distributed training, gathers data in one place or one cluster the team controls. Federated learning leaves the data with separate owners and moves the model instead, so it adds coordination, privacy controls and communication rounds that centralized training does not need.
Which companies use federated learning?
Google is the best-documented user: it described testing federated learning in its Gboard Android keyboard in 2017 and co-authored the FedAvg and Secure Aggregation papers. NVIDIA maintains the NVIDIA FLARE framework, and Flower Labs maintains Flower, both active in October 2026. For any other company, rely on its own published case studies rather than vendor lists.
How does federated learning work step by step?
First, participants agree on the task, features and labels. Second, a coordinator sends the current model to every site. Third, each site trains it on local data. Fourth, sites protect and send back their updates. Fifth, the coordinator averages them into a new global model. Finally, each site evaluates the result, and the loop repeats.
Does federated learning guarantee data privacy?
No. Federated learning keeps raw data local, which lowers exposure, but research such as Deep Leakage from Gradients and guidance from NIST show that model updates can reveal training data. It is more private than copying records to one server only when paired with secure aggregation, differential privacy and controls against malicious participants.
What is federated averaging (FedAvg)?
Federated averaging, or FedAvg, is the standard method for merging site updates, introduced by McMahan and colleagues at Google in 2016. Each site trains for several local passes, then the coordinator averages the resulting weights, weighted by each site’s number of training examples. In the paper’s tests it needed 10 to 100 times fewer communication rounds.
Which federated learning framework is best?
No single framework is best; pick the one that fits your stack and setting. Flower and NVIDIA FLARE are the most actively released as of October 2026, and Flower includes FlowerTune examples for fine-tuning language models. TensorFlow Federated and FATE have had no new release since 2024, which matters for long-running production systems.
What is an example of federated learning?
Google’s Gboard keyboard on Android is the best-known example. In April 2017 Google described testing federated learning there: phones improved the keyboard’s suggestions by training on local typing and sent only model updates to the server. A hospital consortium training a shared imaging model, with every scan kept on site, is a common enterprise example.
What are the downsides of federated learning?
Federated learning costs more to run than centralized training. Each site needs training compute, every round moves model updates across the network, and uneven data slows convergence. Debugging is harder because engineers cannot inspect remote records. Updates can also leak training data, so teams must add secure aggregation, differential privacy and checks against poisoned updates.
What are the three types of federated learning?
The three types are horizontal, vertical and federated transfer learning. Horizontal federated learning joins sites that hold the same features for different people, such as hospitals using one scan format. Vertical joins parties holding different data fields about the same people, such as a bank and a retailer. Transfer learning bridges parties that share few records and features.
Where is federated learning used?
Federated learning is used where useful data is split across owners who cannot pool it. The main sectors are healthcare, where hospitals share models instead of scans; banking, where institutions learn fraud patterns together; mobile devices, such as keyboard suggestions; manufacturing and vehicle fleets with sensor data; and private fine-tuning of language models on internal documents.
What are the applications of federated learning?
By business function, federated learning supports risk and fraud scoring across institutions, diagnostic and clinical models across hospitals, predictive maintenance on partner-owned sensor data, on-device personalization such as next-word suggestions, and internal assistants tuned on documents that cannot leave a business unit or region. Each case shares learning while the raw records stay with their owner.
Why do you need federated learning?
You need federated learning when moving data is forbidden, too slow or too risky, yet no single site has enough data to train a good model. If the data can be pooled legally and cheaply, centralized training is simpler and cheaper. Federated learning earns its extra cost only when collaboration helps and centralizing is off the table.
What is the future of federated learning?
The clearest signals are active open-source development and language-model support. Flower and NVIDIA FLARE both shipped new releases in October 2026, and Flower’s documentation includes FlowerTune examples for federated fine-tuning of large language models. Expect more private model tuning across business units and partners, combined with secure aggregation and differential privacy as standard controls.
Is federated learning supervised or unsupervised?
Federated learning can be either, because it describes where training happens, not the learning method. Most production examples are supervised, such as classifiers trained on labeled scans or transactions, which need agreed label definitions across sites. Unsupervised and self-supervised models, such as clustering or language-model pretraining, can also be trained federatedly when the data stays distributed.
