Compute With Legal Identity

A CTO who designed a clean global architecture in 2022 can now discover, late in the review cycle, that an inference endpoint handling French customer data cannot sit on infrastructure where an American employee holds administrative authority over the control plane. That is not a policy footnote. It changes where the workload can live, how it can be operated, and which platform patterns remain viable.

The borderless cloud was never as borderless as its marketing suggested. But in the 2026 build window, the change is sharper. The same container image, the same virtual machine, and the same inference stack can become a different asset depending on the legal entity operating the environment, the residency and employer of the people with privileged access, the sovereignty regime governing the platform, and the ownership chain above it. In practical terms, compute now carries legal identity.

Jurisdiction is no longer an external wrapper placed around infrastructure after the design is complete. It now behaves like a first-class design constraint, on the same tier as latency, throughput, resilience, and cost. Systems designed on the assumption that any compliant European region is functionally equivalent are increasingly brittle because they ignore a property that now shapes both deployment and operations.

This is not a compliance article. It is an architecture article.

The Three Sovereignty Archetypes

The market has already produced reference architectures for this shift. The most useful way to read them is not as vendor positioning but as three sovereignty archetypes: three different answers to the same question. What has to be local, who has to operate it, and how much foreign dependency can remain in the stack.

The first archetype is the Trusted Operator. In this model, hyperscale technology is retained, but the operating entity is domestic and the platform is reconstituted under national control. S3NS, the joint venture between Thales and Google Cloud, is the clearest example. S3NS is a French-law company fully controlled by Thales. Google provides the technology stack. Thales controls operations, personnel, and data access through S3NS employees in French data centers. The architectural differentiator is the quarantine: cloud technology updates from Google are not pushed directly into the sovereign environment. They are quarantined, analyzed, and validated by S3NS before deployment. That is not a cosmetic sovereignty layer. It is a distinct operating model with deliberate friction inserted into the technology supply chain.

S3NS received SecNumCloud 3.2 qualification from ANSSI on December 17, 2025, becoming the first offering to cover IaaS, CaaS, and PaaS simultaneously in a single ANSSI decision. Its commercial offering, PREMI3NS, entered general availability after an early access program with more than 50 clients. The current service catalog includes Compute Engine, Cloud GPUs with NVIDIA H100s, BigQuery Enterprise, GKE Autopilot, Cloud SQL Enterprise Plus, and monitoring services, with 15 additional services planned for H1 2026 and Vertex AI joining in H2 2026. Customers include organizations across insurance (MGEN, Matmut, AGPM), finance (Qonto, BConnect), energy (EDF, Birdz/Veolia), and hospitality (Club Med). Thales itself has migrated 70% of its internal cloud workloads to the platform.

Bleu, the joint venture between Orange, Capgemini, and Microsoft, follows a similar model for sovereign Azure. Delos Cloud, a partnership between SAP and Arvato using Microsoft Azure Stack, serves the German public sector. The structural pattern is consistent across all three: domestic operational control, foreign technology supply, legal separation at the entity level.

The second archetype is the Isolated Region. Here, the hyperscaler does not hand operational primacy to a national joint venture. Instead, it builds a ring-fenced sovereign environment inside its own corporate structure. AWS European Sovereign Cloud is the most developed current example, launched to general availability on January 15, 2026, from its first region in Brandenburg, Germany. The infrastructure runs through dedicated German legal entities under German law, with EU-citizen managing directors and an advisory board composed exclusively of EU citizens. It launched with more than 90 services and is physically and logically separated from global AWS regions, with dedicated IAM, billing, and Route 53 configured for European top-level domains. AWS has committed €7.8 billion in investment through 2040.

The attraction is obvious. The service surface remains recognizably AWS. The migration path from existing AWS deployments is shorter than in a Trusted Operator model. But the caveat is equally important. AWS ESC GmbH is a 100% subsidiary of Amazon.com, Inc. It remains subject to the US CLOUD Act because of its ownership structure, regardless of where the data sits or who operates the systems. It also does not currently meet BSI 200km geo-redundancy requirements until Local Zones expand to Belgium, the Netherlands, and Portugal. Analysts applying the European Commission's Cloud Sovereignty Framework score it low on strategic and legal sovereignty dimensions. And there is a historical precedent worth noting: Microsoft Cloud Deutschland, a similar isolated-region model, was discontinued in 2021. Isolation of the region is not identical to isolation of the ownership layer.

