Sovereign AI: Definitions, Requirements, and How to Evaluate a Provider

A useful working definition, distilled from the AI Act's Recital 27 (on the Union's strategic autonomy in AI), the EDPB's June 2025 guidelines on international data transfers in AI contexts, and the ENISA sovereign cloud reference architecture published in April 2026, has four components.

**Jurisdictional autonomy.** The provider is legally established in an EU/EEA member state, its ultimate parent entity is not subject to third-country legal orders with extraterritorial reach affecting the service (the US CLOUD Act being the paradigmatic example), and disputes concerning the service are governed by EU/EEA law and adjudicated in EU/EEA courts.

**Operational autonomy.** Service operations — including model training, inference infrastructure, support, incident response, and administrative access — are carried out by personnel located in the EU/EEA, using infrastructure located in the EU/EEA, without dependency on non-EU/EEA personnel for continuity of core service functions.

**Technical autonomy.** The customer has the technical means to migrate away from the provider without loss of essential functionality within a defined timeframe. For foundation models this includes access to model weights or functionally equivalent alternatives; for AI infrastructure it includes standard APIs and open formats supporting workload portability.

**Transparency.** The provider maintains and makes available to customers documentation sufficient to verify each of the above properties, including corporate structure, personnel jurisdictions, infrastructure locations, sub-processor chains, and change notification processes.

A provider meeting all four is a sovereign AI provider in the meaningful sense. A provider meeting some but not all is offering something more limited — often "EU data residency" or "EU-hosted" — which are real but distinct properties. The distinction matters because different regulatory contexts require different subsets of the four components, and buyers over-purchase sovereignty when they conflate the properties.

Jurisdictional autonomy is the most legally consequential component and the most frequently misunderstood. Three tests apply.

**Ultimate parent test.** The ultimate parent entity of the service provider must be established in the EU/EEA. This is a corporate law test — it looks at ownership and control, not marketing structure. A US-headquartered corporation with an EU subsidiary offering AI services does not meet this test even if the EU subsidiary is legally distinct, because the parent-subsidiary relationship remains subject to the parent's home jurisdiction. Both Microsoft's EU Data Boundary and Google Cloud's Sovereign Controls fail this test.

**Extraterritorial order test.** The provider must not be subject to third-country legal orders that could compel disclosure of customer data or interference with customer service against the customer's interests. The US CLOUD Act (18 U.S.C. § 2713) is the paradigm example: it permits US authorities to compel US-headquartered providers to produce data regardless of storage location. Similar concerns arise from China's National Intelligence Law and Russia's Yarovaya Law. A provider whose ultimate parent falls under any such regime fails this test.

**Governing law and forum test.** Service contracts must be governed by EU/EEA law and disputes resolved in EU/EEA courts. This is not merely a boilerplate preference — it determines the practical availability of GDPR enforcement, injunctive relief, and DORA cooperation mechanisms. Contracts with governing law choices favouring US, UK (post-Brexit), or offshore jurisdictions fail this test regardless of the provider's technical footprint.

