Transfert de données hors UE des IA LLM, que dit le RGPD
Un prompt saisi dans un assistant conversationnel peut quitter l’Europe en quelques centaines de millisecondes, sans qu’aucun fichier n’ait été exporté manuellement. C’est tout le paradoxe du transfert de données hors UE d’une IA LLM, un flux invisible, continu et souvent ignoré des équipes métiers.
Le RGPD ne l’interdit pas, il l’encadre strictement, et cette nuance change tout pour un DSI ou un RSSI qui doit arbitrer entre adoption rapide et maîtrise juridique. Encore faut-il savoir où partent réellement les requêtes, les pièces jointes, les journaux d’utilisation et la télémétrie. Cet article détaille les obligations du chapitre V, les garanties appropriées mobilisables et la méthode de vérification à appliquer avant tout déploiement.
Transfert de données hors UE des IA LLM, que dit le RGPD
Temps de lecture : ~9 min
- Ce qu’est réellement un transfert de données hors UE
- Pourquoi le transfert de données hors UE d’une IA LLM est si fréquent
- Le cadre RGPD applicable, article 44 et garanties appropriées
- Comment vérifier si votre fournisseur transfère vos données
- Hébergement en Europe et souveraineté des données, deux notions distinctes
- DPIA, minimisation et mesures techniques à mettre en place
- Cas d’usage sensibles, du chatbot RH au dossier de l’usager
- Aller plus loin avec le transfert de données hors UE
- Questions fréquentes sur le transfert de données hors UE et l’IA
Ce qu’est réellement un transfert de données hors UE
Définition d’un transfert de données personnelles au sens du RGPD
Un transfert de données personnelles hors UE au sens du RGPD ne se limite pas à l’envoi d’un fichier vers un serveur étranger. Il recouvre toute communication ou mise à disposition de données personnelles à un destinataire situé en dehors de l’Espace économique européen, y compris lorsqu’un simple accès à distance est ouvert depuis un pays tiers.
Un technicien basé hors EEE qui consulte une base hébergée à Paris pour une opération de maintenance réalise un transfert, même si la donnée ne bouge pas physiquement.
Cette définition large a une conséquence directe sur les projets d’intelligence artificielle. Dès lors qu’un appel API part vers une infrastructure d’hébergement située hors EEE, ou qu’un sous-traitant hors UE intervient dans la chaîne, le chapitre V du RGPD s’applique. La CNIL le rappelle clairement dans ses questions-réponses sur l’utilisation d’un système d’IA générative, un traitement peut impliquer un transfert hors UE si l’infrastructure d’hébergement est située hors de l’Union ou si elle est opérée par un fournisseur non européen. La localisation technique d’un serveur ne suffit donc jamais à clore le sujet.
Pourquoi le transfert de données hors UE d’une IA LLM est si fréquent
Les principaux points de sortie des données dans un projet d’IA générative
Les grands modèles de langage multiplient les points de sortie potentiels. Le premier est évident, le contenu du prompt lui-même. Un gestionnaire RH qui colle un courrier disciplinaire, un juriste qui soumet un contrat, un soignant qui résume une situation d’usager transmettent des données personnelles, parfois sensibles, à un système tiers.
Le second point de sortie concerne les documents rattachés, notamment dans une architecture RAG où des extraits de dossiers internes sont envoyés au modèle à chaque requête.
Viennent ensuite les couches que personne ne regarde. Les journaux d’utilisation conservent souvent les requêtes pendant plusieurs jours ou plusieurs mois pour des besoins de sécurité et de lutte contre les abus. La télémétrie remonte des identifiants techniques, des adresses IP, des horodatages et parfois des fragments de contenu. Le support technique accède aux environnements clients depuis des centres opérés dans plusieurs fuseaux horaires. Enfin, le transfert ultérieur, c’est à dire la retransmission des données par le sous-traitant à ses propres prestataires, échappe presque toujours à la vigilance de l’entreprise utilisatrice.
À cela s’ajoute la question de la réutilisation. Certains contrats grand public autorisent l’exploitation des saisies pour améliorer les modèles, ce qui transforme une donnée métier confidentielle en matériau d’entraînement hébergé hors d’Europe. C’est précisément ce mécanisme qui alimente le Shadow AI, ces usages non déclarés que les directions informatiques découvrent souvent après coup.
Bon à savoir
Un accès distant depuis un pays tiers suffit à caractériser un transfert, même si les données restent stockées sur un serveur européen. La question à poser à un fournisseur n’est donc pas seulement où sont mes données, mais qui peut y accéder et depuis où.
Le cadre RGPD applicable, article 44 et garanties appropriées
Les mécanismes juridiques disponibles pour encadrer un transfert vers un pays tiers
Le principe posé par l’article 44 du RGPD est simple. Un transfert vers un pays tiers n’est possible que si le niveau de protection garanti par le règlement n’est pas compromis. Le responsable de traitement doit donc s’appuyer sur un instrument juridique valide. La CNIL rappelle qu’aucune autorisation préalable n’a besoin d’être demandée lorsqu’une garantie appropriée est correctement mise en œuvre, ce qui déplace la charge vers la documentation et la preuve.
Les mécanismes disponibles ne se valent pas et ne s’adressent pas aux mêmes situations. Le tableau suivant résume leurs usages typiques dans un projet d’IA générative.
| Mécanisme | Principe | Pertinence pour un projet LLM |
|---|---|---|
| Décision d’adéquation | La Commission européenne reconnaît un niveau de protection équivalent dans le pays destinataire | Utilisable si le fournisseur relève effectivement du périmètre certifié, ce qui suppose une vérification nominative |
| Clauses contractuelles types (CCT ou SCC) | Modèle de contrat adopté par la Commission, signé entre exportateur et importateur | Solution la plus courante, mais elle impose une analyse d’impact du transfert et des mesures supplémentaires |
| Règles d’entreprise contraignantes (BCR) | Politique interne contraignante approuvée par une autorité de contrôle | Adaptée aux flux intragroupe, rarement disponible chez un éditeur d’IA tiers |
| Code de conduite ou certification | Engagement sectoriel assorti d’un contrôle par un organisme agréé | Encore peu répandu sur le marché des modèles de langage |
| Dérogations de l’article 49 | Consentement explicite, exécution d’un contrat, motif d’intérêt public | Réservées à des transferts occasionnels et non massifs, donc inadaptées à un usage quotidien d’assistant IA |
Depuis l’arrêt Schrems II rendu par la Cour de justice de l’Union européenne en 2020, la signature de clauses contractuelles types ne suffit plus à elle seule. L’exportateur doit évaluer la législation du pays de destination, notamment les possibilités d’accès des autorités locales aux données, puis mesurer l’efficacité réelle de l’outil de transfert choisi et, le cas échéant, ajouter des mesures techniques ou organisationnelles complémentaires. Le Data Privacy Framework entre l’Union européenne et les États-Unis a apporté un cadre nouveau, mais son application reste conditionnée à l’adhésion effective du fournisseur concerné et à la nature des traitements réalisés.
Comment vérifier si votre fournisseur transfère vos données
La CNIL recommande une démarche en plusieurs temps, qui commence par le recensement des flux hors UE puis par la vérification des paramétrages des outils et des destinations réelles des données. Appliquée à un projet d’IA générative, cette méthode se traduit par une cartographie des flux de données allant du poste de travail jusqu’au modèle, en passant par les passerelles applicatives et les services annexes.
Voici les points à contrôler dans la documentation contractuelle et technique du fournisseur avant toute mise en production.
- La localisation des données d’inférence, des données au repos et des sauvegardes, pays par pays et non pas au niveau d’une simple mention Europe.
- La durée et le lieu de conservation des journaux d’utilisation ainsi que la nature exacte des éléments journalisés.
- La liste nominative des sous-traitants ultérieurs, avec leur pays d’établissement et leur rôle précis.
- Les modalités d’accès du support technique, y compris les astreintes assurées depuis des pays tiers.
- L’engagement écrit de non réutilisation des contenus pour l’entraînement ou l’amélioration des modèles.
- Le mécanisme de transfert invoqué, avec la copie des clauses contractuelles types signées et l’analyse d’impact du transfert associée.
Ces éléments doivent figurer dans l’accord de traitement des données (DPA) et se retrouver dans votre registre des activités de traitement. Un DPA qui reste évasif sur la sous-traitance internationale constitue en soi un signal d’alerte. Notre checklist de conformité RGPD appliquée à l’IA détaille ces vérifications point par point.
Hébergement en Europe et souveraineté des données, deux notions distinctes
Beaucoup d’organisations considèrent qu’un outil est conforme dès lors qu’il affiche un hébergement européen. La réalité est plus nuancée. Un modèle peut être exécuté dans un centre de données situé en France tout en étant opéré par une entité soumise à une législation extraterritoriale, ce qui expose les données à des demandes d’accès émanant d’autorités non européennes. L’hébergement relève de la géographie, la souveraineté relève du droit applicable et de la chaîne de contrôle capitalistique et technique.
Pour un DSI de secteur régulé, cette distinction devient un critère de décision structurant. Choisir une plateforme conçue, opérée et hébergée en France réduit mécaniquement le périmètre des transferts à documenter et simplifie la démonstration de conformité auprès du DPO comme du régulateur. C’est le parti pris de SafeBrain, plateforme d’IA générative souveraine destinée aux organisations de 50 à 500 utilisateurs dans le public, la banque, l’assurance, la mutualité, la santé et l’industrie. Nous développons cette approche dans notre analyse de l’IA souveraine en France.
DPIA, minimisation et mesures techniques à mettre en place
Un déploiement de LLM à l’échelle d’une organisation traite fréquemment des données à caractère personnel de manière systématique et à grande échelle, ce qui rend l’analyse d’impact relative à la protection des données très souvent nécessaire. Cette AIPD, aussi appelée DPIA, doit décrire les finalités, les catégories de données, les destinataires, les durées de conservation et les mesures de sécurité. Lorsqu’un transfert hors EEE existe, elle se double d’une analyse d’impact du transfert, ou TIA, qui documente le contexte juridique du pays destinataire.
En parallèle, plusieurs leviers techniques réduisent l’exposition. La minimisation des données consiste à ne transmettre au modèle que ce qui est strictement nécessaire à la tâche. La pseudonymisation remplace les identifiants directs par des jetons réversibles sous contrôle interne, tandis que l’anonymisation, lorsqu’elle est réellement irréversible, fait sortir la donnée du champ du RGPD. Le respect des droits d’accès applicatifs au sein du moteur de recherche documentaire évite qu’un utilisateur n’obtienne, via une réponse générée, une information à laquelle il n’aurait pas accès dans le système source. Nous avons consacré un guide pratique à ces techniques.
Important
Les dérogations de l’article 49 du RGPD, comme le consentement explicite, ne peuvent pas fonder un usage récurrent et massif d’un assistant IA. La CNIL les réserve à des transferts occasionnels et non répétitifs.
Cas d’usage sensibles, du chatbot RH au dossier de l’usager
Certains usages concentrent le risque. Un assistant RH manipule des informations de carrière, de rémunération, parfois de santé ou de procédure disciplinaire. Les données personnelles d’un chatbot interne et leur conformité doivent donc être traitées avec le même sérieux qu’un applicatif de paie, information des salariés comprise. Un assistant juridique traite des données de contentieux couvertes par le secret professionnel. Dans le secteur médico-social, la recherche d’information dans les dossiers d’usagers ou la préparation de synthèses de parcours mobilisent des données de santé soumises à des exigences renforcées, dont l’hébergement certifié.
Dans ces contextes, l’arbitrage se joue rarement sur la performance brute du modèle mais sur la capacité à prouver la maîtrise du flux. Un DSI qui peut présenter une cartographie complète, un DPA sans sous-traitance internationale non documentée et une politique de rétention courte obtient bien plus facilement l’accord de son RSSI et de son DPO. C’est ce qui permet de dire oui à l’IA générative auprès des métiers plutôt que de subir des usages non maîtrisés.
Aller plus loin avec le transfert de données hors UE
Le transfert de données hors UE d’une IA LLM n’est pas une hypothèse théorique, c’est la situation par défaut de la plupart des services grand public et de nombreuses API professionnelles. Le RGPD autorise ces transferts, à condition de mobiliser des garanties appropriées, de documenter le contexte juridique du pays destinataire et de réévaluer régulièrement la situation.
La démarche recommandée par la CNIL reste la plus robuste, recenser les flux, vérifier les paramétrages, encadrer contractuellement, analyser l’impact et réexaminer périodiquement. Réduire le périmètre des transferts en choisissant une solution conçue et opérée en Europe ne dispense pas de cette rigueur, mais simplifie considérablement la charge de conformité et le dialogue avec les métiers. Pour échanger sur votre propre cartographie, notre équipe est joignable.
FAQ : Questions fréquentes sur le transfert de données hors UE et l’IA
Un modèle open source installé sur nos propres serveurs supprime-t-il tout risque de transfert ?
Un déploiement sur une infrastructure que vous contrôlez en France élimine le transfert lié à l’inférence, mais pas nécessairement les flux annexes. Les briques de supervision, les outils de journalisation centralisée, les services de monitoring ou les mises à jour peuvent remonter des métadonnées vers des plateformes situées hors EEE. La cartographie doit couvrir l’ensemble de la chaîne technique, pas seulement le moteur d’inférence.
Qui est responsable en cas de transfert non conforme, l’entreprise ou l’éditeur de l’IA ?
L’organisation qui décide des finalités du traitement reste responsable de traitement et assume la charge de démontrer la licéité du transfert. L’éditeur agit généralement comme sous-traitant et engage sa propre responsabilité sur les obligations qui lui incombent, notamment le respect des instructions et l’encadrement de ses sous-traitants ultérieurs. Une défaillance du fournisseur n’exonère pas l’entreprise utilisatrice.
Faut-il informer les salariés lorsqu’un outil d’IA traite leurs données ?
Oui, l’information des personnes concernées est une obligation autonome du RGPD. Lorsqu’un transfert hors EEE existe, la mention doit préciser l’existence de ce transfert, le mécanisme juridique retenu et les moyens d’en obtenir une copie. Dans le cadre d’un déploiement en entreprise, l’information des instances représentatives du personnel est également à anticiper, un sujet que nous détaillons dans notre analyse de l’IA et du droit du travail.
Que fait le règlement européen sur l’intelligence artificielle sur ce sujet ?
L’AI Act encadre les systèmes d’IA selon leur niveau de risque et impose des obligations de transparence, de documentation et de gestion des risques. Il ne se substitue pas au RGPD et ne traite pas des transferts internationaux de données personnelles. Les deux textes s’appliquent donc en parallèle, avec des logiques de conformité complémentaires.
À quelle fréquence faut-il réexaminer une analyse d’impact du transfert ?
Il n’existe pas de périodicité imposée, mais une révision annuelle constitue une pratique raisonnable. Un réexamen s’impose également à chaque évolution significative, changement de sous-traitant, modification de l’architecture technique, extension du périmètre d’usage ou évolution du cadre juridique du pays destinataire.
