Insights · Privacy engineering

FHE, ZKML, SMPC or federated learning? Choosing the right privacy technology

The four privacy-technology families solve different problems at very different costs. This is the decision logic we apply in proposals and client projects.

Published 23 July 2026 · EXPERANOS engineering team

"We need privacy-preserving AI" is where most GDPR-critical project discussions start - and where many stall, because the four main technology families solve different problems at very different costs. Here is the decision logic we apply in proposals.

Start from the threat model, not the technology

Ask two questions first. Who must not see what? And what must be provable to whom? The answers map surprisingly cleanly onto the technology families:

  • Federated learning (FL), when raw data cannot move between institutions, but the institutions trust a coordination process. The model travels; the data stays. Cheapest of the four, mature tooling, and usually the right first choice for cross-organisation training.
  • Fully homomorphic encryption (FHE), when even the party running the computation must not see the data. Inference on encrypted inputs is practical today for small and medium models; training under FHE generally is not. Budget for 3-5 orders of magnitude of compute overhead versus plaintext.
  • Zero-knowledge machine learning (ZKML), when the output must be verifiable: proving that a specific model produced a specific result without revealing the model or the input. Think regulatory audit, model marketplaces, medical second opinions. Proof generation is expensive; verification is cheap.
  • Secure multi-party computation (SMPC), when several parties must jointly compute on combined private inputs with no trusted party at all. Communication-heavy: plan for network topology early.
Start from the threat model who must not see what · what must be provable Federated learning data cannot move, process is trusted cost: LOW · mature FHE compute party must not see the data cost: 3-5 orders of mag. ZKML output must be verifiable by a third party cost: HIGH proving SMPC joint compute, no trusted party cost: network-heavy they compose: FL + DP for training · ZKML at inference
The threat model, not the hype cycle, selects the mechanism

They compose

The strongest architectures combine families: federated learning for training, with differential privacy applied to the updates, and ZKML proofs at inference time where verifiability matters. In proposal terms: one privacy work package, staged across the project, with each mechanism justified by a named risk in the threat model, evaluators notice the difference between that and a keyword list.

The practical trap

The most common failure we see is choosing the strongest mechanism rather than the right one, then discovering in month 18 that proof generation takes minutes per inference on the pilot hardware. Benchmark the privacy overhead on realistic model sizes in the first six months, it is a deliverable we always insist on.

Want this thinking inside your project?

We bring the same engineering realism to proposals, work packages and client systems.

TARGET [0,0]