The third archetype is the Air-Gapped Factory. Google Distributed Cloud Air-Gapped is the reference: a fully disconnected sovereign cloud environment for defense, intelligence, and critical infrastructure. Zero public internet connectivity. Updates arrive through secure, one-way transfers. It is the most sovereign of the three archetypes and the least functionally rich. The trade-off is absolute.

Three models, three very different architectural implications. Choosing between them is a design decision on par with choosing between active-active and active-passive, or between managed services and self-managed platforms. Most enterprises do not yet treat them that way.

!three sovereignty archetypes

Why Uniform Sovereignty Is the Expensive Mistake

The most common strategic error is to treat sovereignty as a binary flag. Sovereign or not sovereign. Compliant or not compliant. Once that framing takes hold, the entire stack gets pushed toward the most restrictive tier. Costs rise, feature velocity slows, operational flexibility collapses, and a surprising share of migrated workloads never needed that treatment in the first place.

The better frame is segmentation by jurisdictional risk. That is the point of the Sovereignty Portfolio: a deliberate allocation of workloads across different infrastructure types based on jurisdictional exposure rather than a uniform policy applied to the entire stack.

Segmentation follows a clear hierarchy. Inference control planes handling regulated customer data for specific jurisdictions carry the highest exposure and belong in a Trusted Operator environment. Proprietary model weights that constitute competitive advantage sit one tier below: they require domestic operator control because they are strategic assets, but they may not need the full SecNumCloud treatment. Anonymized training data for models that will never touch regulated customers represents a third tier, where standard cloud regions often suffice. Generic experimentation and R&D workloads carry the lowest jurisdictional exposure and should run where they are most cost-effective.

The evidence for segmentation is already visible in practice. EDF, one of France's most strategically sensitive enterprises, has selected both S3NS and Bleu as trusted cloud providers and has stated that, depending on sensitivity, it will host data on public cloud solutions, trusted cloud solutions, or its own data centers. That is not indecision. It is architecture. One enterprise, multiple workload classes, multiple sovereignty treatments, multiple commercial partners.

The Sovereignty Portfolio is the infrastructure equivalent of a financial portfolio. Not every asset needs the same level of protection. Over-protecting low-risk workloads is waste. Under-protecting high-risk workloads is exposure. The goal is match quality between the sovereignty treatment and the jurisdictional risk of each workload class. The CTO building a Sovereignty Portfolio asks a different question than the CTO applying uniform sovereignty. The uniform approach asks whether this is compliant. The portfolio approach asks what the minimum sufficient sovereignty treatment is for this workload, given its jurisdictional risk profile and the regulatory trajectory it faces over the next 24 months.

The enterprises paying a premium on every workload they run have confused compliance with architecture. The ones building Sovereignty Portfolios are treating jurisdiction as a design variable. Only one of those approaches scales.

!sovereignty portfolio workload segmentation

Legal Identity as Architectural Layer

Infrastructure has always had physical properties. Location, latency, throughput, cost, reliability. These are the constraints architects design around. They are measurable, non-negotiable, and cannot be wished away. Sovereignty adds a new class of property to this list: legal identity.

A VM now has a nationality in the same functional sense that a ship has a flag state. The nationality is determined by four factors: the operating entity's jurisdiction, the personnel with administrative access, the regulatory framework governing the data center, and the ownership structure above the operating entity.

Legal identity operates at the same tier as latency. It is not a policy wrapper applied after deployment. It is a constraint the architect must design around from the first whiteboard session, because retrofitting legal identity into a running stack requires re-architecting the operational model, the personnel chain, the entity structure, and frequently the vendor relationship itself. That is not a migration. That is a rebuild.

Three practical implications follow.

First, data locality is no longer sufficient. For a decade, the primary sovereignty question was "where does the data sit?" That question now produces incomplete answers. Operational locality, meaning who can touch the system and under which employer and jurisdiction they operate, matters independently. A VM can hold French data in a French data center and still be administered by an SRE employed by a US entity, creating an exposure path that data residency alone does not close.

