Tarun Bulchandani
← All writing
by Tarun Bulchandani

Sovereign AI is mostly theatre. The actual technical question is data residency

European 'sovereign AI' announcements are increasingly political. The architecture questions buried inside them are technical and answerable. A framework for separating the two.

TL;DR

"Sovereign AI" is the framing every European government and most European enterprise software vendors are using in 2026 to describe the goal of running AI infrastructure without dependence on US hyperscalers. The political case is straightforward. The technical delivery is much messier than the framing suggests. Most "sovereign AI" propositions in the market today are either repackaging a US provider behind a European brand, building a non-frontier-class model with EU funding, or solving a different problem (data residency, model provenance, supply chain) and calling the bundle "sovereignty".

For an architect making real decisions in 2026 about where to run inference, where to store the data that feeds the models, and what to commit to in vendor contracts, the useful move is to separate the political question from the technical questions. The political question is whose flag is on the press release. The technical questions are three: where does the inference physically run, where does the data that the model sees physically live, and under whose jurisdiction is the operating company subject to discovery, subpoena, or compelled-access orders. Each of these has a clean answer for a given deployment. None of them are answered by buying a "sovereign AI" product per se.

This piece is the framework I would use to make the call, with specific patterns for the regulated enterprise context.

What "sovereign AI" usually means in 2026

The category is doing too much work. When a European government, a hyperscaler, a regional cloud provider, or a vendor uses "sovereign AI" in 2026, they typically mean one of:

  • A European frontier model. Mistral is the canonical example. Aleph Alpha was an earlier one. The pitch is that the model itself is European-trained, European-controlled, and competitive with the US frontier. The reality is that the gap to the US frontier has been narrowing on some metrics and widening on others, with the result that "sovereign frontier model" is a credible product for some workloads and not for others.

  • A European cloud running US models. OVHcloud running Mistral. Scaleway hosting Llama. The various "EU Bedrock-equivalent" offerings from European hyperscalers. The pitch here is that the infrastructure is European even if the model came from elsewhere.

  • A US hyperscaler running in EU regions with EU contractual controls. Microsoft's EU Data Boundary, AWS's European Sovereign Cloud, Google's Sovereign Cloud arrangements. The pitch is that the US provider can demonstrate that data stays in the EU and is subject to EU contractual controls even though the operating company is US.

  • A managed-services wrapper around any of the above. The service provider takes responsibility for "sovereignty" as a service offering. The customer doesn't have to design the controls themselves; they outsource the question to a vendor.

  • A pure marketing claim with no underlying architecture. This category exists. The vendor uses "sovereign AI" as a positioning word with no specific technical commitment behind it. Worth being able to recognise.

The five things are not the same. They have different cost profiles, different risk profiles, different capability profiles, and different legal postures. Treating "sovereign AI" as a single category obscures all of that.

The political moment

It is worth being honest about why "sovereign AI" is having the moment it is having.

A combination of: the EU AI Act compliance regime now in active enforcement (the second tranche of obligations landed in 2025, the third in 2026), the broader European tech-sovereignty push that predates AI, the geopolitical realignment around US-EU technology relations under the current US administration, the specific concerns that the Cloud Act creates for any EU data hosted by US companies, and a cohort of European AI investors who genuinely believe the next decade of model competition has space for non-US-aligned alternatives.

All of this is real and all of it produces real announcements and real funding flows. Several of the announcements over the past eighteen months are substantive. Several are political theatre. The architect's job is to be able to tell them apart at the specification level.

The three technical questions

The political framing — "is this sovereign?" — is not actionable. The actionable questions are three. Every architecture decision about AI deployment in a regulated European context can be decomposed into them.

Question 1: Where does the inference physically run?

The literal compute. The GPUs. The data centre. The geographic location of the silicon doing the matrix multiplications when your prompt is being processed.

This is the most concrete and most easily auditable of the three questions. The answer can be a city, a region, or a country. For EU regulatory purposes it usually needs to be a member state. For some specific national rules (FCA outsourcing rules, some defence contracts, some healthcare deployments) it needs to be the specific country.

