Sovereign is not an address

Sovereign Is Not an Address

Sovereign is not an address

This week an analyst firm read the small print of 35 "sovereign AI" providers, and a chip CEO toured Europe telling governments what sovereignty really means. Put the two side by side and you get a simple, slightly uncomfortable conclusion: for most organizations, sovereignty is not a place you buy. It is something you have to be able to operate.

What did the small print actually say?

Omdia published "Sovereign AI: A Playbook for Success" on October 14. The interesting part is not another survey of intentions, because the analysts did something far less glamorous and far more useful: they went through the terms of service, the SLAs, the data processing agreements, the privacy practices and the certifications of 35 providers in 20 countries, from frontier AI labs and hyperscalers to datacenter operators, neoclouds and telcos. In other words, they read the documents most buying committees skim on the way to signature.

The findings are not subtle. 28% of the providers disclose no proof at all for their sovereignty claims, and some expect the customer to pay for the audit that would verify them. Eight in ten contracts state that network resilience is outside the provider's control or responsibility. Two thirds limit compensation for non-performance to service credits, and vague "best efforts" language is widespread. Omdia's own summary is that the word sovereign is often "little more than a marketing adjective" meaning local assets.

And then the detail that will annoy a few people on this side of the Atlantic: according to Omdia, US-headquartered providers generally offer better service transparency and contract terms than most of the local "sovereign" providers. Yes I know, that is not the story we like to tell ourselves in Europe. But it is a finding from reading contracts, not from reading press releases.

Omdia sovereign AI findings: 28% no proof, 8 in 10 contracts exclude network resilience, two thirds service credits only, up to 45% of large enterprises plan to add or replace an ICT supplier

So who owns sovereignty, the landlord or the operator?

The same week, Fortune covered Jensen Huang's trip through Paris and London, where NVIDIA has been busy investing in and talking about sovereign AI. His line was short: "So long as you can operate the service yourself, that's the most important." In the article's summary of his view, sovereignty depends on who controls the data, the services and the ability to advance the technology, not on where the chips are made.

Let's be clear about the self-interest here. According to Fortune, NVIDIA's sovereign AI revenue tripled to more than 30 billion dollars in its last fiscal year, so nobody should mistake this for a neutral academic position. But the sentence itself is right, and honestly it is the most useful definition of sovereignty I have heard from a chip CEO in a while. Not where. Who can operate.

Put that next to the Omdia numbers and the picture gets sharp. If eight in ten contracts push network resilience outside the provider's responsibility, then the question "where is my data?" is answered by the datacenter address, but the question "who keeps my service running when it matters?" is answered by nobody in particular. That is not sovereignty. That is a postal code with a nice logo.

Isn't regulation going to sort this out?

Partly, and later. The European Commission proposed the Cloud and AI Development Act in June as part of its tech sovereignty package, with four assurance levels for cloud providers. The lowest level is essentially about data being processed and stored in infrastructure in the Union. The higher levels move into independence from third countries, ownership and control, and transparency over the software supply chain.

I think the structure is the right one, because it admits openly what the marketing usually hides: location is level one, not the finish line. But a framework for certifying providers does not answer the question that sits inside your own organization. Even a perfectly certified provider cannot operate your runbooks, decide your recovery order or explain to your auditor what your AI agent did last Tuesday. Regulation can make the label more honest. It cannot make you operationally capable.

And there is a timing problem. Omdia says up to 45% of large enterprises plan to add or replace an ICT supplier for sovereignty or compliance reasons within the next 18 months. Those decisions will be made long before any assurance level becomes everyday procurement routine, so they will be made on what buyers can verify themselves. Or on what they are told.

What does sovereignty look like if you have to operate it?

I would describe it as four layers, and most "sovereign" offerings stop after the first one.

1. The address. Where the data sits and where the compute runs. Important, necessary, and the easiest layer to sell, because you can put it on a map. This is where most of the current marketing lives.

