Sovereign Cloud vs On-Premises AI: What Regulated Buyers Should Evaluate

Two things changed the sovereignty conversation in the first half of 2026. In January, AWS declared general availability of the AWS European Sovereign Cloud with a first region in Brandenburg, operated through EU-resident staff and a European parent structure. In February, Microsoft extended its Sovereign Private Cloud so that large AI models can run on Foundry Local in fully disconnected environments. Sovereign cloud stopped being a slide and became something a procurement team can actually buy.

That is good news, and it makes the buying decision harder rather than easier. “Cloud or on-premises” was never the real question. The real question is which specific sovereignty control a given AI workload requires, and which delivery model supplies it at an acceptable cost.

Sovereign cloud is now three different products

The term covers at least three delivery shapes, and they do not offer the same guarantees.

Sovereign public regions run in the provider’s own data centres inside a declared geopolitical boundary, with data residency, customer-managed keys, restricted operator access, and access logging. The AWS European Sovereign Cloud is the strongest current example of this shape: physically and logically separated from other AWS regions, with a European governance structure and more than 90 services at launch.

National or partner-operated clouds place operations with a domestic partner. Microsoft calls these National Partner Clouds, with service scope and rollout sequencing that differ from the global platform. The European Commission’s own €180 million sovereign cloud award went to four consortia of this type — Post Telecom with OVHcloud and Clever Cloud, STACKIT, Scaleway, and Proximus with S3NS, Clarence and Mistral.

Sovereign private or disconnected clouds run provider software on customer or partner premises. Microsoft’s Sovereign Private Cloud is delivered through Azure Local, Microsoft 365 Local, GitHub Enterprise Local, and Foundry Local, and is positioned for defence, critical infrastructure, and national security scenarios where the control plane must remain local.

Only the third shape resembles on-premises AI in its threat model. The first two are supplier-operated environments with stronger contractual and technical assurances than a standard region.

The Commission gave buyers a scoring vocabulary

The most useful procurement development is not a product at all. The Cloud Sovereignty Framework translates sovereignty into measurable criteria across eight objectives — strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability — and scores each with Sovereignty Effectiveness Assurance Levels from SEAL-0 to SEAL-4.

The levels matter more than the labels. SEAL-2 corresponds to data sovereignty. SEAL-3 adds resilience against non-EU supply chain disruption. SEAL-4 implies an EU supply chain from chips to software. In the Commission’s own tender, three consortia were assessed at SEAL-3 and one at SEAL-2 — a reminder that even purpose-built European providers land on a scale rather than a binary.

Borrow the structure even if you are not a public buyer. Ask which objective your risk committee is actually trying to satisfy, then ask each candidate — hyperscaler, national partner, or on-premises platform — to evidence that objective specifically. It ends the unproductive argument in which one side means “data stays in Frankfurt” and the other means “no foreign legal process can reach it.”

Where the models genuinely differ

Notice what the table does not say. It does not say sovereign cloud is insecure — the engineering behind these regions is serious, and confidential computing plus external key management genuinely narrows operator access. It says the trust chain is different. In a provider-operated environment, sovereignty is a set of commitments you verify. In an enterprise-operated environment, it is a property of where the machines are and who holds the credentials — with the corresponding obligation to run them competently.

Residency and sovereignty blur together in most procurement documents, and the difference is worth settling before the vendor conversation starts; our procurement guide sets out the questions that separate them.

The AI-specific questions generic cloud sovereignty misses

A sovereignty assessment written for storage and compute will pass an AI platform that leaks in five other places. Add these to the checklist:

• Where inference runs versus where data rests. A document can sit in an EU region while the model serving the request runs elsewhere, or while a managed AI service pre-processes content in a shared control plane. Ask for the inference topology, not the storage topology.
• Model provenance and licence terms. Which weights are used, under which licence, updated on whose schedule, and can a specific version be pinned for the life of a regulated workload? Open-weight licensing is a procurement question, not an engineering footnote.
• Prompts, embeddings, and logs. Embeddings derived from confidential documents inherit their sensitivity. Vector stores, prompt caches, evaluation datasets, and trace logs all need the same residency treatment as the source corpus.
• Agent tool calls. An agent that runs in a sovereign region but calls a non-EU SaaS API has moved the data anyway. Tool inventories belong in the sovereignty review.
• Telemetry. Establish in writing what usage data leaves the boundary, in what form, and whether it can be disabled entirely.
• Oversight evidence. Under the EU AI Act, deployers of high-risk systems carry obligations around oversight, monitoring, and record-keeping. Those records need a home that survives a change of provider.

Decide per workload, not per company

Enterprises that make one platform-wide decision usually over-buy for the routine work and under-protect the sensitive work. A three-tier split holds up better in practice.

Tier 1 — public or sovereign cloud AI. Marketing content, public documentation, general research, code that is already open. The value of elasticity outweighs the exposure.

Tier 2 — sovereign cloud with strict controls. Internal but non-regulated material: project documents, general knowledge bases, HR policy text. Customer-managed keys, EU-resident operations, and a documented tool inventory are proportionate here.

Tier 3 — on-premises or disconnected. Case files, underwriting and claims material, patient records, investigation notes, source code, board and legal correspondence, and any workflow that must keep running during a connectivity or supplier disruption. The air-gapped and restricted-network patterns apply here.

Then insist on one governance layer across all three tiers. The failure mode is not choosing the wrong tier for a workload — it is running three different control planes with three different audit formats and no way to answer a supervisor’s question about a decision made last quarter. Cost comparisons should follow the same discipline; the on-premises TCO guide sets out what to include on both sides of the ledger.

How VDF AI fits

VDF AI is built for tier 3 and for the governance layer that spans all three. The platform runs inside enterprise infrastructure — data centre, private cloud, or restricted network — with local model hosting, private RAG over enterprise repositories, model routing constrained by data classification, and execution traces that stay in the customer’s custody.

That does not make sovereign cloud the wrong answer for everything else. It makes the boundary explicit: workloads whose inputs are the sensitive asset stay inside, workloads whose inputs are already public can use elastic capacity, and one governance model records what happened in either case.

The organisations that handle the next supervisory review well will not be the ones that picked the most sovereign-sounding vendor. They will be the ones that can show, workload by workload, which control they required and how it is evidenced.