How do you deploy and update AI in an air-gapped environment without internet access?

An air-gapped AI is deployed and updated by carrying every model, patch and policy change across the gap on cryptographically signed physical media, verifying each signature at load time before any code executes, and writing the update event to a tamper-evident, post-quantum signed audit ledger. Nothing is pulled at runtime, so the system has no path to the internet and cannot fetch, phone home or auto-update. The signature proves the media is genuine and unmodified, and the ledger proves, after the fact, exactly what changed, when, and under whose authority.

This matters more in 2026 than a year ago. Defence, critical national infrastructure, healthcare and regulated finance want the reasoning leading public AI services provide, but cannot send classified or regulated data to a third-party cloud. DORA has been in force since January 2025, NIS2 is transposed across much of the EU, and the US CLOUD Act means data touching a US-operated cloud is reachable by US legal process. Keeping advanced AI and its data inside the wire means running it fully offline, which turns deployment and updates into a security problem, not a convenience.

How does the update path actually work?

Every update follows the same fixed sequence, a chain in which each step depends on the one before it.

• A new model, patch or policy is assembled and signed inside a trusted, offline build environment on operator-owned hardware.
• The artefact is written to physical media and stamped with a detached signature and a content hash.
• The media is carried across the air gap by an authorised operator. No cable, no bridge, no temporary connection.
• On the target, the SIOS verifies the signature and the hash before a single byte is loaded into memory.
• On success, the load event is written to the post-quantum signed audit ledger. On failure the artefact is rejected, and the rejection itself is logged.

The physical carry is not the weak point people assume. Security lives in the signature and the ledger, not the courier, so a stolen or swapped disc is useless: an unsigned or altered artefact fails verification and never runs.

Why are there no runtime pulls or callbacks?

A true air gap is defined by what the system cannot do, not by what it chooses not to do. Mickai runs behind a zero-egress inbound perimeter: updates come in on signed media, and nothing leaves. There is no telemetry, no licence server to phone, no model registry to poll, and no automatic update channel. This is the architectural difference from a cloud service, whose model, logging and licence check all depend on a live connection. Remove that connection and a cloud service degrades or stops; an offline SIOS does not change, because it never had one.

What does signature verification on load check?

Verification happens before execution, not after. The named test on every artefact has four parts.

• Authenticity: the detached signature validates against the operator's trusted publisher key, using post-quantum signatures aligned to FIPS 204.
• Integrity: the recomputed content hash matches the signed hash exactly, so a single flipped bit fails the load.
• Freshness: the version is checked against the ledger to block rollback to a known-bad or superseded build.
• Identity: the load is bound to hardware-attested identity, so the artefact only runs on the machine and operator it was authorised for.

If any part fails, the artefact does not load: there is no override and no partial acceptance.

How is every update tied back to the audit chain?

The update path and the audit path are the same path. When an artefact passes verification, the SIOS appends an entry to an append-only, post-quantum signed ledger: the artefact hash, the signer, the attested hardware identity, the timestamp and the approver. Where an update changes model behaviour, not just code, cross-model consensus can be required, so a change is only sealed when independent models agree the output is within policy. Because the same cryptographic material that authorises the change also signs the ledger entry, no update can be applied without leaving a permanent, verifiable record.

“An air-gapped update is only trustworthy when the same cryptographic chain that authorises the change is the one that later proves exactly what changed.”

What can an auditor verify after an update?

Everything an auditor needs travels with the system, so verification depends on no live service or vendor. Given the public keys and ledger, an auditor can, entirely offline, confirm which artefact was loaded, who signed it, on which hardware it ran, when, and who approved it. They can recompute the artefact hash to match the ledger, then walk it back to the first entry to confirm no record was inserted, removed or altered. This is what scattered guidance on signed media leaves out: signing the disc proves the media, but only sealing the load event proves the history.

Which rules make this necessary?

This architecture maps to obligations regulated buyers already carry. DORA requires financial entities to control and evidence changes to critical systems. NIS2 extends similar duties across essential sectors. GDPR and data-residency duties are easier to meet when data never leaves owned hardware. ISO/IEC 42001 expects a governed, auditable AI management system that an append-only ledger supports directly. FIPS 204 (ML-DSA) provides the post-quantum signatures that keep signed records defensible. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged, which we read as a build window. The design here is the subject of 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, patent pending and never granted or patented.

Frequently asked questions

Can you update an air-gapped AI model without ever connecting it to the internet?

Yes. The new model is signed in an offline build environment, written to physical media, carried across the gap and verified on load. The system never connects, so there is no runtime pull and no callback. The only thing crossing the gap is a signed artefact that must pass verification before it runs.

Is signed USB media secure enough for AI model updates?

The media is a carrier, not the control. Security comes from the detached signature and content hash, which are checked before anything loads. A swapped, copied or altered disc fails verification and is rejected. Provided the signing keys stay protected and every load is sealed to the ledger, signed physical media is a sound update mechanism for classified environments.

How do you prove an air-gapped AI update was not tampered with?

Two independent checks prove it. First, the artefact hash is recomputed at load time and matched against the signed hash, so any modification fails. Second, the load event is written to an append-only, post-quantum signed ledger that an auditor can replay offline. Together they show that the artefact is genuine and that its application was recorded and cannot be quietly rewritten.

What is a zero-egress perimeter?

A zero-egress perimeter means data can only enter under strict control and nothing leaves. Updates arrive on signed media, but there is no outbound telemetry, licence check or auto-update traffic. It is stronger than a firewall rule: the system is built with no outbound capability rather than told not to use one.

Does an air-gapped AI still meet EU AI Act and DORA requirements?

An offline SIOS with signed updates and a sealed audit ledger supports the change-control, traceability and residency expectations behind DORA, NIS2, GDPR and ISO/IEC 42001. On the EU AI Act, high-risk obligations now fall due from 2 December 2027 after the Digital Omnibus deferral, so building the audit chain now positions an operator ahead of the timeline, not behind it.