When the data cannot move
Federated learning trains a shared model by sending the model to the data instead of the data to the model. Each participant trains locally on its own records, and only model updates travel to a coordinator that combines them. It is the natural option when hospitals, banks, retailers, factories or devices hold related data that cannot be pooled because of regulation, contracts, competition or sheer volume.
It is also easy to oversell. Federation adds engineering complexity, can lose accuracy when participants’ data differs, and does not by itself make training private. The question for a buyer is not whether federated learning is interesting, but whether it will produce a useful model for these participants under these constraints. This engagement answers that first, then builds it if the answer is yes.
What the work involves
Threat assumptions. Before choosing any technology, we write down who the participants are, who runs the coordinator, what each party is trusted with, and what an attacker or a curious participant might try to learn. This decides whether secure aggregation, differential privacy, trusted hardware or contractual controls are needed, and which are overkill.
Baselines. Local-only models show what each participant can achieve alone. A centralised baseline, where any permitted pooled or synthetic data exists, shows the ceiling. Without these, a federated result has no meaning.
Simulation. A federation run on one machine with the data split to mirror the real participants: uneven sizes, different label balances, participants dropping out, limited bandwidth. Imbalanced and non-uniform data across participants is the most common reason federation underperforms, and the simulation reveals it early. My published guide to federated learning in production covers these trade-offs for technical leaders.
Implementation. If the fit assessment supports it: training clients deployed at each site, a coordinator with authenticated, encrypted communication, the agreed privacy measures, model versioning, and monitoring for participation, convergence and drift.
My background here includes peer-reviewed and preprint research in federated learning and distributed systems, listed through the research practice.
The signature deliverable
You receive federated learning engineering: the threat assumptions, the fit assessment and, if commissioned, the working federation. Illustrative example of a fit assessment summary:
| Measure | Local-only (median site) | Centralised baseline | Simulated federation | Note |
|---|---|---|---|---|
| Evaluation metric on held-out data | Lower | Highest | Close to centralised | Gap widens for the two smallest sites |
| Effect of 30% participant dropout per round | n/a | n/a | Small degradation | Acceptable under agreed threshold |
| With differential privacy at agreed setting | n/a | n/a | Noticeable degradation | Needed only if coordinator is untrusted |
| Recommendation | Go, with secure aggregation and no differential privacy, under stated threat model |
Illustrative example. Not taken from a client engagement.
How acceptance is judged
The fit assessment is accepted by the collaboration owner and each participant’s technical contact, against the evaluation measure and threat assumptions agreed at the start. An implementation is accepted when the federation trains across the real participants, reaches the agreed level relative to the baselines, and the operator can run a training round, roll back a model and add or remove a participant using the runbook.
Ownership and handover
Code and configuration live in repositories owned by the collaboration or its lead organisation. Each participant keeps control of its own training client and data. The named operator receives the runbook, monitoring and a walk-through of the privacy measures and what they do not cover.
When to choose something else
If the data can be centralised, use Python and machine learning engineering. If the requirement is a model that runs entirely within one organisation’s infrastructure, see private and local LLM deployment. For research collaborations and independent validation, see the research practice linked on this page.