What enterprises need to control in sovereign AI infrastructure

Sovereign AI infrastructure is usually discussed as a question of where servers sit: which country, which data center, and which cloud region. That framing is incomplete, for enterprises and for nations. Sovereign cloud regions and domestic data centers answer where compute runs physically. They say very little about whether an enterprise, or a country, controls the models running on that compute, the data feeding them, or the people who can reach them. What follows is the governance and deployment framework that sits above the data center. It is the part of sovereign AI that determines whether control is real or only geographic.

This distinction matters because the stakes are no longer abstract. Governments increasingly treat AI infrastructure as critical infrastructure, comparable to power or telecommunications. This is because AI capability now touches national security and long-term economic growth at the same time.

Enterprises face a narrower version of the same problem. A vendor's support engineer with standing access to a production environment can read the data in it, whatever the contract says about residency. An evaluation run on a third party's infrastructure exposes a model's failure modes as readily as its training data would. And the models themselves are now a target. Google's threat intelligence team reported in February 2026 that distillation attacks, in which a competitor queries a model through its API to train a derivative, had moved from research into practice, and that a model tuned for one enterprise's domain can be targeted by a competitor looking to build a derivative product. Neither a vendor's data center location nor a national border resolves any of this on its own. Sovereign AI, at either scale, rests on control across the models, the data, the compute, and the access that AI systems depend on, and on having the people who can operate all of it. That control is what this framework addresses at the enterprise AI platform layer, and it is where Gartner's September 2026 research on technology sovereignty (The Gartner Value-Risk Flywheel for Technology Sovereignty) frames it as well, as a question of dependencies rather than locations.

Data residency vs data sovereignty vs sovereign AI

These three terms get used interchangeably, and the confusion causes planning mistakes.

Data residency is the narrowest of the three. It means data physically stays within a defined geographic boundary, usually a country's borders, though a large enterprise may draw its own. A regional cloud instance can satisfy data residency without granting any other kind of control.

Data sovereignty goes one step further. It covers not just where data sits but whose laws or regulations govern it, who can compel access to it, and under what legal process. An enterprise can meet data sovereignty requirements and still be running its models on infrastructure it does not own, using vendor-controlled tooling it cannot fully audit.

Sovereign AI is the full-stack expression of digital sovereignty. An enterprise or a nation retains authority over its infrastructure, its data, its models, and the talent required to run all of it. An organization can achieve data sovereignty and still fail to achieve sovereign AI, typically because the models and the AI systems layered on top of that data remain outside its control. That gap is exactly what the rest of this framework addresses. Closing it means tracing hidden supply chain dependencies, overlapping jurisdictions, and proprietary lock-in across every vendor in the stack, a far larger task than locating data centers on a map.

The four control layers of sovereign AI infrastructure

Meeting sovereign AI infrastructure requirements means controlling four layers of the enterprise AI platform that decide how AI systems are built, scaled, and governed. The dictionary definition names compute, data, and model sovereignty. This framework adds a fourth layer, access, because it is the one that gets left out when sovereignty is defined by location. Each layer closes a different failure mode, and a gap in any one undermines the other three. BARC's 2026 governance research found that 62% of governance teams concentrate their controls on the data layer, while only 45% have adopted model-layer controls and 43% infrastructure-layer controls.

Model control, with weights, registries, and lineage

Model control means knowing exactly which model weights are running in production, where they came from, and what changed between versions. A private model registry, holding every approved model image and checkpoint, is the mechanism that makes this auditable. Lineage tracking extends that further. For any output, an enterprise should be able to trace which model version, which training data, and which fine-tuning run produced it. An enterprise cannot govern its models if it cannot see how they were trained. Few organizations have this capability in place today. BARC found that 23% of organizations use model registry and inventory tools, and 26% use model monitoring and observability tools.

Data control, with residency, pipelines, and AI artifacts

Data control covers more than storage location. It includes the pipelines that move sensitive data from source systems into training or inference, and it includes what those pipelines generate along the way. These are artifacts such as embeddings, logs, cached prompts, and intermediate datasets. Each of those artifacts can carry as much exposure risk as the original source data, and each needs the same governance applied to it.

Compute control, or where training and inference run

Compute control determines whether training and inference happen on infrastructure the enterprise can fully inspect, or on infrastructure it can only trust by contract. This is the layer hyperscaler AI factories are usually built to address. But it is one layer among four rather than the whole answer. Compute control also shapes how data moves between training and inference environments, since that movement is itself a point of exposure. An enterprise can own every GPU in a data center and still lose control if the models and data running on those GPUs are managed by someone else's tooling.

Access control, with identity, keys, and operator access

Access control is the layer that decides who, human or machine, can reach the model and under what identity. It includes the credentials and keys used to call an endpoint. It also covers operator access, the vendor's own support and engineering staff, which enterprises frequently overlook. An LLM gateway that logs every request against the calling user's identity turns access control into an audit trail. It is also the layer that most directly closes the path a distillation attack takes, because every call to the model arrives with an identity attached and can be budgeted, rate-limited, and reviewed.

