Sovereigntyiscontrol,notmerelylocation
A dataset can sit in a European region and still leave you with no meaningful control over the system built on it. Residency answers one of six questions.
- Compute sovereigntyCan you determine where and on whose hardware inference runs?Placement of training, fine-tuning and inference workloads — including which jurisdiction the accelerators sit in and who holds physical access.
- Model sovereigntyCan you change model provider without redesigning the system?Freedom to run open-weight, private or commercial models, to inspect what a model is, and to move workloads between them.
- Data sovereigntyDo you control residency, retention, keys and what leaves the boundary?Residency and retention, encryption key custody, and enforceable limits on what may cross a boundary — including into a model provider's logs.
- Identity sovereigntyDo you own the directory that decides who and what may act?Control of the identity provider and of the non-human identities issued to agents, rather than depending on a vendor's tenant model.
- Operational sovereigntyCan you operate the system if the vendor relationship ends?Who can administer, upgrade, restart and recover the system — and whether operator access can be constrained and audited.
- Governance sovereigntyDo your own policies decide what the system may do?Whether policy, approval and evidence requirements are yours to define and change, or inherited from a provider's defaults.
Definition
Sovereignty over an intelligence system is the degree to which an organisation can determine where it runs, which models it uses, what happens to its data, who and what may act within it, who can operate it, and whose policies govern it — and can continue to exercise those determinations if a commercial relationship ends.
Whyresidencyaloneisinsufficient
Consider a system where the data is stored in an EU region, the encryption keys are held by the provider, inference happens through an API terminating 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 hypothetical, and it is not usually anyone's bad faith. It is what happens when sovereignty is procured as a location attribute rather than as a set of control rights, because location is the one attribute that is easy to write into a contract.
The six dimensions below exist to make the other questions equally contractible. Each has a test, and each test can be applied to any vendor — including us.
Thesixdimensions
Use these as diligence questions rather than as a description of a product.
- Compute sovereigntyCan you determine where and on whose hardware inference runs?Placement of training, fine-tuning and inference workloads — including which jurisdiction the accelerators sit in and who holds physical access.
- Model sovereigntyCan you change model provider without redesigning the system?Freedom to run open-weight, private or commercial models, to inspect what a model is, and to move workloads between them.
- Data sovereigntyDo you control residency, retention, keys and what leaves the boundary?Residency and retention, encryption key custody, and enforceable limits on what may cross a boundary — including into a model provider's logs.
- Identity sovereigntyDo you own the directory that decides who and what may act?Control of the identity provider and of the non-human identities issued to agents, rather than depending on a vendor's tenant model.
- Operational sovereigntyCan you operate the system if the vendor relationship ends?Who can administer, upgrade, restart and recover the system — and whether operator access can be constrained and audited.
- Governance sovereigntyDo your own policies decide what the system may do?Whether policy, approval and evidence requirements are yours to define and change, or inherited from a provider's defaults.
Exitability
The clearest test of sovereignty is what happens when you want to leave. If leaving is impractical, control was theoretical.
Data portability
Ontology, policies, evidence records and agent definitions exportable in documented formats, not a proprietary dump.
No proprietary control plane dependency
The runtime is conformant Kubernetes, so the deployment is not itself the lock-in.
Model substitutability
Workloads declare requirements rather than naming vendors, so switching a model is configuration.
Operational transfer
Runbooks and documentation sufficient for your staff or another party to operate the system.
Transition window
A contractual period during which the system keeps running while you move.
Tested rather than promised
An exit path that has been walked through is worth considerably more than one that has been written down.
Howdeploymentposturemapsontothedimensions
No posture maximises every dimension. Choosing well means knowing which ones matter for your risk.
| Dimension | Shared European region | Your cloud tenancy | On-premises / disconnected |
|---|---|---|---|
| Compute | Region and class fixed by contract | Your account, your region choices | Your hardware |
| Model | Full choice, including local models | Full choice | Local models only if disconnected |
| Data | Residency enforced; customer keys available | Never leaves your tenancy | Never leaves your premises |
| Identity | Federated to your directory | Federated to your directory | Your directory |
| Operational | NeuroCluster operates; access logged | Shared, by agreement | You operate |
| Governance | Your policies | Your policies | Your policies |
On-premises deployment maximises some dimensions and creates new operational risk in others: you own patching, capacity and recovery. Sovereignty is a set of trade-offs to be chosen deliberately, not a single posture to be reached.
Questions
- Is sovereign AI the same as sovereign intelligence?
- Not quite, and the distinction is load-bearing. Sovereign AI usually refers to models and compute being under national or organisational control. Sovereign intelligence extends that to the whole operating capability: the semantic model of your business, the policies that govern action, the identities that act, and the evidence produced. You can have sovereign AI and still not control what your intelligence systems are permitted to do.
- Does a certification prove sovereignty?
- No certification confers it. Certifications and frameworks are useful evidence about specific controls, and several are worth having. Sovereignty is a property of the control rights you actually hold, which is why the tests above are phrased as questions rather than as badges.
- Can we hold our own encryption keys?
- Yes, including the root of trust, in the private deployment postures. This is one of the questions worth resolving early, because retrofitting key custody is considerably harder than specifying it.
- What about legal access requests from other jurisdictions?
- Exposure depends on the corporate structure of every party in the chain and on your deployment posture, not on where a datacenter is. That is a legal analysis specific to your circumstances; what we can do is be transparent about the chain and support postures with no external dependency at all.
Continue
Bring us one operational problem.
You do not need a finished brief. Bring the problem — we will work out the next step together.
Or book a call with the team