Second, CLOUD Act exposure is an architectural property, not merely a legal one. AWS European Sovereign Cloud meets every data residency requirement. Data stays in Germany. EU citizens operate the systems. The infrastructure is physically separated. And it still sits under US CLOUD Act jurisdiction because AWS ESC GmbH is wholly owned by Amazon.com, Inc. That is not a compliance gap. It is a structural feature of the ownership layer that the architect must account for in workload placement decisions.

Third, the technology supply chain becomes a sovereignty vector. When PREMI3NS quarantines Google Cloud technology updates and subjects them to independent review before deployment, that is not a deployment model. It is a technology governance model that addresses whether a foreign technology partner can push code into a sovereign environment without domestic review. Most cloud arrangements do not include this control.

These three implications map to a framework worth naming: the Sovereignty Stack. Four layers, each independently assessable. Layer one is data: where data physically resides. Layer two is operational: who operates the systems and under which employer. Layer three is legal: under which national law the operating entity is constituted. Layer four is ownership: under which jurisdiction the parent entity that controls the operating entity sits.

A workload can be sovereign at the data layer and exposed at the ownership layer. That is precisely the architectural profile of AWS European Sovereign Cloud. A workload can be sovereign at all four layers. That is the profile of a Trusted Operator model with SecNumCloud qualification. The Sovereignty Stack gives architects a diagnostic tool for reasoning about these differences with precision rather than treating sovereignty as a single binary attribute.

!sovereignty stack four layers

The CTO who understands sovereignty as a stack can reason about it layer by layer. The CTO who treats it as a single flag will consistently misjudge where exposure actually lives.

What I See in Architecture Reviews

The patterns are consistent enough to catalog.

The most common error I encounter is architects designing around data residency and assuming the rest follows. They select a European region, confirm data stays in the EU, and treat the sovereignty question as resolved. It is not resolved. It is one layer of four. The operational, legal, and ownership layers remain unexamined, and those are frequently where the actual exposure sits.

The second pattern is treating "region equals Europe" as sovereignty. Deploying to eu-west-1 does not make a workload sovereign. It makes the data European. The operating entity, the personnel chain, and the ownership structure above the cloud provider are unchanged by region selection.

The third pattern is ignoring operational locality entirely. I have reviewed architectures where the data residency controls were meticulous and the SRE team with root access to the control plane was entirely based in the United States, employed by a US entity, subject to US legal process. The architects had not considered the personnel chain as a sovereignty surface.

The fourth pattern is failing to audit the ownership chain above the cloud entity. The question "who is your cloud provider?" has a different answer depending on whether you mean the entity on the contract, the entity operating the infrastructure, or the entity that owns both. These can be three different legal persons in three different jurisdictions.

The fifth, and perhaps most consequential, pattern is building policy firewalls that cannot survive a foreign legal demand. If the operating entity is a subsidiary of a foreign parent, a legal demand served on the parent can compel access through the subsidiary. Policy controls at the subsidiary level do not override legal authority at the parent level.

On the other side, the architects getting this right share identifiable practices. They treat legal identity as a design constraint at the architecture review stage, not as a compliance sign-off at the end of the process. They select sovereignty archetypes by workload class, building the Sovereignty Portfolio rather than applying a uniform standard. They read the fine print on joint-venture structures versus subsidiary arrangements, because the difference between a JV and a subsidiary is the difference between domestic operational control and foreign ownership-chain exposure. And they ask a question that cuts through ambiguity faster than any framework: which specific legal entity employs the SRE who would execute a subpoena response?

Legal identity is showing up in architecture reviews whether the architect included it or not. The only variable is whether it is caught at the design stage or discovered after deployment.

The CADA Horizon

Everything described above operates under current law. The regulatory trajectory over the next 24 months will intensify these dynamics significantly.

The EU Cloud and AI Development Act is a Commission proposal scheduled for Q1 2026. Its legal basis is Article 114 TFEU: internal market harmonization, which means a binding regulation with direct effect across all member states. Not a voluntary framework. Not guidelines. Not a directive requiring national transposition. A regulation. It originated from the Draghi report on EU competitiveness in September 2024 and falls under Executive VP Henna Virkkunen's Tech Sovereignty portfolio.

