A cloud deployment can meet its performance target and still fail the requirements of the organization that needs it. The missing constraint may concern where information is processed, who can administer the service, how software reaches production, or which entity can be required to produce data.
These questions belong in architecture and capital planning early enough to influence the design. Discovering them after contracts are signed can change the service catalog, staffing model, recovery arrangement, and cost of migration.
I use legal identity as a planning term for this combination of entities, jurisdictions, responsibilities, and controls. It is not a literal nationality attached to a virtual machine, and it does not determine a legal conclusion on its own. It helps leaders make the deployment assumptions explicit.
Separate the dimensions of sovereignty
A region name is only one part of a deployment's control model. I would review five dimensions together:
| Dimension | Evidence needed for an architecture decision |
|---|---|
| Data and processing location | Locations of primary data, backups, logs, metadata, and processing; permitted transfers and exceptions |
| Operational authority | Who can administer the control plane, access keys, authorize support, and restore the service |
| Legal entities and jurisdiction | Contracting, operating, and parent entities; applicable obligations and the documented legal assessment |
| Technology supply chain | Who builds, signs, reviews, approves, and deploys updates; dependencies during prolonged disruption |
| Continuity and exit | Recovery options, available skills, export formats, switching costs, and the ability to operate through a supplier interruption |
The purpose is to establish what the deployment must withstand and what evidence supports that expectation. A control that addresses one dimension should not be assumed to settle the others.
What the CLOUD Act analysis actually requires
The U.S. Department of Justice's CLOUD Act guidance, particularly questions 21–25, explains that the relevant analysis concerns a provider subject to U.S. jurisdiction and data within its possession or control, regardless of storage location. Jurisdiction is fact-dependent. The guidance also states that whether a company has sufficient control over data held by a subsidiary is a fact-dependent inquiry.
That does not support a rule that U.S. ownership automatically makes all subsidiary data accessible, or that domestic ownership automatically prevents foreign legal exposure. Nor does a European data-center address settle the question. The entity relationships, actual control over data, applicable process, and relevant law have to be assessed.
Legal counsel should establish the obligations and exposure for the specific deployment. Architecture and security teams should supply the technical facts: access paths, key custody, support procedures, separation controls, and the ability to retrieve or disclose information. A corporate diagram and a marketing label are insufficient evidence for either team.
Three operating patterns to compare
These patterns are useful for evaluating options. They are not a ranking of providers and do not confer compliance by themselves.
A domestic operator using an external technology stack. S3NS's account of PREMI3NS controls describes a French company majority-owned and fully controlled by Thales, operating Google Cloud technology in France. It describes review of updates in a quarantine environment before production and controlled third-party support. S3NS announced SecNumCloud 3.2 qualification for PREMI3NS in December 2025. These are service-specific controls and qualification claims; they should not be generalized to every product or treated as complete technological independence.
A separately operated hyperscaler environment. AWS's January 2026 launch announcement describes the European Sovereign Cloud as physically and logically separate, with its first region in Brandenburg and dedicated European legal entities. At launch, AWS described operations by EU residents in the EU and a transition toward EU-citizen-only operations. Evaluate the current contractual controls, attestation scope, services, and dependencies for the proposed workload. This article makes no categorical conclusion about its CLOUD Act exposure.
A disconnected deployment. Google's Distributed Cloud air-gapped documentation describes a hardware-and-software solution that can operate without a connection to Google Cloud or the internet. Disconnection is a relevant technical property. It does not remove the need to assess update handling, support access, component dependencies, recovery, and the governing contracts.
For each pattern, test the actual service boundary. Confirm that the database, model endpoint, identity service, telemetry, backup, and incident-response path all fit the requirements. An approved compute layer does not automatically make every connected service appropriate.
CADA is a proposal to plan for
On 3 June 2026, the European Commission presented the Cloud and AI Development Act as part of its Tech Sovereignty package. The proposed regulation is a legislative proposal, not an already applicable final regulation. Planning should distinguish existing obligations from provisions that may change through the legislative process.
The Commission's CADA overview describes four proposed assurance levels for public-sector use based on risk assessments. In condensed form:
| Proposed level | Emphasis in the Commission's overview |
|---|---|
| 1 | Storage and processing on infrastructure in the EU |
| 2 | Independence from third countries and transparency over the software supply chain |
| 3 | EU ownership and control, with additional criteria including personnel citizenship; a mechanism for Commission recognition of third-country providers |
| 4 | Full transparency and control over the software supply chain and protection against third-country interference |
This is a summary of the proposal, not a qualification checklist. The articles and annexes define the detailed criteria and assessment process. Do not assign a provider a level from this table, or assume that a product label or another certification establishes recognition under the proposed framework.
For an investment review, record CADA as a policy scenario with an owner and a review trigger. Assess the cost of meeting a stricter procurement requirement without presenting an adoption date, final text, or provider outcome as certain.
Segment by requirements, not by labels
A portfolio approach starts with each workload's information, purpose, users, and consequences of failure. Model weights, prompts, retrieved documents, logs, and support records may have different requirements. The control plane deserves its own assessment because it governs the service even when it does not store the primary dataset.
Do not assume that all inference is highly sensitive or that all research data is low risk. Establish the requirements first, then compare feasible deployment patterns. Where a common policy imposes a uniform standard, treat that as a real constraint rather than presuming segmentation is permitted.
Within those constraints, the investment case should account for service availability, migration effort, staffing, resilience, and the cost of duplicated platforms. More isolation can be appropriate, but its benefits and operational burden need to be explicit. A less restrictive option can be appropriate where it meets the established requirements and risk tolerance.
Make the decision jointly accountable
I would require a deployment decision record owned jointly by architecture, security, legal, procurement, and the service owner. It should identify the workload, applicable requirements, chosen operating pattern, evidence reviewed, unresolved dependencies, and accepted residual risks.
Attach a continuity and exit plan. Test how the organization handles a provider outage, loss of external support, an urgent update, a change of ownership, or a new procurement requirement. Record who can authorize a change and what evidence would trigger another review.
This connects sovereignty to the system the organization must operate. The strongest architecture is one whose performance, control, and continuity assumptions remain explainable throughout its useful life.
Originally published 16 April 2026. Revised 13 September 2026 with official policy and provider sources, a fact-dependent treatment of legal exposure, and an updated account of the CADA proposal.