ML Privacy
Labs
A bank wants a fraud model trained across its subsidiaries, and Gramm-Leach-Bliley governs what may move between them. A hospital network wants a diagnostic model trained across its sites, under HIPAA. Insurers want to price risk on claims they cannot pool. Fintechs want shared signal on accounts they cannot see, and anything touching Europe answers to GDPR, or to CCPA in California. Governments hold the same citizen twice in departments forbidden to compare notes.
In every case the data exists, the model is worth building, and the law is right that it should not be copied into one place.
The methods for this are settled. Federated learning sends the model to the data and returns only weight updates. Differential privacy adds calibrated noise to those updates and bounds how much any one person can influence the result. The infrastructure is real too: Flower runs federated training in production today, with authentication, audit logs and a certified security posture.
What is missing sits at the end. Flower's own differential privacy is marked preview and not recommended for production use on sensitive data, and nothing in the open-source stack keeps a privacy budget. You can add noise. You cannot yet say what a year of training across forty models actually spent, or hand a regulator a number and its derivation.
We think that last mile is the thing worth building: composition tracked across a whole model portfolio, and an audit record produced by the run rather than reconstructed from memory afterward.
We may be wrong about why adoption is low. It could be that the budget question is the blocker, or that the real obstacle is organizational, or that the uplift does not justify the complexity. Those have different answers and we would rather learn which before building further.
First version fall 2026. If you have run into this from the inside, in model risk, privacy engineering or compliance, we would like to hear how it actually failed: jameshan.cs@gmail.com.