A lot of the discussion around sovereign compute still treats ownership like it’s binary: either you own the stack or you don’t. But ownership is a poor measure of sovereign compute. In practice ownership can sit on top of many many dependencies, which can matter more in practice than who technically owns the hardware.
You can own the machines and still need someone else to patch them. You can own the model weights and not really have the people or infra to keep the thing useful. You can keep all the data “sovereign” and still depend on outside services for the system to actually work. So maybe the better test is, can you break the dependency when you need to? If you switch suppliers, what gets stranded? What data, workflows, tacit knowledge, whatever, gets left behind? Can you actually see what the system is doing well enough to control the important parts of it?
There’s a weird failure mode on the other side too. If sovereignty means rebuilding absolutely everything yourself, you eventually end up recreating whole research ecosystems, tooling, infra, expertise, etc, and at some point that starts making you weaker. You learn from a smaller pool, move slower, miss stuff happening elsewhere.
So I think the more useful version of sovereignty is something like: dependency is fine, as long as it stays reversible. You can rely pretty heavily on outside providers and still have decent sovereignty if none of them can suddenly turn that reliance into leverage over whether you can keep operating, keep what you’ve learned, or leave. That seems way more real than saying “we own the servers” and calling the problem solved.