Providers that meet all three tests include Mistral (headquartered in Paris), Aleph Alpha (Heidelberg), Silo AI (Helsinki, though Silo's 2024 AMD acquisition creates a nuanced position that has been the subject of ongoing analysis), OVHcloud (Roubaix), Scaleway (Paris), Exoscale (Zurich, EEA-adjacent), Deutsche Telekom's Open Telekom Cloud (Bonn), and IONOS Enterprise Cloud (Karlsruhe).

The list is deliberately short. It reflects the fact that meaningful jurisdictional autonomy in AI is currently offered by a limited set of providers, and that most "sovereign" branding in the market is drawing on the other three components — operational, technical, or transparency — while making claims about jurisdiction that do not survive the three tests.

Operational autonomy is where sovereignty claims most often break down under scrutiny. The Bundesamt für Sicherheit in der Informationstechnik (BSI) C5:2020 attestation and the EUCS High assurance level (finalised by ENISA in November 2025) both require operational autonomy demonstrations. The specific requirements that emerge in practice are as follows.

**Personnel location.** All administrative, support, and privileged access personnel handling customer data or infrastructure must be located in the EU/EEA. This includes on-call rotations covering out-of-hours incident response. "Follow-the-sun" support models involving personnel in the US, India, or Asia typically fail this test unless the non-EU personnel have no privileged access to customer data or infrastructure.

**Infrastructure supply chain.** Physical infrastructure — servers, network equipment, storage — may be manufactured outside the EU/EEA but must be operated by EU/EEA-established entities. Firmware and BIOS updates are a nuanced sub-issue: US-headquartered vendors (Dell, HPE, Cisco) supplying hardware to EU-operated infrastructure remains acceptable under current guidance, but firmware update chains must be documented.

**Software supply chain.** Software components used to deliver the service, including AI frameworks and inference engines, may be developed outside the EU/EEA if they are open-source and the operator can build and patch them independently. Proprietary software components under third-country vendor control that are essential to service continuity fail the operational autonomy test.

**Technical autonomy** — the fourth component — has one dominant requirement for foundation models: weights portability. The customer must be able to obtain the model weights (for open-weights models like Mistral's, Aleph Alpha's Pharia series, and Meta's Llama family) or functionally equivalent migration paths (for closed-weights providers). Without weights portability, the customer is technically locked in regardless of jurisdictional autonomy. Closed-weights sovereign providers (Mistral's Large 3 remains closed-weights despite the company's Apache-licensed model family) must offer strong contractual portability commitments including weight escrow arrangements to meet the technical autonomy standard.

The EU Cloud Certification Scheme (EUCS), finalised at High assurance level by ENISA on 12 November 2025 and now moving through Commission Implementing Act adoption, is the closest formal analogue to a sovereign AI standard. Its assurance levels map to sovereignty as follows.

**EUCS Basic.** Baseline cloud security controls. Does not address jurisdictional or operational autonomy. Not a sovereignty attestation.

**EUCS Substantial.** Enhanced security and operational controls including EU/EEA data residency requirements. Addresses residency but not jurisdictional autonomy. Compatible with US-headquartered providers.

**EUCS High.** Adds "immunity from non-EU law" requirements substantially aligned with the four-component definition above. Requires EU/EEA-headquartered ultimate parent, EU/EEA operations, and EU/EEA governing law. Providers certified at EUCS High are strong candidates for meeting a full sovereign AI definition, subject to model-specific technical autonomy evaluation.

The EUCS High level has been politically contested throughout 2024–2026, with member states divided on whether "immunity from non-EU law" should remain a High-level requirement or be moved to a separate optional label. The November 2025 ENISA final position retained it at High level, but the Commission's implementing act may modify this. As of June 2026 the position remains unresolved; buyers should track the final published version rather than relying on ENISA's draft.

For sovereign AI evaluation, EUCS High attestation of the underlying infrastructure combined with jurisdictional autonomy of the model provider is the strongest currently available evidence combination. The Franco-German joint procurement framework for sovereign AI (Cadre Franco-Allemand IA Souveraine), published on 3 March 2026, uses this combination as its minimum standard.

A defensible sovereign AI evaluation follows a fixed sequence. The methodology below is derived from the audit approaches used by ANSSI (France), BSI (Germany), and the Dutch Rijksinspectie Digitale Infrastructuur, adapted for use by non-regulator buyers.

**Step 1 — Corporate structure verification.** Obtain the ultimate parent entity name and jurisdiction from the provider. Cross-reference against public corporate registries (INPI/Infogreffe for France, Handelsregister for Germany, Companies House for UK). A provider unwilling to disclose ultimate parent identity fails the evaluation at this step.

**Step 2 — Extraterritorial exposure mapping.** Identify all jurisdictions to which the ultimate parent, direct subsidiaries operating the service, and material sub-processors are subject. Assess each for extraterritorial legal reach affecting the service. The Cloud Act, PATRIOT Act, FISA 702, China's National Intelligence Law, and Russia's laws on data localisation are the primary concerns.

**Step 3 — Operational autonomy attestation.** Request evidence of personnel location, on-call rotation composition, infrastructure supply chain, and software supply chain. C5:2020, ISO 27001 Annex A.11 evidence, or SOC 2 Type II reports with location-specific scope may be acceptable substitutes for direct attestation.

**Step 4 — Technical autonomy assessment.** For foundation models, verify weights portability status: open-weights (verify licence), closed-weights with escrow (verify escrow arrangement and trigger conditions), or closed-weights without escrow (score as technical autonomy failure). For AI infrastructure, verify API and format portability against candidate migration targets.

**Step 5 — Governing law verification.** Review the actual master service agreement (not sales-stage summary) for governing law, forum, and dispute resolution clauses. EU/EEA law and EU/EEA forum required.

**Step 6 — Documentation completeness check.** Verify that documentation covering steps 1–5 is available to customers on request and updated on material change. Providers that require NDAs to disclose Step 1 or 2 information fail this step.

The methodology should be run once per provider at initial procurement and re-run annually or on material change. Producing a written evaluation report for each provider — even in a two-page format — creates the audit trail that European regulators are increasingly asking for during ICT third-party risk reviews.