How to Write an RFP for Sovereign AI: What to Specify

To write an RFP for sovereign AI, specify five non-negotiable requirements: the system runs on hardware you own or control, it operates fully offline with no external calls, it produces a provable audit trail of every action, it guarantees zero data egress, and it passes the network-cable test. The network-cable test is the simplest acceptance criterion you can write: unplug the network cable, and the AI must keep working with no loss of function. Any requirement a supplier cannot meet with the cable unplugged is not sovereign, whatever the marketing says.

• Owned hardware: the model weights, inference engine and all data reside on infrastructure the buyer owns or fully controls, with no dependency on a third-party account or licence server.
• Offline operation: full functionality with no inbound or outbound internet connection, demonstrated live during evaluation.
• Provable audit trail: every prompt, action and model response recorded in a tamper-evident log the buyer can inspect and export independently.
• Zero data egress: a written guarantee, testable at the network layer, that no prompt, document or item of telemetry leaves the perimeter.
• Right to inspect: the buyer may audit the running system, its logs and its update mechanism at any time without supplier mediation.

What ownership requirements should the RFP set?

State plainly that the buyer owns or controls the hardware the AI runs on. A useful clause: the supplier shall deploy all model weights, the inference runtime and any knowledge or vector stores on infrastructure owned or exclusively leased by the buyer, with no runtime dependency on the supplier cloud, API keys or licence servers. Ownership of the compute is what makes every other guarantee enforceable, so put it first.

Ask suppliers to confirm the system keeps running if the supplier ceases trading. If the answer depends on a remote licence check or a hosted endpoint, the deployment is rented, not sovereign.

How do you require provable isolation?

Isolation is only real if it can be tested, so write the test into the RFP rather than accepting a policy statement. Require the supplier to demonstrate, during evaluation, that the system completes representative tasks with all network interfaces disabled, and require a network capture proving no packets attempt to leave the perimeter.

The network-cable test belongs in your acceptance criteria verbatim: with the cable physically removed, the assistant must answer questions, run its workflows and complete tasks exactly as it does when connected. Make passing it a condition of award, not a nice-to-have.

What should the RFP demand for the audit trail?

Specify a tamper-evident record, not simply logging. Require that every prompt, retrieved document, model output and administrative action is written to an append-only log with cryptographic integrity, that the buyer can verify the log independently of the supplier, and that records export to the buyer's own systems for retention.

For regulated sectors, add that the audit trail must be sufficient to reconstruct any decision after the fact, and that it survives a full system rebuild. An audit trail the supplier can quietly edit is worse than none, because it manufactures false confidence.

How do you specify no data egress without naming a vendor?

Describe the behaviour, not the brand. State that no prompt, document, embedding, log or item of telemetry may leave the defined security boundary under any circumstance, including model updates, error reporting and usage analytics, and that this must hold at the network layer where it can be observed and proven.

Then require the mechanism to be inspectable. The supplier should show how egress is prevented, whether by a default-deny outbound firewall, an air-gapped enclave or an egress gate, so your security team can verify the control rather than trust a clause.

What update and continuity terms keep it sovereign over time?

Sovereignty erodes if updates arrive through a channel you cannot see. Require that model and software updates are delivered as signed artefacts the buyer reviews and applies on its own schedule, with no automatic pull from the internet and no silent changes to model behaviour.

Add a continuity clause: the buyer receives everything needed to keep the system running independently, including weights, runtime and documentation, held on-premises or in escrow, so a change of supplier never means a loss of capability.

These requirements are deliberately generic. Any serious sovereign supplier should meet every one, and a buyer is right to reject any that cannot. Mickai is a SIOS built to satisfy exactly this specification: owned hardware, offline by default, a tamper-evident audit trail and no data egress, tested the way a good RFP tests it, with the cable unplugged.

Frequently asked questions

What is the single most important clause in a sovereign AI RFP?

The network-cable test. Require that the system keeps working with every network interface disabled, and make passing it a condition of award. It is the one criterion a cloud service dressed as sovereign cannot fake, because the behaviour is observable and binary rather than a matter of policy.

Can I ask for sovereign AI without specifying a particular vendor?

Yes, and you should. Write the requirements as testable behaviours: owned hardware, offline operation, a tamper-evident audit trail and zero egress. Any capable supplier can meet a behaviour-based specification, which keeps the tender competitive and defensible.

How is sovereign AI different from a private cloud deployment?

A private cloud still depends on someone else's infrastructure, accounts and update channels, so data and control can leave the perimeter. Sovereign AI runs on hardware the buyer owns or controls and functions with the network unplugged, which a private cloud deployment cannot claim.

Where does Mickai fit in a sovereign AI tender?

Mickai is a SIOS founded by Micky Irons, built from the outset for owned hardware, offline operation, a provable audit trail and no data egress. It is protected by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, and teams evaluating a tender like this can apply to the selective private beta at mickai.co.uk/beta, which does not accept everyone.

What evidence should suppliers provide to prove no data egress?

Ask for a live network capture taken while the system runs representative workloads, showing no outbound packets crossing the boundary, plus documentation of the control that enforces it, such as a default-deny outbound firewall or an air-gapped enclave. Proof should be observable at the network layer, not asserted in prose.