AI Act, souveraineté et AWS European Sovereign Cloud — Le cloud comme pièce de conformité

AI Act, souveraineté et AWS European Sovereign Cloud - Guide Sylvain BRUAS

Le règlement européen sur l'intelligence artificielle (Artificial Intelligence Act, ou « AI Act », Regulation 2024/1689) est entré dans sa phase d'application progressive. Pour beaucoup d'entreprises, la question s'est longtemps résumée à « mon système d'IA est-il à haut risque ? ». C'est une bonne question, mais elle en cache une autre, plus discrète et tout aussi structurante : où et par qui mes données d'IA sont-elles traitées ?

C'est précisément là que l'AI Act rejoint le sujet de la souveraineté numérique, et que des offres comme l'AWS European Sovereign Cloud (ESC) deviennent un élément d'architecture de conformité, et pas seulement un choix d'hébergement. Cet article prend l'AI Act comme fil conducteur, le lit sous l'angle de la souveraineté, puis regarde concrètement ce que l'ESC apporte — et ce qu'il n'apporte pas.

L'AI Act en bref, et pourquoi la souveraineté s'y invite

Une approche par le risque

Le principe de l'AI Act est simple : plus un système d'IA présente de risques, plus ses obligations sont lourdes. La première étape, pour toute organisation dont un système touche le marché européen, est donc de le classer dans l'une des quatre catégories prévues par le règlement (Commission européenne — Cadre réglementaire de l'IA) :

Risque inacceptable : pratiques interdites (notation sociale, manipulation, etc.). Ces systèmes sont purement et simplement bannis.
Haut risque : IA utilisée dans des domaines sensibles (recrutement, scoring de crédit, santé, infrastructures critiques). Ce sont les systèmes les plus encadrés : documentation technique, gestion des risques, gouvernance des données, supervision humaine.
Risque limité : chatbots, contenus générés par IA. Obligations de transparence (informer l'utilisateur qu'il interagit avec une IA).
Risque minimal : la grande majorité des usages (filtres anti-spam, jeux). Aucune obligation spécifique.

C'est cette classification qui commande tout le reste : le niveau d'obligations, les contrôles à mettre en place, et — c'est le cœur de cet article — la sensibilité des données traitées.

Le calendrier d'application, lui, a beaucoup bougé. Il faut retenir les grandes lignes :

Échéance	Ce qui s'applique
2 février 2025	Pratiques interdites + obligation de former les équipes à l'usage de l'IA
2 août 2025	Obligations pour les modèles d'IA à usage général (General-Purpose AI, GPAI)
2 août 2026	Application générale, transparence (Article 50), pouvoirs de sanction sur les GPAI
2 décembre 2027	Obligations des systèmes à haut risque (Annexe III)
2 août 2028	Systèmes à haut risque intégrés à des produits réglementés (Annexe I)

À noter : le « Digital Omnibus » — un paquet législatif européen visant à simplifier et assouplir plusieurs textes numériques, dont l'AI Act — a repoussé les principales obligations « haut risque » à fin 2027, voire 2028. Mais le 2 août 2026 reste une échéance clé, avec l'entrée en vigueur des règles de transparence et des sanctions sur les GPAI (Commission européenne — AI Act Service Desk).

Le point de contact avec la souveraineté : l'Article 10

L'AI Act ne parle pas de « cloud souverain ». Mais son Article 10, consacré aux données et à la gouvernance des données pour les systèmes à haut risque, impose des exigences sur la qualité, la représentativité et la traçabilité des jeux de données d'entraînement, de validation et de test (Commission européenne — Article 10).

Or, dès qu'un système d'IA traite des données à caractère personnel — ce qui est la règle plus que l'exception — l'AI Act se superpose au Règlement général sur la protection des données (RGPD). Le cabinet Osborne Clarke souligne ce recouvrement : lorsqu'un système d'IA régulé traite des données personnelles, les deux textes s'appliquent conjointement. Et le RGPD, lui, pose frontalement la question du lieu de traitement et de la juridiction applicable.

C'est ainsi que la conformité à l'AI Act, apparemment centrée sur la gestion du risque, finit par toucher trois questions de souveraineté : où vivent les données, qui les opère, et quelle loi s'y applique.

Souveraineté : de quoi parle-t-on exactement ?

Le terme « souveraineté » est galvaudé. Il recouvre en réalité plusieurs exigences distinctes qu'il faut séparer :

