Six Questions To Ask Before You Call It Sovereign AI

Sovereign artificial intelligence means the system runs on hardware you own, under keys you hold, producing a record you can verify without the supplier in the room. It is a property you can test rather than a claim you have to accept. The six questions below turn the procurement argument into things you can watch happen. Either the network cable can come out and the work continues, or it cannot.

• Start with the network cable. If the work stops when it comes out, nothing else matters.
• Whoever holds the signing key holds your evidence, so generate it and keep it on your own estate.
• You should be able to read the raw audit record with your own tools, on a machine that has never run the supplier's software.
• Records should be sealed as the action happens, and consequential actions should wait for a named human to approve or refuse.
• Ask in writing what stops working if the supplier ceases trading. The honest answer settles it.

Does it still work when you pull the network cable?

Question one is deliberately crude. Ask the supplier to run a real workload on your hardware, then physically disconnect the network and carry on working. A good answer is the supplier offering this before you ask, with your own firewall logs open so you can see that nothing attempts to leave. The system should be bound to loopback only, with no outbound path configured by default rather than discouraged by policy.

A weak answer changes the subject: the deployment sits in your region, the data never leaves your tenant, offline operation is on the roadmap. Each of those describes where a hosted service sits, not whether the intelligence runs without a network.

Who generates and holds the signing keys?

Question two decides who owns your evidence. Your organisation should generate its own signing key on its own hardware, the private key should never leave the estate, and the supplier should have no technical path to it, even under a support contract. Ask where key material is created, who can export it, and what the supplier would have to do to sign something in your name. If they could, the system is not sovereign.

Can you revoke the supplier's access without asking them?

Question three is the sharper half of control. You should be able to cut supplier access yourself, from your own administration console, without raising a ticket, and the revocation should appear in the audit record as an ordinary entry. Weak answers amount to the supplier managing keys on your behalf. A supplier who has to be asked to remove their own access never gave you control.

Can you read the raw audit record with your own tools?

Question four separates accountability from a dashboard. Ask for the raw record as a file on your own disk, then read it without the supplier's software. Our own record, the Open Audit Record, is append-only and hash-chained, and each entry carries an index, a timestamp, an actor, a typed action, a target and a SHA-256 of its payload, signed with FIPS 204 ML-DSA, so it verifies cold and offline with the operator public key alone. FIPS 203 ML-KEM is key encapsulation and never signs, a useful detail to check a supplier on.

Then test the evidence yourself. Copy the file, alter a byte in an old entry, re-run verification, and watch the chain fail at the entry that broke. No honest supplier claims a log cannot be altered, because a file on a disk always can be. The useful property is that alteration is detectable by anyone holding the public key, and that signed checkpoints written off the box make a truncated tail detectable too. Detection rests on key custody, which is why question two comes first.

Who approves a consequential action before it happens?

Question five is the one most suppliers have never been asked. Establish whether the entry is sealed as part of performing the action, so that an action which is not recorded does not happen, or whether logging is a downstream pipeline that can fail, lag or be switched off. The first is evidence. The second is telemetry wearing a compliance label.

Then ask who was asked. Consequential actions should be staged for a named human to approve or refuse, and both the approval and the refusal should sit in the same chain, next to who held which entitlement at that moment. Ask how a seat is granted and revoked, and whether licences bind to specific hardware.

What happens to your system and your numbers if the supplier folds?

Question six belongs in writing. If the supplier ceases trading tomorrow, what stops: a licence check that phones home, weights streamed on demand, keys held in their cloud account, an activation server nobody has budgeted to replace? A sovereign deployment keeps running because nothing it needs sits on the other side of a network.

The same question applies to your figures. Where a number carries consequences it should come from a deterministic engine rather than a generative guess, so identical inputs give identical results and the figure can be recomputed in front of an auditor who was not there the first time.

Frequently asked questions

How do I run the network cable test without disrupting production?

Run it on a staging machine or a single workstation, long before anything reaches production. Give the supplier hardware you control, hand over a representative workload, then disconnect at the switch and watch. Seeing the work continue with the cable out settles the question in a way a questionnaire cannot.

What should I put in the tender document?

Turn each of the six questions into a pass or fail acceptance test with a named witness and a date. Require the raw audit file, an independent verification routine, a written list of anything that degrades offline, and a continuity statement covering supplier failure.

Is an on-premises deployment automatically sovereign?

No. On-premises describes where the hardware sits, not who holds the keys, who can revoke whom, or whether the system phones home to check a licence. Plenty of on-premises deployments fail question one the moment the cable comes out. Sovereignty is local execution, local key custody and independently verifiable records together.

Do I need a cryptographer on my team to verify the record?

No, but verification must be possible without one of the supplier's engineers present. A good supplier hands over a documented verification routine and a public key, and your own team runs it on a clean machine. If verification only works inside their software, you are trusting them rather than checking them.

Where can I see these six questions answered against a working system?

We built Mickai, a Sovereign Intelligence Operating System, to be examined exactly this way: a capable model on hardware the customer owns, over loopback only, with the Open Audit Record verifiable offline, and 104 filed UK patent applications with approximately 2,340 claims, owned by Mickai LTD, behind the architecture. Buyers who want to run this checklist against a live deployment can apply to the selective closed beta at mickai.co.uk/beta.