Sovereign AI vs Private AI: Which One Your Enterprise Actually Needs

Two questions hiding inside one buzzword

Procurement teams in regulated organisations hear “sovereign” and “private” used as if they meant the same thing. Each answers a different worry from a different person in the room.

The general counsel and the data protection officer usually ask the sovereignty question: if a foreign court or agency demands our data, can our supplier be forced to hand it over, and would we even be told? That is a question about legal jurisdiction, corporate ownership and who holds operational control.

The CISO and the head of data usually ask the privacy question: can anyone outside our organisation see our prompts, documents and outputs, and can any vendor use them to improve its models? That is a question about infrastructure, network boundaries, tenancy and contract terms.

The two answers can diverge. The formal definition is in our glossary entry on sovereign AI; this article covers how the two ideas differ when you write requirements and score vendors.

Sovereign AI vs private AI: where they overlap and where they split

The quickest way to see the difference is to place real deployment options against both tests.

Two cells deserve attention because buyers get them wrong most often.

Sovereign-branded but not private to you. A sovereign cloud region narrows who can reach your data, through EU-resident staff, local legal entities and customer-managed keys. It is still a multi-tenant service run by the provider, and if you use its managed AI services, the provider’s software processes your prompts. That may be acceptable. It is a different promise from “nobody outside our organisation touches this.”

Private but not fully sovereign. An on-premises deployment keeps prompts and documents inside your walls, which makes it sovereign for the data. The stack around that data may still have foreign dependencies: open-weight models published by companies in the US or China, GPUs subject to US export controls, a software vendor whose support engineers connect from another country, or a licence server that must be reachable for the software to start. Each of those is a sovereignty question even when the privacy answer is perfect.

Why the CLOUD Act sits at the centre of the sovereignty question

The US Clarifying Lawful Overseas Use of Data Act was enacted in March 2018. Its effect, as commonly read by lawyers, is that a provider subject to US jurisdiction can be compelled to disclose data in its “possession, custody, or control” regardless of where the data is stored. The US Department of Justice describes the law’s purpose as reaching electronic evidence wherever it happens to be located.

So storage location alone does not settle sovereignty. In a June 2025 hearing before the French Senate, Microsoft France’s general counsel said under oath that he could not guarantee French public-sector data would never be passed to US authorities without French consent, while adding that it had not happened to date (as reported by heise online in July 2025). The structural point applies to any provider with a US parent, and similar questions apply to providers under other non-EU jurisdictions.

For a buyer, the practical test is simple to state: who is the legal entity that operates the system, who ultimately owns it, and which governments can compel it? If the answer is “us, in our own country,” the CLOUD Act question largely disappears for the data you hold.

Sovereign AI vs AI sovereignty

Search for “sovereign AI” and much of what comes back is about countries. That is AI sovereignty: a national goal of owning more of the AI supply chain. Recent examples, as of October 2026:

• European Union. The Commission’s AI Continent Action Plan (April 2025) built on the InvestAI initiative to mobilise €200 billion for AI. On 30 July 2026 the Commission opened the call for up to seven AI gigafactories, with up to €10 billion of EU and national funding expected to unlock around €20 billion of private investment; the call closes on 12 November 2026. On 3 June 2026 it proposed the Cloud and AI Development Act (COM(2026) 502), which includes an EU-wide assessment framework for cloud and AI sovereignty. That proposal is still going through the legislative process.
• European Commission procurement. The Commission’s own Cloud Sovereignty Framework scores providers on eight objectives, from legal jurisdiction to supply chain, using assurance levels from SEAL-0 to SEAL-4. In April 2026 it used the framework to award €180 million of sovereign cloud contracts to four European providers.
• United Kingdom. The government launched its £500 million Sovereign AI Unit on 16 April 2026. It invests in UK AI companies and gives them compute, faster visas and early procurement routes.
• India. Sarvam, a Bengaluru company that builds its own foundation models and presents itself as a full-stack sovereign AI provider, reached a reported $1.5 billion valuation in June 2026 after a funding round led by HCLTech.

NVIDIA, whose chips sit under most of these programmes, describes national AI capability as domestic AI infrastructure combined with local data, a local workforce and a local business ecosystem.

None of this makes a given enterprise deployment sovereign. National programmes increase the supply of local compute, local models and local operators, which gives buyers more options to choose from. The question for your organisation remains narrower: does the specific system you are buying meet the jurisdiction and control requirements your regulator or board has set? Our comparison of data sovereignty and data residency in AI procurement goes deeper on the difference between “stored in-region” and “controlled in-region.”

The decision table: which requirement calls for which

Most AI requirements documents mix sovereignty and privacy requirements without labelling them. Sorting them first stops the team from over-buying for one and under-buying for the other.

The “export controls” row is a moving target. The US rescinded its AI Diffusion Rule for advanced chips in May 2025 and said it would replace it, so check the rules in force at each hardware purchase. Rows marked “both” are where on-premises or private-cloud deployment is often simplest, because one design choice settles two requirements.

What the big sovereign cloud offerings give you (October 2026)

The three largest US cloud providers all now sell sovereign variants. Each is useful for some workloads. Measured against the private-AI test, they fall into the same pattern.

• AWS European Sovereign Cloud became generally available on 15 January 2026 with a first region in Brandenburg, Germany. AWS says it is physically and logically separate from other AWS regions, run through a new EU parent company and German subsidiaries, and operated exclusively by EU residents, with sovereign local zones planned for Belgium, the Netherlands and Portugal. It is still a shared service operated by an Amazon group company.
• Microsoft Sovereign Cloud comes in three forms: a Sovereign Public Cloud in Microsoft-operated EU datacentres, a Sovereign Private Cloud that runs Azure Local, Microsoft 365 Local and Foundry Local in customer or partner datacentres with disconnected operation supported, and National Partner Clouds run with an approved domestic partner, whose service scope can differ from global Azure.
• Google Cloud offers Data Boundary in the public cloud, Google Cloud Dedicated operated by an independent regional partner (in France, S3NS offers it as PREMI3NS, which Google says holds ANSSI’s SecNumCloud 3.2 qualification), and Google Distributed Cloud, which can run fully air-gapped.

