What enterprise AI needs when the data cannot move

The data AI most needs may be the data enterprises cannot move

Some enterprise data with the highest potential value for AI cannot simply be sent to the public cloud. Sovereignty rules, regulation, security reviews, cost predictability requirements, and air-gapped operations keep proprietary records inside enterprise-controlled environments. Banks, government agencies, and health care providers are prominent examples. The resulting deployment question is increasingly how to bring frontier models to that data while preserving the controls required by both the enterprise and the model owner.

“Organizations like banks, government agencies, and health care providers have a lot of data that was never intended to move to the cloud,” says Phil Manez, VP of strategic initiatives at VAST Data. “We‘re at the point now where the opportunity cost of not having these advanced AI models access that data is coming to a head.” Those location constraints have pushed much enterprise AI toward data that can move, leaving proprietary records untouched even when they could provide important context for an application.

Limited access to data also affects model choice. VAST says that for years it could address the enterprise side of the problem with open-source models or models already offered on premises, while stronger cloud-only models remained outside the environments holding restricted data. Frontier models may offer capabilities an enterprise wants, but a public-cloud delivery requirement can exclude them before anyone evaluates their performance.

To address that deployment problem, VAST recently introduced DataEnclave within the VAST AI Operating System. VAST has a commercial stake in this architecture because DataEnclave is its product and wider adoption of confidential enterprise AI can benefit its business. VAST describes the design as confidential AI, in which enterprises retain authority over their information while model providers protect proprietary model weights on infrastructure they do not own. The design depends on reciprocal control: enterprise permissions determine what reaches a model, while provider-controlled security checks determine whether the model can execute.

On-premises deployment leaves a mutual-trust problem

That reciprocal-control requirement remains when a model moves into a customer’s data center. A model can run against an on-premises GPU, but its location does not determine which records it may receive, where its output can travel, or whether the enterprise can reconstruct what happened. “I need to have ways to control what data the AI can access, and get visibility into what the AI was doing,” Manez says. “If you can’t do either of those, just allowing the model to run on prem doesn’t give you much.”

The enterprise’s control problem has a matching problem on the provider side. LLM weights can represent billions of dollars of training investment, along with proprietary intellectual property developed on top of that investment. During inference, those weights enter GPU memory, where an administrator who can inspect that memory could potentially copy them and operate the model elsewhere. A provider shipping weights into somebody else’s data center consequently needs a mechanism that prevents administrators and infrastructure operators from accessing the asset.

Provider control can also help keep acceptable-use rules enforceable. Anthropic disclosed in September that it had disrupted attempts to use Claude for work that could support biological-weapons development. The example concerns a specific misuse case, but it shows why a model builder may care about continued execution control for reasons beyond protecting revenue or preventing weight theft. A deployment design that removes the provider’s ability to police where its model executes can remove one way to enforce those restrictions.

Meeting both sets of requirements requires protection throughout the computation lifecycle. Confidential AI is intended to protect information in three states: at rest in storage, in transit across networks, and in use during computation. Encryption has long addressed the first two states. AI makes the third especially important because weights, prompts, and intermediate computation results have to exist in memory while CPUs and GPUs process them.

Protecting active computation changes the security boundary. The enterprise needs control over inputs, retrieval, outputs, and visibility into execution, while the model owner needs its weights to remain secret and its keys released only to approved environments. A server behind the enterprise firewall cannot provide either side those assurances by location alone. Enforceable trust depends on controlling what happens during execution.

Attestation lets the model owner control execution

Execution protection starts with confidential computing, which isolates working memory from software and administrators that normally control the machine. Confidential computing first addressed CPU workloads by preventing the host operating system, hypervisor, and users with root privileges from inspecting protected memory. AI extends that requirement to GPUs because inference and training put proprietary weights, user prompts, and intermediate results in GPU memory. Without protection on the GPU side, those values remain exposed during computation.

VAST says DataEnclave implements that protection with confidential virtual machines that span CPU and GPU resources. Within VAST’s architecture, DataEnclave adds two pieces to the VAST DataEngine, the system responsible for event-driven computing, secure model deployment, and accelerated inference. One described component is a secure runtime that starts each workload inside its own confidential VM on infrastructure near the enterprise data. On newer GPU platforms, encrypted NVLink protects traffic moving from one GPU to another, while the confidential VM protects transfers across CPU and GPU resources.

Once memory is isolated, the model owner still needs to decide whether a particular environment qualifies to receive its model. Attestation provides that decision mechanism: hardware produces signed evidence about the environment, and the model owner’s attestation service checks it against the owner’s policy. “You have to have a way to validate that the model is running in a secure environment before it’s allowed to run, that’s the attestation part,” Manez says.

