Federated Learning: Train on Data You Cannot Move

Q: What is federated learning in simple terms?

Federated learning is a way to train a shared machine-learning model across multiple data owners without any of them sending their raw data to a central place. Instead of moving the data to the model, you move the model to the data: each participant downloads the current model, trains it for a few steps on its own local, private dataset, and sends back only the resulting model update — the changes to the weights — not the data those changes were computed from. A central server averages the updates from all participants into a new global model and repeats the process for many rounds until the model converges. The result is a model that has effectively learned from everyone's data even though no participant's data ever left its own environment. The technique was introduced and named by Google in 2016 and is widely used today in two shapes: cross-device federation across millions of phones, and cross-silo federation across a handful of institutions such as hospitals or banks. It matters because it makes it possible to build a model on data that regulation, competition or physics forbids you from ever collecting in one place.

Q: When should I use federated learning instead of just centralising the data?

You should use federated learning only when centralising the data is genuinely off the table, because federation adds substantial distributed-systems and privacy-engineering complexity that a simple central training pipeline avoids. The honest default is: if you can legally and practically copy the data into one place — for example under a data-sharing agreement with willing partners and compatible law — do that, because it is simpler to build, debug and operate. Federation earns its complexity when the raw data cannot move, and there are three common reasons it cannot. Regulation: health data under HIPAA, personal data under GDPR or India's DPDP, and financial records under sector rules frequently cannot leave a jurisdiction or an institution. Competition: organisations such as banks or manufacturers will collaborate on a shared model but will never hand a competitor their raw records. And physics or economics: some datasets are too large or too continuously generated to ship, so moving the model to the data is cheaper. If none of these hard constraints applies, reaching for federated learning is buying complexity you do not need; if one of them is a firm requirement, federation may be the only architecture that works.

Q: How does a round of federated learning work?

Federated learning proceeds as an iterative loop of four steps repeated for tens to hundreds of rounds. First, the central server broadcasts the current version of the global model to the participants selected for that round. Second, each participant trains that model locally for a small number of epochs on its own private data, producing a local update that captures what the model learned from that participant's data. Third, each participant sends its update — the weight changes, never the underlying training examples — back to the server. Fourth, the server aggregates the updates into a new global model; in the canonical Federated Averaging algorithm this is a weighted average of the updates by each participant's dataset size. The new global model is then broadcast again and the cycle repeats until the model stops improving. The only thing that ever crosses the network is model parameters. Frameworks such as NVIDIA FLARE, Flower and Intel OpenFL provide the orchestration, secure communication and fault tolerance so teams do not hand-build the loop, and they integrate with existing training code so the model itself usually does not have to be rewritten to be federated.

Q: Is federated learning private and secure by default?

No, and assuming it is is the most expensive mistake teams make with it. Federated learning keeps raw data local, which satisfies data-residency and data-movement requirements, but the model updates that participants share are computed from that private data and can leak it. Published gradient-inversion attacks can reconstruct recognisable training examples from the shared gradients, and membership-inference attacks can determine whether a specific record was part of a participant's training set. So "the data never left the building" is not the same as "the data is private." A serious deployment adds two defences on top of the base protocol. Secure aggregation is a cryptographic protocol that ensures the central server only ever sees the mathematical sum of all participants' updates and never any single participant's contribution, so no individual update is exposed even to the aggregator. Differential privacy adds carefully calibrated statistical noise to the updates so that no single training record measurably changes the outcome, which bounds how much any attacker can extract, at the cost of some model accuracy. Both are built into the major frameworks as configurable options, but they are opt-in and they involve a privacy-versus-accuracy trade-off, so selecting the operating point is a deliberate engineering and compliance decision, not a default you inherit for free.

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

They use the same underlying algorithm but describe very different systems, and identifying which one you are building is a foundational architectural decision. Cross-silo federated learning involves a small number of participants — from two to perhaps a few dozen — that are institutions such as hospitals, banks or manufacturers, each with a real datacentre, reliable high-bandwidth connectivity, and a substantial local dataset. Every participant is expected to take part in every round, model updates are large, and the trust model is that of known but mutually distrustful organisations. Cross-device federated learning, the shape Google popularised with its Gboard mobile keyboard, involves up to millions of participants that are consumer devices such as phones, each with a tiny local dataset, most of them offline at any given moment. The system samples a subset of devices per round and must tolerate large-scale dropout and anonymous participants. The engineering consequences diverge sharply: cross-silo emphasises rich collaboration among reliable institutions and defends primarily against a curious or malicious institution, while cross-device emphasises massive scale, intermittent availability and robustness to poisoning at volume. Most enterprise regulated-data problems — the hospital and bank cases — are cross-silo, which is a different engineering job from the phone-keyboard examples that dominate introductory material.

