All research
16 July 2026·9 min read·Privacy-Enhancing Technologies·Federated Learning·Differential Privacy

Federated Computing: Deploying AI on Data You Cannot Move

Federated learning, differential privacy, and trusted execution environments let organisations train and run AI on sensitive data that regulation or competition keeps locked in place. A grounded look at what has actually shipped, what the regulators say, and where the claims outrun the evidence.

The Problem Sits Before the Technology

Most enterprise AI failures are not model failures. A July 2025 report from MIT’s Project NANDA, The GenAI Divide: State of AI in Business 2025, found that roughly 95% of generative-AI pilots produced no measurable profit-and-loss impact. The report attributes this less to the models and more to an integration gap — the difficulty of wiring AI into real workflows, data, and controls. That framing is contested and the sample is modest, so it should be read as a directional signal rather than settled fact. But it points at a structural truth that regulated organisations already know: the data that would make a model valuable is usually the data you are least able to move.

A bank’s fraud signal is spread across institutions that cannot pool transaction records. A hospital’s rare-disease cohort is spread across sites that cannot combine patient data. A manufacturer’s failure data sits behind competitors’ firewalls. In each case the useful dataset exists, but law, data sovereignty, or competition prevents anyone from assembling it in one place. Centralising the data is the obvious move and, for these organisations, frequently the illegal one.

Privacy-enhancing technologies (PETs) are the architectural response. Rather than bringing data to the computation, they bring the computation to the data. This is not a new academic idea, but 2025 and 2026 have seen it move into named production deployments — which is what makes it worth a UK business’s attention now rather than in a research-horizon sense.

The Stack, Defined Plainly

“Federated computing” is a marketing umbrella. Underneath it are several distinct techniques that solve different parts of the problem, and it is worth keeping them separate.

Federated learning distributes a model to each data holder, trains it locally behind their firewall, and returns only the model updates — the mathematical adjustments learned from local data, not the data itself — to a central server that aggregates them into an improved shared model. Raw records never leave the premises.

Differential privacy adds calibrated statistical noise to an output so that the presence or absence of any single individual cannot be inferred from it. It carries a formal, tunable guarantee (an “epsilon”) that trades accuracy against privacy. Critically, it protects outputs — model parameters, published insights — not the computation itself.

Trusted execution environments (TEEs), sometimes called confidential computing, use hardware isolation so that data and code in memory cannot be read even by a privileged administrator or the cloud provider hosting the machine. Attestation lets a data owner verify that only approved code is running.

Homomorphic encryption and secure multi-party computation sit further along the cryptographic spectrum, enabling computation on encrypted data or joint computation without any party revealing its inputs. They are powerful and, today, expensive.

The important governance point is that none of these is sufficient alone. Federated learning without differential privacy can still leak information through the model updates it shares. Differential privacy without a trusted execution boundary protects the answer but not the working memory. A credible deployment layers them by the sensitivity of the use case. Vendors who present any single one as “the” privacy solution are overselling.

What Has Actually Shipped

Three deployments are worth citing because they can be independently verified, and because the distance between the vendor framing and the primary record is itself instructive.

Financial crime detection. In December 2024, Google Cloud and Swift announced a federated-learning collaboration — with Rhino (then trading as Rhino Health) building the platform and Capgemini integrating it — to let banks train a shared anomaly-detection model without pooling transaction data. Swift described a sandbox running on synthetic data in the first half of 2025 with roughly a dozen global institutions. Separately, JPMorgan’s Kinexys unit and BNY, together with RBC, DeepTempo and NVIDIA, ran a proof-of-concept called Project AIKYA on the same principle. The published JPMorgan and BNY materials say the federated model outperformed single-institution models and nearly matched a centralised model trained on pooled data. Some third-party summaries claim a “40–50% improvement”; that figure does not appear in the primary documents and should not be repeated without a source.

