Sovereign inference is a control question, not a map question
European buyers have started asking where inference runs and receiving an answer about which region a service is deployed in. Those are different questions, and the gap between them is where most residency commitments quietly fail.
The requirement arrives in a procurement document as a single line: processing must take place in the European Union. It is answered by a supplier confirming that the service runs in an EU region, and both parties record the matter as settled.
It is not settled, and the reason it is not is that “where the data sits” and “who can compel access to it, operate it, change it or switch it off” have come apart. A workload can run entirely on machines in Frankfurt, on infrastructure operated under a legal regime that is not European, by staff who are not in Europe, on a platform whose configuration can be changed from outside it. Each of those is a different question and only the first is answered by a region name.
The claim: residency is now the easy half of a European inference requirement, and the half most contracts stop at.
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 right-hand column is what the European policy conversation has moved to. The Commission’s cloud work now frames sovereignty across a set of dimensions — legal, operational, data, supply chain, technology — rather than as a question about geography, and the proposed Cloud and AI Development Act is an attempt to make that assessable in procurement rather than argued case by case. The Commission’s own summary of its cloud policy is the least mediated place to read what is coming.
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. The easy one, and the one everyone already asks for.
- 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.
The fourth row catches most organisations out. A provider may hold prompts and outputs for abuse monitoring, under a different retention period and sometimes in a different place from the primary processing, and that path is described in a policy document rather than in the region selector. It is a fair thing for a provider to do. It is not a fair thing for a buyer to be unaware of.
The sixth row is the one that separates a preference from a requirement. An organisation that states a sovereignty requirement without a viable alternative has stated an aspiration, and the first capacity constraint will convert it back into a preference. Knowing what you would actually run — a smaller open-weight model on European infrastructure, a reduced-scope service, a manual process — is what makes the requirement real.
The architectural consequence
All of this points at the same design decision, which is worth making independently of any of it: put a gateway between your applications and whatever serves your models.
An estate behind a gateway can change where inference runs as a configuration decision, route different data classes to different destinations, and enforce a residency rule in one place rather than in every application. An estate wired directly to a provider has expressed a sovereignty position in application code, which means changing it is a programme rather than a policy.
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.
It is also not an argument that European infrastructure is the right answer for every workload. For a great deal of enterprise AI it is not the binding constraint, and treating sovereignty as a default requirement rather than a scoped one raises cost and reduces capability for work that never needed it. The discipline is to know which of your workloads genuinely carry the requirement, and to be specific about what the requirement is when they do.
The reader who acts differently is whoever writes the next requirement document. Replace the single line about EU processing with the six rows above. Suppliers who have built for this will answer in a page. The ones who cannot will tell you something more useful than a region name.