The answer varies by vendor and by deployment configuration:

  • OpenAI API directly: US, primarily. EU data residency is available on enterprise contracts but the underlying inference may still route through US-based infrastructure for some workloads. Read the terms.
  • Anthropic API directly: US, primarily. Similar enterprise options.
  • Anthropic via AWS Bedrock: Customer-controlled. Pick an EU region; the inference runs there.
  • Anthropic via Google Vertex AI: Customer-controlled. Pick europe-west4 (Netherlands) or similar; the inference runs there.
  • Azure OpenAI: Customer-controlled. Pick West Europe or Sweden Central; the inference runs there.
  • Mistral via Mistral La Plateforme: France.
  • Self-hosted Mistral / Llama / Qwen on European infrastructure: Whichever region you deployed to.

The pattern: the question of where inference runs is a procurement and configuration question, not a "sovereign vs not" question. You can have EU-resident inference from US-based vendors. You can also have non-EU-resident inference from European-branded products if you don't configure carefully.

For most regulated workloads, the answer should be an EU member state and should be contractually committed. The vendor's willingness to commit to this is itself a signal of whether they are operating at enterprise grade.

Question 2: Where does the data the model sees physically live?

A different question. The model is doing inference somewhere. The data the model is reasoning over — the documents in your RAG corpus, the customer records the agent is acting on, the documents attached to the prompt — is being sent to that inference endpoint. The data must travel to where the inference runs. It may also be cached, logged, or retained somewhere along the way.

The data-residency question is therefore: across the full inference path, where does the data live, even transiently?

Specifically:

  • The corpus. Where is the vector database? Where are the source documents? Where are the embeddings stored?
  • The prompt and response in flight. What region does the network path traverse? Where are the load balancers?
  • The prompt and response at rest. Does the vendor retain prompts and responses? For how long? In what region?
  • The model weights, if you are fine-tuning. Where are the training datasets stored, where is the training compute, where are the resulting weights stored?

