I have been talking to enterprise technology teams across a range of industries over the past several months, and a pattern has emerged that I want to name directly. Organizations are receiving pitches for "sovereign AI" solutions — sometimes from vendors, sometimes from internal teams that have assembled an enterprise AI platform — and accepting those claims without a diagnostic framework to evaluate them.
What I am seeing called sovereign AI in practice includes: multi-model access through a consolidated enterprise portal, RAG systems built on corporate document repositories indexed through third-party cloud services, policy-based controls that tell employees not to put sensitive data in prompts, and AI platforms deployed within an enterprise's existing cloud tenancy.
These are all real and often valuable implementations. None of them are sovereign AI. The terminology has been stretched to cover governed cloud AI access, and the stretching matters because it shapes architecture decisions.
I want to offer a diagnostic framework — three tests that separate genuine sovereign AI from what I will call sovereign AI washing.
What Sovereign AI Actually Means
Before the diagnostic tests, a clear definition. Sovereign AI means that your organization has complete, durable control over three things:
The model weights. The parameters that define the model's capabilities. You own them, can copy them, can delete them, can modify them, and no third party can change your access to them or your right to use them.
The inference computation. The processing that transforms your inputs into outputs. It happens on hardware you own or lease in an environment your organization controls. No third party receives your prompts or generates your responses on your behalf.
The derived intelligence. The embeddings, fine-tuned weights, retrieval indexes, and interaction logs that encode what your organization has built on top of the base model. These stay in your perimeter.
If any of these three is held by a third party, you have a dependency. Dependencies can be managed. They can be acceptable. But they are not sovereignty.
Test One: Who Owns the Weights?
The first test is the simplest and the most frequently glossed over.
Ask your vendor or your internal platform team: who owns the model weights that generate our AI outputs? Can we download a complete copy of those weights to infrastructure we control? Can we operate the model independently of the vendor if we choose to?
If the answer is yes: The weights are yours. This test is passed. You control the foundational intelligence.
If the answer is no, or "it's complicated," or the model is a frontier API (Claude, GPT-5, Gemini): The weights are not yours. No enterprise agreement, no data processing agreement, and no contractual commitment changes this fundamental fact. You have licensed access to intelligence that belongs to someone else. When that access is revoked, modified, or repriced, you have no recourse from the weight side.
Most enterprise AI deployments fail this test. They are built on frontier model APIs where the weights are proprietary. There is nothing wrong with building on proprietary models for the right use cases. But it is not sovereignty.
Test Two: Where Does Inference Happen?
The second test addresses where the computation actually occurs when your AI generates a response.
Ask: when our AI system processes a prompt and generates a response, on whose infrastructure does that computation happen? Are our prompts transmitted to any third-party system? Does any third party's software execute on our data as part of the inference process?
If inference happens on hardware your organization owns or leases, with no third-party software executing in the critical path: Test two is passed.
If inference happens on a cloud provider's infrastructure, through a third-party API, or via a managed service: Inference is not sovereign, regardless of what the contract says about data handling. Your prompts travel to infrastructure you do not control. They are processed by software you do not control. The response is generated by a system you do not own.
This test catches the category of "sovereign AI" that amounts to: we use Claude through our enterprise Google Workspace tenant, so it's sovereign because it's within our Google tenancy. A Google Workspace tenancy is a licensing arrangement. Inference that happens within your Workspace tenancy still happens on Google's infrastructure, processed by Anthropic's model, with data handling governed by both Google's and Anthropic's terms of service. This is not sovereignty. It is governed cloud access — which is genuinely valuable, and genuinely not the same thing.
Test Three: Where Does the Derived Intelligence Live?
The third test is the one that is most often overlooked, even by teams that understand the first two.
Ask: where do our AI embeddings live? Where are our RAG indexes stored? Where are our fine-tuned model weights (if any) stored? Where do our inference logs and interaction histories live?
If all derived intelligence lives on infrastructure your organization controls: Test three is passed.
If any derived intelligence — embeddings, indexes, logs, fine-tuned outputs — is stored on third-party cloud infrastructure: You have a sovereignty gap in the most sensitive layer of your AI architecture.
Here is why this matters more for AI than for traditional data. Your raw data may be well-protected — encrypted, access-controlled, covered by a comprehensive DPA. But your embeddings encode the semantic content of that data in a form that reveals business intelligence without revealing the raw data directly. An embedding index of your engineering documentation reveals the structure and content of that documentation in ways that partial inspection of individual documents does not. An inference log reveals what problems your organization is trying to solve, what information your AI is retrieving, and what decisions it is supporting. These are derived intelligence artifacts. They belong in your perimeter.
The Policy Substitute That Is Not Sovereignty
There is one more pattern worth naming explicitly. Some platforms address the sovereignty concern with a policy: we tell employees not to put sensitive or proprietary information in their AI prompts. This policy is a governance control. It is not sovereignty.
The difference: sovereignty guarantees that sensitive data cannot leave the perimeter through the architecture. Policy-based controls ask employees to self-enforce the boundary, with all the error and circumvention that human enforcement entails. An employee who pastes a confidential contract into a Claude prompt — accidentally or intentionally — has violated the policy. But if the architecture permitted the operation, the data still left the perimeter. Policy did not prevent it; policy just made it a policy violation after the fact.
Genuine sovereign AI makes the bad outcome architecturally impossible, not just policy-prohibited.
The Diagnostic Summary
Run these three tests on your current AI platform:
- Do you own the model weights, with the ability to operate independently of the vendor?
- Does inference happen on infrastructure your organization controls, with no third-party execution in the critical path?
- Does all derived intelligence — embeddings, indexes, fine-tuned weights, interaction logs — live on infrastructure your organization controls?
If all three are yes, you have sovereign AI. If any is no, you have something else — something that may be appropriate for your risk tolerance and use case profile, but that should be called what it is.
Governed cloud AI access is valuable. Enterprise-grade AI compliance is valuable. Well-designed policy controls are valuable. None of these is sovereignty. An architecture built on the false assumption that they are sovereignty will have gaps that only become visible when the architecture matters most — during a security incident, an audit, a pricing change, or a regulatory inquiry.
The gap between "sovereign AI" and genuine sovereignty is not a marketing problem. It is an architecture problem. And architecture problems need architecture solutions.