Every so often, a routine service disruption doubles as a lesson. When access to a widely-used AI capability was abruptly cut for some users, most people experienced it as an inconvenience. For anyone responsible for critical infrastructure, it should have landed differently: a capability you depend on, but do not control, can be withdrawn — and you will not choose the timing.
Rented capability is not sovereign capability
This is not an argument against commercial software or foreign suppliers. It is an argument about where the control point sits. When the capability runs on someone else’s platform, under someone else’s terms and jurisdiction, three things are true at once:
- It can be repriced (see: Broadcom/VMware).
- It can be relicensed (see: HashiCorp/Vault).
- It can be withdrawn or degraded (see: any number of service and sanctions events).
None of those are hypothetical anymore. Each has happened to organizations that had built on the assumption of continuity.
The defense stakes are higher
For a consumer app, a withdrawn capability is an outage. For a command system, a classified workload, or critical national infrastructure, the same event is an operational failure — and it tends to arrive precisely during the crisis the system was supposed to help manage. That is why, for these environments, the sovereignty question is not about datacenter location. It is about who can switch it off.
What “control” actually requires
The practical answer is unglamorous and durable: run the things that matter on open source you can audit, self-hosted on infrastructure you operate, with no foreign root access. That is not a slogan — it is a checklist you can hold a vendor to, and it is the entire basis of this platform.
If a supplier relationship ends tomorrow, sovereign infrastructure keeps running. That is the whole point.
Read the sovereignty-washing test for the five questions we use to separate real sovereignty from the marketing kind.