Sovereignty Is a Stack, Not a Download
POLICY BRIEF – Infrastructure and decision authority. Research current to 19 July 2026. This brief proposes a planning framework, not a legal definition of technological sovereignty.
The strongest argument for open-weight AI fits in one sentence: once the weights are running on your own infrastructure, the provider cannot switch off your API account.
That is real independence.
It is also one layer of a much larger dependency structure.
A government, bank, hospital, or critical-infrastructure operator can download a model and still depend on foreign accelerators, proprietary networking, external serving software, scarce engineering talent, vendor updates, uncertain licences, imported energy equipment, and training data it cannot reconstruct.
Local hosting is therefore neither fake sovereignty nor full sovereignty. It is a specific transfer of control that must be located inside the stack.
Five kinds of sovereignty
The word becomes more useful when decomposed.
1. Data sovereignty
Can sensitive prompts, documents, embeddings, logs, and outputs remain within the organisation’s chosen legal and physical boundary?
Local inference can provide a strong answer. It avoids sending operational data to an external model API and permits local retention and deletion rules.
It does not establish where the model’s training data came from or whether local telemetry still reaches upstream software providers.
2. Operational sovereignty
Can the organisation keep the system running if the original provider withdraws service, changes price, alters an endpoint, or exits the jurisdiction?
Downloaded weights and a stable local deployment improve operational continuity. But continuity also depends on replacement hardware, patches, security response, serving engines, and staff able to operate the system.
3. Model sovereignty
Can the organisation inspect, preserve, modify, fine-tune, evaluate, and replace the model?
Open weights support these actions. Training transparency, data information, and permissive licensing strengthen them. A model too large to evaluate independently may remain formally modifiable but practically opaque.
4. Infrastructure sovereignty
Can the organisation obtain the chips, memory, networks, energy, facilities, cooling, and software needed to run the model at the required scale?
This is where many sovereignty claims fail. Stanford’s 2026 AI Index reports that the United States hosts 5,427 data centres, more than ten times any other country, while the leading-chip supply chain remains heavily dependent on a small set of firms and one Taiwanese foundry.
The weights may be portable. The means to run them are not evenly distributed.
5. Decision sovereignty
Can the institution decide whether, where, and how the model enters a consequential process, and can it reverse that decision without losing the service it exists to provide?
This is the layer most often omitted. A technically local system can still govern the institution if no one understands its dependencies, no credible alternative exists, and stopping it would halt a public or critical function.
Decision sovereignty requires a real exit option.
The sovereignty ladder
| Level | Control achieved | Dependency that remains |
| 0. Hosted API | use of a capability | provider controls access, version, price, monitoring |
| 1. Multi-provider interface | some switching ability | providers and compatible endpoints |
| 2. Downloaded weights | possession and local execution | licence, hardware, tools, expertise |
| 3. Domestic deployment | local data path and operations | imported chips, software, maintenance, updates |
| 4. Modifiable documented stack | deeper inspection and adaptation | training cost, data, talent, upstream components |
| 5. Substitutable critical stack | credible exit and continuity | residual global interdependence |
The goal is not autarky. No advanced AI ecosystem is independent of every international supplier. The goal is to know which dependencies are acceptable, which are concentrated, and which can terminate the institution’s ability to decide.
The kill-switch inventory
An API kill switch is only the most visible control point. A sovereignty assessment should identify every actor able to stop, degrade, or legally disable the deployment.
Potential control points include:
model-provider accounts and authentication;
cloud tenancy and regional service availability;
model and software licences;
export controls and sanctions;
accelerator supply and replacement parts;
proprietary drivers, compilers, and serving software;
energy and network contracts;
security updates and vulnerability disclosure;
key personnel and external support contracts;
standards or procurement rules that determine admissibility.
For each control point, record the actor, authority basis, trigger, notice period, technical mechanism, affected services, and available remedy.
This turns “sovereignty” from a slogan into a dependency map.
Four tests before calling a deployment sovereign
The continuity test
If the original provider disappeared tomorrow, how long would the system continue at the required service level?
The answer should include hardware failure, security patching, model updates, and staff coverage, not only whether the weight files remain on disk.
The substitution test
Can the organisation move the workload to another model or stack? How long would migration take, which functions would be lost, and what data or workflow changes would be required?
A theoretical alternative that takes eighteen months to integrate is not an immediate exit.
The inspection test
Can competent internal or independent reviewers reconstruct the model version, configuration, data path, evaluations, tools, and decision role?
Local opacity is still opacity.
The refusal test
Can an accountable official or body stop or narrow the model’s role without retaliation, mission collapse, or an unmanageable loss of service?
This is the institutional equivalent of the Institute’s Ceremonial Human test. Formal authority to stop is meaningless if exercising it is operationally impossible.
Procurement must record dependence before deployment
Public and regulated procurement should require a pre-deployment dependency record covering:
model and version identity;
access type: API, dedicated hosting, or weights;
final licence and jurisdiction;
minimum and realistic infrastructure requirements;
upstream hardware and software dependencies;
data and telemetry routes;
update, support, and vulnerability process;
replacement model and migration plan;
decision authority for admission, suspension, and re-admission;
review date, expiry, and public disclosure layer.
This is not a new ethics checklist. It is an admissibility record for dependence.
Implications for Poland and Europe
Europe should not have to choose between an American API dependency and a Chinese weight dependency as if those exhausted the policy space.
A resilient strategy can combine:
domestic and European compute capacity;
open-weight models from multiple origins;
European and local-language model development;
enforceable procurement portability;
independent evaluation and red-teaming;
strategic inventories of hardware and software dependencies;
common records for model admission and withdrawal;
participation in international standards without exclusive stack lock-in.
The immediate policy objective is not to build every layer domestically. It is to prevent any unrecorded layer from becoming the place where effective authority silently moves.
The decision rule
Do not ask whether a model is sovereign.
Ask which control has moved to the deployer, which control remains upstream, who can exercise it, and whether the institution can continue to decide when that control is used.
Sovereignty is not possession of a file. It is a maintained capacity to choose, operate, refuse, migrate, and remain accountable across the stack.
Sources
Stanford HAI, 2026 AI Index: Research and Development.
Stanford HAI, 2026 AI Index: Policy and Governance.
European Commission, Commission signs Pax Silica declaration, 25 June 2026.
Open Source Initiative, The Open Source AI Definition 1.0.
UK AI Security Institute, Frontier AI Trends Report.
This is Article 5 of Open-Weight Power: Models, Access, and the Emerging AI Order.
