Patient Data and Zero Egress: On-Premise AI for Hospitals

On-premise artificial intelligence for hospitals means the model runs on hardware the hospital owns, inside its own network, so patient data never crosses the network boundary. Zero egress is the technical property that makes this real: the system answers requests from inside the clinical network but has no route to send anything out, so protected health information has no path to a cloud provider. This design supports a hospital's duty to safeguard patient data: a record that is never transmitted to a third party cannot be intercepted or copied elsewhere. We build Mickai, a Sovereign Intelligence Operating System (SIOS), to run this way by default, with every action written to a cryptographically sealed ledger.

This question matters more in 2026 than it did two years ago, as public cloud AI services answer prompts on infrastructure the hospital does not own and cannot audit, so a clinician who pastes a patient summary into one has already sent it out of the building. Boards, insurers and regulators now treat that outbound flow as a live exposure, and the buyer question has shifted from whether to use AI to whether the data can stay inside.

What does zero egress actually mean, technically?

Zero egress is not a marketing phrase but a firewall posture and a network design. The system sits behind an inbound-only perimeter. It answers requests that originate inside the clinical network, and it has no outbound route: no default gateway to the internet, no external name resolution, no licence callback, no telemetry, no updates fetched over the wire. Outbound traffic is denied by default rather than filtered by exception. This is stricter than a private cloud, where data still travels to a provider's data centre, and close to an air gap, except that the machine stays reachable by authorised staff inside the hospital. The practical test is simple: disconnect the outbound link and the system keeps working, because nothing it does depends on reaching the outside world.

Why should patient data never cross the network boundary?

Once patient data leaves the hospital network, control over it becomes contractual rather than physical. The hospital then trusts a provider's policies, staff and jurisdiction to honour a promise that can be sound and still not be a technical guarantee. Under the United States CLOUD Act, a provider subject to US jurisdiction can be compelled to produce data it holds, wherever it is stored, which creates exposure for records a hospital believed were private. A cloud copy is also a second breach surface: it can be misconfigured, retained, or accessed by the provider's own staff. Keeping the data inside the boundary removes these questions rather than answering them.

“The strongest privacy control is not a promise that data will be handled carefully; it is an architecture in which the data has nowhere to go.”

How does a signed audit trail support clinical governance?

Clinical governance depends on being able to answer, after the fact, who did what and on what basis. We bind every action to a hardware-attested identity and write it to an append-only ledger. Each entry is signed with a post-quantum digital signature under FIPS 204, the ML-DSA standard, so an altered or back-dated record can be detected. The signing keys are held in hardware, and the operator and device identities are part of the sealed record, not fields that can be edited later. Encryption of data at rest uses key encapsulation under FIPS 203, the ML-KEM standard, which protects stored records but does not sign them; signing and verifiability come from FIPS 204 alone.

What can an auditor actually check?

An auditor should be able to verify the record without trusting the vendor and without an internet connection. Given the public keys, an auditor can recompute the signatures in the room and confirm the chain has not been altered. A short checklist:

• Outbound network rules: confirm the deny-by-default posture and the absence of any external route or callback.
• Ledger integrity: verify the post-quantum signatures across the chain and confirm there are no gaps or re-writes.
• Identity binding: confirm each action is tied to a hardware-attested operator and device.
• Data residency: confirm the model, the prompts and the outputs all remain on hospital-owned hardware.
• Update provenance: confirm any model or software update was brought in deliberately and recorded, not fetched silently.

Which rules make this necessary?

No single rule mandates zero egress by name, but several duties point the same way. Under HIPAA, a hospital must protect the confidentiality and integrity of protected health information; keeping it inside the boundary reduces the number of parties who can touch it. Under UK and EU GDPR, transferring personal data outside the region carries conditions and risk that never arise if the data does not move. DORA has applied since January 2025 and NIS2 raises security duties for essential sectors, both rewarding direct control of critical systems. ISO/IEC 42001, the AI management standard, expects documented governance that a sealed and verifiable ledger supports. On the EU AI Act, the high-risk obligations under Annex III once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems under Annex I moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

How is this different from a cloud service with a business associate agreement?

A business associate agreement is a contract. It obliges a provider to handle protected health information in defined ways and to report breaches. It does not stop the data from leaving the building, and it does not let the hospital inspect what the provider does with a prompt once it arrives. A signed on-premise ledger is different in kind: it is evidence the hospital holds itself, verifiable without the provider's cooperation. A contract allocates liability after something goes wrong, whereas an architecture that keeps data inside the boundary reduces the chance that it goes wrong at all. Both have a place, but a promise about data handling is weaker than an environment in which the data cannot leave.

Frequently asked questions

Is an on-premise LLM automatically HIPAA compliant?

No. Compliance is an organisational outcome, not a property of a single system. It depends on policies, training, access controls and risk assessments. On-premise deployment with zero egress supports several of those duties by keeping data inside the hospital's control and producing an auditable record, but no vendor can hand a hospital compliance, and any vendor that claims to should be treated with caution.

What is the difference between on-premise AI and a private cloud?

On-premise means the hardware sits inside the hospital and the data never leaves it. A private cloud is still a remote data centre run by a provider, so the data travels off site even when it is logically separated from other tenants. The distinction matters for zero egress: a private cloud has egress by design, whereas an on-premise system with an inbound-only perimeter has none.

Can a hospital prove that nothing left the building?

Yes, to a strong degree. Outbound network rules can be inspected to confirm there is no external route, and traffic can be monitored to confirm nothing is attempting to leave. The signed ledger records every action on hospital-owned hardware and can be verified offline. Together these give a hospital evidence it holds itself, rather than a provider's assurance.

Does zero egress mean the system can never be updated?

No. It means updates are brought in deliberately rather than fetched silently over the wire. New models or software are reviewed, signed and installed as a controlled step, and that step is recorded in the ledger. The system does not reach out on its own, so there is no hidden channel that could carry data out.