What Is Federated Learning? Training Models Without Sharing Data

What is federated learning?

Federated learning is a way to train an AI model without moving raw data to one central place. In other words, the data stays on each device or inside each organization. Only the model's learned updates travel to a server, and the server merges them into one shared model.

In the classic approach, you first collect all data in one pool and then train the model there. Federated learning, however, flips that order. The model travels to the data, and the data never travels to the model.

This idea reached a wide audience through the arXiv paper by McMahan and colleagues. Specifically, the authors propose training on data that lives spread across mobile devices, and they merge the results by iterative model averaging.

So the short answer to what is federated learning is simple: you learn from data without taking custody of it. In practice, however, privacy and engineering questions hide behind that sentence.

This article covers one term in depth. We explain how it works, why it matters, what privacy it really gives you, and where it stops helping.

What is federated learning in plain terms, with an analogy?

Picture a classroom where every student keeps private notes in a notebook. Instead of collecting the notebooks, the teacher hands everyone the same summary card. Then each student improves the card using their own notes and returns only the changes.

The teacher merges all the changes and prepares a better card for everyone. As a result, nobody hands over a notebook, yet the shared card learns from everyone's experience.

In this analogy, the notebook is raw data and the card is the model. The changes are model updates, and the teacher is the central server that merges them. In practice, real systems are more complex, but the core idea stays the same.

The analogy also has a weak spot. Someone who studies the changes closely might still guess something about the notebook. We also come back to that risk below.

Note also that the teacher does not have to be a single point. Some designs spread the merging job across several parties.

What is federated learning doing in each training round?

Federated learning moves forward in repeated loops called rounds. In each round, the server picks some participants and sends them the current model. A participant can be a phone, or it can be an organization's own server.

1. The server sends the current shared model to the chosen participants.
2. Each participant trains the model briefly on its own local data.
3. Each participant sends back only the model change, never the raw data.
4. The server merges the incoming changes into a new shared model.
5. The new model goes out again, and the loop repeats until the goal is reached.

This loop can also run for many rounds before the model gets good enough. The number of rounds, the number of participants per round and the length of local training are design choices. In short, they change from project to project.

For example, if local training runs too long, devices can drift toward different models. If it runs too short, then you waste network traffic. Therefore you tune this balance by experiment.

How does the server merge the updates?

The best known merging method is federated averaging. The server takes a weighted average of the changes that participants send. Specifically, a participant that trained on more data usually carries a larger weight.

The paper by McMahan and colleagues shows that this averaging can cut the number of communication rounds sharply. The reason is practical, because on mobile networks the bottleneck is data transfer, not processing power.

Averaging looks simple, but real participants rarely hold similar data. One user types technical terms all day, while another writes casual chat. That difference also makes merging harder.

If you want to see how production systems work, the Google team's system design paper is a good source. It describes how devices drop out, how the server selects them and how rounds stay coordinated.

In short, merging is not only math. It is also a systems engineering problem.

Why does federated learning matter?

A lot of valuable data cannot move for legal or commercial reasons. Personal messages, organizations' internal records and on-device usage habits top that list. Federated learning gives you a way to use the value of that data anyway.

The second benefit is a lighter transfer load. Moving a huge dataset to one place is expensive, and it also widens the attack surface. Moving only updates, on the other hand, is often much lighter.

The third benefit is trust. Because users know their data never leaves their device, they join more willingly. For that reason, federated learning can be a smart choice for technical and reputation reasons alike.

A fourth benefit is data ownership. Also, organizations can contribute to a shared model without giving up their own data. Parties that hold similar data but do not compete can then work together.

A fifth benefit is personalization. Because the model learns from patterns on the device, it can fit local habits better. A purely central model tends to drift toward the average.

Still, this method is not a magic privacy shield. You need to see its benefits and limits together.

What is the difference between cross-device and cross-silo federated learning?

The literature separates two main setups. The first is cross-device, where a huge number of small devices take part. A keyboard model trained across thousands of phones is the classic example.

