Sovereign and Confidential Deployment: VPC, On-Prem, Air-Gapped, and TEEs

Ask most teams where their AI runs and you get a single answer: the cloud, or on-premises, or, if they are cautious, air-gapped. One topology, chosen once, applied to everything. It is a tidy decision, and for an unregulated business it is usually fine.

However, in a regulated enterprise a single deployment topology is either wasteful or dangerous, and often both at once. Deployment topology is not one choice you make for the whole system. It is a routing rule driven by data sensitivity, and it has to fail closed. Pick one topology for everything and you either over-constrain cheap, non-sensitive work by locking it inside an air-gap it never needed, or, far worse, you let regulated data flow to a place it should never have gone because that place was convenient for something else. The right model is a spectrum of topologies, and a rule that routes each workload to the least-exposed environment its data class permits.

There is also a newer point on that spectrum most reference architectures skip, and it is the one that solves the hardest case: how to process regulated data on infrastructure you do not physically control without exposing it, using confidential computing and trusted execution environments. That is where this gets genuinely interesting.

The topology spectrum, routed by sensitivity

Think of deployment as a ladder of decreasing exposure, and data sensitivity as the thing that decides how far up you have to climb for each workload.

At the low-exposure-tolerant end sits a cloud account you bring yourself, giving elasticity and the lowest operational burden, at the cost that data leaves your account for the model's region if you allow it. Above that, a VPC pinned to a region keeps data inside your own cloud perimeter and your required residency zone, in exchange for you operating the boundary and the routing. Higher still, on-premises deployment gives full physical control when the rules bar external processing at all, and hands you the capacity planning and GPU operations in return. At the top, an air-gapped environment removes the egress path entirely for the highest-sensitivity work, and you pay for that isolation with manual, deliberate model updates and operations.

The mistake is to read that ladder as a menu and pick one rung for the whole organization. It is not a menu. It is a routing table. You classify the data a given workload carries, and the classification tells you the lowest rung that workload is allowed to run on. A single business process routinely spans classes: one step reads a regulated dossier and belongs high on the ladder, another drafts a generic notification and can sit low. So the routing happens per step, not once for the system, and the same process can touch two topologies inside one run.

Confidential computing: processing regulated data you cannot fully isolate

Here is the case the classic ladder handles badly. Sometimes you need the elasticity or the specialized hardware of infrastructure you do not physically own, but the data is too sensitive to expose to whoever runs that infrastructure. The air-gap says no. The VPC says "trust your cloud provider's operators." Neither is satisfying when the threat model includes the platform itself.

This is what confidential computing addresses, and the mechanism is a trusted execution environment, a TEE. A TEE is a hardware-enforced enclave in which data is decrypted and processed while remaining encrypted everywhere else: in memory, the enclave holds it in a region the host operating system, the hypervisor, and the cloud operator physically cannot read. The data is protected not just at rest and in transit, the two states everyone already secures, but in use, the state that has historically been the gap. The workload runs, the regulated data is processed, and the operator of the machine it ran on never had the ability to see it.

Two properties make this a control rather than a claim. The enclave is enforced by the CPU hardware, not by software configuration that a privileged operator could disable. And remote attestation lets you cryptographically verify, before you send any data, that the code running inside the enclave is exactly the code you expect and that it is genuinely running in a real TEE. You do not trust the operator's assurance that your data is protected. You verify the enclave, then release the data to it, and the verification is a signature you can keep as evidence.

For a regulated organization, this reframes a decision that used to be binary. The old question was "own the hardware, or expose the data." Confidential computing adds a third answer for a specific, valuable slice of workloads: run on hardware you do not own, over data you could not otherwise expose, because the environment is attested and the operator is cryptographically locked out. It does not replace on-prem or air-gap for the most extreme cases. It extends the reach of sovereignty to places it previously could not go.

Sovereignty routing that fails closed

A spectrum of topologies is only as safe as the rule that assigns workloads to it, and the property that makes that rule defensible is a specific one: it fails closed.

The routing policy classifies data by sensitivity and pins each class to the topologies it is permitted to run on. Regulated and PII data stays inside your perimeter by default, whether that perimeter is a region-pinned VPC, on-prem, an air-gap, or an attested enclave. Only explicitly non-sensitive workloads may reach an external-region model, and only when a policy has allowed that class to leave. The decisive part is what happens under uncertainty: when a classification is ambiguous, the system treats the data as sensitive and keeps it in the most protected environment its possible classes allow. The default protects you. Relaxing it takes a deliberate, logged decision, not an omission.

That is the difference between "your data never leaves your walls" as a marketing line and as an architecture. As an architecture, egress is denied by default and permitted only per explicit policy, per data class, per step, with each relaxation recorded. A misconfiguration does not silently open a door, because the door is closed unless something deliberately opened it. Fail-closed is the whole reason a supervisor can believe the sovereignty claim, because it means the failure mode of the system is over-protection, not leakage.

DORA and residency are the drivers, not the paperwork

None of this is engineering for its own sake. It is the shape that regulatory obligation forces, and two obligations in particular drive it.

Data residency is the blunt one. Rules that require certain data to remain within a jurisdiction turn "where does the model run?" into a legal question with a physical answer. A region-pinned VPC, an on-prem cluster, or an attested enclave in the right jurisdiction is not a preference; it is how you satisfy a rule that a convenient default region would breach. Operational-resilience regimes such as DORA push in a parallel direction: they care about concentration risk and about your ability to keep a critical process running and inspectable, which is exactly what a routed, provider-agnostic, deploy-anywhere posture provides and a single hardcoded topology does not. When your deployment is a routing rule you own rather than a vendor's default, you can demonstrate to a supervisor both where regulated data stays and how the process survives a provider or region becoming unusable.

So the question to bring to your next architecture review is not "cloud or on-prem?" It is for each class of data in this process, what is the least-exposed environment it is allowed to run in, does routing send it there by default, and does the system fail closed when it is not sure? If you can answer that per data class, and if confidential computing has extended your reach to the workloads that used to force an impossible choice, you have a sovereignty architecture. If your answer is one topology for everything, you have a hope that nothing sensitive ever takes the convenient path.

If you want to map your data classes to permitted topologies, and find where an attested enclave changes the answer, book a meeting and bring us the process with the most jurisdictionally sensitive data in it.