Engineering notes from the field

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

"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.

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.

Federated learning in health projects: what the papers don't tell you

FL is the default answer for multi-hospital AI, and rightly so. But the distance between an FL paper and an FL pilot is large. These are the four issues that dominate real deployments.

1. The data is non-IID in ways that matter clinically

Different scanners, different protocols, different populations. Naïve FedAvg can converge to a model that is worse than a local model for some sites, a result you must detect and report per-site, not on pooled metrics. Personalisation layers and site-stratified evaluation belong in the plan from day one.

2. Governance takes longer than engineering

Even though raw data never moves, each hospital's DPO will (correctly) ask what the model updates leak. Differential privacy on updates plus a written DPIA answer turns a six-month legal negotiation into a manageable one. Start the governance track in parallel with development, never after it.

3. Orchestration is an infrastructure problem

Hospital IT environments are heterogeneous and locked down. Containerised FL clients with outbound-only connections, automated health checks and remote debugging designed for the case where you can't SSH in, this is where the engineering effort actually goes.

4. Plan the evaluation baseline honestly

The scientifically interesting question is not "does FL work?" but "how close does FL get to the centralised upper bound, and is that clinically sufficient?" Pre-register that comparison in the pilot design; it makes the final review meeting a formality instead of a debate.

From TRL 4 to TRL 8: what the jump actually costs

Every proposal promises TRL advancement. Few budget for what it really involves. Having made this journey with research code many times, here is our honest accounting.

TRL 4 → 5: the rewrite nobody wants to admit

Research code optimises for the paper deadline. Reaching a "relevant environment" means dependency pinning, deterministic builds, tests, error handling for inputs the authors never imagined, and usually a partial rewrite. Rule of thumb: as much engineering effort as produced the original prototype.

TRL 5 → 6: integration is the project

Your component now meets the other partners' components. Interface contracts, message schemas, versioning discipline and a shared integration environment with continuous testing are what distinguish consortia that demo on time from those that demo slides. This is why we push for an integration work package with teeth, starting no later than month 6.

TRL 6 → 7: the operational environment fights back

Site networks that block your ports. Cameras mounted where the light is wrong. Users who use the system differently than the requirements said. TRL 7 is reached through deployment rounds, deploy, measure, harden, repeat, not through a single heroic installation. Budget at least two full rounds per pilot site.

TRL 7 → 8: evidence, or it didn't happen

The difference between "we demonstrated it" and TRL 8 is the evidence package: documented KPI results against the pre-registered baseline, reproducible deployment from scratch, operations documentation, and a component set a third party could actually adopt. That package is also the foundation of every exploitation claim in your final review.

Planning a proposal and want this realism in your work-package structure? That's exactly the role we take.