Why Sovereign AI?

1. Where your data ends up

This is the data sovereignty layer.

The risk on a public AI tool

When you paste a document into ChatGPT, it travels to OpenAI's servers in the United States. The text gets processed there. A copy stays in OpenAI's usage logs (free tier: up to 30 days, longer for abuse monitoring).

Unless you've turned the right setting off, the text may also feed future training runs. Copilot, Gemini, and Claude each have their own version of the same picture, with different tiers and different terms.

Under UK GDPR, when you use a third party to process personal data on your behalf, you need a written contract with them covering security, deletion, and how they handle the data. ChatGPT on the free tier doesn't give you that contract.

The Data (Use and Access) Act 2025 didn't change this. Same controller and processor framework, same requirements.

The data also sits in scope of US legal process. Wherever the document legally belongs, you've moved it somewhere another country's courts can ask for it.

The sovereign answer

The model and the workspace (a self-contained area where your documents and the rules for using them sit together) live in your organisation's own slice of Amazon's UK cloud, in London. Documents go in, get processed by a model running in the same place, and don't leave. When the work is done, the workspace is archived.

No third party logs. No training pool. No US legal process. The data was never anywhere a future query might surface it.

The models I use have publicly available weights, meaning you can see exactly what's inside them and run them yourself, rather than calling a closed service where you can't. Magistral Small, Mixtral, and Llama 3 are the current options.

They're served through AWS Bedrock, Amazon's way of letting you run an AI inside your own corner of a UK data centre with the door locked from the outside. The infrastructure is industry standard. The difference is where it's running and who can see the prompts.

See it in the use cases

• CV shortlisting: applicants' CVs, personal data and often special category.
• Staff policy assistant: your handbook with bonus structures, named exceptions, commercially sensitive arrangements.
• Tender qualification check: your capability statement, the document you use to win work.

2. Whose rules the assistant follows

This is the operational sovereignty layer.

The risk on a public AI tool

Public AI tools come with the vendor's policy decisions baked in. OpenAI decides what its model will and won't do. Google decides for Gemini. Microsoft decides for Copilot.

Some of those decisions you might agree with. Some you might not. Either way, you don't get to vote. When the policy changes (it has, and it does), the behaviour your team relies on changes with it.

The harder problem: you can't reliably enforce your own organisation's rules. If your policy is "we don't rank candidates by gender even when asked", a public tool won't enforce that for you. The model will do whatever its own filter allows. Some prompts will work, some won't, and you can't see the rules being applied.

The sovereign answer

A sovereign build puts a system prompt between every user prompt and the model. The system prompt is yours: written by your team, reviewed by HR, Legal, or your DPO, applied the same way to every user on every prompt.

What goes into it depends on the use case. A hard refusal on protected characteristics. A required citation format. A tone of voice for sensitive questions. A boundary that says "you are a comparison tool, not a legal advisor". The behaviour is yours, enforced consistently.

When your organisation's policy changes, you update the system prompt. The assistant's behaviour changes with it. There's no waiting for a vendor's roadmap.

See it in the use cases

• CV shortlisting: refusing to rank candidates by gender, on Equality Act 2010 grounds your organisation wrote into the system prompt.
• Tender qualification check: refusing to draft a bid response, staying as a qualification tool.
• Staff policy assistant: handling sensitive questions (grief, bereavement, harassment) with warmth, and admitting "I don't know" when a policy isn't covered.
• UK regulator guidance Q&A: refusing personal legal advice even when pushed, punting to a solicitor or DPO.

3. Where the answer came from

This is the model sovereignty layer.

The risk on a public AI tool

A general purpose AI tool answers from a mix of everything it was trained on. For UK law, that's a mix of UK statute, US legal material, and pre Brexit EU law. The version of GDPR a chatbot quotes might be the original 2016 text, not the post Brexit UK version, not the post 2025 DUAA amendments.

The model has never read your handbook, your contracts, your tender, or your playbook. It guesses from general patterns. Sometimes the guess is close. Sometimes it's wrong in a way you can't easily tell.

And nothing gets cited. "ChatGPT said so" isn't an answer for a DPO, a tribunal, an auditor, or a head of legal. You have no way to verify a reply, and no way to defend it later.

The sovereign answer

A sovereign workspace gets loaded with your documents: handbook, playbook, contracts, ICO guidance, whatever the use case needs. The system prompt requires every answer to cite the specific document and section it came from.

Click through and verify. If the cited section doesn't say what the assistant claims, you see it. If the source updates, a watcher script can keep the workspace current.

The answer is auditable in the way the work needs it to be: ready for a tribunal, defensible to a DPO, reviewable by a partner. It points at a source you can show someone.

See it in the use cases

• Staff policy assistant: every answer cites the section of your handbook, with a record you could produce if a tribunal asked.
• Tender qualification check: every row cites the tender and the capability statement, with the arithmetic shown.
• UK regulator guidance Q&A: answers cite ico.org.uk pages; a watcher script keeps the workspace current as the ICO updates guidance.

4. What happens when the vendor changes

This sits across the operational and model sovereignty layers.

The risk on a public AI tool

A public AI tool is one vendor's pricing, one vendor's model lifecycle, one vendor's terms of service.

Pricing goes up. (It has.) Models get retired. (OpenAI has deprecated GPT-3.5 and the original GPT-4; teams with prompts tuned to those models had work to do.) Terms change. (Data use, retention, training opt outs, all moving targets across all the providers.)

The longer your team uses one vendor, the harder it is to move. Prompts get tuned to that vendor's quirks. Workflows get built around its quirks. By the time you decide a different vendor would be safer or cheaper, the migration cost is real.

The sovereign answer

The workspace is yours. The documents are yours. The system prompt is yours. The model is the only part that's swappable, and it sits behind a standard interface.

The working default is Magistral Small from Mistral AI: a French company, open weights, native system prompt support, 128k context. Mixtral 8x7B from the same provider and Llama 3 70B from Meta are documented alternatives. All three run on AWS Bedrock. Switching between them is a configuration change, not a rebuild.

When pricing shifts or a model is retired, you swap. The workspace and the system prompt don't move. The AWS bill comes to your account, not someone else's. Your usage shapes your cost, not someone else's pricing decisions.

See it in the use cases

• All three use cases run on open weights models on AWS Bedrock, with documented alternatives.
• CV shortlisting: the gender refusal lives in the system prompt, so a model swap doesn't touch it.
• UK regulator guidance Q&A: when the ICO updates guidance, a watcher script keeps the workspace current; when a model is retired or repriced, you swap.