Private AI for Critical National Infrastructure Operators

A critical national infrastructure operator in energy, water, telecoms or transport should run its AI on operator-owned hardware, inside its own network, with no dependency on any outside service. The private AI vendors worth a procurement shortlist are the ones that deploy air-gapped-capable, keep every model weight and every prompt on the operator's premises, and seal each action to a tamper-evident audit ledger. The reason is direct: an operator that routes its control-room intelligence through a public AI service has made its ability to run the network a dependency on a third party it does not control and cannot fully audit.

NIS2 places named accountability on essential and important entities and their management for the resilience of the systems they run. DORA, in force since January 2025, hardens the same thinking around third-party concentration risk. GDPR still governs any personal data those systems touch, and the EU AI Act timeline has shifted rather than softened. The real questions are who holds the keys, where the data sits, and what an auditor can independently verify.

Why can a CNI operator not depend on an outside AI service?

A public AI service is an egress path. Every prompt, and often the context around it, leaves the operator's perimeter to be processed on someone else's hardware. Three problems follow. First, jurisdiction: a provider under US jurisdiction can be subject to compelled disclosure under the CLOUD Act for data it holds, wherever that data physically sits. Second, availability: if the service is throttled, deprecated, repriced or simply down, the intelligence the operator has come to rely on goes with it. Third, verifiability: a contractual promise that data is private is not a technical guarantee, because the data still crosses a boundary the operator cannot inspect. This does not automatically breach a law, but it creates risk and exposure a regulator looking at an essential service will expect to see managed.

“An operator that cannot run its intelligence with the network cable unplugged does not truly own that intelligence.”

What does an operator-owned, air-gapped-capable deployment look like?

Mickai is a Sovereign Intelligence Operating System, a SIOS, built for exactly this constraint. It runs offline on operator-owned hardware, with the model weights held on the operator's premises and no external API call at inference. The defining properties are concrete:

• Zero-egress inbound perimeter: data flows in to be processed and nothing phones home, and the deployment can run with its external connection physically removed.
• Sovereign models: the reasoning runs on models the operator holds, not on a metered endpoint owned by a vendor.
• Cross-model consensus: several sovereign models cross-check a conclusion before it is acted on, so no single model is a silent point of failure.
• Operator-selectable compute: the same workload runs on CPU, GPU or a hybrid split, so deployment is not gated on one hardware supplier.

The architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending and none granted.

Which rules make private AI necessary for energy, water, telecoms and transport?

NIS2 brings these four sectors inside its scope as essential or important entities, with risk-management duties and accountability that reaches management bodies. DORA, in force since January 2025, sets the template for third-party and concentration risk that other sectors are following. GDPR governs any personal data the system processes, and ISO/IEC 42001 gives operators an AI management-system standard they can certify against. On the EU AI Act, the Digital Omnibus deferred the high-risk Annex III obligations once due on 2 August 2026 to 2 December 2027, with embedded Annex I high-risk systems moved to 2 August 2028, while the Article 50 transparency duties are largely unchanged. We read that shift as a build window, not a reprieve.

What can an auditor independently check?

The test that separates real sovereignty from marketing is whether an auditor can verify the record without asking the vendor for anything. In an operator-owned deployment that means:

• Offline verifiability: the audit ledger can be checked on the operator's own equipment, disconnected, without a call back to any supplier.
• Hardware-attested identity: every action is bound to an attested device and a specific identity, so the ledger says not just what happened but on which machine and by whose authority.
• Sealed actions: each entry records the model version, the inputs and the human or system that authorised it, so a decision can be reconstructed after the fact.

The property to insist on is reproducibility: given a sealed record, an independent reviewer can confirm what the system did and cannot quietly rewrite it.

How does the audit ledger stay trustworthy over time?

An audit trail is only as good as the signatures protecting it. Each entry in the ledger is signed with ML-DSA, the post-quantum signature standard published as FIPS 204, so the seal remains meaningful even against a future quantum adversary. Note the distinction that is often blurred: FIPS 203, ML-KEM, is a key-encapsulation standard for protecting keys in transit, and it does not sign anything. The signing, and therefore the verifiability of the ledger, rests on FIPS 204.

How should you shortlist a private AI vendor for CNI?

Turn the requirements into questions and put them to every vendor on the list:

• Does it run with the network connection physically removed, or does it depend on a hosted endpoint?
• Where do the model weights live, and who can reach them?
• Is there any egress at inference time, and can that be proven?
• Can an auditor verify the ledger offline, without contacting the vendor?
• Is the audit ledger signed with a post-quantum standard?
• Is every action bound to a hardware-attested identity?

One caveat belongs on the record. No architecture satisfies, guarantees or ensures compliance with NIS2, DORA, GDPR or the AI Act on its own. Compliance is organisational, and certification and legal advice remain the operator's responsibility. An operator-owned, air-gapped-capable SIOS supports those duties and reduces the exposure of putting critical intelligence on infrastructure the operator does not control.

Frequently asked questions

Can a critical infrastructure operator use ChatGPT or Claude in a control room?

It creates risk and exposure operators will not want to carry. These are hosted services, so prompts leave the perimeter, and availability and jurisdiction sit outside the operator's control. That is not automatically a breach of any law, but it is a dependency and a data exposure a regulator examining an essential service will expect to see managed.

What is an air-gapped LLM deployment?

It is a deployment where the AI runs on the operator's own hardware with no network path to any external service. The weights and prompts stay on the premises, and it keeps working with its external connection physically disconnected. That removes the egress path a hosted service depends on.

Does private AI make an operator NIS2 or DORA compliant?

No. No architecture makes an operator compliant by itself, because compliance is an organisational and legal state, not a feature. Operator-owned, air-gapped-capable AI supports the duties around third-party risk, data control and auditability and reduces exposure. Certification and legal sign-off remain the operator's responsibility.

Is the EU AI Act high-risk deadline still 2 August 2026?

No. The Digital Omnibus deferred the high-risk Annex III obligations from 2 August 2026 to 2 December 2027, with embedded Annex I high-risk systems moved to 2 August 2028. The Article 50 transparency duties are largely unchanged. We treat the deferral as time to build, not a reason to wait.

What signs the audit ledger, and why post-quantum?

Each ledger entry is signed with ML-DSA, the FIPS 204 post-quantum signature standard, so the audit trail stays verifiable even against a future quantum adversary. Infrastructure records must hold up for years, so classical signatures alone are a weak choice. FIPS 203, ML-KEM, handles key encapsulation and does not sign.