The second is cross-silo, where a few strong participants take part. A handful of organizations training on their own servers and sharing updates is the typical case.

• In cross-device setups, participants are numerous, but each device is weak and unreliable.
• In cross-silo setups, participants are few, but each one has stable and powerful infrastructure.
• Devices often drop out mid-round in the first case. In the second case, trust between organizations and contract terms are the real issue.

Knowing which setup you are in also shapes every architecture decision. Cross-device work stresses resilience and scale. Cross-silo work, instead, stresses data compatibility and governance.

Also, success looks different in each. One setup aims for a small gain across millions of users. The other aims for a reliable, consistent model that a few organizations can trust.

So settle this question first, before you design anything else.

What is federated learning good for in real products?

Federated learning shines where data is scattered and sensitive. Most uses fall into three groups.

• Personalization on mobile devices, such as keyboard suggestions, voice command recognition and next-word prediction.
• Collaboration between organizations, where several parties build a shared model without sharing their own records.
• Edge devices, such as sensors, cameras or industrial equipment that produce data worth processing in place.

In practice, the common thread is that the data either cannot move or you prefer that it does not. If your data already sits in one place and you can use it freely, federated learning often adds needless complexity.

Besides, not every AI need requires training your own model. Many jobs work fine with an existing model that you set up well. Check whether you truly need training before you consider a federated design.

Do not confuse this method with AI that runs on the device. We covered that topic in our post on what is Edge AI.

How does federated learning work in a keyboard suggestion example?

Google most often explains the idea with keyboard suggestions. The official Google page on federated learning uses this example too. The text a person types stays on the phone, and the model learns next-word prediction right there.

Let us walk through an example scenario. An app developer wants to improve the suggestion feature in a messaging app. The text users type should never reach the app's server.

While the phone is charging and connected, the model produces a small update from that day's typing patterns. Then the update goes to the server, merges with thousands of similar updates, and the new model returns to everyone.

As a result, suggestions improve over time, yet nobody's messages pile up in a central place. This is the clearest and most cited example of the method.

It also shows why the idea grew up in the mobile world. Phones hold plenty of personal text, so users do not want it on a server. The method answers exactly that tension.

Note that the phone joins only under suitable conditions. Battery life and user experience matter as much as privacy in such systems.

How do organizations use federated learning to collaborate?

Several organizations may hold the same kind of sensitive records, yet none can open them to the others. Each one has too little data on its own, so its model stays limited. Training together can produce a stronger model.

As an example scenario, think of image records kept at different institutions. Healthcare often serves as the textbook case, but we keep the topic general here. Each institution then trains the model inside its own system and shares only the update.

That way, the records stay within each organization's boundaries. However, trust between organizations, compatible data formats and contract terms matter as much as the technology.

For instance, if one organization labels records in a different way, the shared model learns in a confused manner. Therefore a common labeling standard is one of the first things to settle before training.

Another issue is how reliable each organization's updates are. If one trains on faulty data, then the shared model suffers. So you need to write participation rules and quality checks up front.

Such a project is a governance effort as much as a software setup. For the legal side, talk to your organization's advisers.

If the data stays on the device, is privacy fully protected?

No, it is not fully protected. Federated learning reduces data collection; however, it does not solve privacy on its own. The reason is that model updates also carry information about the training data.

So describing the method as "the data is private" in one sentence misleads. The accurate version goes like this: raw data does not reach the center, but unprotected updates can leak indirect information.

In addition, participants themselves are not always trustworthy. A faulty or malicious participant can send updates that damage the shared model.

The party that runs the server is also a trust point. If the server sees each update one by one, part of the leakage risk is still there.

In short, privacy comes from layers, not from a single technique. Let us look at those layers one by one in the next sections.

How can model updates leak information?

Researchers have shown that you can sometimes recover training data from shared gradients, which are numbers that show the direction a model learns. One well known study is the paper titled Deep Leakage from Gradients.

The paper reports that, under certain conditions, private data such as images and text can come back from shared gradients. The authors also compare some defense methods.