For a typical RAG-based agent in 2026, the corpus is the part most companies handle correctly (it lives in the company's own systems, usually in a regional managed service) and the inference logs are the part most companies handle incorrectly (the vendor's retention defaults are often longer than the company's policy, and the region may be different).

The audit-grade answer to this question is: every byte of data that touches the model — going in or coming out — has a specified region of residence at every stage, and the vendor contract matches the specification. Where the contract is silent, the default is whatever the vendor's general infrastructure does, which is usually US-routed.

Question 3: Under whose jurisdiction is the operating company subject to compelled access?

The hardest of the three to reason about because it is about legal process rather than technical configuration.

A US company operating a cloud in the EU is, under the Cloud Act, potentially subject to US compelled-access orders for data the company holds, regardless of where the data is physically stored. This is the core argument against US-headquartered hyperscalers hosting truly sensitive EU data. The US company can be ordered by a US court to produce the data, and complying with that order may put them in conflict with EU law (specifically GDPR's restrictions on third-country data transfers).

The mitigations:

  • EU Data Boundary and equivalent. Microsoft, AWS, and Google have all rolled out variants of contractual and technical arrangements designed to address Cloud Act concerns. The details matter. Some of these arrangements are substantive (separate legal entities incorporated in the EU, with EU staff, EU encryption keys held by EU entities, technical separation of the EU infrastructure from US operations). Some are less so. Read the actual terms.

  • EU-incorporated operating companies. A truly EU-resident cloud — operated by an EU-incorporated company, with no US parent in the legal structure, with no US staff with admin access — is not subject to the Cloud Act. OVHcloud, Scaleway, Aruba, and the various national cloud initiatives fall in this category.

  • On-premise deployment. The company runs the inference inside its own data centre, on its own infrastructure, using a model it has the right to run (typically an open-weights model). No third-party operator at all. No Cloud Act exposure because no US company is involved.

The third question is the one where "sovereign AI" framing comes closest to making sense, because it is genuinely about jurisdictional sovereignty. But it is also the question with the largest gap between political claim and technical reality. Most "sovereign AI" offerings address questions 1 and 2 but punt on question 3.

A decision framework

For an architect making a deployment decision, the question is not "is this sovereign". It is: "for this specific workload, with this specific sensitivity level, what answers do I need to questions 1, 2, and 3, and which deployment configurations satisfy them?"

A reasonable framework, in order of escalating constraint:

Tier 0: Public, non-sensitive workloads

Marketing copy generation. Internal-document summarisation of non-confidential material. Developer-tooling LLM use against non-confidential code.

Answers needed: Q1 and Q2 should be in-region (EU for EU operations), via contractual commitment. Q3 is generally not a concern at this tier.

Acceptable deployments: Any major LLM vendor with an EU inference region and standard enterprise terms. OpenAI in EU, Anthropic via Bedrock EU, Mistral, Azure OpenAI in EU, Vertex AI in EU.

Tier 1: Confidential business data

Internal architecture documents. Internal financial planning data. Internal HR data (non-PII). Source code where commercial sensitivity is moderate.

Answers needed: Q1 in-region with contractual commitment. Q2 in-region with contractual commitment, including retention terms and incident-response data handling. Q3 should be considered: a US-headquartered hyperscaler running an EU region with strong contractual controls is acceptable; pure consumer-tier vendor endpoints are not.

Acceptable deployments: Azure OpenAI in EU on an enterprise contract with EU Data Boundary attestation. Anthropic via Bedrock EU on a similar contract. Mistral La Plateforme for workloads where the model quality is sufficient. Self-hosted Llama or Mistral on EU-resident infrastructure for workloads where data-residency control is paramount.

Tier 2: Regulated PII, financial customer data, healthcare records

Customer transaction data. Patient records. KYC documentation. Anything covered by financial-services or healthcare regulation.

Answers needed: Q1, Q2, and Q3 all need strong answers. Q3 is now actually the binding constraint: the legal exposure to US compelled access becomes a meaningful concern, depending on the specific regulator's view.

Acceptable deployments:

  • For most workloads, US hyperscaler in EU region with full EU Data Boundary controls is still acceptable, provided the company is comfortable with the residual Cloud Act exposure. Most large EU banks operate at this tier.
  • For workloads where Cloud Act exposure is unacceptable: an EU-incorporated cloud provider running an EU-developed model (Mistral on OVHcloud, for example), or self-hosted infrastructure with open-weights models.
  • The decision is partly about the workload's regulatory exposure and partly about the regulator's known posture on the question. The Dutch DNB and the German BaFin have been more conservative on US-hyperscaler exposure than some others. Calibrate to your primary regulator.

Tier 3: Defence, national-security-adjacent, certain forms of intelligence

Out of scope for most of the readers of this post. The pattern is on-premise, air-gapped, open-weights, with the entire inference path under the operating company's physical control.

Where the European model providers actually win

A fair assessment of where Mistral and the smaller European players genuinely deliver value rather than just political framing.

On data-residency questions where the customer wants to deal with an EU-incorporated counterparty rather than a US one. Mistral La Plateforme is operated by a French company. Its contract is governed by French law. There is no US holding company in the chain. For Tier 2 workloads where Cloud Act exposure is the specific concern, this is a real technical answer, not just positioning.

On model quality for non-frontier workloads. Mistral's smaller models (in 2026, the latest mid-tier Mistral models) are competitive with US mid-tier models on many evals. For workloads where you do not need frontier capability, the European model is a viable choice on capability alone, and the residency story is a bonus.

On open-weights availability for self-hosting. Mistral has been one of the more consistent providers of weights that can actually be deployed on customer infrastructure. For workloads where self-hosting is the architectural requirement, the open weights from Mistral and from Meta's Llama family are the practical choice.

On specific language strength. Some European models have strength in specific European languages (French, German, Spanish) that exceeds the major US models. For workloads where the working language is something other than English, this is occasionally a meaningful capability difference.

Where they don't matter

A fair assessment of where the European positioning is mostly marketing.

On frontier-class capability. As of mid-2026, the frontier of capability — the most demanding agentic reasoning, the most complex tool use, the most reliable code generation — sits with the major US frontier models. The gap has been narrowing on some benchmarks and not narrowing on others. If your workload genuinely requires frontier capability, the European alternatives are not yet substitutable.

On managed enterprise tooling around the model. The vendor ecosystem around the major US providers — observability tools, prompt-management platforms, evaluation frameworks, deployment patterns, integration platforms — is significantly more mature than the equivalent ecosystem around European providers. This matters for production deployments at scale.

On Q3 if the workload's regulatory exposure is low. For most Tier 0 and Tier 1 workloads, the Cloud Act concern is theoretical. Choosing a European provider specifically to address Q3 when Q3 is not actually a binding constraint is over-engineering.

A concrete recommendation

If I were the Chief Architect of a regulated European company today, making the call about AI infrastructure for the next two years, here is what I would actually do.

For Tier 0 workloads: Standardise on whichever frontier model the company has the strongest enterprise relationship with, deployed in an EU region with standard contractual residency commitments. Do not over-engineer the sovereignty question.

For Tier 1 workloads: Same as Tier 0, with stronger contractual commitments on data handling, retention, and incident response. The Bedrock or Vertex AI path with explicit region selection. Do not run consumer-tier endpoints.

For Tier 2 workloads with Cloud Act exposure as a binding constraint: Mistral via Mistral La Plateforme, or self-hosted open-weights model on an EU-incorporated cloud. Accept the capability trade-off; for these workloads, the regulatory clarity is worth more than the marginal model quality.

For Tier 2 workloads where Cloud Act exposure is acceptable to the regulator: US hyperscaler in EU region with strong contractual controls (EU Data Boundary, equivalent). Most of the EU regulated sector is operating at this tier today and it is workable.

For Tier 3 workloads: Out of scope for this piece. Talk to your sector-specific authority.

The thing I would not do is pick a "sovereign AI" product because the brand says sovereign. Read the contract, check the inference region, check the data-residency commitments, check the operating company's jurisdiction. Then make the call on the merits.

The next two years

A prediction. The "sovereign AI" framing peaks in 2026 and 2027, then transitions into a more technical conversation about data-residency engineering as the political moment passes and the real architecture decisions get made. The vendors that survive this transition are the ones whose technical claims hold up — not the ones with the best press release.

Specifically:

  • Mistral becomes a credible mid-tier European choice for regulated workloads. Its frontier-model ambitions either succeed or stall; either way, the mid-tier business is durable.
  • The US hyperscalers' EU Data Boundary arrangements get contractually stronger as their European customer base demands more. Microsoft, AWS, and Google all add layers of EU-control through 2026 and 2027. By 2028 these arrangements look much more like proper sovereign clouds for most practical purposes, although the Cloud Act exposure does not fully go away.
  • Open-weights models become the default for the most sensitive workloads. Self-hosting on EU infrastructure is the answer for the cases where Q3 is the binding constraint. The ecosystem around self-hosting (deployment patterns, observability, evaluation, fine-tuning) matures rapidly through 2026 and 2027.
  • The political framing fades. By 2028 "sovereign AI" is no longer the headline framing. The conversation is about specific technical commitments, just as the conversation about "cloud sovereignty" — which had its own moment in 2018-2020 — became technical rather than political over time.

The architects who do well in the next two years are the ones who stay grounded in the three technical questions and don't get distracted by the framing. The political conversation will resolve itself. The technical decisions will be on the architecture function's books long after.

If you are reading vendor proposals right now with "sovereign AI" in the title and you have not separately verified the answers to questions 1, 2, and 3 for the specific deployment configuration being proposed, please go back and do that before you sign.

Related

This piece sits adjacent to: