Guide souveraineté
IA souveraine : ce que l'hébergement en Europe protège, et ce qu'il ne protège pas
Mise à jour : · Information générale, pas un avis juridique.
En bref
Héberger un système d'IA dans un centre de données situé en Europe ne suffit pas à le soustraire au droit américain : le CLOUD Act permet aux autorités des États-Unis d'exiger des données d'un fournisseur soumis à leur juridiction, quel que soit le lieu de stockage. La souveraineté d'un système d'IA se juge donc sur quatre critères : la juridiction des fournisseurs, la localisation des données et des calculs, les dépendances externes (notamment les API de modèles) et la maîtrise des clés et des journaux.
Le RGPD, lui, s'applique dans tous les cas : base légale, analyse d'impact, sous-traitance et encadrement des transferts restent à la charge de l'organisation, quel que soit l'hébergeur.
Ce que dit le CLOUD Act
| Point | Contenu | Source |
|---|---|---|
| Adoption | Clarifying Lawful Overseas Use of Data Act, adopté le 23 mars 2018 dans la loi de finances fédérale | Département de la Justice des États-Unis |
| Portée | Un fournisseur de services de communication électronique ou de cloud doit communiquer les données en sa possession, sa garde ou son contrôle, qu'elles soient stockées aux États-Unis ou à l'étranger | 18 U.S.C. § 2713 |
| Contestation | Le fournisseur peut demander l'annulation d'une réquisition dans certains cas, notamment quand le client n'est pas une personne américaine et que la communication violerait le droit d'un pays ayant conclu un accord avec les États-Unis. Cette voie dépend donc de l'existence d'un tel accord avec le pays concerné | 18 U.S.C. § 2703(h) |
| Information du client | Un tribunal peut interdire au fournisseur d'informer son client de la demande pendant une durée déterminée | 18 U.S.C. § 2705(b) |
Côté européen, l'article 48 du RGPD prévoit qu'une décision d'une juridiction ou d'une autorité d'un pays tiers exigeant le transfert de données personnelles n'est reconnue ou exécutoire que si elle repose sur un accord international, comme un traité d'entraide judiciaire (RGPD, article 48). Un fournisseur soumis aux deux droits peut donc se trouver face à des obligations contradictoires.
Les transferts de données personnelles vers des entreprises américaines certifiées sont par ailleurs encadrés par la décision d'adéquation du 10 juillet 2023 sur le cadre de protection des données UE-États-Unis (décision d'exécution (UE) 2023/1795). Cette décision traite les transferts commerciaux ; elle ne supprime pas la portée du CLOUD Act.
Les 4 critères de souveraineté d'un système d'IA
| Critère | Question à poser | Pourquoi c'est important pour l'IA |
|---|---|---|
| Juridiction des fournisseurs | Quel droit s'applique à l'hébergeur, à l'éditeur du modèle et à leurs maisons mères ? | Le CLOUD Act suit le fournisseur, pas le serveur |
| Localisation | Où sont stockés les données, les index de recherche, les journaux, et où ont lieu les calculs ? | Les prompts et les journaux contiennent souvent plus d'informations sensibles que les données sources |
| Dépendances externes | Le système appelle-t-il une API de modèle, un service de recherche, une télémétrie hors de l'UE ? | Un seul appel externe suffit à faire sortir des données |
| Maîtrise des clés et des journaux | Qui détient les clés de chiffrement et qui peut lire les journaux de décision ? | Les journaux exigés par l'AI Act pour les systèmes à haut risque sont eux-mêmes des données sensibles |
Pour le cloud, la France dispose d'un repère officiel : la qualification SecNumCloud de l'ANSSI, dont la version en vigueur ajoute des critères d'immunité aux lois extra-européennes (siège dans l'UE, capital majoritairement européen, limitation du recours à des sociétés tierces hors UE, autonomie d'exploitation). La qualification porte sur une offre précise, pas sur un fournisseur entier (ANSSI, FAQ SecNumCloud).
Comparer les modes de déploiement
| Mode | Juridiction des fournisseurs | Dépendance externe | Effort d'exploitation | Pour quels usages |
|---|---|---|---|---|
| On-premise (serveurs de l'organisation) | Celle de l'organisation | Aucune si le modèle est local | Élevé : matériel, mises à jour, sécurité | Données les plus sensibles, environnements isolés |
| Cloud privé opéré par un fournisseur européen | Droit européen, à contrôler pour chaque fournisseur et sa chaîne de sous-traitance | Faible si le modèle est hébergé dans ce cloud | Moyen | Données sensibles, besoin de capacité variable |
| Région européenne d'un fournisseur américain | Droit européen et droit américain | Selon l'architecture | Faible | Données dont l'exposition au droit américain est acceptée après analyse |
| API de modèle hébergée hors de l'UE | Droit du pays de l'éditeur | Totale pour les données envoyées | Très faible | Données non sensibles, prototypes |
| Hybride | Selon la répartition | Limitée et listée | Moyen | Données sensibles traitées localement, tâches non sensibles déléguées |
Le choix se fait par type de données et par traitement, pas pour toute l'organisation. Les options proposées par KOREV sont détaillées sur la page Déploiement.
RGPD : ce qui reste à votre charge, quel que soit l'hébergeur
- Base légale et finalité de chaque traitement (articles 5 et 6).
- Analyse d'impact relative à la protection des données quand le traitement présente un risque élevé (article 35).
- Contrat de sous-traitance avec chaque prestataire qui traite des données pour votre compte (article 28).
- Encadrement des transferts hors de l'Espace économique européen, y compris par les prestataires de vos prestataires (articles 44 à 49).
- Décision fondée exclusivement sur un traitement automatisé : droit d'obtenir une intervention humaine dans les cas prévus (article 22).
- Minimisation et conservation des données, y compris dans les prompts et les journaux.
Source : règlement (UE) 2016/679.
Ce que KOREV AI propose et ne revendique pas
- Déploiement au choix : cloud européen, hybride ou on-premise, selon l'environnement défini par l'organisation. La même architecture fonctionne aux différents niveaux d'indépendance.
- Modèle exécutable localement : KOREV Atlas est construit sur Olmo 3 32B, un modèle ouvert publié par l'Allen Institute for AI (Ai2), ce qui permet une exécution sans appel obligatoire à une API externe. Pour une exécution sur site, un nœud d'inférence compact (par exemple un MSI EdgeXpert) peut accueillir les modèles locaux et les agents KOREV Evidence. Voir les modes de déploiement.
- Dépendances listées : en mode hybride, les dépendances externes acceptées sont listées explicitement pour chaque projet.
- Données clients : KOREV n'utilise pas les données de ses clients pour entraîner des modèles publics.
- Pas de certification revendiquée : KOREV AI ne détient à ce jour ni qualification SecNumCloud, ni certification HDS, ni ISO 27001. Si l'un de ces repères est exigé, il doit être porté par l'hébergeur retenu pour le projet.
Source : Trust Center.
Checklist : évaluer la souveraineté d'un système d'IA
- Lister tous les fournisseurs du système : hébergeur, éditeur du modèle, base vectorielle, recherche web, télémétrie, support.
- Pour chacun, identifier la juridiction de l'entité contractante et de sa maison mère.
- Cartographier les flux : où vont les documents, les prompts, les réponses, les journaux et les sauvegardes.
- Repérer chaque appel à une API hors de l'UE et décider s'il est acceptable pour ce type de données.
- Vérifier qui détient les clés de chiffrement et qui peut accéder aux journaux.
- Pour un besoin SecNumCloud, vérifier que l'offre précise utilisée (calcul GPU, stockage, API) est dans le périmètre qualifié.
- Mettre à jour le registre des traitements, l'analyse d'impact et les contrats de sous-traitance.