This finding weakens the assumption that updates are just meaningless numbers. Specifically, the leakage risk depends on the model structure, the update size and what the attacker knows.

For that reason, every federated system needs its own threat model. In other words, you write down in advance who can see what, and who might act in bad faith.

These studies do not make federated learning worthless. On the contrary, they show that the method alone is not enough and needs extra protection.

In practice the lesson is simple. So do not pile raw updates onto a server, and add protection layers to the design from the start.

What do differential privacy and secure aggregation do?

Two common protections answer this leakage. The first is differential privacy. It limits how much one participant can contribute and adds controlled noise to updates. As a result, the model finds it harder to memorize one person's data.

The second is secure aggregation. Updates travel in encrypted form, and the server can decrypt only the total. As a result, the server cannot see any single participant's contribution.

Google's official page mentions both mechanisms together. However, both come with a cost: noise can lower accuracy, and encryption can raise the communication load.

Think of an everyday example. When you report a crowd's average height, you do not reveal anyone's exact measurement. Differential privacy tries to share the pattern of a group in a similar way, without exposing one person.

So you strike a balance between privacy and model quality. Where that balance sits depends on how sensitive the data is.

For current method details, check the relevant papers and the provider's official documentation. This field moves fast, and only the concepts here are lasting.

What are the limits and challenges of federated learning?

Federated learning needs more engineering than central training. These are the main challenges.

• Data heterogeneity: each participant's data follows a different distribution, which makes merging harder.
• Communication cost: network load and waiting time grow as rounds multiply.
• Device dropouts: participants can lose their connection in the middle of a round.
• Hard debugging: since you cannot see raw data, finding the cause of a model error gets difficult.
• Security: malicious participants can try to corrupt the model.

Therefore federated learning is not a method you should use in every project. So choose it only when the need is real.

Projects with little training data also face the risk of memorizing instead of learning. For that topic, see our post on what is overfitting.

Most of these limits come from the nature of working with scattered data, not from the method itself. Knowing them early helps you plan the project realistically.

How do you measure model quality in federated learning?

Because you cannot see raw data, evaluation also becomes scattered. Keeping a validation set at the center is the simplest path, but such a set may not exist.

As an alternative, you can run evaluation in a federated way too. The server sends the model to participants, they measure it on their own data and return only summary metrics.

This approach shows how the model behaves across different groups of participants. However, even when the average score looks high, the model may work badly for one group.

For that reason, do not look at a single average number. Check group-level results, and look at fairness and consistency as well.

Also, the measurement itself can carry a privacy risk. Metrics that are too detailed can leak hints, especially for small groups, so decide with care which summaries you share.

What is the difference between central training and federated learning?

Putting the two methods side by side makes it easier to see when each one fits. The table below is a conceptual comparison, and details change from project to project.

In short, federated learning does not replace central training. It steps in instead when data cannot move. If you can collect data freely, central training is usually simpler and cheaper.

The "best fit" row matters most. For most projects, the real question is not "which is more modern?" but "can my data really not move?"

Which terms do people often confuse with federated learning?

Neighboring concepts get mixed up all the time. The table below separates what each one solves.

Edge AI tells you where inference runs. Federated learning tells you how training happens. Consequently, you can see both in the same project.

Each of these terms also deserves its own article. We kept them short here to show the difference only.

What are the common misconceptions about federated learning?

As the topic grew popular, a few slogans began to circulate. Let us correct the most common ones.

• "The data never leaves the device, so leaks are impossible." Updates can carry information.
• "Federated learning is always safer." It is safer only with the right protection layers.
• "Federated learning shrinks the model." No, model size is a separate matter.
• "It gives you legal compliance automatically." No, your obligations continue.
• "It makes the organization's job easier." On the contrary, operational complexity grows.

Most of these misconceptions come from the short sentences used to promote the method. A short sentence sticks in memory, but it also hides the detail.

So when you decide, go into the detail, and get expert help if needed.

Also remember that federated learning is not a product name. It is an approach, and you can apply it with different tools and different setups.

