All articles

Federated learning and differential privacy: training without collecting

A model can learn from data it never receives. That is genuinely useful, and the guarantee is narrower than the phrase suggests.

The default architecture for machine learning is to centralise: gather every record, put it in one place, train on it. For a great many kinds of data — health records, keystrokes, anything a municipality holds about residents — centralising is the part that carries the risk.

Federated learning inverts it. The model travels to the data, trains locally, and only the update comes back.

shared modeldata 1data 2data 3data 4data 5gradients travel up · records never do
Each participant trains on its own records and returns a weight update. The server averages the updates into a new shared model and sends it back out. Records never move.

The loop

The server sends the current model to a sample of clients. Each runs a few steps of gradient descent on its local data and returns the difference in weights. The server averages those differences, applies them, and repeats. Thousands of rounds later there is a model that learned from everyone's data without anyone's data being copied.

Why the update is not automatically safe

Two mechanisms close the gap. Secure aggregation uses cryptography so the server can compute the sum of updates without seeing any individual one. And differential privacy adds calibrated noise, so the result is provably close to what it would have been had any single record been absent.

What differential privacy actually promises

The guarantee is about influence. It says that from the output, nobody can tell with confidence whether a given individual's record was in the input, because the output would have been nearly the same either way. The parameter epsilon bounds how much difference one record is allowed to make: smaller is stronger and noisier.

privacy budget ε → weakermodel accuracywith DPno DPthere is no free setting
Privacy and accuracy trade against each other directly. The honest question is not whether to pay but how much, and that is a policy decision rather than an engineering one.

What it does not promise is worth stating plainly. It does not stop a model learning true patterns about groups, and a correct inference about a population can be uncomfortable for a member of it. Nor does it help if epsilon is set so high that the noise is cosmetic — and unreasonably high values do appear in production systems.

  • Non-IID data is the practical headache: each client's data looks different, updates pull in conflicting directions, and naive averaging converges slowly or not at all.
  • Client availability is unreliable — phones sleep, sites go offline — so the algorithm must tolerate a changing subset each round.
  • Communication, not computation, is usually the bottleneck, which is why update compression is a live research area.

Where it fits

Federated learning suits situations where data cannot legally or ethically be pooled but a shared model would benefit everyone — several municipalities improving a classifier without exchanging resident reports, for instance. It is not a way to avoid data governance. It is a way to make a specific governance position technically feasible.

The question is never whether a system is private. It is what, precisely, it promises, and to whom.