Sovereignty-Washing

The term "sovereign AI" has arrived in enterprise technology the same way "sustainable" arrived in consumer goods a decade ago — fast, everywhere, and largely undefined. Every major cloud provider now offers a sovereign tier. Every infrastructure vendor has added the word to their positioning. Every government partnership announcement carries it in the headline.

This is not a coincidence. Sovereignty is what European enterprises want right now. And where there is demand, there is marketing.

The problem is not that these vendors are lying. The problem is that sovereignty is a spectrum, and most of what is being sold sits at the convenient end of it — the end that satisfies a procurement checkbox without changing the underlying architecture in any meaningful way. The result is a growing gap between what enterprises believe they are buying and what they actually have.

This piece is about closing that gap.

The Distinction That Matters

Before identifying the signs of sovereignty-washing, it helps to be precise about what sovereignty actually means in the context of AI infrastructure.

Sovereignty is not a compliance status. It is not a contractual arrangement. It is not a data residency policy or a localised instance of a foreign platform. These things can be components of a sovereign setup, but none of them constitute sovereignty on their own.

Sovereignty — genuine sovereignty — is the condition in which an organisation retains full, unilateral control over every layer of the AI stack: the hardware it runs on, the jurisdiction it operates within, the audit trail it generates, and the ability to continue operating without the permission, cooperation, or goodwill of any external party.

The test is not "where is my data stored?" The test is "can someone else turn this off?"

If the answer is anything other than a definitive no, the setup is not sovereign — regardless of what the contract says.

The First Sign: Conflating Storage With Processing

The most common form of sovereignty-washing begins with a sleight of hand that most procurement teams never catch. Vendors describe where data is stored. They do not describe where it is processed.

These are not the same thing.

Data at rest in a Frankfurt data centre is a storage question. Data being processed — passed through an inference pipeline, fed into a model, returned as an output — is a different question entirely, and it is where the meaningful exposure occurs. A model that processes data on infrastructure controlled by a foreign entity creates a jurisdictional dependency regardless of where the resulting output is stored.

When evaluating any sovereign AI claim, the first question to ask is not "where does the data live?" but "where does the inference happen, and who owns that infrastructure?"

The Second Sign: Contractual Sovereignty

The second pattern is more sophisticated and therefore more dangerous. Vendors who cannot offer genuine architectural sovereignty instead offer contractual sovereignty — a set of promises, policies, and data processing agreements designed to create the impression of control without actually transferring it.

Contractual sovereignty has real value in certain contexts. A well-drafted DPA reduces legal exposure. Data residency commitments matter for regulatory compliance. These instruments are not worthless.

But they are revocable. A policy can be rewritten. A contract can be renegotiated. A vendor can be acquired, sanctioned, or subject to a court order in a jurisdiction that does not recognise the protections your legal team negotiated. The history of cloud computing is full of examples where contractual assurances turned out to be contingent on circumstances nobody anticipated at signing.

Architectural sovereignty — hardware your organisation owns, in a facility your organisation controls, running software your organisation can operate independently — cannot be revised by a vendor's legal team. That is the distinction that matters when the stakes are high enough to matter.

The Third Sign: European Infrastructure, Foreign Jurisdiction

Perhaps the most persuasive form of sovereignty-washing is the offering that combines genuinely European data centres with a corporate structure that remains subject to foreign law.

This arrangement is not hypothetical. It is the current model of every major hyperscaler operating in Europe. The data centres are real. The European locations are real. The staff operating them may be European. None of this changes the legal reality.

The CLOUD Act, for example, grants US authorities the ability to compel US-incorporated companies to produce data held on their infrastructure — regardless of where that infrastructure is physically located. An enterprise running AI on a European instance of a US-owned platform is not outside the reach of that legislation. The physical address of the server does not determine the jurisdiction of the entity that owns it.

This is not a theoretical risk. It is the structural condition of every enterprise that has conflated geographic proximity with legal independence. Before accepting any sovereign AI claim, the question of corporate ownership and legal jurisdiction deserves the same rigour as the question of data location.

The Fourth Sign: Opacity as a Feature

Genuine sovereignty comes with visibility. Every model call, every data path, every cost should be observable and auditable by the organisation that owns the infrastructure. This is not a luxury feature — it is the operational definition of control.

Sovereignty-washing tends to produce the opposite condition. Enterprises find themselves dependent on vendor dashboards for visibility into their own AI operations. Audit logs are available, but only through interfaces controlled by a third party. The organisation can see what the vendor chooses to show them.

This matters acutely at the moment of a compliance audit, when a client or regulator asks for a complete record of how their data was handled. The inability to produce that record independently — without relying on a vendor's cooperation — is not a minor operational inconvenience. It is a structural dependency that sits at the centre of what sovereignty is supposed to eliminate.

If your AI infrastructure cannot be fully audited without the involvement of a third party, the control you believe you have is conditional on that third party's continued cooperation. That is not sovereignty.

How to Apply This in Practice

The four patterns above — storage conflated with processing, contractual promises substituted for architectural reality, European geography obscuring foreign jurisdiction, and visibility mediated through third-party interfaces — do not require a technical specialist to identify. They require the right questions.

Ask your vendor where inference happens, not just where data is stored. Ask what would change if they were acquired tomorrow. Ask whose legal team would respond to a government request for your data. Ask whether you can produce a complete AI audit log without their involvement.

The answers will tell you more than the marketing materials.

Sovereignty-washing will not disappear as long as enterprises are willing to accept contractual assurances in place of architectural ones. The demand for genuine sovereignty is real — but so is the incentive to sell something cheaper and call it the same thing.

The question worth sitting with is this: if you had to demonstrate, to a regulator or a major client, that your AI infrastructure operates entirely within your control and your jurisdiction — could you do it today, and could you do it without calling your vendor first?

Your hardware, your building, your jurisdiction. If the question above gave you pause, we're worth a conversation.