The stated goals include tripling EU data center capacity within five to seven years and fully meeting EU business and public administration cloud needs by 2035. The mechanisms under discussion include harmonized fast-track permitting for data center construction, strategic grid integration for energy supply, capital support through the European Competitiveness Fund, and a single EU-wide cloud policy for public administrations and procurement. A public consultation ran from April through July 2025.

The context statistics frame the ambition. The US currently holds approximately twice Europe's share of global data center capabilities, despite comparable GDP. Three US-based companies account for 65% of the EU cloud services market. CADA is, in part, an industrial policy response to that concentration.

CADA does not arrive alone. Companion legislation includes a Public Procurement Act scheduled for Q2 2026 with explicit "Buy European" framing for strategic sectors, Chips Act updates in Q1 2026, and the Digital Omnibus, which delayed certain AI Act obligations by up to 16 months to December 2027. CADA complements the Data Act, whose provisions have been effective since September 12, 2025, and existing EUCS certification efforts, though those remain stalled on member state disagreement over sovereignty tiers.

The architectural implication is direct. CADA embeds jurisdictional preference into public procurement. Every CTO selling to European public-sector buyers will feel this in their RFPs before they feel it in their courts. The procurement shift will favor Trusted Operator and Isolated Region archetypes over standard commercial cloud, not because the standard offerings are technically inferior, but because they will not meet the jurisdictional requirements written into tender criteria.

This is the CADA Horizon: the 24-month window in which voluntary sovereignty preferences harden into binding procurement rules. Architects designing infrastructure today for a five-year operational life are not designing for today's rules. They are designing for the rules CADA will enshrine.

Designing for Legal Identity

The frameworks above converge into a diagnostic. These are the questions I find myself asking in every architecture review where sovereignty is a factor.

What is the legal entity operating this infrastructure, and under which national law is it constituted? Not the brand on the console. The actual signing entity. AWS European Sovereign Cloud GmbH under German law is a fundamentally different answer than Amazon Web Services, Inc. under Washington state law, even when the API surface looks identical to the developer consuming it.

Who has administrative access to the control plane, and what is their employer? Not access to the data. Access to the control plane. The distinction matters because control-plane access creates an exposure path that data-layer encryption does not close. A VM can hold French data, encrypted at rest and in transit, and still be administered by an SRE in Seattle employed by a US entity.

What is the ownership chain above the operating entity? A German GmbH that is 100% owned by a US parent corporation has a different CLOUD Act exposure profile than a German GmbH owned by a European parent. The operating entity's sovereignty is bounded by the sovereignty of the entity that owns it.

How are technology updates governed? Does a foreign technology partner push updates directly into the production environment, or are updates quarantined, independently reviewed, and deployed by the domestic operator? PREMI3NS follows the latter model. Most commercial cloud arrangements follow the former. This is the difference between a sovereign supply chain and a sovereign data center with an unsovereign software pipeline.

Which sovereignty archetype does this workload actually need? Not the maximum available. The minimum sufficient. Inference control planes processing regulated customer data are not training clusters running on anonymized public datasets. The Sovereignty Portfolio approach matches the archetype to the workload. Applying the Trusted Operator model to every workload is as much an architectural error as applying no sovereignty treatment at all.

What happens in 24 months when CADA procurement preferences are binding? An architecture that satisfies today's voluntary sovereignty expectations can fail under mandatory procurement preference rules. The legislative process is underway, the public consultation is complete, and the regulation's legal basis allows direct effect without national transposition. Designing without accounting for this trajectory is designing for a regulatory environment that is actively being replaced.

These six questions do not require legal counsel to answer. They require architectural awareness. They separate architects who have absorbed the legal identity frame from architects who will encounter it as a surprise in their next procurement cycle.

The question is not whether infrastructure has legal identity. It already does. Every VM running in a sovereign cloud, every control plane administered by personnel under a specific employer, every data center operated by an entity constituted under a specific national law carries legal identity as a property of the deployment.

The question is whether the architect designed for that identity or inherited it by default.

Architects who design for legal identity segment workloads through a Sovereignty Portfolio, reason about the Sovereignty Stack layer by layer, select archetypes by workload class, and build systems that remain viable as European procurement and compute policy harden. Architects who inherit legal identity by default, who select a region and assume the rest follows, are building legacy technology in real time. The borderless cloud was a reasonable assumption in 2015. In 2026, it is technical debt.

— Maggie Nanyonga