Sovereign AI

The engagement

Three of them, really, converging on one problem.

A UK government department needed a classified data architecture to HMG standards. A Gulf smart-city programme needed AI capability under data-sovereignty law that forbade the obvious cloud answer. A group of NHS practices needed to run LLM inference over patient calls at a cost that a GP surgery could actually afford — and with patient data that could not, under any circumstances, be posted to an American API.

In each case the delivery was policy, architecture and governance. In none of them did I personally write the retrieval layer that enforced the boundary — because in 2021 the boundary was a network boundary, and the model wasn't in the room.

Now the model is in the room, and the boundary has moved.

The mistake almost everyone makes

Here is the architecture I see in nine out of ten sovereign-AI proposals:

Index all the documents. At query time, tell the model in its system prompt: "The user has SECRET clearance. Do not reveal TOP SECRET material."

This is a regulatory boundary defended by a politely-worded request. The model has the classified chunk in its context window. It has been asked nicely not to mention it. Prompt injection, an oblique question, a summarisation request, a translation task, a "what did you just read?" — and the control is gone.

You cannot patch this with a better prompt. It is wrong at the architecture level.

The correct design

Security is enforced at retrieval, not at generation.

The caller's clearance and need-to-know compartments become a filter on the vector search itself. The search runs within the permitted subset. Chunks above the caller's clearance are never candidates, never retrieved, never placed in the context window.

The model cannot leak what it was never given. That's not a mitigation, it's a guarantee — and the difference between those two words is the whole engagement.

What that requires

• Every chunk carries labels at ingest: classification, compartments, handling caveats, originator. Labels inherit from the document but can be overridden per chunk, because paragraph nine is often the sensitive one.
• Filtered vector search. A pre-filtered ANN query, not a post-filter — post-filtering is a timing side channel and an efficiency disaster.
• Policy as code. Clearance logic lives in OPA/Rego, not scattered through application code. It is testable and auditable in isolation.
• The model is not a trust boundary. Nothing in the system prompt is load-bearing for security. Delete every guardrail instruction and the system must remain secure.

Aggregation risk

The genuinely hard problem, and the one that separates people who have thought about this from people who have read about it.

Five unclassified facts can combine into a classified conclusion. Retrieval is very good at assembling exactly that combination — it is, after all, what retrieval is for.

There is no complete solution. There are partial ones: flag queries whose retrieved set spans an unusual number of compartments; detect known aggregation-sensitive topic combinations; log everything and review; cap the breadth of any single retrieval.

Saying openly that this is unsolved, and showing what you do about it anyway, is far stronger than pretending otherwise. Security architects trust people who name the hard part.

Prompt injection as a supply-chain problem

The moment you ingest documents you didn't write, an attacker can put instructions in one. A poisoned PDF in the corpus is a code-execution vector against your agent.

• Treat retrieved content as data, never instruction — structurally separated in the prompt, not merely asked to behave
• Scan at ingest for injection patterns
• Nothing an agent retrieves may authorise a tool call
• Red-team suite in CI, so a regression in injection resistance fails the build like any other test

Cost — the NHS question

The claim I've made on a CV for years is 95% cheaper than commercial APIs. I have never personally measured it. This build measures it.

Quantised open-weight model on a single GPU, versus a frontier API, on identical workloads: cost per thousand queries, latency, and — the part everyone skips — quality. If the local model is materially worse, the sovereignty argument has a price, and honesty about that price is worth more than the claim.

Results

Metric	Frontier API	Local (quantised)
Answer quality — groundedness	___	___
Recall@10 on the golden set	___	___
p99 latency	___	___
Cost per 1,000 queries	___	___

Security evaluation — the numbers that actually matter:

Test	Result
Leakage across clearance levels (red-team suite)	___
Prompt-injection resistance	___
Retrieval filter — false permits	___
Aggregation flags raised / confirmed	___

A single confirmed leak across a clearance boundary is a failed build. That threshold is not negotiable and it is the point of the whole exercise.

Decisions I'd defend in an architecture review

1. Filter at retrieval, not generation. The model is not a trust boundary. ADR-001.
2. Pre-filter, not post-filter. Post-filtering leaks through timing and result counts. ADR-002.
3. Policy in Rego, not in application code. Auditable in isolation. ADR-003.
4. Retrieved content is data, never instruction. ADR-004.
5. Air-gapped by default. Egress is a feature you enable, not a default you disable. ADR-005.

What I got wrong

Run it

Unplug the network cable. Ask it a question. It answers.

That demo is the entire point.