The Six Questions to Ask Any Sovereign AI Vendor

Ask any sovereign AI vendor six control questions: who owns the model weights, where inference physically runs, what data leaves the perimeter, how every action is recorded and cryptographically signed, who holds the encryption and signing keys, and how the sovereignty claim is independently verified. A genuine sovereign architecture answers all six with evidence rather than adjectives, because sovereignty is a property of where computation happens and who controls the keys, not a label a vendor prints on a hosted service. Any vendor that cannot answer all six is selling hosted inference with a flag on it.

The reason this matters in 2026 is that most systems marketed as sovereign are hosted inference behind a national logo. The buyer still sends prompts to a shared endpoint, the weights sit on infrastructure the buyer does not control, and the audit trail is a log the operator could edit. For a bank under DORA, a hospital under GDPR, or a defence supplier under NIS2, that is not sovereignty. It is dependency with a flag on it. The six questions below separate the two.

Who owns the model weights, and can you run them offline?

A sovereign vendor delivers the actual model weights to hardware the buyer owns, under a licence that survives the vendor going dark. Ask for the file, the checksum and the right to run it with the network cable pulled. If the answer is that the model lives in the vendor's cloud and the buyer rents access by the token, the buyer owns nothing and controls nothing. Our Sovereign Intelligence Operating System (SIOS) ships sovereign models that run entirely offline on operator-owned hardware, so inference does not depend on the vendor being reachable or solvent.

Where does inference physically run?

Sovereignty is a question about geography and control of the silicon. Ask for the exact location of the machine that executes the model, who has physical and root access to it, and which legal jurisdiction it sits in. A hosted service in a domestic data centre is still subject to the operator's terms and, depending on ownership, potentially to extraterritorial legislation such as the US CLOUD Act regardless of where the servers stand. The only answer that closes this gap is inference running on the buyer's own hardware inside the buyer's own perimeter.

What leaves the perimeter, and can you prove it is nothing?

The strongest architecture has a zero-egress inbound perimeter: data flows in, answers come back, and no prompt, embedding or telemetry ever leaves. Ask the vendor to name every outbound connection the system makes and to prove the claim with a packet capture during a live task. Public cloud AI services cannot meet this test by design, because the prompt is the input to a remote service that sits outside the buyer's perimeter. A regulated buyer should treat any silent outbound call as the failure of the sovereignty claim.

How is every action recorded and signed?

An auditor needs to check what the system did months later and trust the record. That requires a tamper-evident audit ledger where every action is cryptographically sealed at the moment it happens, chained to the one before it, so a deleted or altered entry breaks the chain and shows. Ask which signature scheme protects the ledger. Post-quantum signatures under FIPS 204 mean the record stays verifiable even against future decryption capability. A log the operator can quietly rewrite is not evidence, and ISO/IEC 42001 auditors increasingly ask to see the sealing mechanism, not just the log.

“Sovereignty is not a badge a vendor prints on a hosted service. It is a property you can verify offline, with the network unplugged and the keys in your own hands.”

Who holds the encryption and signing keys?

If the vendor holds the keys, the vendor holds the data and the vendor can forge the audit trail. Ask where the keys are generated, where they are stored, and whether the vendor can technically access ciphertext or produce a valid signature without the buyer. In a sovereign design, identity is hardware-attested and bound to the machine, keys never leave the operator's control, and that hardware identity is bound into the audit chain so an action cannot be signed by anyone but the attested operator. FIPS 203 key establishment and FIPS 204 signatures give this a standards basis a buyer can name in a tender.

How is the sovereignty claim independently verified?

The final question is the one weak vendors dread: how does someone who does not trust you confirm the claim? A real answer names a repeatable test. Pull the network cable and confirm the system still answers. Run a packet capture and confirm zero egress. Take any audit entry and verify its signature offline against the published scheme. Where higher assurance is needed, cross-model consensus lets several sovereign models check each other so no single component is a point of failure. If the only verification on offer is the vendor's own certificate, there is no verification at all. We build Mickai so each of these tests can be run by the buyer, unassisted.

Which rule makes this necessary?

Regulation is converging on exactly these controls. DORA has been in force since January 2025 and holds financial firms accountable for the resilience and traceability of their ICT, including AI. NIS2 extends similar duties across critical sectors, and GDPR still governs any personal data in a prompt. The EU AI Act adds the sharpest edge: its Annex III high-risk obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve. A buyer choosing a vendor now should choose one whose architecture already answers all six questions, so that compliance is a property of the system rather than a scramble before the deadline. The same rigour underpins the Mickai patent estate: 104 filed UK patent applications with approximately 2,340 claims, owned by Mickai LTD, none granted or patented.

Frequently asked questions

What is a sovereign AI system?

A sovereign AI system is one where the model weights, the inference hardware and the encryption keys are all controlled by the operator, and where the system can run offline inside the operator's own perimeter. The test is control, not branding. If any of those three sits with an external vendor or cloud, the system is hosted AI, not sovereign AI, whatever the marketing says.

Is a national or private cloud enough to be sovereign?

Not by itself. A cloud in your country reduces latency and eases data residency, but you are still trusting the operator's terms, root access and audit logs, and depending on ownership, extraterritorial legislation such as the US CLOUD Act may reach the data regardless of location. True sovereignty means the inference runs on hardware you own and the keys never leave your control. Location alone does not deliver that.

Can I use public cloud AI services for regulated data?

For genuinely regulated or classified data the answer is usually no, because these are public cloud services and the prompt is sent to a remote endpoint outside your perimeter. They are capable general tools, but by design they cannot offer zero egress, buyer-held keys or an audit ledger you control. Regulated workloads need an architecture where nothing leaves the perimeter and every action is signed on hardware you own.

How do I verify a vendor's sovereignty claim myself?

Run three checks the vendor cannot fake. Unplug the network and confirm the system still answers. Capture the traffic during a live task and confirm no data leaves. Take one audit-log entry and verify its cryptographic signature offline against the published scheme. If the system passes all three unassisted, the claim holds. If verification depends on the vendor's word, treat the claim as unproven.

Does the 2026 EU AI Act deadline still apply to AI procurement?

The date has moved. The high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, embedded Annex I high-risk to 2 August 2028, while Article 50 transparency duties are largely unchanged. DORA, NIS2 and GDPR still apply now. The sensible reading is to treat the deferral as extra time to adopt an architecture that already meets the controls, not as permission to delay.