Governing sovereign AI models across the lifecycle

Control at a single point in time is not enough. Sovereign AI models need governance across the full lifecycle, from selection through retirement.

Selecting open-weight and self-hosted models

The starting choice is which foundation models to run at all. Open-weight models can be inspected, self-hosted, and constrained in ways a closed, API-only model cannot. Open-weight models can also be adapted to a specific language and culture in ways a closed model's provider may never prioritize. Openness alone does not make a model sovereign. It is a precondition that closed models cannot offer regardless of contract terms, and sovereignty is then measured by how much control the enterprise holds over the architecture around the model.

The tradeoff is that open-weight models sometimes trail closed frontier models on raw capability. An enterprise has to decide how much of that gap it is willing to accept in exchange for verifiable control. Gartner expects open-weight models to account for half of enterprise AI use cases by 2028, up from about 20% today. The added control over data and operations, and the freedom from vendor lock-in, come with a requirement for deeper in-house technical expertise.

Fine-tuning and evaluation within jurisdiction

Once a base model is selected, fine-tuning is where an enterprise's most sensitive data meets the model. Running that fine-tuning process inside the enterprise's own jurisdiction, rather than sending proprietary data to an external service for adaptation, is what keeps refinement from becoming a second data-export channel. Evaluation deserves the same treatment. Evaluation runs on external infrastructure can leak as much about a model's real capabilities and failure modes as the training data itself.

Model approval, versioning, and audit trails

The last piece of lifecycle governance is procedural. It is a documented approval step before a model reaches production, a versioning scheme that makes rollbacks possible, and an audit trail that survives long after the person who approved the model has moved to a different role. Governance that only exists informally, in one engineer's memory, is not governance that regulators overseeing AI systems will accept.

Deployment patterns for sovereign AI infrastructure

The four control layers can be assembled into more than one working deployment. The right pattern depends on how strict the enterprise's residency and isolation requirements are.

Fully sovereign on-premises deployment

The strictest pattern runs entirely inside an enterprise's or country's own network, sometimes fully air-gapped, with no traffic leaving the boundary. A private container registry holds every image the deployment uses. Model weights are loaded and served locally, typically through an inference layer running on GPUs the enterprise owns or leases outright. An LLM gateway sits in front of the model, enforcing access control and logging every request. This pattern gives up the elasticity of a shared cloud in exchange for the strongest possible guarantee that data and models never leave the enterprise's control.

Central control plane with local data planes

Multinational enterprises, and national governments with many agencies, rarely need one uniform answer everywhere. Segmenting workloads into strict sovereignty tiers keeps localized constraints from applying everywhere by default. A more common pattern pairs a single control plane for governance, policy, and orchestration with local data planes that keep each region's sensitive data and inference workloads inside that region's own jurisdiction. An LLM gateway deployed in each region enforces the same access rules and logging everywhere. This is the pattern that lets a single platform team enforce one governance standard globally.

Sovereign cloud and regional deployment

Sovereign cloud regions, offered by most major cloud providers, satisfy data residency and often satisfy compute control. They rarely satisfy model control or access control on their own, since the platform layer running on top of that infrastructure is frequently still managed by the enterprise's AI vendor rather than the enterprise itself. BARC's Data Sovereignty 2026 survey points to lingering doubt. Only 10% of respondents expressed interest in European sovereign cloud offerings from US hyperscalers. A sovereign cloud region is a legitimate part of a deployment pattern. It is not, by itself, sovereign AI infrastructure.

Sovereign AI infrastructure for government agencies

Government agencies tend to face the strictest version of every requirement above, which makes public sector deployments a useful stress test for the whole framework.

Classified and controlled workloads

A defense or intelligence agency running AI-assisted work against classified or controlled data typically requires a deployment closer to the fully sovereign on-premises pattern than to any sovereign cloud offering. In practice, that looks like a Kubernetes cluster running inside a physically air-gapped enclave, a GPU node serving an open-weight model through an OpenAI-compatible endpoint, and a private registry holding every image moved across the air gap under a documented import process. Every request is logged against the requesting user's identity, and no traffic leaves the network at any point. Domino has built this pattern for government and defense customers.

Cross-agency governance and auditability

A single agency's air-gapped environment solves isolation but not coordination. Agencies that need to share models, evaluation results, or governance standards across programs need the same orchestration layer described earlier in this framework, applied at a larger scale. The goal is one governed environment that enforces a consistent approval and audit standard across otherwise separate deployments, and how that is built depends on the enclaves.

Where each enclave keeps a live management connection to a central control plane, that control plane holds policy and metadata and never holds data, prompts, or secrets. Where the enclaves are fully air-gapped, the policy set itself crosses the boundary as an artifact, through the same documented import process as a model, so every enclave runs the same rules without any enclave talking to another.

Sovereign AI infrastructure readiness checklist

Before committing to a deployment pattern, an enterprise or agency can run its current stack against a short set of questions:

