The datacenter myth: Why sovereign AI demands a tenancy model, not just geography

There’s a version of the digital sovereignty conversation that stops at geography: Put the servers in-country, keep the data inside the border, tick the box. It was never quite enough for cloud, and in a regulatory era that has shifted from “trust us” to “show us,” it’s definitively not enough for AI.

AI services concentrate the exact things sovereignty platform providers care about—sensitive data, scarce accelerator capacity, opaque runtime behavior—into a single shared platform. The moment you offer those services to more than 1 consumer—whether that’s a government department, a regulated enterprise, or a business unit inside a telecommunications service provider—sovereignty stops being a question of where and becomes a question of how strongly separated.

That’s a multi-tenancy problem. And it’s one that Red Hat has been diligently converging on.

Deconstructing AI sovereignty

Red Hat frames AI sovereignty across 4 pillars: cyber resilience, model sovereignty, safeguarding sensitive data, and promoting economic interests. Reversibility is the connecting principle. An organization is sovereign to the degree it can control its infrastructure, data, and technology, and can leave a provider without breaking its operations.

Map that onto an AI services platform, and each concern turns into a concrete architectural requirement:

• Cyber resilience: A compromise in 1 tenant's AI workload must not become a compromise of the platform or of its other tenants. Blast radius is a sovereignty property.
• Safeguarding sensitive data: Tenant data used for fine-tuning, retrieval-augmented generation (RAG), or inference must be provably isolated, with control over where it rests, transits, and is processed.
• Model sovereignty: The tenant must be able to choose the model that best fits its needs and constraints.
• Economic interests and reversibility: The tenant must be able to take its models, data, and pipelines elsewhere. A "sovereign" AI platform you can’t exit is just a domestic lock-in.

The reversibility point deserves emphasis, because it’s where most AI platforms quietly fail. Regulators and industry standards are catching up here: The Digital Operational Resilience Act (DORA) and frameworks like the Cloud and AI Development Act (CADA), for instance, don’t just focus on standard compliance—they require institutions to prepare, test, and demonstrate exit plans while emphasizing AI safety and resilience. And they explicitly care about interoperability, portability, and avoiding lock-in. An AI platform built on proprietary serving runtimes and closed operational tooling can’t satisfy that, no matter which country the rack sits in.

Namespaces were never a sovereignty boundary

For years, Kubernetes multi-tenancy meant namespaces plus role-based access control (RBAC) plus network policy. That’s a fine boundary between cooperating teams. But it’s a weak one between distrusting tenants—which is exactly the relationship a sovereign AI service provider has with its customers.

The uncomfortable truth is that soft multi-tenancy shares a control plane, a kernel, and—critically for AI—a set of physical accelerators. Workloads in different namespaces still contend for the same underlying system resources. When your tenants are a ministry, a bank, and a hospital, "logically separated but physically shared, with a shared application programming interface (API) server" is a hard story to tell an auditor who expects a verifiable, zero trust architecture.

The traditional answer was to give every tenant its own cluster. That answer is correct and, at scale, can be ruinous. Three control plane nodes per tenant, per environment is a tax that makes sovereign AI economically unviable for anyone but the largest providers. This, ironically, recreates the concentration risk that sovereignty policy was meant to solve.

Hosted control planes change the economics of hard isolation

Hosted control planes (the downstream of the HyperShift project) break the assumption that a strong tenant boundary has to be expensive. Instead of dedicating master nodes to every cluster, control planes run as pods in isolated namespaces on a shared management cluster, while worker nodes are attached via the NodePool API. Paired with Red Hat OpenShift Virtualization, those workers run as virtual machines (VMs), compressing the hardware footprint dramatically and delivering the predictable, stable economics required for operational and economic sovereignty. This gives each tenant a real cluster: their own API server, their own etcd, and their own upgrade cadence.

Where Red Hat AI Enterprise comes in

None of the above is AI specific. What makes it a sovereign AI story is that Red Hat AI Enterprise runs on it.

Red Hat AI Enterprise on a hosted, virtualized cluster means a tenant gets its own AI platform—its own workbenches, pipelines, model registry, and vLLM-based serving stack—inside its own cluster boundary, on shared physical infrastructure it never sees. The accelerator question is closing too: Graphics processing unit (GPU) attachment to hosted cluster NodePools has been progressing through preview, which is the last structural gap between "hosted clusters are great for applications" and "hosted clusters are where we run inference."

That combination lets a sovereign provider—a national cloud, a telco offering AI services, a regulated enterprise serving internal business units—offer something that has been genuinely hard to offer before: a per-tenant, Model-as-a-Service utility with a hard isolation boundary, on domestic infrastructure, running an open stack with transparency the tenant could take with it.

Each of those items is critical. Drop the isolation and you fail the auditor. Drop the domestic infrastructure and you fail the regulation. Drop the open source stack and verifiable AI bill of materials (BOM) and you fail reversibility. And reversibility should be the core principle the whole sovereign cloud approach is built on.

Red Hat AI Enterprise benefits from scale and sovereign controls from the underlying platform provided by cloud extensions for Red Hat platforms, including Red Hat OpenShift, which extends tenancy controls even further. 

The accelerator is the remaining hard problem

Honesty compels a caveat: The cluster boundary is now solvable. The accelerator boundary is still where the interesting work is.

GPUs were not designed as multi-tenant security devices. Whether you’re slicing with multi-instance GPU (MIG), mediating with virtual GPUs (or vGPUs), or time-slicing, you’re making a trade between isolation strength, use, and operational complexity. And the strongest isolation is also the least efficient, which is precisely the tension a sovereign provider can’t escape. To help break this tension, Red Hat AI gives you the ability to change isolated hardware into a cluster-wide GPU-as-a-Service (GPUaaS) utility. By introducing dynamic fair-share GPU scheduling, the platform provides each tenant a guaranteed GPU quota while automatically making idle capacity available for other tenants to borrow. In many cases, this increases use from 30% to 80% without sacrificing control.

Add confidential computing to the picture (protecting data in use inside an attested trusted execution environment, so even the platform operator can’t see tenant data during processing) and you have the genuinely complete sovereignty story: data protected at rest, in transit, and in use. The ongoing work on confidential containers and confidential VMs is what closes that final gap.

This is where "safe multi-tenancy" as an ongoing engineering effort matters more than any individual feature. The question is not whether 1 isolation primitive is sufficient. It’s whether the platform composes them coherently: 

• Hypervisor isolation for the node
• A dedicated control plane for the cluster
• Accelerator partitioning and fair-share scheduling for the device
• Confidential computing for the runtime
• Policy as Code (PaC) holding the whole thing to a stated posture

The takeaway

Sovereign AI is not a datacenter location. It’s an isolation model, a governance model, and an exit plan.

Hosted control planes and OpenShift Virtualization solve the economics of hard isolation. Red Hat AI Enterprise running on that foundation turns it into a comprehensive metal-to-agent AI platform rather than just a Kubernetes one. Red Hat Advanced Cluster Management for Kubernetes provides the fleet-wide policy enforcement that makes the claim auditable. And the open source foundation—upstream first, portable, with an operational model that can be taken elsewhere—is what keeps the whole thing from becoming a domestic lock-in wearing a sovereignty badge.

The shape of the answer is now clear, and it’s a good deal more concrete than "keep the data in-country."

Learn more about Red Hat's blueprint for sovereign AI

A note on where AI sovereignty goes next: The same argument applies 1 layer up. If the AI services that a tenant consumes are agentic—calling tools, touching data across systems—then observability of the agent's execution, not just of the cluster, becomes part of the sovereignty and auditability story. With the rise of AgentOps, traces are the new logs. But that's a different post.