AI Act, Sovereignty and AWS European Sovereign Cloud — The Cloud as a Compliance Building Block

AI Act, sovereignty and AWS European Sovereign Cloud - Guide Sylvain BRUAS

The European Artificial Intelligence Act ("AI Act", Regulation 2024/1689) has entered its phase of progressive application. For many enterprises, the question has long boiled down to "is my AI system high-risk?". It is a good question, but it hides another, more discreet and just as structuring one: where and by whom is my AI data processed?

This is precisely where the AI Act meets the topic of digital sovereignty, and where offerings like the AWS European Sovereign Cloud (ESC) become a compliance architecture element, and not just a hosting choice. This article takes the AI Act as a common thread, reads it through the lens of sovereignty, then concretely looks at what the ESC brings — and what it does not.

The AI Act in brief, and why sovereignty comes into play

A risk-based approach

The principle of the AI Act is simple: the more risks an AI system presents, the heavier its obligations. The first step, for any organization whose system touches the European market, is therefore to classify it into one of the four categories provided for by the regulation (European Commission — Regulatory framework for AI):

Unacceptable risk: prohibited practices (social scoring, manipulation, etc.). These systems are purely and simply banned.
High risk: AI used in sensitive domains (recruitment, credit scoring, healthcare, critical infrastructure). These are the most tightly regulated systems: technical documentation, risk management, data governance, human oversight.
Limited risk: chatbots, AI-generated content. Transparency obligations (informing the user that they are interacting with an AI).
Minimal risk: the vast majority of uses (spam filters, games). No specific obligation.

It is this classification that governs everything else: the level of obligations, the controls to put in place, and — this is the heart of this article — the sensitivity of the data processed.

The application timeline, for its part, has shifted a lot. The main lines to remember are:

Deadline	What applies
February 2, 2025	Prohibited practices + obligation to train teams in the use of AI
August 2, 2025	Obligations for General-Purpose AI (GPAI) models
August 2, 2026	General application, transparency (Article 50), sanction powers over GPAI
December 2, 2027	Obligations for high-risk systems (Annex III)
August 2, 2028	High-risk systems integrated into regulated products (Annex I)

Note: the "Digital Omnibus" — a European legislative package aiming to simplify and ease several digital texts, including the AI Act — pushed back the main "high-risk" obligations to late 2027, or even 2028. But August 2, 2026 remains a key deadline, with the entry into force of the transparency rules and sanctions on GPAI (European Commission — AI Act Service Desk).

The point of contact with sovereignty: Article 10

The AI Act does not talk about "sovereign cloud". But its Article 10, devoted to data and data governance for high-risk systems, imposes requirements on the quality, representativeness and traceability of training, validation and test datasets (European Commission — Article 10).

Now, as soon as an AI system processes personal data — which is the rule rather than the exception — the AI Act overlaps with the General Data Protection Regulation (GDPR). The law firm Osborne Clarke highlights this overlap: when a regulated AI system processes personal data, the two texts apply jointly. And the GDPR, for its part, directly raises the question of the place of processing and the applicable jurisdiction.

This is how AI Act compliance, apparently centered on risk management, ends up touching on three sovereignty questions: where the data lives, who operates it, and which law applies to it.

Sovereignty: what exactly are we talking about?

The term "sovereignty" is overused. It actually covers several distinct requirements that need to be separated:

Data residency: the data remains physically within a given geographic zone (here, the European Union).
Operational autonomy: the infrastructure can operate and be administered without dependence on resources or personnel outside the EU.
Jurisdictional sovereignty: the data escapes the scope of application of non-European law.

This last point is the thorniest: data residency and jurisdictional sovereignty are two distinct objectives. Data can very well live in Frankfurt while remaining, in theory, accessible to American law if the cloud provider depends on a parent company in the United States. This is precisely what the CLOUD Act allows, this American law that authorizes US authorities to demand data from an American company, even when it is stored abroad.

For a compliance officer preparing a high-risk AI system, this distinction is crucial: hosting in a classic European AWS region satisfies data residency, but does not, on its own, answer the question of operational autonomy and jurisdiction.

What the AWS European Sovereign Cloud brings