• Can you name the exact model weights and version running in production today, and trace the training and fine-tuning data behind them?
• Does any sensitive data, or any AI artifact derived from it, leave your security boundary at any point, including during evaluation?
• Do you control where training and inference physically execute, or only where the contract says they execute?
• Can you produce a log, tied to an individual identity, for every request a model has served in the last twelve months?
• If your model vendor were acquired or discontinued tomorrow, could you continue operating without it?
• Does your governance process survive a change in personnel, or does it live in one person's institutional knowledge?

An answer of no to any of the first four is a gap in one of the four control layers. The last two ask whether that control outlasts a change in vendor or in staff, and the vendor question will apply to more organizations over time as model vendors consolidate, reprice, and retire models.

Why enterprise platforms simplify sovereign AI infrastructure

Assembling all four control layers for every deployment is where most sovereign AI efforts stall. An enterprise platform that already implements model control, data control, compute control, and access control as a single governed environment turns a four-part infrastructure project into a configuration exercise.

This is what Domino provides across financial services, pharma, and government deployments. It includes a private registry and model lineage for model control, pipelines that keep sensitive data inside the boundary and where necessary air-gapped for data control, deployment options that run wherever the enterprise's GPUs live for compute control, and an LLM gateway logging every request by identity for access control. The same platform extends to the talent requirement that sits underneath all four layers, since none of this holds up over the long term without the people in place to operate it.

Model control, data control, compute control, and access control are how sovereignty becomes operational at the platform layer. This piece has stayed close to that layer because it is where the gaps show up. The air-gapped build itself, what has to be mirrored, staged, and imported before a model runs, is the subject of a companion piece.

FAQs

What is the difference between data residency and sovereign AI infrastructure?

Data residency answers one question: where does data physically sit, usually within a country's borders. Sovereign AI infrastructure asks more: who controls the models running on that data, who can access them, where training and inference execute, and who operates the platform end to end. An enterprise can satisfy data residency by choosing the right cloud region and still have no control over the model, the vendor's operators, or the pipelines feeding it. Data residency is typically the easiest layer to satisfy, since most cloud providers now offer regional options. Model control, compute control, and access control require deliberate platform decisions on top of that choice.

What does an enterprise need to control to achieve sovereign AI?

An enterprise needs control across four layers: model, data, compute, and access. Model control means knowing which weights are running and how they changed over time, usually through a private registry and lineage tracking. Data control covers residency and the pipelines and artifacts, such as embeddings and logs, that move sensitive data into training or inference. Compute control means training and inference run on infrastructure the enterprise can inspect directly. Access control governs identity and credentials, including the vendor's own operator access, typically enforced through a logging gateway. A gap in any layer undermines the rest, and the enterprise needs the talent to operate all four before calling its AI stack sovereign.

Are hyperscaler sovereign cloud offerings enough for sovereign AI?

No, not on their own. Sovereign cloud regions reliably satisfy data residency and often satisfy compute control, since the provider can guarantee servers stay inside a specific country. They rarely satisfy model control or access control, because the platform running on top of that infrastructure is frequently still managed by a separate vendor, using that vendor's own registries and operator access. An enterprise can run a sovereign cloud region and still be unable to say who can access its models or whether the vendor's staff can reach production data. Sovereign cloud is a legitimate part of a deployment pattern, but the platform layer covering models, pipelines, and access still has to be built or governed separately.

How are sovereign AI models governed differently from hosted foundation models?

Hosted foundation models are governed by the provider's terms of service and contractual assurances, such as zero-data-retention agreements, which rely on trusting the provider's process rather than verifying it directly. Sovereign AI models are governed by the enterprise itself, using its own registry, approval workflow, and audit trail, regardless of whether the weights are open or licensed. That means the enterprise can trace lineage from training data to production output, control which version is running, and log every request by identity. Fine-tuning and evaluation also happen inside the enterprise's own jurisdiction. The practical difference is verifiability. One kind of governance is something an enterprise is told about, and the other is something it can inspect directly.

How do public sector agencies deploy sovereign AI infrastructure?

Government agencies typically deploy sovereign AI infrastructure at the strict end of the spectrum, closer to a fully sovereign on-premises pattern than to any cloud option. A common architecture runs a Kubernetes cluster inside a physically air-gapped enclave, with a dedicated GPU node serving an open-weight model behind a gateway that logs every request against the user's identity. Software and model weights move in through a documented import process, and no traffic leaves the network once live. Agencies coordinating across programs extend the same governance standard across several enclaves, as a policy set that crosses each boundary through the same import process as a model.

Sources

BARC, Data Sovereignty 2026: Reality, Relevance, Roadmap, April 2026.

BARC, The State of Data and AI Governance: Requirements and Best Practices to Safeguard Innovation, September 2026.

Gartner, Open-Weight Models Must Be Part of Your AI Stack, but at a Cost, 3 September 2026.

Gartner, The Gartner Value-Risk Flywheel for Technology Sovereignty, 14 September 2026.