Sovereign AI Has a Definition Problem

The word doing too much work

Over the past year, "sovereign AI" went from a phrase used mostly by national governments to a phrase used by nearly every infrastructure and security vendor selling into enterprise AI. A McKinsey survey of 300 executives, investors, and government officials found 71 percent now describe sovereign AI as an existential concern or a strategic imperative. The same research found that most of those organizations have no detailed strategy, action plan, or budget behind that concern.

That gap, real urgency, unclear execution, is worth understanding precisely, because the word "sovereign" is currently being used to describe at least three distinct things: where your data physically sits, who is legally permitted to compel access to it, and whether the AI model processing it ever sees the values in a readable form. Those are three different problems, with three different solutions, and a lot of what's being marketed under one banner right now only solves one of them.

This isn't a critique of any specific company. Every vendor named below is solving a real problem for real customers. The purpose here is simpler: to separate the actual claims being made from the word being used to describe them, using each company's own public materials.

What "sovereign" actually covers

Industry analysts covering this space have started breaking sovereignty into distinct components rather than treating it as one thing. A useful way to think about it: geographic sovereignty (where the data and compute physically live), legal sovereignty (which country's laws govern access to it), operational sovereignty (who controls the infrastructure day to day), and what might be called architectural sovereignty (whether the system processing your data can technically read it at all, independent of policy or jurisdiction).

Most products marketed as "sovereign AI" today address the first three. Very few address the fourth.

Data residency: real, necessary, and not the same as protection

A large share of current sovereign AI activity is, at its core, about where infrastructure is physically located. National and regional cloud buildouts, IBM's Sovereign Core platform (built on Red Hat OpenShift, live since May 2026), Yotta's India-based GPU and database infrastructure under the IndiaAI Mission, and similar programs across the Gulf and Europe, are real, substantial investments in keeping data and compute within a defined jurisdiction.

This matters. Data residency requirements are written into real regulations, and for many organizations, simply knowing which country's servers hold their data is the actual compliance question they need answered. But residency alone says nothing about what happens to the data once an AI model processes it. A server sitting in the right country can still send your data, in readable form, to a model that reads it, retains it, or gets compromised. Geography and exposure are separate questions.

Confidential computing: a real technical advance, with real limits

The more technically sophisticated tier of "sovereign AI" products relies on Trusted Execution Environments, TEEs, hardware-isolated regions of a processor that shield data and code from the rest of the system, including the cloud provider's own operators. Companies like OPAQUE, Fortanix, and Anjuna build real, credible products on this foundation, and OPAQUE in particular reached a $300 million valuation in a February 2026 Series B, evidence the market is willing to pay real money for this level of protection.

Worth understanding precisely what a TEE guarantees and what it doesn't. It protects against a specific threat: someone with access to the underlying infrastructure, including a cloud provider's own staff, reading your data. It does not change which country's courts have jurisdiction over the provider running the hardware. A TEE encrypts what's in memory; it does not repeal legal frameworks like the US CLOUD Act, which allows US authorities to compel access to data held by a US company, regardless of where that data is physically stored. Attestation can prove what code ran inside the enclave. It does not move the courtroom.

There's also a more recent, technical limitation worth naming. At the Linux Foundation's 2026 confidential computing summit, Google's own director of confidential computing publicly acknowledged that agentic AI, workflows where a model takes multiple sequential actions rather than answering one query, breaks the traditional TEE model. Agents accumulate context across steps, and the proposed fix, a fresh encryption key issued per agent, is itself a new secret that has to be protected. A separate academic survey published this year found TEE-based systems remain vulnerable to denial-of-service attacks, attestation-service outages, and metadata leakage, even when the underlying content stays encrypted.

None of this makes TEE-based products bad. It makes them a specific, real answer to a specific, real problem, infrastructure-level isolation, not a complete answer to the exposure question. (The distinction between a vendor promising not to look and a vendor being unable to look is the subject of The Two Perils of AI Risk.)

Governance and permissioning: proving what happened, after it happened

A third, fast-growing category focuses on control and auditability rather than encryption. Palantir's Foundry platform, whose enterprise sales grew 149 percent in a single quarter this year on exactly this positioning, centers on deciding who may access what data and maintaining a verifiable record of every access. IBM Sovereign Core pairs infrastructure isolation with continuous compliance monitoring and audit trails. Google Cloud's newly launched Gemini Enterprise platforms for legal and financial services build governance, policy enforcement, and citation verification directly into the workflow. TRACE, a hardware-attested standard jointly built by AMD, Intel, Microsoft, OPAQUE, and the UAE's Technology Innovation Institute this year, creates cryptographically verifiable evidence of exactly what an AI agent did and what data it touched.

These are sophisticated systems, and the problem they solve is real: as of this year, only 45.1 percent of organizations have even basic audit logging in place for their AI agents, and only 41.2 percent have identity and access management controls specific to agents. Most companies deploying AI right now have neither. A platform that builds governance in by default closes a real, current gap.

What governance answers is a different question than what architectural exposure prevention answers, though. Governance decides who is allowed to look and keeps a record that the looking was authorized. It doesn't change what the AI model has to read to do its job. A perfectly governed, perfectly audited system can still have a model reading sensitive financial data, medical records, or client information in plaintext, correctly, by policy, with every access logged. The audit trail gets stronger. The exposure itself doesn't move. (The same gap shows up in how AI agents connect to enterprise systems, examined in Is MCP Safe for Sensitive Data?)

The gap: architectural exposure prevention

The fourth category, computing on data the model never actually reads in a decrypted form, has almost no vendors building specifically for it as a deployable enterprise product today. The underlying cryptographic foundations for this are not new, the core research goes back decades, but making them fast enough and practical enough for real-time enterprise use, at a price a mid-market company can actually afford, is a comparatively recent engineering achievement. Most of the industry's commercial momentum over the past decade went toward infrastructure isolation and governance tooling, categories with a faster, more familiar path from research to enterprise sale. Production systems built specifically on this fourth approach, priced and deployed for organizations well below Palantir-scale institutional budgets, are still rare, less because the science is unsolved and more because turning long-standing research into something genuinely fast and deployable is difficult, specialized engineering that few teams have taken on.

This is the gap Nera Systems is built to fill. Data is encrypted before it ever leaves a customer's environment, using keys the customer holds. The AI model receives the query and the structure of the data, never the underlying values. Computation happens on the encrypted data itself. There is no point in the process, not the model, not the infrastructure, not Nera, where a readable copy of the customer's data exists outside their control. (For how that architecture works in practice, see What Is Confidential AI.)

That is a materially different claim than data residency, TEE isolation, or governance and audit logging, and it's worth being precise about why it matters: it is the only one of the four categories where the guarantee holds regardless of jurisdiction, regardless of who has infrastructure access, and regardless of whether every access was properly authorized. There is nothing to compel, nothing to breach, and nothing to misuse, because there is nothing exposed in the first place.

Where this leaves a buyer

None of the four categories above are competing solutions to the same problem. They're answers to four different questions, and most real deployments will need more than one. Data residency matters for regulatory jurisdiction. TEEs matter for infrastructure-level isolation. Governance and audit trails matter for accountability and regulatory examination. Architectural exposure prevention matters for the specific case where the underlying data itself, not just access to it, cannot be risked.

The useful question for any organization evaluating a "sovereign AI" claim right now isn't whether a vendor uses the word. It's which of these four things they're actually offering, and whether that matches the specific risk the organization is trying to manage. A company protecting patient records or client financials from ever being read by a third party needs a different guarantee than a company that mainly needs to prove, after the fact, that access was authorized.

The market is going to keep using "sovereign" to describe all four categories for a while longer, because the word is doing useful marketing work regardless of which layer a product actually addresses. Worth reading past it to the specific claim underneath.

References

1. McKinsey & Company, December 2025 survey of 300 executives, investors, and government officials on sovereign AI, as cited in industry research coverage, 2026.
2. IBM Newsroom, "IBM Sovereign Core and IBM Optim Bring Data Lifecycle Control to Sovereign AI," 2026.
3. Yotta and IntelliDB Enterprise partnership announcement, covered in Express Computer, 2026; additional Yotta infrastructure coverage under the IndiaAI Mission.
4. OPAQUE Systems Series B funding coverage, SiliconANGLE and FinSMEs, February 2026.
5. Remarks by Google's Director of Confidential Computing at the Linux Foundation's 2026 confidential computing summit, on agentic AI and TEE limitations, as reported in industry coverage.
6. Academic survey on TEE-based system vulnerabilities, including denial-of-service, attestation-service outages, and metadata leakage, published 2026 (arXiv).
7. Palantir Technologies Q2 2026 earnings coverage and shareholder letter commentary, CNBC, August 2026.
8. IBM Sovereign Core launch coverage and independent analyst commentary (Sanjeev Mohan, SanjMo), IBM Newsroom and syndicated press coverage, 2026.
9. Google Cloud, "Introducing Gemini Enterprise for Financial Services" and related legal-sector platform announcements, Google Cloud Blog, 2026.
10. Linux Foundation, "Linux Foundation Welcomes TRACE to Advance Verifiable Runtime Evidence for AI Workloads," 2026.
11. Industry survey data on AI agent governance and audit logging adoption rates, as reported by Futurum Group research coverage, 2026.

Nera Systems builds confidential AI infrastructure for regulated industries. The platform lets teams run Claude, Gemini, and ChatGPT on their most sensitive data without that data ever existing in readable form outside their control. Learn more or try it on your own data.