Sovereign AI in UK Defence Procurement: What Buyers Must Specify

A UK defence buyer should specify five properties in a sovereign AI requirement: the system runs on operator-owned hardware, operates fully offline, uses signing and encryption keys held only by the operator, produces an independently verifiable audit trail, and places no vendor in the trust path. Sovereignty is a property of architecture, not a clause in a contract, because any design that needs a live link to a supplier's cloud hands control of availability, data and updates to that supplier.

This matters in 2026 because the market is full of "sovereign" claims that reduce to a private tenant inside someone else's data centre. The US CLOUD Act can reach data held by US-headquartered providers wherever the servers physically sit. A defence programme that depends on a remote model also inherits every outage, price change and policy shift of its supplier. Procurement language is the control point. If a requirement does not name the mechanism, the buyer will be sold a badge.

What does operator-owned hardware actually require?

It requires that the operator owns the physical machines and can run the whole system with no external dependency. The specification should demand hardware-attested identity: each node proves who it is from a hardware root of trust, and that identity is bound into the audit chain so that later actions trace to an attested device.

There is a simple acceptance test. Disconnect the network and ask the system to perform its core task. If it stops answering, it was never sovereign. We design Mickai, our Sovereign Intelligence Operating System, to pass exactly this test, running offline on operator-owned hardware.

Why does offline operation matter, and what is a zero-egress perimeter?

Offline operation means the model, the data and the reasoning stay inside the operator's boundary. A zero-egress inbound perimeter is the mechanism: the system can receive tasking from the operator, but it originates no outbound connection to any supplier, and nothing leaves the perimeter. Telemetry, prompts and outputs are not phoned home.

This closes the most common exposure route. If there is no foreign-held copy of the data, there is nothing for a foreign order to compel. A specification should require zero outbound egress by default and treat any supplier callback as a defect, not a feature.

Who should hold the keys?

The operator, and only the operator. The signing keys that seal the audit trail and the encryption keys that protect data at rest should be generated and held inside the operator's boundary, with the supplier holding none. If the vendor can decrypt the data or forge a ledger entry, the vendor is in the trust path, whatever the contract says.

A contractual promise that a supplier will not look is not the same as a technical inability to look. Buyers should specify the second, because only the second survives a change of ownership, a subpoena or a breach at the supplier.

“Sovereignty in a defence system is not a label a supplier grants, it is a property the buyer can verify after unplugging the network cable.”

What can an independent auditor actually check?

An auditor should be able to verify the record without the vendor's help. The mechanism is a post-quantum signed audit ledger: every material action is written to an append-only chain and sealed with a signature. FIPS 204, the ML-DSA standard, is the post-quantum signature scheme used to sign the ledger. Verification needs only the ledger and the public key, so a third party can confirm the chain has not been altered.

Tenders often blur the two post-quantum standards. FIPS 204 (ML-DSA) signs and gives verifiability. FIPS 203 (ML-KEM) is a key-encapsulation standard for protecting keys, and it does not sign anything. The test is concrete: hand the ledger and the public key to an assessor with no supplier access, and they verify every entry offline.

Which rules make this architecture necessary?

Several regimes push in the same direction, and none of them are met by a badge. Under 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 duties moving to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that as a build window, not a reprieve. DORA has applied to financial entities and their critical ICT suppliers since January 2025, NIS2 raises duties for essential sectors, and GDPR still governs personal data wherever it is processed.

An architecture like this supports those duties and reduces exposure, but it does not by itself satisfy or guarantee any of them, and no vendor should claim otherwise. ISO/IEC 42001 gives a management-system framework for AI governance that an operator can certify against, and the architecture makes the evidence easier to produce. Compliance remains the operator's responsibility.

How should a buyer write the specification?

Turn the properties into clauses the supplier must meet or fail. A workable core reads as a short checklist:

• The system shall run on operator-owned hardware and require no external service to perform its core function.
• The system shall operate fully offline behind a zero-egress inbound perimeter, with no outbound connection to the supplier.
• All signing and encryption keys shall be generated and held by the operator; the supplier shall hold none.
• Every material action shall be written to an append-only ledger sealed with a FIPS 204 (ML-DSA) signature, verifiable offline by a third party.
• Each node shall present hardware-attested identity bound to the audit chain.
• No supplier shall sit in the trust path for availability, decryption or verification.

Written this way, sovereignty becomes testable rather than decorative. We build Mickai to this standard, and our approach is documented across 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, all filed and patent pending.

Frequently asked questions

What is a sovereign AI operating system for defence?

It is an AI system the operator fully owns and controls, running on their own hardware with no dependency on an external supplier's cloud. That means offline operation, operator-held keys, an independently verifiable audit trail and no vendor in the trust path. Mickai is built as a Sovereign Intelligence Operating System to these properties.

Can a public cloud AI service meet UK defence sovereignty requirements?

A hosted AI service keeps the model, the keys and the logs inside the supplier's boundary, which creates real exposure for sensitive data, including reach under the US CLOUD Act. A private tenant reduces some of that but still places the vendor in the trust path. A design that needs a live supplier connection cannot meet a requirement for offline operation and operator-held keys.

Is a contractual data-protection promise enough?

A contractual promise is not a technical guarantee. If the supplier retains the ability to decrypt data or alter records, that ability survives the clause and can be compelled by a court or exposed by a breach. Buyers should specify technical inability, such as operator-held keys and offline verifiability.

What does the EU AI Act require of defence AI buyers now?

The high-risk Annex III obligations once due on 2 August 2026 have been deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk duties moving to 2 August 2028 and Article 50 transparency largely unchanged. Read it as time to build verifiable systems, not a reason to wait. DORA, NIS2 and GDPR continue to apply.

How can an auditor verify the audit trail independently?

The ledger is sealed with a FIPS 204 (ML-DSA) post-quantum signature and written as an append-only chain. An assessor is given the ledger and the public key, and can confirm offline that no entry has been altered, with no access to the supplier. This is verification by mathematics rather than trust in the vendor.