Drug discovery. In September 2025, Eli Lilly launched TuneLab, built on Rhino’s federated platform atop NVIDIA’s FLARE framework. It gives biotech partners access to AI models Lilly trained on internal data — by Lilly’s count, 18 models at launch: 12 predicting small-molecule properties and 6 assessing antibody developability — while partners run them locally and contribute improvements back through federated learning, without either side exposing its underlying data. (Rhino’s own platform page cites 16 ready-to-use models; the two counts have not been reconciled publicly, and we cite Lilly’s because it is the deploying party.) The initial use cases were deliberately chosen in pre-competitive areas — ADMET and antibody developability — where firms are not differentiating and are therefore likelier to share. Lilly’s release describes hundreds of applicant companies; specific partner counts beyond the named early adopters are vendor-stated.

The pattern across these is consistent and genuinely novel: competing institutions collaborating on a shared model that none of them could have built alone, without any of them surrendering the data that constitutes their competitive or regulatory risk. That is the capability worth understanding. The specific performance percentages attached to it in marketing decks are worth treating with more caution than the architecture itself.

Where the Regulators Stand

For a UK business, the relevant question is not whether PETs are clever but whether they are recognised by the bodies that will judge a deployment.

The ICO’s guidance on privacy-enhancing technologies now covers differential privacy, synthetic data, homomorphic encryption, zero-knowledge proofs, trusted execution environments, secure multi-party computation, private set intersection, and federated learning by name, and recommends considering them at the design stage of data-heavy or higher-risk processing. The UK government’s Responsible Technology Adoption Unit (RTAU, within DSIT) published a regulator’s-eye analysis of federated learning in November 2024 — part of a joint RTAU/NIST series on privacy-preserving federated learning — that is candid about its limits, noting that model updates themselves can leak information and that federated learning generally needs to be combined with differential privacy or other techniques to constitute a genuine data-protection measure. This is a useful document precisely because it does not oversell. The European Data Protection Supervisor reached a compatible conclusion in its June 2025 TechDispatch on federated learning.

The harder regulatory questions are the ones PETs are often claimed to answer but only partly do. The GDPR’s right to erasure remains awkward for any model trained on personal data, because a trained model cannot straightforwardly “forget” an individual whose data shaped its parameters. Differential privacy narrows this problem by weakening the link between any individual and the output, but whether a given federated or differentially-private output counts as anonymised — and therefore outside the regime — is a fact-specific judgement, not a blanket exemption. Vendors sometimes present PETs as removing the compliance question. More accurately, they change its shape.

In financial services, the mapping onto existing controls is where adoption will be decided. Model risk management expectations, anti-money-laundering effectiveness frameworks, and explainability standards were written for models an institution controls end to end. A federated model trained across institutions raises real questions about validation, accountability, and auditability that a governance function will need answered before it signs off. Mature federated platforms answer this with layered audit logging — append-only, signed records of who requested a training action, under which policy, and when, so an institution can reconstruct the run after the fact. That capability is vendor-stated rather than standardised, and the burden of demonstrating that the mapping to your own model-risk framework holds sits with the deploying institution, not the vendor.

A Realistic First Step

For an organisation that finds this compelling, the mistake is to begin with the flagship use case. The more grounded path, and the one that practitioners recommend, is to start with a federated analytics project — computing statistics or insights across siloed datasets — rather than a federated model. Analytics delivers a useful answer quickly, and, more importantly, it forces the organisation to stand up the compute, security, and governance controls that any later AI work will reuse. The infrastructure is the deliverable; the first insight is the excuse to build it.

The strategic case is straightforward without needing the hyperbole that usually accompanies it. Organisations that can put their proprietary data to work — combined with public models, inside a defensible governance boundary — will build capabilities that competitors relying on public data alone cannot replicate. That is a real advantage. It does not require believing every percentage in a vendor deck to be worth pursuing.

Sources and Further Reading

Where we can help

If you are weighing a PET deployment — or being sold one — the questions that decide it are governance questions before they are cryptographic ones: which technique actually addresses your threat model, whether the output is genuinely anonymised in your regulator’s eyes, and how a federated model gets validated by a function that did not train it. We advise UK organisations on exactly that through our privacy engineering review and AI governance framework engagements.

This article is analysis, not legal advice. Whether a specific PET deployment satisfies UK GDPR or sector regulation is a fact-specific assessment. Percentages and partner counts attributed to named deployments are stated at the confidence level of their primary sources; where a figure is vendor-stated or absent from primary documents, we have said so.

Interested in working with us?

Get in touch to discuss our products, partnerships, or research collaborations.

Get in touch