How to Evaluate a Sovereign AI Vendor

You evaluate a sovereign AI vendor by refusing to accept the word sovereign at face value and testing the six things it is supposed to mean. Ask whether inference truly runs locally and offline, and make them prove it rather than assert it. Ask whether the egress boundary is enforced as a release gate, not a configuration toggle. Ask whether licensing is bound to the hardware, whether retrieval stays on your data, whether the audit record is tamper-evident and verifiable offline, and whether the vendor's own claims are precise. If a vendor cannot answer these plainly, the sovereignty is marketing. I am the founder and named inventor of Mickai, and I would rather you held us to this checklist than took our label on trust.

• Truly local inference: can you watch it run with the network physically off, not just read a claim?
• Enforced egress boundary: is outbound blocked as a release gate the build must pass, or a setting someone can flip?
• Hardware-bound licensing: is entitlement tied to the machine, so a copied model will not run elsewhere?
• Grounded private retrieval: does the system answer from your data without that data ever leaving?
• Offline-verifiable audit: is there a tamper-evident record you can check yourself, with no vendor and no connection?
• Precise claims: filed not granted patents, tamper-evident not tamper-proof, no certifications overclaimed.

Start by agreeing what sovereign means

The word has been stretched to cover almost anything hosted in the right country. That is not enough. Data residency tells you where a server sits. It tells you nothing about whether your prompts, your documents and your model outputs leave that server in the course of normal operation. A genuinely sovereign system keeps inference, retrieval and audit inside your control boundary, and can run with no external connectivity at all. Everything below is a way of checking that the definition holds.

Make them prove inference is local and offline

The first question is the one most easily fudged. Many on-premise offerings still call out to a hosted endpoint for the heavy model, or phone home for telemetry. Do not accept the architecture diagram. Ask to see the system answer a real query with the network interface disabled, and ask what happens to functionality when it is.

In SIOS the capable model, our engine Poros, runs locally and binds to loopback only, so it is reachable by the machine itself and nothing else. It is designed to work fully offline. The test I would apply to any vendor, including us, is simple: pull the cable and see whether the assistant still works. Sovereignty that survives that test is real. Sovereignty that fails it was a hosting arrangement.

Ask whether egress is a release gate, not a toggle

There is a meaningful difference between a system that can be configured not to send data out and a system that is built so it cannot. A setting can be changed, forgotten or overridden. A release gate is a check the software must pass before it ships, so a build that would leak is a build that does not exist.

Ask the vendor directly: is your egress boundary tested as a condition of release, or is it a runtime option? In our case, no outbound connectivity is one of the gates a SIOS release has to pass before it is cut. I have written this up separately as the egress boundary treated as a release gate, because it is one of the load-bearing distinctions between sovereign in fact and sovereign in aspiration.

Ask whether licensing is bound to the hardware

A sovereign system that ships you a capable model has to answer an awkward question: what stops that model being copied and run somewhere you never approved? If the answer is a licence agreement, the answer is nothing technical. Ask whether entitlement is bound to the specific hardware, so that a copied model simply will not run on a machine it was not issued to.

Hardware-bound entitlement is what turns a licence from a promise into a mechanism. It is one of the areas I have filed patents on and written up as a preprint, because getting it right is what lets a vendor distribute powerful models without losing control of where they execute. When you assess a vendor, ask them to explain their answer in mechanical terms, not contractual ones.

Ask where retrieval happens

Most useful AI work involves grounding the model in your own documents. The critical question is where that grounding happens and whether your data leaves to make it work. A retrieval system that sends your private corpus to an external service to build or query an index has moved your data off your boundary, whatever the marketing says.

The standard to hold out for is retrieval that runs against your private data in place, with nothing egressing. In SIOS this is what the private knowledge bases do: they let the assistant answer from your material without that material leaving the system. Ask any vendor to show you the data path, end to end, and to name every point at which anything crosses the boundary.

Ask for an audit record you can verify yourself

Accountability that depends on the vendor is not accountability. If the only way to know what the AI did is to ask the vendor's dashboard, you are trusting the party with the most reason to want to be trusted. Ask for a tamper-evident record that you can verify independently, offline, without the vendor in the loop.

Our answer is the Open Audit Record: an append-only, hash-chained ledger anchored by post-quantum signed checkpoints held off-box, so any alteration or rollback is cryptographically detectable, fully offline. I am careful to call it tamper-evident, not tamper-proof, because an attacker can still destroy a file or refuse to run the verifier. What matters for a buyer is that you can check the record yourself, on the published standard, with no connection required.

Listen to how they phrase their claims

The last item on the checklist is not a feature, it is a tell. Vendors who are careful about what they can defend tend to be careful about everything else. Vendors who overclaim on the easy things are usually overclaiming on the hard ones too. There are three phrases I would treat as flags.

First, patents: granted and filed are not the same. We hold 104 filed UK patent applications with 2,340 claims, patent-pending at the UK IPO. They are filed, not granted, and I say so. Second, security: tamper-proof and unbreakable are claims almost no honest system can make, whereas tamper-evident is a claim you can stand behind. Third, compliance: certifications such as ISO 27001 or SOC 2 are either held or they are not. For us they are targets, and a vendor claiming a certificate should be able to show it. Precision on the small things is the best available signal for the things you cannot test in a meeting.

Frequently asked questions

What is the single most important test?

Whether inference genuinely runs with the network off. Almost every sovereignty claim collapses or holds on that one test, and it is the hardest thing to fake in a live demonstration.

Is data residency the same as sovereignty?

No. Residency tells you where a server is located. Sovereignty is about whether your data and model activity stay inside your control boundary during normal use. A system can be hosted in the right country and still send your prompts elsewhere.

Why does hardware-bound licensing matter to a buyer?

Because it is what stops a capable model being copied and run outside your approval. Without it, control over where a model executes rests on a contract rather than a mechanism, which is a weaker guarantee than most regulated buyers should accept.

How can an audit record be trustworthy if I cannot break the maths myself?

You do not have to. A tamper-evident record built on a published signature standard lets an independent verifier confirm offline that history has not been rewritten. You are trusting the open standard and your own verification, not the vendor's assurances.

What claims should make me cautious?

Any granted patent that turns out to be merely filed, any tamper-proof or unbreakable security claim, and any certification stated without evidence. Overclaiming on the checkable things is a reliable indicator of overclaiming on the rest.

How does Mickai fit into this checklist?

As one honest reference point, not the only answer. SIOS is a British Sovereign Intelligence Operating System with local inference, an enforced egress boundary, hardware-bound entitlement, private retrieval and the Open Audit Record. The closed beta is open at mickai.co.uk/beta, and I would rather you tested us against these questions than believed the label.