Résidence des données (data residency) : les données restent physiquement dans une zone géographique donnée (ici, l'Union européenne).
Autonomie opérationnelle : l'infrastructure peut fonctionner et être administrée sans dépendance à des ressources ou du personnel hors UE.
Souveraineté juridictionnelle : les données échappent au champ d'application du droit extra-européen.

Ce dernier point est le plus épineux : la résidence des données et la souveraineté juridictionnelle sont deux objectifs distincts. Une donnée peut très bien vivre à Francfort tout en restant, en théorie, accessible au droit américain si le fournisseur cloud dépend d'une maison mère aux États-Unis. C'est précisément ce que permet le CLOUD Act, cette loi américaine qui autorise les autorités des États-Unis à réclamer des données à une entreprise américaine, même lorsqu'elles sont stockées à l'étranger.

Pour un responsable conformité qui prépare un système d'IA à haut risque, cette distinction est cruciale : héberger dans une région AWS européenne classique satisfait la résidence des données, mais ne répond pas, à lui seul, à la question de l'autonomie opérationnelle et de la juridiction.

Ce qu'apporte l'AWS European Sovereign Cloud

J'ai déjà détaillé l'architecture et les enjeux de l'ESC dans deux articles précédents : architecture et enjeux pour les fondations (partition isolée, système Nitro, chiffrement, SecNumCloud), et défis et recommandations pour la mise en œuvre (parité de services, IAM régional, connectivité, migration). Je me contente donc ici d'un rappel des trois caractéristiques qui comptent pour l'AI Act :

Une infrastructure séparée : une partition AWS distincte (aws-eusc), avec une première région eusc-de-east-1 dans le Brandebourg (Allemagne), physiquement et logiquement isolée du reste d'AWS, et une extension prévue via des Local Zones souveraines en Belgique, aux Pays-Bas et au Portugal.
Une gouvernance européenne dédiée : une entité constituée sous droit européen, avec des filiales en Allemagne (GmbH) dirigées par des citoyens de l'UE résidant dans l'UE, juridiquement tenus d'agir dans l'intérêt de l'ESC, et un conseil consultatif indépendant.
Une exploitation depuis l'UE : l'accès logique et physique aux systèmes est restreint à du personnel qualifié résidant dans l'UE, et l'ESC est conçu pour fonctionner sans dépendance aux systèmes AWS globaux. AWS précise que la transition vers une exploitation exclusivement assurée par des citoyens de l'UE est progressive, avec une équipe mixte pendant cette période (AWS — Whitepaper Overview of the AWS European Sovereign Cloud).

La correspondance avec les exigences de l'AI Act

En croisant ces caractéristiques avec les exigences que fait naître l'AI Act (via son intersection avec le RGPD), on obtient une cartographie assez nette :

Exigence induite par l'AI Act / RGPD	Réponse de l'ESC
Résidence des données (Article 10, jeux de données)	Données conservées dans l'UE, partition dédiée
Traçabilité et journalisation (Articles 12, 19)	Métadonnées, rôles et configurations conservés dans l'UE
Autonomie opérationnelle	Exploitation par du personnel UE, gouvernance GmbH
Réduction du risque juridictionnel extra-UE	Isolement structurel et société mère européenne

Les limites : la souveraineté n'est pas un interrupteur

Il serait malhonnête de présenter l'ESC comme une case à cocher qui « résout » l'AI Act. Trois nuances méritent d'être posées.

1. Le cloud souverain ne classe pas votre système à votre place. L'obligation première de l'AI Act reste la classification du risque et la mise en conformité du système lui-même (documentation technique, gestion des risques, supervision humaine). L'infrastructure aide sur le volet données et traçabilité, mais ne dispense d'aucune obligation métier.

2. La souveraineté juridictionnelle reste débattue. Le lancement de l'ESC s'est accompagné de questions publiques sur la portée réelle du droit américain, notamment le CLOUD Act, sur une filiale d'un groupe américain (InfoQ). La structure GmbH et l'opération par du personnel UE sont conçues pour réduire ce risque, mais l'appréciation juridique finale dépend du contexte de chaque organisation et de son conseil juridique.

3. Le catalogue de services est plus restreint qu'en région commerciale. Une partition récente ne propose pas, au démarrage, l'intégralité des services disponibles dans les régions historiques. Il faut donc vérifier la disponibilité des briques nécessaires à votre pipeline d'IA (stockage, calcul, services de machine learning) avant de vous engager.

Pour les institutions financières, ce faisceau d'obligations est encore plus dense : l'AI Act s'y superpose au RGPD et au règlement DORA (Digital Operational Resilience Act), rendant la souveraineté des données, l'auditabilité et la gestion du risque tiers indissociables de la conformité à l'AI Act.

Comment aborder le sujet concrètement

Si vous préparez un système d'IA destiné au marché européen, une progression pragmatique consiste à traiter la conformité et l'infrastructure comme deux chantiers parallèles mais coordonnés :

Classer le système selon les catégories de l'AI Act. C'est le préalable à toute décision d'architecture.
Cartographier les flux de données personnelles : quelles données, d'où, vers quels traitements. C'est ici que le RGPD et l'Article 10 entrent en jeu.
Définir le niveau de souveraineté requis : résidence seule, ou résidence + autonomie opérationnelle + réduction du risque juridictionnel.
Choisir l'infrastructure en conséquence : une région européenne classique peut suffire pour la résidence ; l'ESC devient pertinent quand l'autonomie opérationnelle et l'isolement juridictionnel sont exigés par le secteur (santé, public, finance).
Documenter et journaliser : la traçabilité exigée par l'AI Act doit être opérationnelle, pas seulement contractuelle.

Ce qu'il faut retenir

L'AI Act n'impose pas de cloud souverain. Mais en rendant obligatoires la gouvernance des données, la traçabilité et la supervision, et en se superposant au RGPD, il pousse mécaniquement les organisations les plus régulées vers des questions de souveraineté : où vivent les données, qui les opère, quelle loi s'applique.

L'AWS European Sovereign Cloud apporte une réponse d'infrastructure crédible à ces trois questions — partition isolée, exploitation par du personnel UE, gouvernance européenne — sans pour autant dispenser de l'essentiel du travail de conformité, qui reste à la charge du fournisseur ou du déployeur du système d'IA. En clair : l'ESC est un outil au service de la conformité, pas un substitut à celle-ci. Le bon réflexe n'est donc pas « dois-je aller sur du souverain ? » mais « quel niveau de souveraineté mon système d'IA exige-t-il, et à quelle échéance de l'AI Act ? ».