Geopolitical Risk Makes Data Sovereignty an AI Architecture Problem
On 27 March 2026, the three European Supervisory Authorities published their spring Joint Committee update, naming geopolitical pressure and ICT third-party concentration as top risks for EU financial institutions. This is not a macro warning. Under DORA, it is a supervisory expectation with examination consequences.
What the ESA Update Changes
The update flags "increased third-party risk exposure to providers delivering services from countries more vulnerable to disruptions, or storing and processing data in such countries." That sentence is aimed directly at the two-thirds of EU cloud spend that flows to US-headquartered hyperscalers.
The ESAs published this update in the same cycle as the first full DORA oversight round for critical ICT third-party providers. On 18 November 2025, 19 providers were designated for direct supervision, including AWS, Google Cloud, and Microsoft. Each now has a lead overseer and a Joint Examination Team. The mechanism that converts geopolitical risk from a board concern into a regulatory examination is already running.
For teams building AI-powered features on top of US-headquartered API providers, the question is no longer whether geopolitics affects their architecture. It is whether their DORA ICT risk framework accounts for it.
Data Residency Is Not Legal Residency
A common pattern in EU organisations using AI APIs is to select a provider with an EU data centre region and assume sovereignty is covered. It is not. The US CLOUD Act gives US law enforcement the power to compel data access from US-headquartered companies regardless of where the data is physically stored. A data centre in Frankfurt operated by a US company does not change the legal jurisdiction under which access requests are adjudicated.
This distinction is at the core of the SEAL assessment framework:
| Level | Provider Type | Jurisdiction | CLOUD Act Exposure | DORA CTPP Status |
|---|---|---|---|---|
| SEAL-1 | US hyperscaler, EU region | US | Yes | Likely designated |
| SEAL-2 | EU provider, non-qualified | EU | No | Possible |
| SEAL-3 | EU-qualified sovereign provider | EU | No | Lower probability |
| SEAL-3+ | EU-qualified + EU key management + EU monitoring | EU | No | Minimal |
For AI inference specifically, SEAL-1 means that prompts containing personal data, financial data, or commercially sensitive information pass through a provider subject to US legal process. No data processing agreement overrides statute law. The Schrems II (C-311/18) ruling already established that US surveillance law creates inadequate protection under GDPR Article 45. The same logic applies to AI inference payloads.
Concentration Risk in AI Inference
DORA Article 28(2)(e) requires financial entities to identify and assess concentration risk in their ICT third-party arrangements. The ESA update makes clear that "diversification" across two US hyperscalers does not reduce geopolitical jurisdiction risk. Both are subject to the same foreign legal regime.
The same concentration problem exists in AI inference. Most EU companies building with LLMs use a single US-headquartered API provider. If that provider faces a service disruption, whether from infrastructure failure or a geopolitical escalation that restricts access, the dependent organisation has no fallback. DORA Article 11 requires ICT business continuity plans that include response and recovery measures for severe scenarios. A single-provider AI dependency without a pre-qualified alternative is a gap in that plan.
Multi-provider routing, where inference requests fall back to a secondary provider when the primary is unavailable or degraded, directly addresses both concentration risk and business continuity requirements. The architecture does not need to be complex: an OpenAI-compatible API that routes to multiple EU-incorporated providers removes single-provider dependency while keeping SDK integration unchanged.
What a Sovereign AI Stack Looks Like
The ESA update recommends scenario analysis for geopolitical disruptions. Applied to AI inference, that means answering concrete questions:
- Under which jurisdiction would a law enforcement data access request be adjudicated for this provider?
- If US-EU trade restrictions escalated, would this provider's EU operations be disrupted?
- Is the inference provider designated on the DORA CTPP list, and what does its oversight plan focus on?
- Does the provider store prompts or completions after processing, and under what legal framework?
A sovereign AI inference architecture satisfies these questions by ensuring that every subprocessor in the chain is EU-incorporated, operates from EU data centres, and is subject exclusively to EU jurisdiction. Zero Data Retention agreements ensure that prompts and completions are never stored, removing the data access question entirely. Published subprocessor lists provide the supply chain transparency that DORA Article 28(3)(d) requires.
ozeye's approach to this is straightforward: EU-only inference with every provider vetted for EU incorporation and EU data centres, zero data retention enforced across the network, and full subprocessor transparency. The multi-provider fallback routing means no single provider dependency, which directly addresses the concentration risk the ESAs flagged.
The 2026 Risk Register
82% of EU companies surveyed by Bitkom in 2025 said they no longer want to be technically dependent on US cloud providers. 78% acknowledged they currently are. European cloud infrastructure spending is forecast to triple from 2025 to 2027, partly driven by this realisation.
The ESA spring 2026 update is not warning about hypothetical future risk. It is naming specific scenarios, including the risk of restrictions on access to ICT resources, that belong on this year's risk register. For teams consuming AI APIs, the operational question is whether their inference provider stack would survive a scenario where US-EU relations deteriorate further.
Running critical AI workloads on an EU-sovereign provider while keeping lower-sensitivity development environments on a US hyperscaler is a defensible architectural split. The audit trail shows reduced geopolitical exposure for high-criticality services. The key is that the decision is documented, deliberate, and reflected in the DORA ICT risk framework, not discovered during an examination.