Air-Gapped by Design: Why Running Inside the Customer's Infrastructure Is the New Baseline

A shift is under way in how serious institutions buy artificial intelligence. Through the first half of 2026, a wave of sovereign models has arrived with a common promise: they will run entirely inside customer infrastructure, including systems with no connection to the public internet. The framing has moved from where the data is stored to where the computation happens. For a hospital trust, a defence contractor or a central bank, that distinction is everything.

The timing is not accidental. The EU AI Act reaches full application on 2 August 2026, ISO/IEC 42001 is becoming the reference standard for AI management systems, and the UK Sovereign AI programme has made domestic control of critical models an explicit policy goal. NHS data-sovereignty concerns have hardened into procurement conditions. Against this backdrop, an assurance that data never leaves the building is welcome, but it is only half of what a rigorous buyer should ask for. The other half is proof.

The claim that outruns the evidence

Running a model inside customer infrastructure is now presentable as a checkbox. Many suppliers can package weights, ship a container and point to a diagram of the workload inside the customer's estate. That improves on a call to a distant endpoint, but it is easy to overstate.

Locality of compute does not, by itself, establish that a system behaved as claimed. A workload can sit inside a firewall and still phone home through a telemetry channel, still update its behaviour from a source the operator never inspected, still leave no durable record of what it decided or why. The air gap describes the network. It says nothing about the integrity of what runs across it.

The distinction that matters is between an air gap that is a deployment option and one that is a design constraint. In the first case, the system merely tolerates isolation. In the second, isolation is the condition it was built to satisfy, and everything downstream, from identity to audit, is shaped to work with the wire cut.

Air-gapped by design, not by exception

Mickai is a Sovereign Intelligence Operating System, a SIOS, and it is built to the second standard. It runs offline on operator-owned hardware, and its default posture is a zero-egress inbound perimeter: the system receives what it is given and emits nothing outward on its own initiative. There is no background channel to disable, because none is present.

Designing for the air gap changes the engineering discipline throughout. Every function a connected system would delegate to an external service, such as licence checks, model verification, time-stamping and key management, has to resolve locally or not at all. That constraint is demanding, and it is precisely why it is worth accepting. A system that genuinely cannot reach outside cannot quietly leak, and its behaviour can be reasoned about as a closed set.

“Running inside the customer's walls is necessary, but it is only credible when the system can prove offline, to the operator alone, exactly what it did and that nothing was altered.”

Offline verifiability closes the loop

Verifiability is the property that turns a locality claim into evidence. The question it answers is narrow: can the operator, with no reference to the supplier and no connection to any network, confirm that the system that ran is the system that was approved, and reconstruct precisely what it did?

For that answer to hold offline, the proof cannot depend on a remote service. It has to be produced and checked inside the perimeter. Concretely, the model artefact and its configuration carry signatures the operator can validate on their own hardware, and every consequential action writes an entry to a sealed record that can be replayed and confirmed later. Verification is not a certificate issued once at procurement. It is a capability the operator keeps in their own hands, exercisable at any moment.

This is where the two halves meet. Locality without verifiability is a promise. Verifiability without locality reintroduces the dependency that sovereignty was meant to remove. Only together do they close the loop.

The mechanisms underneath

Three mechanisms carry most of the weight, and each is chosen because it works without a network.

• Hardware-attested identity. Each deployment is bound to the specific hardware it is licensed to run on, so a component cannot be silently moved, cloned or substituted. The machine itself becomes part of the trust anchor, checkable on site.
• Post-quantum signed audit chains. Every action is sealed into an append-only chain using signatures chosen to remain sound against future quantum attack. An entry cannot be edited or removed without breaking the chain, and the whole record can be verified offline. This is the material an ISO/IEC 42001 assessor or a regulator under the AI Act needs, and it exists whether or not anyone is watching.
• Cross-model consensus. High-consequence outputs are put to more than one model, and disagreement is surfaced rather than hidden. A single model failing quietly is among the harder risks to catch. Requiring agreement, and recording the dissent when it occurs, converts an opaque judgement into an inspectable one.

None of these depends on a live link to any external party. Each degrades gracefully to nothing when the wire is cut, the state a sovereign deployment should treat as normal rather than exceptional.

What this means for governance and audit

Governance regimes are converging on a requirement that AI systems be accountable after the fact. The AI Act's obligations for high-risk systems, the management-system discipline of ISO/IEC 42001 and the emerging practice of agentic-audit governance all assume that someone can later ask what happened and receive a truthful, complete answer. A sealed, offline-verifiable record is the substrate that makes such an answer possible.

It matters that the record lives with the operator, not the supplier. When the audit trail is held by the supplier, every assurance rests on trust in that supplier. When it is sealed inside the customer's perimeter and checkable without the supplier's cooperation, the operator can satisfy a regulator, an auditor or their own board on their own authority. Sovereignty over the audit is as important as sovereignty over the data.

This work sits within a larger body of engineering. Across the system there are 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. Those filings cover the offline verification, sealed audit and consensus mechanisms described here, and they mark where the hard problems have been concentrated.

Where the baseline settles

The market is arriving at a floor it did not have a year ago. Running inside the customer's infrastructure is becoming the minimum a credible supplier must offer, not a premium feature. That progress will be uneven, because the harder half of the requirement, provable behaviour when the system is cut off from the world, is not yet as widely met as the easier half.

The serious question for a buyer through the rest of 2026 is therefore not whether a system can be deployed inside their walls. Most will claim they can. It is whether, on a machine with no network, the buyer's own staff can confirm what ran, prove nothing was altered and reconstruct every decision the system made. Where the answer is yes, the loop is closed. Where it is no, the air gap is a diagram and the assurance rests on faith. The institutions setting policy this year will increasingly decline to run on faith, and the system described here is built for that world.