How does sovereign AI answer a security questionnaire before a bid?

A sovereign AI answers a security questionnaire by turning promises into properties an auditor can test. Because it runs entirely offline on operator-owned hardware, behind a zero-egress inbound perimeter, with every action written to a cryptographically sealed audit ledger, the hardest questions (data residency, third-party access, sub-processors, cross-border transfer) resolve to demonstrable facts rather than policy statements. Mickai is a Sovereign Intelligence Operating System, a SIOS, built so that the truthful answer to those questions is yes and so that the yes can be shown. That is the difference that carries the section: a control the buyer can verify, not a commitment the vendor asks them to trust.

Security questionnaires now gate serious bids. In regulated sectors a procurement team sends a standard pack (the SIG or the CAIQ) or a bespoke due-diligence sheet before any commercial talks begin, and one unqualified answer can end the process. In 2026 the questions have sharpened around a single theme: where does the data go, and who else can reach it. A general-purpose public AI service, hosted in a vendor's cloud, cannot honestly guarantee the data never leaves its estate. A sovereign architecture can, because the architecture, not the contract, keeps the data in the building.

How does a sovereign architecture change the answers?

Most vendor answers are policy: a statement of what the vendor intends to do, backed by a contract and a certificate. A sovereign architecture answers with structure instead. Mickai runs on hardware the operator owns, inside their own perimeter, with no outbound path for prompts, documents or model output. We call this a zero-egress inbound perimeter: work comes in, nothing sensitive goes out, and no telemetry flows to a vendor cloud. Because there is no egress, whole categories of questionnaire risk simply do not apply. Asked whether data can be transferred to a third country, the answer is not "we have safeguards" but "there is no route by which it could be".

Which questionnaire lines flip from qualified to clean?

A handful of the standard lines change character under a sovereign design:

• Data residency: the data stays on named hardware in a known location, because there is nowhere else for it to go.
• Sub-processors: there are none in the inference path, so the sub-processor list is empty rather than long.
• Model training on customer data: prompts and documents never leave the perimeter, so they cannot train an external model.
• Third-party access: no vendor operator, support engineer or cloud provider can reach the running system from outside.
• Incident data handling: logs and evidence are held locally under the operator's control, not exported to a shared platform.

Each of these is an answer a hosted service cannot give without a qualifier; under a sovereign architecture the qualifier disappears and the reviewer moves on.

“A security questionnaire is answered best by an architecture in which the honest answer and the verifiable answer are the same answer.”

What can an auditor actually check?

A clean answer is worth little if it cannot be inspected, and sovereign design is built for inspection. Every action inside Mickai is written to an append-only audit ledger, each entry bound to a hardware-attested identity, so the record shows what happened, on which attested machine, and under which key. The ledger is sealed with post-quantum digital signatures under FIPS 204, the primary standard for this purpose, with FIPS 205 available alongside it, so an auditor can prove that no entry was altered or removed after the fact. Because the system runs offline, that verification happens in the room, on the operator's own hardware, with nothing external to trust. Where a questionnaire asks how model output is kept reliable, the design answers with cross-model consensus: a material claim is checked by more than one model before it is acted on, and any disagreement is logged in the same ledger. The underlying design is the subject of 104 filed UK patent applications covering approximately 2,340 claims, owned by Mickai LTD, and remains patent pending.

Which rules make a sovereign answer necessary?

The questionnaire is the buyer's proxy for the law they sit under. Several regimes now push in the same direction:

• The EU AI Act's high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read the deferral as a build window, not a reprieve.
• DORA has been in force since January 2025 and holds financial entities accountable for their ICT and third-party risk.
• NIS2 raises security duties across the essential and important entities in its scope.
• GDPR still governs personal data, and its transfer rules are hardest to satisfy when data can leave the jurisdiction at all.
• The US CLOUD Act means data held by a US-linked provider can be compelled regardless of where it sits, precisely the exposure a sovereign perimeter removes.

ISO/IEC 42001 gives buyers a management-system standard for AI to map these duties against. A sovereign architecture is a direct way to satisfy the residency and control questions those regimes generate.

Where must a sovereign system still answer honestly?

Sovereignty is not a blanket yes. Physical security of the hardware, personnel vetting, patch discipline and key management remain the operator's responsibility, and a good questionnaire will probe them. A sovereign design narrows the attack surface and removes the egress risk, but it does not remove the operator's own duties. A questionnaire answered with an overclaim fails at the audit, not at the desk. A sovereign architecture lets a buyer give true yes answers where they matter, and honest scoped answers everywhere else.

Frequently asked questions

Can a sovereign AI pass a SIG or CAIQ questionnaire?

Yes, and it tends to pass the data-handling sections more cleanly than a hosted service. Questions about residency, sub-processors, egress and cross-border transfer resolve to a demonstrable architecture rather than a policy commitment. The operator still answers the physical, personnel and patching questions on their merits.

What is a zero-egress perimeter in plain terms?

It means work comes in but sensitive data does not go out. The system runs offline on the operator's hardware, with no outbound path for prompts, documents or model output and no telemetry to a vendor. Because there is no route out, whole categories of transfer risk no longer apply.

How can a buyer verify the audit trail rather than trust it?

Every action is written to an append-only ledger, bound to a hardware-attested identity and sealed with post-quantum signatures under FIPS 204, the primary standard, with FIPS 205 available alongside it. Because the system is offline, the buyer can verify the ledger in the room on their own hardware. Any alteration or deletion after the fact is detectable.

Does the deferral of the EU AI Act mean sovereign controls can wait?

No. The high-risk Annex III obligations moved from 2 August 2026 to 2 December 2027, with embedded high-risk systems to 2 August 2028, but the direction is fixed and DORA, NIS2 and GDPR already bite. We treat the extra time as a build window, which is why buyers ask now.

Why can a public AI service not give the same answers?

A hosted public AI service processes data on infrastructure the buyer does not own, often across borders, under laws such as the US CLOUD Act that can compel disclosure. That is a matter of architecture, not vendor intent. A sovereign design keeps the data on operator-owned hardware, so the honest answer and the verifiable answer become one.