Health, finance, HR: a regulator with specific rules, a model that could memorise a record, partners who cannot pool. Deleting the name column satisfies none of it.
GDPR, sector rules, a data protection officer with questions. Anonymising a spreadsheet by deleting the name column does not satisfy any of them.
Health, finance, HR, minors. A model that memorises a record can be made to repeat it, and a breach of a model is a breach of the data.
Two banks, three hospitals, a supplier and a customer. Each has half the picture, and no lawyer will sign the transfer that would complete it.
We pick the technique that fits the data and the rule: differential privacy for a bound on what any record can leak, federated learning to train without moving data, secure computation for partners who cannot share. Each comes with a number the DPO can read.
Three parts: choose the technique, implement it properly, and design the system around it.
The right guarantee for the data and the rule.
The guarantee, done correctly.
The system around the model respects the same rules.
Four phases, with the DPO in the room from the first.
Data, rules, threats, accuracy needed.
The mechanism, built and verified.
Accuracy within the guarantee.
Proof, then ongoing control.
Models on the data that matters, with a guarantee instead of a hope.
A privacy budget, a protocol and an architecture the DPO can review. The question changes from whether to how much.
Tested: the model cannot be made to repeat a record. What it learned is patterns, within a bound you set.
Federated or secure computation lets organisations train one model without any of them seeing the others' data.
| Side by side | Ordinary ML | Privacy-preserving ML |
|---|---|---|
| Data handling | Copied to a training environment | Trained in place or under a bound |
| What the model can leak | Unknown; it may memorise records | Bounded by the privacy budget, tested |
| Compliance | Argued after the fact | A protocol reviewed before training |
| Working with partners | Needs a data transfer | Federated or secure computation |
| If the model is stolen | The data may be at risk | The bound still holds |
Usually some, and how much depends on the technique and the budget. We measure it: the model under the guarantee against an unconstrained baseline on the same held-out data, and the trade-off is tuned with the business owner and the DPO together. Federated training on its own often costs little; strong differential privacy costs more.
It follows from the data, the rule and the threat. One organisation with sensitive data and a regulator: differential privacy, often with federated training across its own sites. Several organisations that cannot share: federated learning with secure aggregation, or secure computation when the joint result itself is the product. The assessment tests the candidates on your data.
The mechanisms come from audited libraries, the privacy budget is tracked across every run, and the finished model is attacked: membership inference and extraction tests try to recover records from it. The results go to the DPO with the documentation. Where required, an independent reviewer checks the guarantee.
Mostly, yes. Differential privacy is a change to the training loop. Federated training adds a client at each site and a coordinator. Secure computation needs its own runtime. In every case we build on the pipelines and platforms your team already runs, and say in assessment what has to be added.
We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.
