WhatIsaSovereignIntelligenceControlPlane?

Sovereign AI, as the term is generally used, concerns models and compute: a nation or an organisation having models it controls, trained on data it holds, running on infrastructure within its jurisdiction. It is a real and important agenda, and most of the public investment discussion is about it.

Sovereign intelligence is a broader and more operational idea. It concerns the whole capability an organisation runs: not only the models and the hardware, but the semantic model of the business the AI reasons over, the policies that decide what it may do, the identities under which it acts, and the evidence it produces. The distinction has a practical consequence that is easy to miss.

You can have sovereign AI and still not have sovereign intelligence. Imagine an organisation running open-weight models on hardware it owns, inside its own jurisdiction — and the policies governing what those models may do are the vendor's defaults, the agents act under credentials issued by the vendor's tenant, and only the vendor's staff can operate the control plane. Every sovereign AI box is ticked. Control over what the intelligence actually does sits elsewhere.

Residency is a good control and a poor proxy. Consider a system where data is stored in an EU region, the encryption keys are held by the provider, inference happens through an API that terminates outside the region, the identity model belongs to the provider's tenant, only the provider's staff can operate the control plane, and the governance defaults are the provider's. Every residency question has been answered correctly. Almost every control question has been answered in the provider's favour.

This is not usually anyone's bad faith. It is what happens when sovereignty is specified as a location attribute, because location is checkable in a procurement questionnaire and the other five dimensions are not — unless someone writes tests for them.

There is also a subtler failure. Residency programmes commonly leak at the edges: backups in another region, telemetry leaving the boundary, a vector index built in a different location than the source data, or model inference routed through a convenient endpoint because the primary one was unavailable. A residency commitment that is enforced by the platform for data, indexes, evidence, backups and inference is a different thing from one asserted in a policy document.

The test: can you determine where, and on whose hardware, inference runs?

This covers placement of training, fine-tuning and inference — which jurisdiction the accelerators sit in, who has physical access to them, and whether you can require that a class of workload never runs anywhere else. It is the dimension most affected by capacity scarcity, because a placement commitment is only as strong as the capacity available inside the boundary. When there is none, the pressure to make an exception arrives at exactly the moment the commitment matters.

Worth asking specifically: what happens under capacity pressure or provider outage? A fallback path that silently routes inference outside the boundary defeats the commitment more thoroughly than never having made it.

The test: can you change model provider without redesigning the system?

This is the freedom to run open-weight, private or commercial models, to know what a model is, and to move workloads between them. The architectural question underneath it is whether applications name a vendor or declare a requirement. If application code calls a specific provider's API surface, model choice is structural and changing it is a project. If workloads declare what they need — capability, sensitivity class, latency tolerance, jurisdiction — and a policy layer selects the model, changing it is configuration.

Given how quickly model capability moves, this is a resilience property rather than a philosophical one. It is also increasingly a concentration-risk question that supervisors in regulated sectors ask directly.

The test: do you control residency, retention, keys and what leaves the boundary?

Beyond storage location, this covers who holds the encryption keys — including whether you can hold the root of trust — what may cross a boundary, and crucially what a model provider may retain, log or train on. That last item is where a great deal of otherwise careful data governance quietly fails, because the data leaving is a prompt rather than a file and prompts are not always treated as data flows.

The complete question includes derived artefacts. Vector indexes, evidence records, evaluation datasets and caches all contain your data in some form, and a residency commitment that covers the source system but not the index is incomplete.

The test: do you own the directory that decides who and what may act?

Human identity is usually already sovereign — the organisation runs its own identity provider and federates. Non-human identity frequently is not. If the principals agents act under are issued and managed inside a vendor's tenant model, then the answer to "who may act in your organisation" is partly the vendor's to give.

This dimension is easy to overlook because it does not feel like a sovereignty question. It becomes one the first time you need to revoke something quickly, or to prove to an auditor that a given agent could not have accessed something.

The test: could you operate the system if the vendor relationship ended?

This covers who can administer, upgrade, restart and recover the system, and whether operator access can be constrained, approved and audited by you. It also covers the documentation question: is there enough of it for your staff or a third party to run the system, or is operational knowledge effectively held by the vendor?

It is worth being honest about the trade-off here. Taking full operational control maximises this dimension and creates new risk in exchange: you own patching, capacity and recovery. That is the right trade for some environments and the wrong one for many, and it should be a decision rather than a default.

The test: do your own policies decide what the system may do?

This is the dimension the term sovereign AI does not reach at all. It asks whether policy, approval thresholds, risk classification and evidence requirements are yours to define and change, or inherited from a provider's defaults with limited configurability. It also asks whether they are enforced — a policy you can express but the platform does not evaluate is a preference.

In practice this is the dimension that determines whether an organisation can use AI for consequential work at all, because consequential work requires the organisation's own rules to be the ones in force.

The clearest single test of sovereignty is what happens when you want to leave. If leaving is impractical, control was theoretical regardless of how the six dimensions were answered at signature.

Exitability has components that can each be examined. Data portability: can the semantic model, the policies, the evidence records and the agent definitions be exported in documented formats, rather than as a proprietary dump? Runtime portability: is the deployment itself a lock-in mechanism, or does it run on conformant infrastructure? Model substitutability: can workloads move between models without application changes? Operational transfer: is there documentation sufficient for someone else to run it? And contractually, is there a transition window during which the system keeps running while you move?

The strongest version of this is a tested exit path rather than a documented one. An organisation that has exported its ontology and policies and stood the platform up in an alternative posture knows something that a contract clause cannot tell it.

A recurring misunderstanding is that legal access exposure is determined by where a datacenter sits. It is determined by the corporate structure of every party in the chain and by which entities can be compelled, in combination with the deployment posture. A facility in one jurisdiction operated by a subsidiary of a company incorporated in another does not straightforwardly give you the first jurisdiction's protections.

This is a legal analysis specific to an organisation's circumstances and it should be done with legal advice rather than inferred from a vendor's marketing map. What a vendor can reasonably be asked for is transparency about the chain — which entities are involved, which subprocessors, and in which postures — and support for postures with no external dependency at all.

Operators of essential services carry duties that make several of these dimensions non-negotiable rather than preferable. Continuity obligations mean an operational sovereignty question — could you keep running without the vendor — is a regulatory question. Supply-chain security duties mean the composition of the chain matters. Incident reporting timelines mean evidence has to be available immediately rather than reconstructable.

There is also a straightforward operational reason. These organisations plan on decade horizons and run assets older than most software companies. A dependency they cannot exit is a dependency they are unlikely to accept for anything that matters, which is why exitability tends to come up earlier in these conversations than pricing does.

Three properties tend to distinguish architectures that hold up. The first is that the enforcement layer is separable from the provider: policy, identity and evidence live in components the customer can run, inspect and export, rather than in a hosted service with an API.

The second is that the deployment substrate is conformant rather than proprietary. If the runtime is standard Kubernetes, the deployment is not itself the lock-in; if it is a bespoke control plane only the vendor can operate, then operational and exit sovereignty are compromised by construction regardless of what the contract says.

The third is that declarations replace names throughout. Workloads declare sensitivity, jurisdiction and capability requirements; policy resolves them to a model, a region and an infrastructure class. That indirection is what makes the other dimensions adjustable without a rewrite — and it is also, not coincidentally, what makes the governance model expressible in the first place.