Sovereign AI explained with Cohere, Claude and Mistral

"Sovereign AI" shows up in a lot of vendor decks now. It usually arrives about ninety seconds after someone in the room asks where the data goes.

I get that question in nearly every session I run with a team. Someone has been pasting client documents into ChatGPT for months. Procurement has now got involved. There are three vendors on the shortlist and all three describe themselves as sovereign. Nobody in the room can say what the word is doing.

So this is how to test the claim: what the term is being used to mean, the four ways you can run a model, and the five questions I'd want answered before anyone signs.

One in three leaders can't define sovereign AI

IDC surveyed more than 500 senior people responsible for AI purchasing at enterprises turning over more than US$1bn, across Canada, the US, the UK and Germany. The survey was fielded in April and May 2026 and sponsored by Cohere ("The state of sovereign AI adoption in 2026", IDC InfoBrief, May 2026).

One in three had difficulty describing sovereign AI in their own words.

Among those who could, 52% described it as local or national control and 35% as digital independence. Only 13% said they were "very widely" aware of it. IT respondents had twice the awareness of line-of-business leaders.

That awareness gap is where the trouble starts. If your commercial lead thinks sovereignty means "our data stays in Britain" and your CISO thinks it means "no overseas parent can be compelled to hand it over", a vendor comparison is being asked to settle an argument the business hasn't had yet.

The underlying worries are consistent, at least. Data leakage and privacy came top for 82% of financial services respondents, 77% in manufacturing and 75% in telecoms.

One more figure worth sitting with. Only 18% of UK respondents saw sovereign AI as a competitive advantage, against 35% in Canada and 28% in the US. Over here, buyers treat it as a compliance cost.

The four ways you can run a model

Strip the label off and there are four architectures. Every pitch you'll hear is one of these, or a blend.

Option	What it looks like	What you control	What you give up
Public API, contract only	Claude on the Anthropic API, ChatGPT Enterprise, Gemini via Google AI Studio	Contract terms: no training on your data, retention windows, deletion, audit rights	Processing, support access and incident handling all sit with the provider
Regional managed deployment	Claude via AWS Bedrock in London, Azure OpenAI in UK South, Mistral on Vertex AI in the Netherlands	Which region stores and processes, your own cloud IAM, your own logging	The provider still operates the model. Overseas parent-company legal reach is unchanged
Private deployment in your environment	Cohere North in your VPC or on-prem, Llama or Mistral served with vLLM	The environment, the network boundary, the model version, when it changes	You now run it. Upgrades, evals, uptime and the GPU bill are yours
Fully local	Mistral, Llama or DeepSeek through Ollama or LM Studio	Everything. Nothing leaves the machine	Frontier capability, scale, and someone has to maintain it

Read the region tables before you take "regional" at face value. When I checked in November 2026, only Claude Opus 5.5 ran inside AWS's London region. Sonnet and Haiku were reachable from London only through cross-region inference, which can send the request somewhere else. On Azure, the only pay-as-you-go GPT model deployable regionally in UK South was GPT-4.1 mini. The current models were there on reserved capacity, or on Global Standard, which can process in any Azure region. Mistral on Vertex AI had no London region at all. Europe was served from the Netherlands. None of that is hidden. It's in the docs. It just isn't on the slide.

The trade is the same every time. Control goes up, and so does the amount of work you own. I've written before about what open-weight models like Kimi K2 mean for enterprise AI, and the short version applies here: the gap in capability between an open-weight model you host and a frontier model you rent has narrowed a lot, but it hasn't closed.

Cohere is worth naming carefully. The research above is useful. Cohere also sells private deployment, so it paid for research into the demand for private deployment. Read the numbers. Don't let them pick your architecture.

Five questions that turn the label into a test

Procurement can't test a slogan. Each of these should produce a document or a named person, not a reassurance.

1. Where does the data actually move?

Not the application database. Not the country on the cloud contract. The whole path: prompts, uploaded documents, retrieved chunks and embeddings, model outputs, application and security logs, backups, and any human who opens a support ticket.

