Private and Sovereign AI Are Redrawing the Trust Boundary Around Model Deployment

For most of the last decade, running a powerful AI model meant sending your data to someone else’s infrastructure and hoping that infrastructure would perform. But that arrangement is breaking down as a trust dilemma grows between model owners, data owners and infrastructure providers. Organizations across finance, healthcare, government, and defense increasingly want to run the model inside their own walls, under their own controls, without losing access to whatever made the model strong in the first place.

This is what private and sovereign AI provide, and it’s no longer a niche demand. In fact, more than 95% of surveyed organizations said private and sovereign AI matter to their strategy, even though only about three in 10 are currently prioritizing the work in a concrete, near-term way, according to NTT DATA’s 2026 Global AI Report. A similar pattern is described in McKinsey’s research on sovereign AI ecosystems. Enterprise roadmaps for 2026 list sovereignty in almost all cases, but few of them actually have an executable roadmap that clearly outlines workload tiers.

That gap between ambition and execution reflects a genuine, unresolved tension, where enterprises want models that can run in environments the provider doesn’t control, but model providers built their entire businesses on building, training and fine-tuning models themselves.

Why the Old Security Model Doesn’t Transfer

Traditional software security assumes a fairly clean separation of security controls. The vendor secures its code before shipping it; the customer secures the environment it runs in. Contracts, access controls, and network perimeters do the rest.

Proprietary AI models don’t fit that model cleanly. The “product” isn’t a static binary; it’s a set of weights, in some cases hundreds of billions of parameters, representing months of training investment and the provider’s core intellectual property. Once those weights are deployed into a customer-controlled environment, the provider is effectively handing over the IP and hoping the surrounding controls hold.

Contractual terms and access policies don’t offer much protection against a customer’s own systems administrator, a misconfigured cluster, or a compromised host. And once a model provider extends deployment to someone else’s data center or cloud tenancy, many of the usual technical safeguards no longer apply.

The Real Exposure Is in Memory

The most underappreciated part of this problem is what happens to a model once it’s actually running. Encrypting data while it’s at rest or in transit is widely deployed. The gap emerges while data is in use, the moment weights are decrypted and loaded into GPU or system memory so inference can happen.

Researchers have already demonstrated memory-based extraction attacks against deployed neural networks. A widely cited academic study showed that side-channel techniques against memory hardware could be used to reconstruct a model’s weights without ever touching the provider’s original files. The attack surface isn’t the model file sitting on disk; it’s the live, running process, which is the state a model has to be in to be useful.

But you don’t even need a side channel attack to extract model weights from memory. A privilege escalation by exploiting the kernel could give an attacker sysadmin privileges to dump the weights from the memory.

For a model provider, this means the moment of greatest business risk, when someone else’s infrastructure is actively running your IP, is also when conventional protections are weakest. That’s the core problem private and sovereign AI deployments have to solve. Who or what can technically see the model while it’s running?

Confidential Computing Offers a Path, With Real Limits

The most promising answer to this problem right now is confidential computing: hardware-based trusted execution environments (TEEs) that keep data and model weights encrypted even while they’re actively being processed. The Confidential Computing Consortium, an open community under the Linux Foundation, defines this as protecting data in use inside an attested TEE, meaning the environment can cryptographically prove what it’s running before any sensitive workload is handed to it.

Attestation is what actually creates trust between a model provider and a customer’s infrastructure. It lets the provider’s model check the cryptographic fingerprint of the environment it’s about to run in and refuse to release its weights if that environment doesn’t match what was authorized. Major cloud providers have started building this directly into their AI infrastructure; Google Cloud’s recent confidential computing updates, for instance, extend attestation across both CPU and GPU hardware, so that inference workloads are verified end-to-end before any decryption keys are released.

It would be a mistake, though, to treat attestation as a solved problem. Any security technology is only strong if it’s implemented correctly and securely.

But that doesn’t mean confidential computing is a false promise. It means the discipline is still young, the tooling is still maturing, and enterprises evaluating vendors should be asking pointed questions about how attestation is implemented, not just whether it exists on a spec sheet.

Secure, Flexible Deployment Is Becoming a Precondition, Not a Feature

The business case for solving this is only getting stronger. Deloitte’s global enterprise research puts expected sovereign AI compute investment at close to $100 billion in 2026 alone, driven largely by regulated industries that have no path to broader AI adoption without it. That bet reflects the reality that data residency rules, sector-specific compliance regimes, and geopolitical pressure are now baked into how large organizations plan their AI infrastructure years in advance.

For model providers, that changes things entirely. The ability to run a model securely within a customer’s environment without surrendering control over the weights is shifting from a differentiator to table stakes. Providers who can’t offer some version of this will find themselves locked out of exactly the regulated, high-value industries currently driving enterprise AI spending.

None of this eliminates the underlying tension between model accessibility and IP protection. It probably never fully will. But the direction is clear: enterprises adopting AI at scale are no longer willing to accept “trust us” as an answer, and those who figure out how to respond with cryptographic proof will be the ones competing for and winning that business.