I have already detailed the architecture and challenges of the ESC in two previous articles: architecture and challenges for the foundations (isolated partition, Nitro system, encryption, SecNumCloud), and challenges and recommendations for implementation (service parity, regional IAM, connectivity, migration). So here I will limit myself to a reminder of the three characteristics that matter for the AI Act:

A separate infrastructure: a distinct AWS partition (aws-eusc), with a first region eusc-de-east-1 in Brandenburg (Germany), physically and logically isolated from the rest of AWS, and a planned extension via sovereign Local Zones in Belgium, the Netherlands and Portugal.
A dedicated European governance: an entity formed under European law, with subsidiaries in Germany (GmbH) led by EU citizens residing in the EU, legally bound to act in the interest of the ESC, and an independent advisory board.
Operation from within the EU: logical and physical access to the systems is restricted to qualified personnel residing in the EU, and the ESC is designed to operate without dependence on global AWS systems. AWS specifies that the transition to operation exclusively ensured by EU citizens is progressive, with a mixed team during this period (AWS — Whitepaper Overview of the AWS European Sovereign Cloud).

The correspondence with the AI Act requirements

By cross-referencing these characteristics with the requirements that the AI Act gives rise to (via its intersection with the GDPR), we obtain a fairly clear mapping:

Requirement induced by the AI Act / GDPR	ESC's response
Data residency (Article 10, datasets)	Data kept in the EU, dedicated partition
Traceability and logging (Articles 12, 19)	Metadata, roles and configurations kept in the EU
Operational autonomy	Operation by EU personnel, GmbH governance
Reduction of non-EU jurisdictional risk	Structural isolation and European parent company

The limits: sovereignty is not a switch

It would be dishonest to present the ESC as a checkbox that "solves" the AI Act. Three nuances are worth stating.

1. The sovereign cloud does not classify your system for you. The primary obligation of the AI Act remains the classification of risk and bringing the system itself into compliance (technical documentation, risk management, human oversight). The infrastructure helps on the data and traceability side, but does not exempt you from any business obligation.

2. Jurisdictional sovereignty remains debated. The launch of the ESC was accompanied by public questions about the real scope of American law, notably the CLOUD Act, over a subsidiary of an American group (InfoQ). The GmbH structure and operation by EU personnel are designed to reduce this risk, but the final legal assessment depends on the context of each organization and its legal counsel.

3. The service catalog is more restricted than in a commercial region. A recent partition does not offer, at launch, the entirety of the services available in the historical regions. You must therefore check the availability of the building blocks necessary for your AI pipeline (storage, compute, machine learning services) before committing.

For financial institutions, this bundle of obligations is even denser: the AI Act overlaps there with the GDPR and the DORA regulation (Digital Operational Resilience Act), making data sovereignty, auditability and third-party risk management inseparable from AI Act compliance.

How to approach the subject concretely

If you are preparing an AI system intended for the European market, a pragmatic progression consists of treating compliance and infrastructure as two parallel but coordinated projects:

Classify the system according to the AI Act categories. This is the prerequisite for any architecture decision.
Map the personal data flows: which data, from where, toward which processing. This is where the GDPR and Article 10 come into play.
Define the required level of sovereignty: residency alone, or residency + operational autonomy + reduction of jurisdictional risk.
Choose the infrastructure accordingly: a classic European region may suffice for residency; the ESC becomes relevant when operational autonomy and jurisdictional isolation are required by the sector (healthcare, public, finance).
Document and log: the traceability required by the AI Act must be operational, not just contractual.

Key takeaways

The AI Act does not mandate a sovereign cloud. But by making data governance, traceability and oversight mandatory, and by overlapping with the GDPR, it mechanically pushes the most regulated organizations toward sovereignty questions: where the data lives, who operates it, which law applies.

The AWS European Sovereign Cloud provides a credible infrastructure response to these three questions — isolated partition, operation by EU personnel, European governance — without, however, exempting you from the bulk of the compliance work, which remains the responsibility of the provider or deployer of the AI system. In short: the ESC is a tool in the service of compliance, not a substitute for it. The right reflex is therefore not "should I go sovereign?" but "what level of sovereignty does my AI system require, and by which AI Act deadline?".