Storage and processing are different questions. A document can sit in a London bucket while the inference call, the diagnostic log and the support engineer all cross a border.

The test I'd use: can the vendor draw the path for normal use, for support, for failure and for recovery? Four diagrams, not one.

2. Who can switch it off?

List everyone with technical or contractual power over the service. Your own admins, the implementation partner, the cloud provider, the model provider, subcontractors, and the identity and monitoring vendors nobody remembers to include.

Then write down who can read the data, rotate credentials, change the model version, alter a safety policy, suspend an account, or terminate the contract.

If nobody in the business can answer that from memory, the system isn't under your control yet, whatever the deployment diagram says.

3. What keeps working when something breaks?

Sovereignty conversations obsess over location and skip continuity entirely.

Ask what happens if the model endpoint goes down, the region fails, the account gets suspended, the vendor changes its terms, or a cross-border transfer suddenly needs a lawyer. The answer might be a second provider, a local model on standby, a manual fallback, or a decision that this workflow can simply pause for a day.

For each workflow that matters, write down the longest acceptable interruption, the minimum function that has to survive, who makes the call, and what evidence you need before switching back. Pick the fallback while you still have time to test it.

This happens to me often. A model times out or an API goes down halfway through a run. Nothing I run goes out to a client automatically, so there's always a human check and the cost is a delay. I've since added fallbacks through OpenRouter, so when one provider fails the request goes to another model and the work carries on. Remember that a fallback is also a new place your data goes, so it has to pass the first question too.

4. Which law is in the room?

Data residency is one control, and it's the one everybody buys first.

The rest of it: governing law in the vendor contract, sector regulation, access by an overseas parent, IP terms, training provisions, breach notification, deletion rights, audit access.

Turn those into acceptance criteria a vendor either meets or doesn't. Customer data is never used to train a shared model. Named data classes stay in an agreed region. Support access needs approval and leaves an audit record. You can export your data and configuration in a usable format. Material model or policy changes come with notice.

Legal, security and technology have to agree these together. None of them can answer the whole question alone, which is exactly why the question keeps getting deferred.

5. Who owns the controls after launch?

An architecture diagram doesn't operate anything.

Name the people responsible for user access, model changes, monitoring, incident response, vendor review, exceptions and shutdown. Say what they check and how often. Give them the authority to pause the workflow when the evidence is thin.

This is where I see the most expensive gap. A company buys a private deployment, gets the sovereignty box ticked, and nobody owns the thing on a Tuesday morning.

Running it yourself has its own bill

The most locked-down option isn't automatically the right one. On-prem open-weight models mean you own the GPUs, the upgrade cycle, the evals when a new version lands, and the person who gets paged at 2am. That's a real cost, and for a lot of workloads it reduces a risk that was never the one keeping you up.

The reverse trap is just as common. A familiar enterprise vendor with a good logo isn't sufficient either if you can't test data movement, control or continuity.

Score every option against the same evidence.

Area	Evidence to ask for
Data movement	Current data-flow diagrams for normal use, support, logs, backups and recovery
Access and control	A role and permission matrix covering you, the implementer and every vendor
Continuity	A tested fallback, recovery targets, and named decision owners
Legal and policy	Contract terms mapped line by line to your acceptance criteria
Operations	Runbook, monitoring, review cadence and who holds shutdown authority

Start with one workflow

Pick the single workflow you'd least like to see on the front page. Map it end to end: the data, the systems, the users, the decisions, the providers, the ways it fails.

Then write the five sets of requirements before you choose a model or a deployment pattern. A prototype is useful for testing the riskiest assumption, but a working demo and an operated system are separated by ownership, monitoring, support and recovery.

Sovereign AI is worth having when it gives you practical control over your own systems. The label on its own gives you nothing.

If your team is halfway through this argument and can't find the exit, I run AI training for teams that starts with your workflows rather than a vendor shortlist. If you're not sure whether that's what you need, message me and I'll tell you honestly.