How to deploy sovereign AI: an implementation sequence from pilot to air-gapped production
A staged implementation sequence that takes an organisation from cloud pilot to fully air-gapped, operator-owned AI, returning one concrete control at every step.
Deploy sovereign AI in six ordered stages: define the perimeter, bring weights in-house, run inference locally, gate updates, seal a signed audit ledger, then air-gap.
The pressure in 2026 is regulatory and geopolitical at once. The US CLOUD Act can compel a US-based provider to hand over data regardless of where its servers sit. DORA has been in force across EU financial entities since January 2025, NIS2 now covers essential and important entities, and the EU AI Act's high-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk pushed to 2 August 2028 and Article 50 transparency largely unchanged. The deadlines moved; the direction did not. Boards now want AI they can run without asking anyone's permission.
What does sovereign AI mean before you deploy?
Sovereign AI means the model runs on hardware you own, inside a boundary you control, every action sealed to an audit record you alone read.
Public cloud assistants such as ChatGPT, Copilot and Gemini are excellent for open, non-sensitive work, and for most teams they remain the right first reach. The line they cannot cross is your most sensitive data, because the moment a prompt leaves your estate you inherit another jurisdiction's subpoena power. Sovereign AI removes that dependency. Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action cryptographically sealed. It is not a chatbot bolted onto someone else's servers; it is the substrate those servers were supposed to be.
How do you define the perimeter and bring the weights in-house?
Start by drawing a zero-egress boundary: traffic enters under policy, nothing leaves. Then copy the model weights onto storage you own and verify their checksums.
The perimeter comes first because every later control depends on it. A zero-egress inbound perimeter accepts traffic under policy and lets nothing out by default, so data cannot exfiltrate even if a component is compromised. Bringing the weights in-house means copying the model files onto storage you own and verifying their checksums, giving you offline verifiability: you can prove which model is running without calling anyone. From this point the system has no external interface it must reach to answer a question.
What is the full deployment sequence?
The sequence runs in six stages, each returning one concrete control: perimeter, weights, local inference, update channel, signed audit record, then physical isolation.
Each stage below returns a specific control and produces a specific proof, so a CIO can track deployment against evidence rather than promises.
| Stage | Goal | What you control after it | Proof it produces |
|---|---|---|---|
| Define the perimeter | Draw a zero-egress boundary | What enters; nothing leaves | Documented inbound-only perimeter |
| Bring weights in-house | Own the model files | The weights, no external interface | Verified checksums on owned storage |
| Run inference locally | Compute on your own silicon | Every prompt and output stays on-site | Offline inference logs, zero outbound calls |
| Control the update channel | Gate every change | Which version runs, and when | Signed release manifest, reproducible build |
| Stand up the signed audit record | Seal every action | A tamper-evident, post-quantum record | FIPS 204 signed audit ledger |
| Move to air-gapped production | Remove the last network path | Physical isolation, no route in or out | Attested air gap, hardware-bound identity |
How do you control the update channel without going dark?
Gate every model and code change behind a signed release manifest. Updates arrive as reviewed, reproducible builds you import deliberately, never pushed silently by vendors.
Going sovereign does not mean going dark. The update channel is where most drift and most risk enter, so it is gated, not closed. Model and code changes arrive as signed release manifests and reproducible builds, reviewed and imported on your schedule. No vendor can push a silent change into a live perimeter, and you can always roll back to a known, verified state.
What proves the system is trustworthy: the signed audit record?
A post-quantum signed audit ledger records every action, binding it to a hardware-attested identity. FIPS 204 and 205 sign the entries, keeping the record tamper-evident.
Trust is not asserted, it is recorded. Every action is written to a post-quantum signed audit ledger, with FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) signing the entries; FIPS 203 (ML-KEM) handles key encapsulation and never signs. Each entry binds to a hardware-attested identity, so an action cannot be forged or repudiated. Decisions themselves are checked by cross-model consensus across 50 brains, 25 domain and 25 operational, rather than trusting a single model's output. These substrate mechanisms sit within 104 filed UK patent applications and 2,340 claims owned by Mickai LTD (Companies House 17166618), filed and patent pending.
How do you move to air-gapped production without breaking operations?
Move through isolation tiers: VPN-sandboxed, then network-segmented, then fully air-gapped. Each tier removes a network path only after the audit record proves operations run cleanly.
Air-gapping is the destination, not the entry point. Move through the tiers in order: a VPN-sandboxed pilot, then network segmentation, then a full air gap with no physical network path. Each tier is removed only after the signed audit record shows operations running cleanly at the previous one, so you never trade capability for isolation blindly. By the final tier the system answers, reasons and seals every action with no route in or out.
“Sovereignty is not something bought at the end of a project; it is a sequence of controls taken back one stage at a time.”
What does deploying sovereign AI cost to scale?
Cost behaviour scales with hardware and inference volume as utilisation rises. Adding capacity means adding your own silicon, so marginal cost falls as utilisation rises.
Cost behaviour, not price, is what a CIO should model. Sovereign deployment shifts spend from metered fees to hardware you amortise, so marginal cost per query falls as utilisation rises instead of climbing with every call. The 50 brains share the same substrate, so adding capability is a configuration change rather than a new deployment. On what Mickai itself costs: that is shared in briefings, not publicly.
Frequently asked questions
Do I have to air-gap from day one?
No. Air-gapping is the final isolation tier, not the starting point. Begin with a defined perimeter and a VPN-sandboxed pilot, then remove network paths in stages as the audit record proves each tier is stable. This keeps operations running while sovereignty tightens.
Can my team still use ChatGPT or Copilot after deploying this?
Yes, for open and non-sensitive work those services remain a sensible choice. Sovereign AI is for the data you cannot let leave your estate. Many organisations run both, routing sensitive workloads to the sovereign substrate and keeping public assistants for everything else.
How long does it take to go from pilot to air-gapped production?
It depends on your hardware, data classification and regulatory scope rather than on any fixed timetable. Because the sequence is staged, each tier delivers usable capability before the next, so value arrives early and isolation deepens as evidence accumulates rather than in one high-risk cutover.
Has the EU AI Act deadline changed what I need to build?
The timeline moved, not the requirement. High-risk Annex III obligations were deferred by the Digital Omnibus from 2 August 2026 to 2 December 2027, with embedded Annex I high-risk to 2 August 2028 and Article 50 transparency largely unchanged. A signed audit record positions you for either date.
Does Mickai publish its prices?
Pricing is shared in briefings, not publicly. What we can say in the open is how cost behaves: it scales with hardware and inference volume, so marginal cost falls as utilisation rises. The specifics come in a direct conversation.