Why is data heterogeneity such a big problem?

In central training, you can shuffle the data and cut it into balanced pieces. In federated learning you have no such luxury, because the data stays with the participants as it is. Each participant holds a different distribution, and we call this heterogeneous data.

The paper by McMahan and colleagues explicitly targets unbalanced and non-independent data distributions. So the issue has been part of the method from day one.

As an example scenario, in a keyboard model one user writes only work email while another writes only short casual messages. Their updates can pull the model in opposite directions.

In that case the averaged model may then fit neither user well. People try group-specific fine-tuning, more careful weighting and more rounds to ease the problem.

The concept to keep in mind is this: the more varied your data is, the harder merging becomes.

Therefore get to know the participants' data before you start. Find out which groups it clusters into, which classes are rare and which participants hold far more data. This knowledge also shapes your weighting decision directly.

How can you defend against malicious participants?

In an open federated system, you cannot trust every participant. One participant can send a deliberately broken update and push the shared model off course. People call this a model poisoning attack.

The first defense is to identify and authorize participants. That is easy in cross-silo setups. It is harder, however, in cross-device setups, where many anonymous devices join.

The second defense is to make the merge step robust. The server can limit the influence of updates that look very different from the rest. In other words, it does not accept outliers at face value.

The third defense is monitoring and rollback. If model quality drops unexpectedly, then you must be able to return to an earlier version.

Capping the size of each update is also a simple but effective step. If one participant cannot sway the model too much, the damage from a bad update stays small.

No defense gives absolute assurance. So write the threat model according to the scope of your project, and review it regularly.

What does federated learning mean for GDPR?

Not moving data to a center fits one of the core principles of data protection: do not collect more than you need. In that sense, federated learning can support a data minimization approach.

However, using federated learning does not make you compliant with GDPR automatically. Because updates can leak information, you still need to assess which data counts as personal data.

Duties such as transparency, a legal basis, retention and participant rights also remain. For a general compliance frame, see our guide on how to build a GDPR compliant website.

Note: This article is not legal advice. For your project's legal position, talk to your organization's legal counsel.

What should a business check before starting with federated learning?

Now that you have an answer to what is federated learning and what it costs, the checklist below helps you ground the project in reality.

• Is your data truly unable to move, or is moving it just a hassle?
• Do you know the number and type of participants: many devices or a few organizations?
• How similar is the participants' data to one another?
• Have you planned protections such as differential privacy and secure aggregation?
• Do you have a way to verify against faulty or malicious participants?
• Have you decided how to measure model success without seeing raw data?
• Have you done the legal assessment with qualified advisers?

If you cannot answer several of these clearly, starting with a simpler method may be wiser. If you are new to the field, our beginner guide to machine learning is a good first step.

Where does federated learning fit in AI projects inside a company?

Most businesses do not need to build a federated system from scratch. First, you usually need to understand where your data sits, who can reach it and what risks it carries. Employees pasting data into unapproved AI tools is part of that picture, and we covered it in what is shadow AI.

On the data security side, basics such as encryption and access control also come earlier. For that, see our website data security guide.

As Talha Aslan and our team, we help clarify which data an AI idea will use, which architecture it needs and what limits apply. If you want support, take a look at our AI consulting page.

We also decide together whether an advanced method is needed at all. Often a simpler solution is enough, and saying so openly is part of our job.

What is the short summary of federated learning?

If you remember one answer to what is federated learning, remember this: it is a training approach that takes the model to the data instead of bringing the data to the model. Raw data stays on the device or in the organization, only updates travel, and the server merges them.

Its benefit is that it reduces the need to move data and can raise participant trust. Its limits are complex engineering, heterogeneous data and the information that updates may leak.

For that reason, you should add layers such as differential privacy and secure aggregation to the design from the start. You should also assess the legal side with qualified experts.

If you want to explore close terms, our sister articles complete the picture. For on-device running, read what is Edge AI. For memorizing instead of learning, read what is overfitting.

Methods and tools change quickly, so check the provider's official documentation before you build.