How to Compare On-Premise Sovereign AI Vendors: A Buyer's Scorecard

Compare on-premise sovereign AI vendors against eight technical tests rather than feature lists: weights ownership, update-channel control, egress posture, audit-trail verifiability, key custody, hardware attestation, cross-model consensus on high-stakes actions, and a clean exit. Score each test as pass, partial or fail, because a claim of sovereignty is only as strong as the parts a buyer can independently verify. The vendor that scores highest is the one whose control lives in cryptography and network design, not in a contract clause.

This comparison matters more in 2026 than it did two years ago. Regulated buyers in finance, defence, healthcare and government cannot route sensitive workloads through public, multi-tenant cloud AI services without accepting foreign-jurisdiction and data-egress risk. DORA has been in force since January 2025, NIS2 is transposed across the EU, and the EU AI Act sets a clear direction even after 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. We read that deferral as a build window, not a reprieve.

What does a sovereign AI buyer's scorecard measure?

A useful scorecard measures properties a buyer can test, not promises a vendor can make. Score each line pass, partial or fail:

• Weights ownership: do you hold the model weights outright, or license access you can lose?
• Update-channel control: can the vendor change the model without your sign-off?
• Egress posture: can the system be proven to make no outbound calls?
• Audit-trail verifiability: can a third party check the logs offline?
• Key custody: who holds the signing and encryption keys, you or the vendor?
• Hardware attestation: is each action bound to a known, measured machine?
• Cross-model consensus: are high-stakes actions checked by more than one model?
• Exit: can you leave with your weights, data and logs intact?

Who owns the weights and controls the update channel?

Ownership is the first divide. A sovereign deployment means the operator holds the model weights on owned hardware and can run them with the network unplugged. If the vendor can revoke access, throttle the model or push a silent update, the buyer does not own the system; they rent it. Ask a plain question: if the vendor disappeared tomorrow, would the model still run? Then ask who signs off on model changes. In a sovereign design the operator controls the update channel, reviews each change, and can refuse one. Mickai runs as a Sovereign Intelligence Operating System, a SIOS, entirely on operator-owned hardware, with model updates applied only under operator control.

Can the vendor prove it never phones home?

Data residency is not the same as data isolation. A service can store data in your region and still send telemetry, prompts or embeddings outbound. The stronger design is a zero-egress inbound perimeter: the system accepts requests but is architecturally prevented from initiating outbound connections. This is checkable. Put the deployment behind a network tap and watch for outbound packets under load. A sovereign system shows none. A cloud-connected one cannot help but reach out, and under the US CLOUD Act any data handled by a US-operated service can be subject to foreign legal process regardless of where it sits.

What can an auditor actually verify?

Verifiability separates real sovereignty from marketing. The test is whether an auditor can confirm the record without trusting the vendor. In a strong design every action is written to an append-only ledger and signed with a post-quantum signature under FIPS 204, the ML-DSA standard, so the chain can be verified offline and cannot be forged after the fact. Identity is bound to hardware attestation, so each entry names the measured machine that produced it, not just an account. Key custody sits with the operator, because a ledger the vendor can re-sign is not evidence. FIPS 203, ML-KEM, protects key exchange but does not sign anything, so no verifiability claim should rest on it. The mechanisms described here are the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; they are patent pending, never granted or patented.

“Sovereignty is not a label a vendor applies to itself; it is the set of properties a buyer can verify without the vendor's cooperation.”

How should a sovereign system treat high-stakes actions?

A single model is a single point of failure. For consequential actions, such as moving money, changing access or filing a legal document, the stronger design requires cross-model consensus: two or more independent models must agree before the action proceeds, and any disagreement is logged. This turns a confident hallucination from an executed mistake into a flagged one. On the scorecard, ask whether consensus is enforced in the runtime or merely offered as an option, and whether the vote is written to the same signed ledger as the action.

Which rules make an on-premise posture necessary, and what happens at exit?

No architecture makes a buyer compliant on its own, and no vendor should claim it does. What a sovereign design does is support specific duties and reduce specific risks. Offline operation and a zero-egress perimeter reduce the data-transfer exposure that GDPR and the CLOUD Act create. A signed, attested audit trail supports the record-keeping and traceability that DORA, NIS2 and the EU AI Act expect, and aligns with the management-system discipline of ISO/IEC 42001. A contractual promise of residency is not a technical guarantee, so score contracts and mechanisms separately. Finally, test the exit. A sovereign vendor lets you leave with your weights, your data and your full signed log, on your hardware, with nothing stranded in a service you no longer control. If exit depends on the vendor's goodwill, it is not sovereignty.

Frequently asked questions

What is the difference between on-premise AI and sovereign AI?

On-premise means the software runs on your hardware. Sovereign means you also control the weights, the keys, the update channel and the audit trail, and the system can run with the network disconnected. All sovereign AI is on-premise, but on-premise AI that still calls a vendor cloud for updates or inference is not sovereign.

Can a cloud AI vendor be sovereign if it promises data residency?

Data residency keeps data in a chosen region but does not stop outbound telemetry or foreign legal reach. A contractual promise is not a technical guarantee. Under the US CLOUD Act, data handled by a US-operated provider can face foreign legal process wherever it is stored, which creates exposure that residency alone does not remove.

How can a buyer verify an AI audit trail has not been tampered with?

Ask for an append-only ledger where each entry is signed with a post-quantum signature under FIPS 204, ML-DSA, and bound to a hardware-attested identity. You should be able to verify the chain offline, without the vendor, and confirm the operator holds the signing keys. If the vendor can re-sign the log, it is not tamper-evident.

Does running AI on-premise make an organisation compliant with the EU AI Act?

No single architecture makes an organisation compliant, and no vendor should claim it does. On-premise deployment supports duties such as record-keeping, traceability and data control, which reduces risk. The high-risk Annex III obligations were deferred by the Digital Omnibus from 2 August 2026 to 2 December 2027, so the sensible reading is to build the evidence now.

What should be in an AI vendor exit clause?

A clean exit gives you the model weights, all your data and the complete signed audit log, in open formats, on your own hardware, with no residual dependency on the vendor's service. Confirm you can verify the exported log offline after you leave. If the system stops working the moment the contract ends, you were renting capability, not owning it.