What Clients Mean When They Say Sovereignty
Sovereignty has become one of the most common requirements in AI and digital procurement. The problem is that the word usually describes several different concerns at once.
A few weeks ago I found myself in a familiar conversation. A client wanted a sovereign AI solution. Another wanted sovereign cloud infrastructure. A third wanted sovereign data storage. All three used the same word. None meant exactly the same thing.
The longer I work around AI, cloud infrastructure, and digital transformation, the less convinced I become that sovereignty is something an organisation either has or lacks. More often it is a bundle of separate concerns compressed into a single word, and that compression matters. Procurement decisions get made on it. Budgets get allocated around it. Entire technology strategies can start from it. Yet when you ask what sovereignty actually means in a given conversation, the answer turns out to be less obvious than everyone assumes.
Four things hiding inside one word
Sovereignty sounds precise. It isn't. In practice, people use it to describe at least four different things: legal sovereignty, operational control, technological independence, and security and resilience. These overlap, but they are not the same, and an organisation can improve one while making another worse. That is where most sovereignty discussions quietly lose their footing.
Legal sovereignty
This is usually the concern that surfaces first in government organisations and regulated sectors, and the question behind it is straightforward: who ultimately has legal authority over the systems and data we depend on. This is where conversations about European providers, data residency, foreign jurisdictions, and extraterritorial legislation come from.
When someone asks whether a solution is sovereign, this is often what they mean: not whether it runs on their own servers, not whether they wrote the software themselves, but whether the critical parts of their operation sit under a legal framework they trust.
Critics argue that the scoring model may still favour incumbent hyperscalers, because jurisdictional exposure can be offset by high scores in other domains. The Commission’s own tender outcome illustrates the nuance: one winning consortium relied on S3NS, a Thales and Google Cloud joint venture, and still met the minimum sovereignty threshold.
Operational control
A different question sits underneath the first: who actually operates the system. Many organisations slide from sovereignty into self-hosting without quite noticing the shift. The reasoning sounds logical: if we run it ourselves, we control it ourselves. Sometimes that is true. Often it understates what running something yourself actually costs.
I felt this in miniature on my own infrastructure. I recently put Cloudflare in front of this blog, for DNS, caching, performance, and basic protection. It immediately gave me more control and better functionality. But it also added a new operational layer: settings to understand, security choices to make, logs to interpret, and failure modes that now partly sit with me. That is the practical side of sovereignty that is easy to underestimate.
Bringing a function closer to yourself does not remove dependency; it changes its shape. You gain options, but you also inherit responsibility. Operational control is real. It is valuable. But it is not free, and it should not automatically be confused with sovereignty.
Technological independence
This is where the conversation gets uncomfortable, because most organisations asking about AI sovereignty already made their largest dependency decision years earlier, when they chose a productivity ecosystem. Microsoft. Google. Sometimes both. By the time AI enters the discussion, email, identity management, documents, calendars, and workflow automation are already deeply embedded in that environment, and the AI layer inherits those choices rather than making new ones.
That does not mean organisations are trapped. It means sovereignty is less often a single procurement decision and more often a long history of accumulated dependencies, most of which were never evaluated as dependencies at the time. The useful question stops being whether a system is sovereign and becomes which dependencies are acceptable, which are strategic, and which an organisation would genuinely like to reduce over time.
Security and resilience
Security is perhaps the most misunderstood part of the conversation, because many people intuitively assume that more sovereignty produces more security. The relationship isn't that simple. A highly sovereign system can be poorly secured. A highly dependent one can be extremely well protected.
A small organisation running its own infrastructure may have complete control over it and still be less safe than a professionally managed cloud platform, because security depends on expertise, investment, monitoring, and people, none of which sovereignty supplies on its own.
A spectrum, not a destination
The longer I work with organisations on digital and AI strategy, the less useful I find the idea of sovereignty as a binary state. Almost nobody is fully independent. Almost nobody is fully dependent. Organisations occupy different positions on a spectrum, make trade-offs, accept some dependencies, and reduce others where it matters most. That is true for governments, for companies, and for Europe as a whole, where sovereignty has come to mean something closer to strategic autonomy, the freedom to choose your dependencies, than to self-sufficiency.
The most useful sovereignty conversations, then, are not about achieving independence. They are about understanding dependencies: which ones an organisation accepts consciously, which it can still change, and which it simply inherited without ever deciding on them at all.