This page is practitioner guidance on deployment mechanics, not legal advice — involve your counsel or DPO for decisions about your specific obligations.
Sovereign AI means the four layers of an AI system — the model weights, the compute they run on, the data they touch, and the operational control over all three — sit under a jurisdiction and an operator you have chosen deliberately. A hosted frontier API can give you contractual assurances about data residency, but it cannot give you the weights or independence from the provider's own legal environment. Open-weight models on infrastructure you own or rent under local law can give you all four, which is why sovereignty has moved from a policy talking point to a procurement criterion.
Why this is hard
A model you rent can be deprecated, repriced, or restricted mid-contract, and your workflows are built on it.
Data residency in a contract is not the same as jurisdictional immunity: the operator's home law can still reach the operator.
Capability that lives entirely in a vendor relationship is capability you cannot carry into a crisis.
What the deployment gives you
You hold the weights
An open-weight model on your storage cannot be deprecated out from under you. The version you validated is the version that keeps running next year, which matters most in exactly the regulated settings where re-validating a model is expensive.
One jurisdiction, stated plainly
Hardware in your facility or an operator incorporated under local law, with no foreign parent able to compel disclosure. This is the distinction between data residency, which is about location, and sovereignty, which is about who can lawfully reach the operator.
Operational independence
Serving, updating, and monitoring performed by your own team or a local partner. No dependency on a foreign support rota, an export-control decision, or a sanctions regime you do not control.
An exit that is not a rewrite
Open weights behind a standard inference API mean swapping models is a configuration change. Sovereignty and portability turn out to be the same architectural property viewed from two directions.
The four layers, and who controls each
Sovereignty is not binary — it is a stack, and most organisations end up sovereign at some layers and not others. Mapping the four honestly is more useful than a yes/no answer, because it shows exactly which dependency to address first.
Archive the exact weight files and tokenizer you validated. A model that disappears from a public hub is only a problem if you never kept a copy.
Check the licence for field-of-use and acceptable-use restrictions before you build on it — permissive is not the same as unconditional.
Prefer an operator whose corporate control sits in your jurisdiction; foreign ownership can bring foreign compulsory process regardless of where the racks are.
Keep a documented fallback model that runs on the same hardware, so a licence change is an inconvenience rather than an outage.
Record which layers you have not made sovereign. An honest gap you have accepted is manageable; one you have not noticed is not.
What you have to satisfy
EU Data Act — Cloud switching and portability: Obliges cloud providers to enable customers to move to another service, which strengthens exit rights but does not by itself give you the weights.
NIS2 Directive — Supply chain security: Essential and important entities must manage risk in their ICT supply chain — an AI dependency on a single foreign provider is now explicitly in scope.
Chapter V GDPR — Transfers to third countries: Residency claims are only as strong as the transfer analysis behind them; locally operated inference removes the question rather than answering it.
EU AI Act — Provider vs deployer roles: Self-hosting can move you along the provider/deployer line, particularly if you substantially modify a model — worth classifying before you deploy, not after.
Models that fit this deployment
Model
VRAM (Q4)
Runs on
Context
License
Mistral Small 3.1 24B European-published, Apache 2.0 — Where model provenance is itself part of the sovereignty case, not just where the GPUs sit. ollama pull mistral-small3.1
Building AI capability you will still control in five years?
We help organisations and public bodies design sovereign AI deployments — mapping the four layers against your actual dependencies, selecting models with durable licences, sizing the hardware, and planning the exit from whatever you are on now. Vendor-neutral by construction: we sell no infrastructure and no models.
It is control over four layers: the model weights, the compute, the data, and the operations. A deployment is sovereign to the degree you can answer "who could take this away, and under whose law?" without naming a foreign entity. In practice that usually means open-weight models running on owned hardware or on infrastructure operated by a company incorporated in your jurisdiction, with your own staff holding the keys and running the updates.
Is data residency the same as sovereignty?
No, and conflating them is the most common mistake in this area. Residency is a statement about geography — your data sits in a datacentre in a particular country. Sovereignty is a statement about legal reach — which government can compel the operator to act, and which corporate parent sits above them. A foreign-owned provider running a local region satisfies residency while leaving the sovereignty question open, which is precisely why vendor country of origin became a selection criterion: 77% of organizations now factor it into AI vendor decisions, per Deloitte's State of AI in the Enterprise survey of 3,235 business and IT leaders across 24 countries.
Are open-weight models good enough to build sovereign capability on?
For the workloads organisations actually deploy — internal assistants, document analysis, retrieval over institutional knowledge, drafting, translation, coding support — yes, comfortably. A 32B-class model on a single card handles most of it, and open models in the 120B class reach frontier-adjacent benchmark territory on two server GPUs. Hosted frontier models retain an edge on the hardest reasoning tasks. The sensible posture is to pilot with your own documents and measure, rather than assuming either that open models are inadequate or that they are equivalent.
Can we get sovereignty without buying hardware?
Partly. Renting GPUs from an operator incorporated in your jurisdiction, running open weights you supply, gets you weight sovereignty, data locality, and a good deal of operational control without a capital purchase. What you do not get is independence from that operator's continued existence and terms. For many organisations that is an acceptable trade, especially as a first step — the important thing is that because you hold the weights, moving to owned hardware later is a migration rather than a rebuild.
What is the single most important thing to do first?
Archive the weights and tokenizer of any model you depend on, with a checksum, somewhere you control. It costs almost nothing, takes an afternoon, and it is the one step that converts "we use an open model" into "we can still run this if the internet, the publisher, or the licence changes." Everything else in a sovereignty programme is easier once that is true.