RHETRA / Sovereign AI
What is Sovereign AI?
Sovereign AI is artificial intelligence whose models and data operate under an organisation's full legal and technical control — with no uncontrolled data egress, under its own jurisdiction, and verifiably so. The last word is the one that matters. Anyone can claim control; sovereign AI is the discipline of proving it, cryptographically, while the system runs.
1 · The three-part definition
A system qualifies as sovereign AI when all three properties hold simultaneously:
- Legal control — every layer of the stack (hardware, OS, model, gateway) is governed by an entity under your jurisdiction. No foreign parent company that extraterritorial law can compel.
- Technical control — you decide what data enters and leaves. The default is zero egress: prompts, documents and telemetry stay inside your perimeter unless policy explicitly allows an exception.
- Verifiability — both of the above can be demonstrated with evidence a third party can check: hardware attestation reports, signed audit trails, reproducible builds. Not contracts. Not slide decks.
Drop any one of the three and you have something weaker: outsourced AI with a nicer address (no legal control), an intranet chatbot that quietly calls cloud APIs (no technical control), or a genuinely isolated system nobody can audit (no verifiability).
2 · Why "hosted in the EU" is not sovereignty
Most "sovereign cloud" marketing reduces sovereignty to geography: the data centre is in Frankfurt or Paris, therefore you are sovereign. That claim fails both remaining tests. A Frankfurt region operated by a non-EU hyperscaler remains subject to its parent's legal obligations — the US CLOUD Act explicitly reaches data "regardless of whether such [data] is located within or outside of the United States". And geography says nothing about egress: your prompts may be processed in Frankfurt and logged in Virginia.
Location is one input. Sovereignty is a property of the system — legal control, technical control, verifiability — and a property can be tested.
3 · What proof looks like: attestation
Modern server CPUs can do something remarkable: attest to their own workload. On AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging), the processor measures the exact code loaded into a confidential VM, encrypts that VM's memory with keys the host operator never sees, and signs the measurement with keys that chain back to AMD's hardware root of trust.
The consequence is a reversal of the trust model. You no longer ask "do I trust the operator?" — you verify a signature. Concretely:
- The attestation report names the exact byte-for-byte measurement of the running code.
- It proves the memory is encrypted against the host — the cloud or data-centre operator cannot read it.
- Anyone can verify the signature chain against AMD's public root keys — no vendor cooperation needed.
Pair this with a post-quantum signed audit trail (RHETRA uses Dilithium5, a NIST-standardised PQC algorithm) and every policy decision the system makes becomes tamper-evident — even against an adversary with a future quantum computer.
4 · The EU AI Act connection
The EU AI Act — in force since August 2024, with high-risk obligations phasing in through 2026/2027 — requires exactly the capabilities sovereignty provides: logging and traceability (Art. 12), transparency (Art. 13), human oversight (Art. 14), and data governance (Art. 10) for high-risk AI systems. Fines for high-risk non-compliance reach €15M or 3% of global turnover — and up to €35M or 7% for the more severe prohibited-practices violations (Art. 5, Art. 99).
Compliance teams usually respond with documents. The sovereign approach responds with a running loop: author the policy machine-readably, enforce it inline on every AI call, prove each decision with a signature, export the evidence for the auditor. A regulator that can verify signatures does not need to trust your PowerPoint.
5 · The 5-question sovereignty checklist
Use these on any vendor — including us:
- 1. Attestation: Can you show a hardware attestation report for the running workload — today, not "on the roadmap"?
- 2. Independent verification: Can I check that report against the CPU vendor's root keys myself?
- 3. Signed audit: Is the audit trail cryptographically signed? With which algorithm — and is it post-quantum?
- 4. Egress: What leaves the environment? Can zero-egress be demonstrated, not just promised?
- 5. Jurisdiction: Which legal entity controls each layer, under which law?
A vendor that answers all five with evidence is selling sovereignty. A vendor that answers with a map is selling a postcode.
6 · How RHETRA implements this
RHETRA's stack — five products, one loop — was built so the checklist above answers itself:
- OSI Gateway (KRONOS): OpenAI-compatible enforcement gateway; classifies every call, enforces BLOCK/SANITIZE/ALLOW, signs every decision with Dilithium5, runs inside SEV-SNP attested memory.
- OSI Governance Platform: the author→enforce→prove→export loop as a product — SaaS or bare-metal.
- OSI Shield (AEGIS): on-device PII detection, fail-safe, zero-egress — free Community Edition.
- OSI Browser (HERMES) and OSI OS (ATLAS): the sovereign endpoint, down to the operating system.
Verify a sovereignty claim — live.
45-minute demo on a running system, or a 30-day pilot on your hardware. You keep the signed evidence either way.