Sovereign inference is a control question, not a map question
An EU processing region answers only part of a sovereignty requirement. Specify operator jurisdiction, support access, retained records, change authority and continuity, then assess the arrangement against the workload’s actual needs.
Trace the interfaces between applications and records before changing a system.
A procurement requirement that says only “processing must take place in the European Union” leaves several control questions open. The supplier’s region name may establish where a specified workload runs. It does not establish where every record is retained or which parties can operate and change the service.
Separate location from operational and legal control. A workload can run in an EU region while support access, corporate jurisdiction or configuration authority involves parties elsewhere. Assess each route against the actual arrangement. Geography alone does not settle whether an obligation or contractual restriction is satisfied.
Translate sovereignty into specific, testable requirements for the workload. The buyer needs evidence for processing, records, access, authority and continuity, rather than a single regional label.
The two questions, held apart
| Data residency | Operational and legal control |
|---|---|
| Which region is the service deployed in? | Which legal regime governs the entity that operates it? |
| Where are the model weights hosted? | Who can change the model, and from where? |
| Where are logs and traces stored? | Who can read them, under what compulsion, without telling you? |
| Where is the data at rest? | Where does support access it from, and under whose supervision? |
| Is the region certified for the workload? | What happens to the service if a policy decision elsewhere changes? |
The Commission’s cloud policy addresses sovereignty beyond physical location. Its June 2026 Cloud and AI Development Act proposal includes an EU-wide assessment framework for cloud and AI sovereignty. Distinguish that legislative proposal from an enacted obligation and assess the current procurement requirements separately.
Alongside it, the capacity picture is changing. The EuroHPC AI Factories programme has been standing up AI-optimised supercomputing across member states and connecting it to industry, with substantial public investment behind it and gigafactory-scale facilities intended to follow — the Commission’s AI Factories page carries the current count and the funding figures. Whether that translates into serving capacity an ordinary enterprise can buy is a genuinely open question, and it is the one worth tracking, because a sovereignty requirement is only actionable if there is somewhere to run.
What to specify instead of a region
- Requirement 01 Processing location Where inference executes. Specify the required processing locations and exceptions.
- Requirement 02 Operator jurisdiction Which entity operates the service, and under which country’s law it sits.
- Requirement 03 Support access Who can reach the environment for operational purposes, from where, and under what approval.
- Requirement 04 Record location Where prompts, outputs, traces and abuse-monitoring copies are stored and for how long.
- Requirement 05 Change authority Who may alter the model or the service, with what notice to you.
- Requirement 06 Continuity What happens if the arrangement becomes unavailable — and what you would run instead.
Inspect paths for retained prompts, outputs, traces and abuse-monitoring records. Their location, access and retention can differ from the primary inference path. Obtain the relevant contract terms and service documentation, including exceptions. A region selector cannot establish those conditions by itself.
Define the continuity response if the selected arrangement becomes unavailable. A smaller model on suitable infrastructure, a restricted service or a manual process may support some work. Evaluate the alternative against the same control requirements and name the tasks it cannot preserve. Where no alternative meeting the applicable requirements exists, record that dependency explicitly.
The architectural consequence
Consider whether a model gateway provides a useful enforcement point for routing and service policy. Its value depends on the interfaces, records and controls it can actually cover. The design must also account for paths that bypass it and for the gateway’s own availability.
A gateway can centralise some destination rules and reduce application changes when providers move. It does not make model behaviour, tool support or data residency portable automatically. Evaluate alternative destinations and verify their contracts, access paths and outputs before treating a routing change as a continuity measure.
What this does not tell you
Nothing here is a legal opinion about whether any particular arrangement satisfies any particular obligation. That analysis depends on the data, the sector, the transfer mechanism and your own regulator’s view, and it belongs with your counsel and your data protection officer rather than with an architecture practice.
Apply sovereignty requirements to the workloads that need them, with a clear reason for each restriction. Compare the resulting cost, capability and continuity trade-offs. Some workloads can use a wider supplier set, while others need tighter control. The architecture review should make that distinction explicit.
The procurement owner should replace the single location statement with scoped questions about the six requirements above. Ask suppliers for verifiable answers and unresolved exceptions. Review those answers with the architecture, security and data-protection owners before accepting the arrangement.