AI in Healthcare: When the Data Cannot Move, Move the Model

Health data is valuable for AI and hard to use. Records, images, genomes and clinical notes are protected by some of the strictest rules in any sector, held by many separate institutions, and often barred from leaving the place they were created. As Rieke et al. put it, medical data is underused by machine learning largely because it is siloed and privacy rules limit access.

The answer is usually not to move the data. It is to move the model to the data, or to put the computation somewhere the data's owner can prove is sealed. This article describes three patterns and what each should leave behind as evidence.

The rules set the architecture

EU. The European Health Data Space regulation, published in March 2025, creates a framework for secondary use of electronic health data for research, innovation and policy, with access through national health data access bodies and processing inside secure processing environments. Its secondary-use provisions apply in phases over the following years. GDPR treats health data as a special category requiring additional safeguards.

US. The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information, and an AI vendor that processes such information for a covered entity is typically a business associate under contract.

UK. Health data falls under UK GDPR and NHS data governance; much research access already runs through trusted research environments.

The common requirement: data stays inside a controlled environment, and access is logged and attributable.

Pattern 1: serve the model inside the walls

The simplest pattern is to run inference on hardware the institution controls, in its own data centre or a dedicated environment.

• Works well for: clinical documentation, coding, triage support, imaging pre-reads, retrieval over local records.
• Requires: models small enough to serve on local hardware, or the budget for larger accelerators; verified model files so a tampered model cannot be swapped in.
• Evidence: which model (by hash) produced which output, on which machine, for which user.

Open-weight models make this practical for many tasks. Note that derived artefacts carry risk: Morris et al. recovered full names from clinical notes using only their embeddings, so vector indexes of records are as sensitive as the records.

Pattern 2: confidential computing for capacity you do not own

When local hardware is not enough, confidential computing lets data be processed on someone else's machine while staying encrypted to everyone except a measured, attested environment.

• CPU confidential VMs (Intel TDX, AMD SEV-SNP) protect memory from the host operator, and their attestation reports state exactly which software was loaded.
• GPU confidential computing extends protection to accelerators. On NVIDIA Hopper GPUs, Zhu et al. measured overhead below 7 percent for the majority of typical LLM queries, approaching zero for larger models and longer sequences, with most of the cost in CPU-GPU data transfer.

The discipline that makes it work:

1. Publish or obtain the expected measurements of the software image.
2. Verify the attestation against those measurements and the vendor's root of trust before sending any data.
3. Seal inputs to a key that only the attested environment holds.
4. Keep the attestation with the result as evidence.

Pattern 3: federated training

For training or fine-tuning across institutions, federated learning sends model updates rather than data. Each site trains locally; only parameters or gradients leave. Rieke et al. present it as a route to multi-institutional models without centralising patient data, while setting out the challenges that remain. Updates are not automatically anonymous, so they deserve the same care as other derived artefacts.

Two additions make federated work auditable:

• Reproducible rounds. If each local round is deterministic and its inputs are committed by hash, a second party can re-run it and confirm the update.
• Attested or replicated aggregation. Run the aggregator in a confidential environment, or have independent parties verify it.

A checklist for health AI deployments

• Classify every artefact (prompts, outputs, embeddings, logs, model updates) by sensitivity, not only the source records.
• Prefer local serving; use confidential computing when capacity must come from elsewhere; use federated training for cross-site models.
• Verify model files by hash before loading.
• Keep per-call records: user, model hash, machine identity, time, and hashes rather than contents.
• Agree retention and no-training-on-inputs terms with every provider, and prefer terms that are signed and checkable.

What this means for regulated health organisations

Treat infrastructure choice as a compliance control, not a procurement detail. The pattern you choose determines what you can prove to a regulator, an ethics committee or a patient.

Where Tenzro fits

Tenzro is an open network where machines of every size serve AI, with hardware-rooted identity. Relevant capabilities built today:

• Private nodes. An operator can run a node as private (never announced, used only by its own callers), serving open models on the institution's own hardware with the same receipts and model verification as the public network.
• Verified model loading. Each weight file is hashed and checked against the catalog's pin and the model's multi-origin manifest before it loads; a mismatch refuses the load, and on TEE hardware the attestation commits to the verified manifest roots.
• Confidential inference. Providers can serve inside Intel TDX, AMD SEV-SNP, AWS Nitro or NVIDIA GPU confidential computing, with request and response sealed to the enclave key. TDX and SEV-SNP attestation has been exercised on the live network. Reproducible confidential-VM images of the node have release-candidate measurements published so anyone can rebuild and compare.
• Signed operator terms. Operators publish signed policies stating data retention days and whether they train on inputs; relying parties can filter on these declarations, though they are not automatically enforced.
• Deterministic training rounds. A node can run deterministic LoRA rounds on CUDA whose result digest another machine of the same GPU model reproduces bit for bit.

A federated-learning coordinator is not a protocol feature; it would be an application built on these pieces. The network is live in preview. See tenzro.com.