2. The contract. Who is responsible when something fails, what the provider actually commits to, and what you get when they do not deliver. Omdia's numbers say this layer is weak more often than not. A service credit is a discount on your next invoice, not a recovery plan.

3. The operation. Who can run, patch, scale, isolate and if necessary switch off the service. This is Huang's point, and it is the layer that decides whether you can act in a crisis or only file a ticket. If the honest answer is "only the provider can do that", then your sovereignty is exactly as strong as their roadmap and their staffing on a bad weekend.

4. The evidence. Whether you can prove, after the fact, what happened: who accessed what, which model or agent did what, in what sequence and under whose authority. This layer is new for AI, and it is where many organizations are weakest right now. A SecurityHQ survey of 204 security leaders, published this week (a vendor study, so read it as such), found that only 49% could fully reconstruct every action their AI agents performed over the last 30 days, and only 17% could do it within minutes after a critical incident. If you cannot replay it, you cannot defend it, not to a regulator and not to your own board.

The uncomfortable part is that layers three and four are not something you buy from a provider. They are capabilities you build, staff and test. A provider can make them easier or harder, and that is a perfectly valid selection criterion, but the capability itself sits with you.

Does that mean everything has to come back in-house?

No. And I would be careful with anyone who tells you that, including people in my own industry. I have spent more than 20 years in VMware architecture, so of course I believe a well-run private cloud is a strong foundation for private AI. But a badly run private cloud is not more sovereign than a well-contracted public one, it is just closer. Owning the hardware without the operating capability gives you the address and maybe the contract, and leaves you exactly as exposed on operation and evidence.

The useful question is not "public or private", "US or European". It is: for this workload, with this data, which of the four layers do we actually need, and can we demonstrate each one? For a marketing chatbot, layer one and a decent contract may be plenty. For an AI agent with write access to your financial systems, you probably need all four, and you need to be able to show them in an afternoon, not in a project.

That is also where Omdia's comparison becomes interesting rather than awkward. If the global providers often have the better contracts and the local providers often have the better address, then the sovereign answer for many organizations is a combination they design themselves: deliberate placement, negotiated terms, and an operating model that keeps the critical controls in their own hands. That is architecture work, not a procurement checkbox.

What should IT leadership ask before the next "sovereign" signature?

Five questions, and I would want each answer in writing, not in a slide:

  • Proof: What evidence does the provider give for the sovereignty claim, and who pays for verifying it? If the answer is "trust us" or "your auditor, at your cost", write that down as a risk.
  • Resilience: Who is contractually responsible for network resilience end to end? If it is excluded, who in your organization owns that gap?
  • Remedy: What happens beyond service credits when the service fails during an incident that matters to you?
  • Operation: Which actions can your own team perform without the provider: isolate, patch, restore, switch off? Test at least one of them before go-live.
  • Evidence: Can you reconstruct what an AI model or agent did over the last 30 days, and how long would it take after a real incident? Minutes, hours or days is a design decision, not a surprise.

None of these questions requires new regulation, a new budget line or a new vendor. They require someone to decide that "sovereign" on the cover page is not an answer, it is a claim to be checked.

Final thoughts...

The sovereignty debate in Europe has spent a lot of energy on flags: whose company, whose chips, whose datacenter. All of that matters to some degree. But this week's numbers say the bigger gap is somewhere else. It is in contracts nobody reads and in operating capabilities nobody tested. An address is easy to buy. The ability to run, recover and explain your own services is not, and it is the only kind of sovereignty that still works on a bad day.

So decide which workloads truly need it, build the capability for those, and stop paying a premium for an adjective on everything else. #DecideOrGoHome

At comdivision we spend most of our time designing and operating private cloud and private AI platforms, which is exactly where the operation and evidence layers are built. If you want to talk through what sovereignty means for your own workloads, reach out to me.

Sources

Related News

dummy_contact-banner_get-in-touch

Questions? Get in touch!

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus.