A local server address can hide dependencies that interrupt an AI service. Assess sovereign AI architecture through data residency, operator access, compute control and a tested ability to move the service.
Sovereign AI means retaining the authority and practical ability to govern an AI capability under the jurisdictions and operating conditions you require. Data residency describes where data is stored or processed. A sovereignty assessment also asks who can access it, change the model, withdraw capacity or prevent an exit. Use the evidence worksheet below to review a specific workload before choosing an architecture.
Infrastructure location is one input. Access authority and service continuity need their own evidence.
Define the control you need before choosing a location
Write the required outcome for each workload, then ask each provider to show how it is enforced. A public-information assistant and a service processing confidential personal records may need different controls even within the same organization.
The European Commission's Cloud Sovereignty Framework, version 1.2.1 of October 2025, separates legal, data and AI, operational, supply-chain and technology concerns. It is a framework for a procurement procedure; its assurance levels do not establish a universal sovereign-AI certification. The questions here turn those concerns into a workload review.
| Input or item | Evidence to request | Why it matters |
|---|---|---|
| Input or itemData and jurisdiction | Evidence to requestData classification, processing purpose, approved locations and legal assessment | Why it mattersDefines which operations and transfers need controls. |
| Input or itemAccess authority | Evidence to requestProvider entity, subprocessors, support locations, privileged-access approval and audit records | Why it mattersA local storage region does not identify everyone who can read the data. |
| Input or itemCompute and model control | Evidence to requestCapacity entitlement, model licence/version, update authority and dependency inventory | Why it mattersHardware ownership alone does not establish operational independence. |
| Input or itemRecovery requirement | Evidence to requestApproved recovery window and a timed restore on an alternative environment | Why it mattersAn export file is only part of a working exit. |
| Input or itemCost period | Evidence to requestSame workload, service scope, currency and evaluation period | Why it mattersPrevents a low infrastructure figure from hiding operating and transition work. |
Map the data paths, including the paths used during failure
Map each copy and access route from ingestion through retirement. Include source records, prompts, retrieved passages, embeddings, fine-tuning data, outputs, evaluation sets, logs and backups. Treat each derived artifact according to what it contains and how it is used; the word “embedding” does not establish that information is anonymous.
For every path, record storage location, processing location, operator, retention, encryption/key authority and deletion behavior. Ask what changes during a regional outage, abuse investigation or support escalation. A default cross-region fallback can conflict with an otherwise carefully restricted normal path.
The boundary is an example of a buyer's approved scope. Check the logs, backup and support branches independently of the main request path.
The EDPB's Guidelines 05/2021, version 2.0, section 2, identify three cumulative transfer criteria: an exporter subject to GDPR for the processing; disclosure to another controller or processor; and an importer in a third country or an international organization. Remote support access can qualify when those conditions hold. Access by an employee within the same controller is a different case; it still needs appropriate safeguards.
For personal data, assign a legal owner to apply that test to the actual entities and processing. Review GDPR Article 32 and Chapter V separately for security and transfers. Encryption and regional storage are evidence inputs, rather than a complete legal conclusion.
Compare architectures by the control that can fail
Choose a pattern only after its evidence meets the workload's requirements. These patterns describe operating arrangements, rather than a ranking of providers.
| Architecture | Useful when | Dominant failure mode & prevention |
|---|---|---|
| ArchitectureManaged service in an approved region | Useful whenIts contract, operator access and recovery options satisfy the required scope. | Dominant failure mode & preventionSupport, telemetry or failover leaves the approved scope. Check the service-specific data flow and restrict routes with auditable controls. |
| ArchitectureLocally operated private cloud or on-premises service | Useful whenThe organization needs direct operational authority and can staff, patch and recover the full service. | Dominant failure mode & preventionLocal infrastructure still depends on an external licence, identity service, model download or specialist. Inventory dependencies and rehearse operation when each is unavailable. |
| ArchitectureDigital embassy arrangement | Useful whenCross-border capacity is proposed under a specific legal and operational agreement. | Dominant failure mode & preventionThe sovereignty label outruns enforceable rights. Examine the actual agreement, host-state obligations, access rules and continuity arrangements before accepting the proposal. |
A digital embassy can place infrastructure outside a country's physical territory while seeking to preserve particular controls through agreements and safeguards. The WEF digital embassies session record introduces that policy question. Require the actual legal instrument and technical scope for the proposed deployment. A commercial description cannot establish diplomatic immunity, a transfer exemption or unrestricted continuity.
For compute sovereignty, examine who allocates capacity, who controls the software stack, and what happens when power, connectivity, hardware support or entitlement is withdrawn. Owning accelerators leaves those questions open. A managed service may meet a bounded workload requirement if its controls and tested recovery are adequate; a locally operated service may fail it if key dependencies remain outside the operator's control.
Prove an exit by restoring a usable service
Time the complete recovery path against the business-approved recovery window. Include artifact export, movement, restore and validation, with the correct model licence, keys, identity and retrieval dependencies available at the target.
For sequential work, use:
Recovery time = export + transfer + restore + validation
Worked example with assumed inputs: 2 hours to export + 3 hours to transfer + 2 hours to restore + 1 hour to validate = 8 hours. Against an assumed approved recovery window of 6 hours, that plan misses the requirement by 2 hours. These inputs illustrate a review calculation; obtain timings from the proposed workload's recovery exercise.
The sequential example reaches a usable service after eight hours. Record actual parallel work separately so elapsed time is not double-counted.
If measured recovery exceeds the approved window, revise the design before approval. Options to evaluate include a prepared second environment, a reduced service mode or a different recovery target agreed with the business owner. Verify each option through the same exercise. Do not accept a download button as proof that models, indexes, permissions and application behavior will work elsewhere.
Keep AI governance and residency assessments separate
An AI governance framework assigns responsibilities across the system lifecycle. NIST's AI Risk Management Framework 1.0, published in January 2023, organizes work around Govern, Map, Measure and Manage. It is voluntary. Use it to structure ownership and evidence; it does not substitute for a legal obligation or conformity assessment.
For EU AI Act compliance, classify the system's purpose and the organization's role before mapping obligations. Local hosting does not establish that classification, appropriate human oversight or sufficient documentation.
The Commission's AI Act overview, retrieved on 19 October 2026, gives the following application milestones with exceptions: prohibited practices and AI literacy from 2 February 2025; GPAI governance obligations from 2 August 2025; general application from 2 August 2026. Its updated guidance lists 2 December 2027 for Annex III high-risk uses and 2 August 2028 for high-risk systems embedded in Annex I regulated products. Check the applicable provisions, transition rules and current consolidated text for the specific system; a single date is insufficient for every deployment.
Keep separate evidence files for data protection and transfers, AI-system obligations, and the procurement's sovereignty requirements. A change in model, use case, supplier entity or support arrangement should trigger a review of the affected file.
Compare the same period of operating and exit costs
Use a consistent scope before comparing proposals. A 36-month review can use the accounting identity:
TCO(36 months) = setup + 36 × recurring monthly cost + transition and exit cost
Include compute or service fees, storage and backup, networking, operational staffing, security/key services, evaluations and audit retention in recurring costs. Put migration, dual running, re-indexing, model adaptation, licence changes and final deletion verification in the transition plan. Allocate shared costs once. Match capacity, support and availability requirements across proposals, and retain the source and date of each estimate.
This comparison does not yield a preferred architecture until the evidence gates are met. A cheaper proposal that cannot meet the approved access or recovery requirement needs revision before its price becomes a meaningful comparison.
Record the evidence and the decision
Complete one worksheet per workload. Use “approve”, “revise” or “reject” with a reason, owner and evidence reference. An unresolved mandatory requirement stays open; an overall average score should not conceal it.
| Review area | Required evidence | Decision to record |
|---|---|---|
| Review areaPurpose and legal scope | Required evidenceUse case, data categories, relevant entities and assigned legal owner | Decision to recordWhich requirements apply, and who confirmed the scope? |
| Review areaData paths | Required evidenceNormal, support, telemetry, backup and failure-route map | Decision to recordDoes each path stay within the approved conditions? |
| Review areaAccess and keys | Required evidencePrivileged-access process, key authority and audit evidence | Decision to recordWho can authorize access, and can that authority be enforced? |
| Review areaCompute and model | Required evidenceCapacity terms, licence, version control and dependency register | Decision to recordWhich dependency could stop or change the service? |
| Review areaRecovery and exit | Required evidenceTimed restore, target entitlements and validation record | Decision to recordDoes the usable service meet the approved recovery window? |
| Review areaGovernance and cost | Required evidenceObligation owners, review triggers and period-consistent cost model | Decision to recordWhat remains unresolved before contracting? |
Download the blank sovereign AI assessment worksheet (CSV), assign owners and record the missing evidence before the next architecture review. For the wider discussion, browse AI governance and law.
Read the WEF policy questions alongside the architecture
The three existing WEF 2026 records frame different decisions. The digital embassies discussion asks how cross-border infrastructure might preserve sovereign control. Carney's address on hegemons and hyperscalers connects AI cooperation with dependence on state and platform power. His official published address supplies the original policy statement. The compute and energy discussion supplies context for capacity and power constraints.
These are policy and strategy records. Use contracts, legal instruments and deployment evidence to assess a particular architecture rather than treating a summit discussion as proof that it meets the worksheet.
Method and sources
Published and reviewed 19 October 2026. This guide combines the Commission's procurement framework, EDPB transfer guidance, GDPR text, the Commission's current AI Act overview and NIST AI RMF with an editorial assessment worksheet. The recovery inputs are explicitly hypothetical. No vendor performance, price or deployment outcome is assumed. The linked talk records retain their source provenance; the worksheet applies separate questions to a proposed workload. See the site's sourcing methodology for the distinction between a source record and editorial analysis.