That check has to happen before a protected model becomes usable. The model owner operates the attestation server, which withholds the model’s decryption keys until the hardware evidence shows that the execution environment complies with its policy. VAST does not receive another party’s keys, and neither does the company operating the underlying hardware. Owning the infrastructure consequently does not automatically provide access to the protected model.

Because key release depends on attestation, provider policy remains a condition of execution rather than a check performed only during installation. Every launch has to qualify, including each new replica of a workload. The provider can retain authority over acceptable execution environments even after encrypted model assets have been placed on someone else’s infrastructure. The customer owns or controls the environment, while the model owner controls the conditions under which its intellectual property becomes usable.

That sequence also produces evidence tied to model use. “Only when you’ve proven you’re in that secure environment do you get the keys to unlock that proprietary information,” Manez says. “Then you have the audit trail that proves when this model was decrypted and how it was used.” The provider gains evidence associated with actual model use rather than relying on a customer’s assertion that the infrastructure met the agreed conditions.

Attestation adds a deployment gate to the protection supplied by encryption and memory isolation. Memory isolation can prevent outsiders from inspecting material during computation, while encryption can protect that material before it is loaded. Successful attestation triggers key release, while a failed check leaves the protected weights unavailable for decryption and execution. Provider policy thus remains connected to model execution on infrastructure outside the provider’s administrative domain.

Enterprise permissions must survive retrieval, vectors, prompts, and egress

Provider-controlled execution addresses one direction of the trust problem, so the enterprise needs a corresponding boundary around its proprietary information. In VAST’s design, the model does not independently search corporate repositories. An application outside the enclave decides what information the model receives, allowing the enterprise to apply its own permissions before information reaches the protected model environment.

That application defines the retrieval path. A retrieval application running on enterprise systems searches documents, selects relevant excerpts, assembles them into a prompt, and sends the completed prompt to the model’s inference API. The prompt is consequently the enterprise information exposed to the model. Search and prompt construction stay on enterprise-controlled systems, and VAST says the model provider has no administrative route into the enclave through which it could inspect either the prompt or the resulting response.

Because retrieval determines prompt contents, authorization has to follow information through that pipeline. Enterprise AI systems commonly turn source material into vectors, numerical representations used to find semantically relevant content. If the vector index loses the permissions attached to the original document, retrieval can expose information from a file the requester is forbidden to open. Authorization at the document repository therefore has to remain connected to AI retrieval.

VAST says it applies “one set of access controls” to source material, whether a file, object, or image, and to the vector representing that material. Under this design, a retrieval request can draw source content only from records the requester is entitled to access. Preserving that relationship means an employee’s AI prompt cannot gain restricted document contents simply because the retrieval system found them relevant to the question.

Those retrieval controls determine what ultimately enters the enclave. Because retrieval and prompt assembly run on enterprise systems, the assembled prompt contains information selected under the requester’s existing permissions. VAST says the enterprise’s existing egress rules then determine where the enclave may transmit information after inference. Access control thus continues from the original record through retrieval and prompt construction to the network boundary around the result.

That chain makes retrieval authorization part of the confidential-AI security boundary. A hardware-isolated VM can protect a prompt once it reaches the model, but isolation cannot correct an upstream retrieval system that selected unauthorized records. Reciprocal control therefore extends beyond CPU and GPU security into the application path that decides what the model is allowed to see.

Independent records make reciprocal control auditable

Once both sides can enforce controls, each needs evidence it can compare with its own records. VAST says its runtime records which application and version launched, the node on which it ran, and the configuration used, storing those launch records in VAST DataBase. That gives the enterprise an operational record of execution associated with its own environment. The record ties the protected computation to a specific application, machine, and configuration.

The provider side maintains a separate account through the attestation service. VAST says that service records the enclaves it verified and the keys it released, complementing the audit trail showing when a protected model was decrypted and used. The two records describe different parts of the same execution event. Their separation reduces the need for either the enterprise or model builder to accept only the counterparty’s account of what occurred.

That independence makes reciprocal control something both parties can examine after execution. Runtime records can establish what application launched and under which configuration, while the provider’s attestation records establish which environment passed its checks and received keys. The resulting audit trail connects deployment conditions to recorded events rather than leaving those conditions only in policy documents.

The harder problem is one operating model across every deployment environment

Auditable control at one site still leaves an operational problem when each new environment requires a different collection of controls. Confidential enterprise AI has to coordinate CPU and GPU isolation, network protection, key management, retrieval permissions, egress restrictions, auditing, attestation, and deployment policy. Differences between infrastructure platforms create opportunities for configuration errors when teams must translate each control separately. A common operating model is meant to reduce that translation work.

