Local data is not the same as local control.

Federated learning can keep original records inside each participant’s environment. Privacy and authority still depend on what updates reveal, who governs aggregation and how the global model is released.

Original conceptual illustration of four transparent local data vaults sending narrow blue model-update streams to a central aggregator, surrounded by a separate amber governance ring with four control checkpoints.
Original conceptual illustration.
Watch the 48-second visual essay

The records can stay put while information still moves

Federated learning offers an important architectural shift. Instead of collecting every participant’s training records in one place, each participant trains locally and sends model updates for aggregation. The original records can remain inside the device, institution or data silo.

That reduces one kind of movement. It does not mean that nothing informative crosses the boundary. The updates are derived from local data, and the resulting global model reflects contributions from many participants. The privacy question therefore changes from “Did the raw file move?” to “What can another party infer from the update, the trained model and the surrounding process?”

NIST’s January 24, 2024 overview of privacy attacks in federated learning describes attacks against both shared model updates and trained models. Its conclusion is direct: federated learning alone is not a complete privacy solution. Keeping records local is a design decision. Privacy is a property that still has to be tested.

Privacy is a system property—not a location label

A privacy-preserving federated system needs a threat model. Who can see individual updates? Is the aggregator trusted? Can participants collude? What can be inferred after the global model is released? The answers determine which protections are needed.

NIST’s Privacy-Enhancing Technologies Testbeds describe privacy-preserving federated learning that adds calibrated noise to model updates through differential privacy and encrypts computation through techniques such as multiparty computation. The testbed evaluates privacy and utility together, including reconstruction and membership-inference risks. Its first public use case uses plant genomic data to avoid privacy risks to people while the methods are studied. The NIST page was updated October 21, 2026.

These protections carry tradeoffs. Additional noise can affect model utility. Cryptographic protection can increase computation or latency. Some alignment methods may reveal limited information even when raw records stay local. The right question is not whether a system uses a privacy-enhancing technology. It is whether the selected controls reduce the relevant risk enough for the specific use case.

Control has more than one owner

Technical privacy does not settle organizational authority. A federation also needs decisions about who may participate, which model and training configuration are in scope, who chooses privacy parameters, how updates are screened, when aggregation can proceed and who may release the resulting model.

A local participant may control its source data but still lack authority over the global model. An aggregator may coordinate training without gaining permission to reuse participant data or updates for another purpose. A participant that stops future training also needs a clear record of what that decision does—and does not—change about prior rounds or an already released model.

Those distinctions should be visible in the operating record: participant identity, approved purpose, model version, update protections, privacy parameters, aggregation decision, release authority, incident path and withdrawal conditions. This is my governance synthesis for federated AI, not a claim that NIST prescribes one organizational template.

Test privacy, utility and authority together

A proposed study could compare three versions of the same consented or synthetic multi-silo task. The first would use ordinary federated updates. The second would protect updates and outputs with selected privacy-enhancing technologies. The third would add an explicit participant-control record covering admission, purpose, aggregation, release, incident handling and future withdrawal. Keep the datasets, model family, task and evaluation resources constant.

Measure task utility, reconstruction and membership-inference risk, effect of a malicious or faulty participant, privacy and compute cost, unauthorized aggregation attempts, time to stop future participation, ability to reconstruct an approved round and reviewer burden. Do not rely on the system’s own privacy label; test the observable behavior.

This is an experiment design, not a measured result or a claim about a deployed federation. For the next federated project, ask two separate questions: where do the records stay, and who controls what the federation learns, aggregates and releases? A strong answer needs both.

More from the blog RSS feed