Transferts hors UE et IA : quand un proxy de pseudonymisation ne suffit pas

Quand une requête d’IA est-elle un transfert hors UE ?

Le chapitre V du RGPD (art. 44 à 49) règle les cas dans lesquels des données personnelles peuvent être transmises à des destinataires hors de l’UE et de l’EEE : sur la base d’une décision d’adéquation, de garanties appropriées comme les clauses contractuelles types, ou d’une dérogation au titre de l’art. 49. Si un modèle d’IA tourne chez un fournisseur aux États-Unis, ou si un tel fournisseur accède techniquement aux requêtes, il s’agit d’un transfert dès que les données sont personnelles pour lui.

Un proxy de pseudonymisation vise précisément à l’éviter : il remplace les noms et les identifiants avant que le texte ne quitte votre établissement (fonctionnement de la technique). Que cela suffise dépend du rôle du destinataire et du texte concret.

Quelle situation entraîne quelle conséquence ?

Situation	Conséquence
Les données d’origine vont à un fournisseur américain	données personnelles ; vérifier le chapitre V du RGPD
Pseudonymisées ; le fournisseur de modèles calcule pour votre compte	selon le projet de lignes directrices 02/2026, personnelles pour lui aussi ; le chapitre V s’applique
Pseudonymisées ; le destinataire peut reconnaître la personne concernée par le contexte, les métadonnées ou des requêtes liées	toujours personnelles ; les règles de transfert hors UE s’appliquent
Anonymes pour un destinataire indépendant, preuve à l’appui	peut échapper aux règles de transfert hors UE ; le traitement en amont reste encadré
Un proxy dans l’UE traite l’original et ne transmet que des données dont l’anonymat est prouvé	le proxy reste soumis au RGPD ; la transmission doit être évaluée séparément
Un proxy ou un modèle dans un matériel protégé reçoit des contenus identifiables	le matériel ne supprime ni le caractère personnel ni les obligations de transfert hors UE

Que disent la CJUE et les autorités de protection des données ?

CJUE : dans l’arrêt C-413/23 P du 4 septembre 2025, la Cour a constaté que des données pseudonymisées ne sont pas personnelles dans tous les cas et pour toute personne. Une pseudonymisation efficace peut empêcher d’autres acteurs que le responsable du traitement d’identifier les personnes. Pour le responsable lui-même, elles restent personnelles.

Lignes directrices 02/2026 (projet) : le Comité européen de la protection des données (CEPD) a adopté le 7 juillet 2026 un projet sur l’anonymisation ; la consultation court jusqu’au 30 octobre 2026. Deux points comptent pour les fournisseurs d’IA situés dans un pays tiers :

• Celui qui traite pour le compte d’un autre est évalué du point de vue de cet autre (point 15). Si les données sont personnelles pour vous, elles le sont aussi pour le fournisseur de modèles qui calcule pour votre compte.
• S’il est raisonnablement probable qu’un destinataire transmette les données à un tiers capable de les rattacher à une personne, elles sont considérées comme personnelles pour cette transmission et pour le traitement ultérieur (point 21).

Recommandations 01/2020 : les recommandations sur les mesures complémentaires aux transferts (version du 18 juin 2021) traitaient déjà la pseudonymisation comme une mesure de protection possible, si l’exportateur peut prouver que les données ne peuvent être rattachées à aucune personne, même à l’aide d’informations dont les autorités du pays destinataire pourraient disposer. Pour les fournisseurs qui ont besoin d’accéder au texte en clair pour accomplir leur tâche, le Comité n’y a trouvé aucune mesure technique complémentaire efficace.

Pourquoi la preuve est-elle difficile pour les requêtes d’IA ?

Un texte libre contient souvent des indications qui, ensemble, rendent une personne reconnaissable, même sans nom. Un exemple inventé : « PATIENT_17, 43 ans, Starnberg, maladie métabolique rare » ne cite aucun nom, mais dans une petite ville cela peut suffire. S’y ajoutent des métadonnées comme l’organisation émettrice, l’heure et l’identifiant du compte, que le fournisseur de modèles reçoit de toute façon, ainsi que des marqueurs stables qui permettent de relier plusieurs requêtes concernant la même personne (réidentification).

Que devez-vous vérifier ?

1. Rôle du fournisseur de modèles : traite-t-il pour votre compte (accord de traitement des données), ou est-il un destinataire indépendant ?
2. Base du transfert : le fournisseur est-il certifié au titre du Data Privacy Framework UE-États-Unis (décision d’exécution 2023/1795), ou des clauses contractuelles types avec analyse d’impact du transfert s’appliquent-elles ?
3. Risque résiduel : pouvez-vous prouver, pour votre type de texte, que l’individualisation, la corrélation et l’inférence échouent ?
4. Autres chemins : des pièces jointes, des journaux ou la recherche web contournent-ils le proxy pour aller dans le pays tiers ?
5. Accès par les autorités : si le fournisseur relève du droit américain, le CLOUD Act s’applique aussi aux centres de données en Europe (CLOUD Act américain).
6. Secret professionnel : pour les données de patients ou de mandants, le § 203 StGB (Code pénal allemand, secret professionnel) s’applique en plus.

Et avec basebox ?

basebox est une entreprise allemande ; la plateforme et le modèle d’IA tournent sur un serveur dans votre établissement ou dans notre cloud, au centre de données München-Ost (Munich). Par défaut, basebox n’envoie vos données à aucun modèle d’IA d’un autre fournisseur, et le CLOUD Act ne s’applique pas au modèle d’IA dans basebox. Il en va autrement de l’app avec un modèle externe, optionnelle : elle tourne chez Google Vertex dans l’UE ; Google étant une entreprise américaine, le CLOUD Act s’y applique. C’est vous qui décidez, avec votre délégué à la protection des données, si vous l’utilisez et pour quelles données (détails).

Pas un conseil juridique : cet article donne un aperçu de la situation au 11 octobre 2026. Les lignes directrices 02/2026 sont un projet en consultation ; la décision d’adéquation relative au Data Privacy Framework peut faire l’objet d’un contrôle juridictionnel. Vérifiez vos transferts avec votre délégué à la protection des données.