The need for a common model grows because target environments differ substantially. A public cloud, a sovereign cloud, a customer’s own data center, and an air-gapped facility can have different administrative and connectivity constraints. DataEnclave’s proposed answer within the VAST AI Operating System is a common operating pattern across those locations. An air-gapped site, for example, can run its attestation and key-management systems locally alongside the workloads they verify because it cannot depend on an outside service.

VAST frames that portability as a way to preserve policy meaning between environments. “Translating the different controls, access requirements, and what audit looks like across all of those is very difficult, and it leaves opportunities for mistakes,” Manez says. “With a common operating model, I create policies one time, and then I move those policies through those environments.” The objective is to carry the same policy between deployment locations instead of rebuilding its meaning separately for each infrastructure environment.

Policy consistency matters because confidential AI depends on controls that cross organizational and technical boundaries. The model owner’s key policy has to align with hardware attestation; enterprise identity permissions have to survive vector retrieval; network policy has to constrain egress; and audit systems have to record what each side needs to verify. Changing one element independently can weaken assurances supplied elsewhere in the stack. Portability therefore depends on maintaining those relationships as infrastructure changes.

VAST’s longer-term vision extends this operating model beyond individual enterprise installations. It describes model builders, AI clouds, and infrastructure partners publishing into a trusted foundation in which the customer’s location ceases to determine which model can be licensed. Achieving that vision depends on making the underlying controls portable enough that moving between public, sovereign, enterprise-owned, and disconnected infrastructure does not require rebuilding the security model from scratch. Because VAST sells the infrastructure intended to support this model, the company would benefit if customers and model providers adopt that approach broadly.

Data sovereignty becomes a distribution and revenue constraint for model providers

If those controls become portable, model availability can extend into markets where customer data has to remain in a particular place. A cloud-only provider can address buyers free to send data into its cloud, while customers bound to other locations can be excluded before model quality enters the purchasing decision. That constraint can affect government, health care, financial services, and European opportunities where privacy, sovereignty, or regulatory requirements restrict deployment.

Manez connects those deployment limits directly to addressable markets. “If you can only run in the public cloud, your sales roster is heavy on consumer and non-regulated industries,” Manez says. “I‘m missing out on government. I could potentially be missing out on all of Europe. I‘m missing out on health care and financial services customers, which can be a lucrative market for these model builders if they meet the privacy and regulation requirements.” Those examples identify the kinds of markets at issue rather than establishing how large the opportunity will prove to be.

Serving those markets requires more than placing an on-premises software package beside enterprise data. A provider has to preserve the controls that made cloud delivery acceptable to it: protection of its weights, selective key release, deployment restrictions, and evidence of use. Meanwhile, banks, government agencies, health care organizations, and other regulated buyers have to retain their own permissions, egress restrictions, and records. The commercial model consequently depends on the same reciprocal controls as the technical architecture.

Manez argues that this operating model has become a commercial constraint on AI deployment. “The operating and revenue model is becoming the biggest inhibitor,” Manez says. “The model IP has evolved very quickly and it’s moving all the time. But without the operating model that satisfies the requirements of the enterprise, AI will feel like a hype bubble. There’s way more to it than a VM technology or a data encryption technology or a network technology. It’s the entire infrastructure and ecosystem around the model.” For model providers, the resulting deployment boundary is whether that ecosystem can make reciprocal controls enforceable and portable wherever the customer’s data has to stay.

Recap

For business leaders, the central question is no longer whether sensitive enterprise data should move to AI. In many regulated, sovereign, or disconnected environments, it cannot. The more practical question is whether organizations can bring advanced models to that data without forcing either the enterprise or the model provider to surrender control.

That makes confidential AI an operating-model decision as much as a security decision. Enterprises need permissions, retrieval controls, egress policies, and auditability to remain enforceable wherever workloads run. Model providers need equivalent assurances around their weights, key release, execution environments, and acceptable-use policies. Confidential computing and attestation provide important technical foundations, but their value depends on how consistently those controls work across the full infrastructure stack.

Executives evaluating these architectures should therefore look beyond whether a platform encrypts data or supports confidential GPUs. The more consequential question is whether it can preserve the same security and governance policies across public clouds, sovereign environments, private data centers, and air-gapped sites while giving both parties independent evidence that those policies were enforced.

If that operating model becomes practical at scale, data sovereignty becomes less of a barrier to model adoption and model distribution. Enterprises gain access to advanced AI without abandoning control of sensitive information, while model providers can reach regulated markets without giving up control of their intellectual property. The competitive advantage will come from making those reciprocal controls routine rather than rebuilding trust for every deployment.