In each case, the further you move from the provider’s public region towards a partner-operated or customer-operated deployment, the more both the sovereignty and the privacy answers improve, and the closer the option gets to an on-premises deployment in cost and effort. The comparison of sovereign cloud with on-premises AI walks through that trade-off workload by workload.

Twelve questions to ask every vendor

Use these in a security questionnaire or a final-round workshop. For each answer, ask for evidence: a contract clause, an architecture diagram or a log sample.

1. Which legal entity operates the service, which company ultimately owns it, and in which countries are both incorporated?
2. Has your legal team assessed whether that entity can be compelled by a foreign authority to disclose our data, and will you share the conclusion?
3. Where are prompts, retrieved document chunks, embeddings, outputs and logs processed and stored, including backups?
4. Does any part of a request (inference, embedding, content filtering, telemetry) leave our chosen boundary, even briefly?
5. Do you, or any model provider you call, retain our content or use it to train or evaluate models? Where is that written in the contract?
6. Which models will we run, who published their weights, under what licence, and can we pin a version for the life of a regulated workload?
7. Can the platform run with no outbound internet connection, and how are updates delivered and verified in that mode?
8. Who holds the encryption keys, and can your staff decrypt our data without our action?
9. Who can access our environment for support, from which countries, and is every session approved by us and logged?
10. Does the software need to reach a licence server or your control plane to start or keep running?
11. Can we export the full audit trail of model calls, retrievals, tool calls and approvals to our own SIEM, and who sets retention?
12. If we end the contract, what do we keep (models, prompts, workflows, logs), in what format, and how long does migration take?

For a fuller scoring sheet that covers agent permissions and governance as well, use the enterprise AI agent RFP checklist.

What each option costs to run

Costs vary too much by scale to give useful numbers here, but the shape of each option is predictable.

Public AI services and APIs have the lowest starting cost: per seat or per token, nothing to install, and a bill that grows with use. They offer the least sovereignty and the least isolation.

Hyperscaler sovereign regions and partner clouds are metered like other cloud services. Budget for the fact that the service catalogue can be narrower than in the provider’s global regions, so some managed AI services you rely on elsewhere may be missing or arrive later. You save on hardware and operations staff.

Self-hosted in a private cloud account moves the platform software into an environment you control. You pay for GPU instances by the hour, which is expensive if they run around the clock, plus the platform licence. It is a fast route to privacy, and its sovereignty depends on the cloud provider’s jurisdiction.

On-premises front-loads the cost: GPU servers, power and cooling, rack space and the staff to run them, plus the software licence. In return the running cost is largely fixed, there is no per-token bill, and both the privacy and the sovereignty answers sit with you. Steady, high-volume workloads are where this tends to pay back.

Air-gapped adds the cost of moving updates and models across the gap by controlled transfer, and of running without cloud monitoring.

To compare your own numbers, the AI savings calculator estimates the difference between metered cloud AI and a fixed-cost deployment for your user count and usage. VDF AI’s own price structure is set out on the pricing page: the hosted VDF AI Cloud plans have published prices, while on-premises deployments are licensed as Seat Bundles at a fixed annual price, with no per-token licence charge, and every bundle can start with a three-month platform trial.

Where VDF AI fits

VDF AI is a governed agent platform built for the private end of the table above. It runs on your own servers, in a private cloud account you control, or fully air-gapped, and it is also available as VDF AI Cloud, a hosted service operated by VDF AI for teams whose requirements allow a supplier-run service.

What it gives you in a self-hosted deployment, as described on our Trust Center:

• No required external model API. On-premises, VPC and air-gapped deployments do not need a third-party model provider for production inference. If you choose to connect one, that is your configuration and your policy.
• Models you choose. The platform is model-agnostic, so you decide which open-weight or licensed models run, where they run and which workloads may use each one.
• Offline updates. In air-gapped mode, updates arrive as signed artifacts your team inspects, approves and installs from an internal registry, with no outbound internet access needed.
• Your identity and permissions. Microsoft Entra ID single sign-on is built in for self-hosted deployments, other identity providers connect through an SSO-aware reverse proxy, and role-based access with per-role tool grants controls what each agent may call.
• Your audit trail. Model calls, retrievals, tool calls and approvals are logged in your environment and can be exported to your SIEM.

Some sovereignty questions remain yours to settle, whichever platform you choose. VDF AI does not change where a model’s weights were published, so model provenance is a selection decision. And if you deploy into your own account on a hyperscaler, the CLOUD Act analysis applies to that hyperscaler. For the jurisdiction-first version of this deployment, see the sovereign AI agent platform page; for the disconnected version, the air-gapped AI agent platform page; and for the full range of private deployment modes, the private AI overview.

How to decide in one meeting

Put the general counsel, the CISO and the business owner of the first AI workload in a room with the decision table. For each row, ask whether the requirement is mandatory, preferred or irrelevant for that workload. Then:

• If every mandatory row is a residency or contract row, a sovereign cloud region or a well-contracted private cloud is probably enough.
• If any mandatory row involves foreign legal compulsion, remote shutdown or support access, shortlist options where you or a domestic partner operate the stack.
• If the workload must run disconnected, or the inputs are the most sensitive material you hold, plan for on-premises or air-gapped deployment.

Record which rows drove the decision. A supervisor or auditor will ask for that record later, and the next workload can reuse it.