Q: How do you apply federated learning to large language models?

The practical technique in 2026 is to avoid federating the entire model and instead federate only small parameter-efficient adapters. Every participant starts from the same frozen open-weights base model — a Llama, Qwen or Mistral checkpoint that is shared and never changes — and trains only LoRA (low-rank adaptation) or similar PEFT adapters on its private local data. Only the adapter weight deltas are sent to the server and averaged, and because the adapters are a tiny fraction of the base model's parameters, this cuts per-round communication from the tens of gigabytes a full model would require down to megabytes. The frozen base never moves, no raw data moves, and the merged adapter captures the cross-silo learning. This maps cleanly onto normal MLOps: the base model is versioned like any dependency, the adapters are build artefacts, and a federated training round becomes a step in a pipeline teams already understand. Real platforms run this in production for regulated data — Eli Lilly's TuneLab, built on NVIDIA FLARE, lets pharmaceutical partners fine-tune models on proprietary data without exposing it — and it is the concrete mechanism behind the common pitch of fine-tuning a model on sensitive data that is not allowed to move.

Q: What is secure aggregation and why does federated learning need it?

Secure aggregation is a cryptographic protocol that lets a server compute the sum of many participants' model updates without being able to see any individual participant's update. The foundational practical scheme was published by Bonawitz and colleagues in 2017, and the core idea is that participants mask their updates with pairwise-cancelling random values so that the masks disappear when all updates are added together but hide each contribution in isolation; the protocol is also designed to tolerate participants dropping out mid-round. Federated learning needs it because, without it, the aggregation server receives each participant's raw update, and those individual updates are exactly what gradient-inversion and membership-inference attacks exploit to reconstruct or fingerprint a participant's private training data. By ensuring the server only ever learns the aggregate, secure aggregation removes the single most sensitive point in the system — the moment an individual update is visible to a party other than its owner. It is typically combined with differential privacy: secure aggregation protects the update in transit and at the aggregator, while differential privacy bounds what the final averaged model itself can leak. Major frameworks including NVIDIA FLARE and Flower provide secure aggregation as a configurable component rather than something you must implement from cryptographic primitives yourself.

Q: What are the main failure modes of federated learning projects?

Five recur. First, federating when centralisation was actually possible: federation is costly in engineering and debuggability, so building it when a data-sharing agreement would have worked is a self-inflicted wound — prove centralisation is impossible before committing. Second, selling federation as privacy without secure aggregation and differential privacy: raw model updates leak their training data, so a deployment that shares them unprotected and calls itself privacy-preserving is making a claim it cannot defend against a gradient-inversion demonstration. Third, ignoring non-IID data: each silo's data is differently distributed, and naively averaging updates trained on divergent distributions can converge slowly or to a model worse than any single site would train alone, so distribution skew must be measured and handled with algorithms like FedProx rather than assumed away. Fourth, no defence against poisoning: a malicious or simply broken participant can send crafted updates that degrade or backdoor the global model, and without robust aggregation methods such as trimmed mean or Krum, one bad silo can corrupt the model for everyone. Fifth, treating governance as solved because the data did not move: the model updates are derived from regulated data and inherit its obligations, so ownership, provenance, access control and cross-border compliance for the updates and the resulting model still have to be designed explicitly.

Satyam Kumar

Back to Blog

ai-architecture

Training on Data You Are Not Allowed to Move

By Satyam KumarAugust 18, 202614 min read

federated learning cross-silo federated learning secure aggregation differential privacy nvidia flare flower framework data residency privacy-preserving machine learning gradient inversion federated lora healthcare ai data sovereignty model inversion non-iid data privacy-preserving ai 2026

Training on Data You Are Not Allowed to Move

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Training on Data You Are Not Allowed to Move

Frequently Asked Questions

Share this article

Comments

Leave a comment