Déploiement d'agents IA conforme au RGPD

Déploiement d'agents IA conforme au RGPD : l'essentiel

Un agent IA n'est pas un outil logiciel classique, mais un système qui traite en continu des données personnelles, souvent à des endroits que les équipes projet négligent au départ. Quiconque exploite un agent IA en Europe en tant que responsable du traitement (controller) doit donc justifier et documenter séparément chaque couche de traitement au regard de la protection des données. Cette page pilier donne une vue d'ensemble des cinq leviers essentiels : base légale (art. 6, le cas échéant art. 9 du RGPD), décisions individuelles automatisées (art. 22), sous-traitance (art. 28), analyse d'impact relative à la protection des données (art. 35) et résidence des données dans l'UE.

Un point important d'emblée : les deux régimes juridiques les plus pertinents pour les agents IA, le RGPD et le règlement européen sur l'IA, se recoupent mais s'appliquent indépendamment l'un de l'autre. Un traitement peut relever du RGPD sans tomber sous une classification à haut risque du règlement sur l'IA ; inversement, un système à haut risque au sens de l'annexe III doit respecter chaque principe du RGPD de manière autonome.

Où le RGPD intervient dans la stack d'un agent

Selon l'art. 4(1)/(2) du RGPD, toute opération portant sur des données personnelles déclenche l'application du règlement. Dans un système agentique, il s'agit en règle générale des éléments suivants :

• Entrées d'inférence : prompts, prompts système, fichiers téléversés, échantillons vocaux et visuels.
• Sorties d'inférence : textes et résumés qui nomment ou décrivent des personnes, y compris des données personnelles hallucinées. Les informations inventées sur une personne sont elles aussi des données personnelles et doivent être exactes en vertu de l'art. 5(1)(d). C'est sur ce point que s'appuient les plaintes de noyb contre OpenAI auprès de l'autorité autrichienne de protection des données, la DSB (avril 2024) et auprès de l'autorité norvégienne de protection des données, Datatilsynet (mars 2025).
• Mémoire de l'agent : fenêtres de contexte à court terme, mémoire épisodique et sémantique, bases vectorielles persistantes (mem0, LangGraph, Letta, bases de données propres).
• Payloads des appels d'outils : chaque corps JSON envoyé à une API interne ou à un serveur MCP fait entrer des données personnelles dans la sphère d'un nouveau sous-traitant.
• Communication multi-agents : les messages A2A sont des opérations de traitement même lorsque les deux agents relèvent du même responsable du traitement.
• Logs et traces, ainsi que les embeddings.

Point particulièrement sous-estimé : les embeddings ne sont pas automatiquement anonymes. Les attaques par inversion de texte (Morris et al., 2023) et les attaques par inférence d'appartenance montrent que les embeddings peuvent permettre une réidentification via la recherche par similarité. En cas de doute, traite donc les embeddings comme des données personnelles pseudonymisées.

Base légale : art. 6 du RGPD

Tout traitement nécessite l'une des six bases légales de l'art. 6(1). Pour les agents IA, trois d'entre elles comptent surtout en pratique :

Le test en trois étapes au titre de l'art. 6(1)(f) (lignes directrices 1/2024 du CEPD du 8.10.2024 et avis 28/2024 du CEPD) exige : (1) un intérêt réel et formulé concrètement (« améliorer notre agent de présélection RH pour nos propres salariés » plutôt qu'un vague « améliorer l'IA »), (2) la nécessité (pourrait-on y parvenir avec moins de données ou avec des données anonymisées ?) et (3) une mise en balance avec les attentes raisonnables des personnes concernées.

Le piège du « publiquement accessible » : une erreur tenace consiste à croire que les données web librement accessibles échappent au RGPD. Clearview AI a notamment été sanctionnée en Italie (20 millions d'euros, 10.2.2022) et en France (20 millions d'euros, 17.10.2022) ; l'accessibilité publique ne remplace ni le consentement ni une autre base légale. L'arrêt de la CJUE Meta c. Bundeskartellamt (C-252/21) le confirme : même pour des données publiques, la mise en balance au titre de l'art. 6(1)(f) doit être effectuée séparément.

Exemples de sanctions : l'autorité italienne de protection des données, le Garante, a infligé le 2.11.2024 une amende de 15 millions d'euros à OpenAI pour un entraînement sans base légale identifiée (violation des art. 5(1)(a), 5(2) et 6), une transparence insuffisante et l'absence de vérification de l'âge. Le tribunal de Rome (Tribunale di Roma) a annulé la décision le 18.3.2026, car en vertu du mécanisme de guichet unique du RGPD, c'était l'autorité de contrôle irlandaise qui était compétente. Le tribunal ne s'est pas prononcé sur les griefs eux-mêmes. La décision Replika contre Luka Inc. (10.4.2025, 5 millions d'euros) complète le tableau : l'exécution d'un contrat (art. 6(1)(b)) ne tient pas lorsque les utilisateurs comprennent des mineurs dépourvus de capacité juridique.

Catégories particulières de données : art. 9 du RGPD

Dès qu'un agent traite des données de santé, des données biométriques ou d'autres données sensibles, l'interdiction de principe de l'art. 9(1) s'applique. Les exceptions pertinentes en pratique sont le consentement explicite (art. 9(2)(a)), les fondements relevant du droit du travail et de la protection sociale (art. 9(2)(b), p. ex. §26(3) BDSG) ainsi que l'intérêt public important (art. 9(2)(g)). Attention à l'articulation avec le règlement sur l'IA : depuis l'omnibus numérique relatif au règlement sur l'IA (règlement (UE) 2026/1744, en vigueur depuis le 27.7.2026), l'autorisation de traiter des données sensibles pour détecter les biais ne figure plus à l'art. 10(5), mais à l'art. 4a. Le paragraphe 1 s'applique aux fournisseurs de systèmes à haut risque. Le paragraphe 2 l'étend aux déployeurs de systèmes à haut risque ainsi qu'aux fournisseurs et déployeurs d'autres systèmes et modèles d'IA, mais uniquement dans la mesure où le biais peut porter atteinte à la santé et à la sécurité, violer des droits fondamentaux ou conduire à une discrimination interdite. Pour les fournisseurs de systèmes à haut risque, le considérant 70 qualifie cela d'intérêt public important au sens de l'art. 9(2)(g) du RGPD. Ce n'est pas pour autant une exception générale : l'autorisation ne vaut que dans la mesure où le traitement est strictement nécessaire pour détecter et corriger les biais, et uniquement avec les garanties prévues par le règlement sur l'IA (notamment pseudonymisation, accès restreint, absence de transmission, suppression après la correction). Toutes les autres obligations du RGPD continuent de s'appliquer en parallèle.

Décisions individuelles automatisées : l'art. 22 après SCHUFA et Dun & Bradstreet

L'art. 22 est la disposition du RGPD la plus contentieuse dans le domaine des agents IA. Deux arrêts de la CJUE en ont considérablement élargi le champ d'application :

• SCHUFA (C-634/21, 7.12.2023) : une simple valeur de probabilité automatisée (score) constitue en soi une décision individuelle automatisée au sens de l'art. 22(1) lorsqu'un tiers (p. ex. la banque) s'y fonde de manière déterminante. L'art. 22 pose une interdiction de principe, et pas seulement un droit à faire valoir ; c'est au responsable du traitement de prouver qu'une exception s'applique.
• Dun & Bradstreet (C-203/22, 27.2.2025) : les « informations utiles concernant la logique sous-jacente » (art. 15(1)(h)) désignent une explication concrète et compréhensible permettant aux personnes concernées de comprendre, vérifier et contester la décision. La divulgation de l'algorithme ou d'une formule mathématique ne suffit pas. Les secrets d'affaires ne font pas automatiquement obstacle à la communication ; en cas de litige, l'autorité de contrôle ou la juridiction tranche au cas par cas.

En pratique, cela signifie que les agents pilotés par un score (présélection RH, décision de crédit, souscription en assurance, tarification dynamique) déclenchent l'art. 22 presque systématiquement. Le constat d'audit le plus fréquent en 2024–2025 est la validation de façade : une confirmation humaine purement formelle. Pour qu'une décision ne soit pas « fondée exclusivement sur un traitement automatisé », la personne doit avoir la compétence et le pouvoir de passer outre, examiner réellement les données et afficher des taux de dérogation plausibles. En tant qu'autorité d'origine de l'affaire Dun & Bradstreet, la DSB autrichienne fait ici directement référence pour l'espace DACH (Allemagne, Autriche, Suisse).

Sous-traitance : art. 28 du RGPD

La plupart des contrats d'IA pour entreprises (Microsoft Azure OpenAI, OpenAI Enterprise, Anthropic Claude for Work, Google Vertex AI, AWS Bedrock, Mistral, Aleph Alpha) sont structurés comme une relation entre responsable du traitement et sous-traitant, avec l'engagement exprès de ne pas utiliser les données clients pour entraîner les modèles. Ces engagements sont toutefois de nature contractuelle et non légale, et réservent souvent des droits restreints pour la détection des abus ou les contrôles de sécurité.

Une stack d'agents moderne génère généralement une cascade de sous-traitants ultérieurs sur cinq à huit niveaux : fournisseur du modèle de fondation → cloud/hébergement → runtime d'orchestration → base vectorielle → fournisseur de mémoire → serveur MCP → observabilité → évaluation. Pour chaque niveau, un contrat de sous-traitance doit exister, la chaîne prévue à l'art. 28(4) doit être complète et la résidence des données cohérente. Les constats d'audit les plus fréquents : des flux vers des serveurs MCP non déclarés, des fournisseurs d'observabilité sans contrat de sous-traitance et des services d'évaluation qui collectent des traces de prompts. Au-delà de la seule question de la sous-traitance, un changement de rôle menace : si un fournisseur utilise les données à ses propres fins, il devient pour celles-ci responsable du traitement à part entière. S'il détermine les finalités conjointement avec toi, on se retrouve en responsabilité conjointe au sens de l'art. 26. La recherche web dans Microsoft Copilot illustre une responsabilité autonome : pour les requêtes envoyées à Bing, Microsoft agit en tant que responsable du traitement selon sa propre documentation, même si l'entreprise s'engage à ne les utiliser ni pour la publicité ni pour l'entraînement de modèles d'IA. Le contrat de sous-traitance de Microsoft ne couvre pas ce traitement. Dans les deux cas, le flux de données quitte la sphère du sous-traitant.

Analyse d'impact relative à la protection des données (AIPD) : art. 35 du RGPD

Les agents IA rendent souvent une AIPD obligatoire, car ils remplissent régulièrement au moins l'un des critères de l'art. 35(3) et des listes obligatoires des autorités de contrôle : décision automatisée produisant des effets, profilage à grande échelle, traitement biométrique, usage innovant de technologies ou surveillance des salariés. Le guide d'orientation de la DSK « Künstliche Intelligenz und Datenschutz » (version 1.0, 6.5.2024, point 39) part du principe qu'une AIPD est souvent nécessaire lors de l'utilisation d'applications d'IA.

La méthodologie de l'AIPD (note de synthèse n° 5 de la DSK, outil du BfDI, CEPD WP248) comprend : (1) l'examen de la nécessité et de la proportionnalité, (2) l'identification des risques (pour les agents IA : hallucinations, biais, injection de prompts, fuite de mémoire, régurgitation de sorties, exfiltration par appels d'outils, réidentification), (3) l'évaluation des risques et (4) le traitement des risques. Les livrables requis sont des diagrammes de flux de données couvrant chaque transit de données personnelles, une cartographie des rôles (responsable du traitement, responsable conjoint, sous-traitant avec la chaîne de l'art. 28(4)), un registre des risques et des preuves de consultation (avis du DPO selon l'art. 35(2) ; participation du comité d'entreprise ou de la représentation du personnel selon le §87 BetrVG ou l'ArbVG). En présence d'un haut risque relevant de l'annexe III, l'AIPD peut être fusionnée avec l'analyse d'impact sur les droits fondamentaux (FRIA, art. 27 du règlement sur l'IA) en un livrable commun (art. 27(4) du règlement sur l'IA).

Résidence des données dans l'UE et transferts internationaux

Pour les décideurs en Europe, la résidence des données dans l'UE est un levier central de réduction des risques. Elle s'obtient via l'EU Data Boundary (Microsoft), les régions UE (Vertex AI avec endpoints régionaux dans l'UE, AWS) ou des fournisseurs souverains comme Aleph Alpha (Pharia), IONOS AI Model Hub, STACKIT, T-Systems Open Telekom Cloud (DE/UE) et Swisscom Sovereign AI (CH).

Pour les transferts vers des pays tiers, le critère Schrems II s'applique : des clauses contractuelles types (CCT) uniquement avec une analyse d'impact des transferts (AITD) propre à chaque cas. L'EU-US Data Privacy Framework (décision d'adéquation du 10.7.2023) est actuellement valide ; le 3.9.2025, le Tribunal de l'UE a rejeté le premier recours dans l'affaire Latombe/Commission, mais un pourvoi est pendant devant la CJUE. Recommandation opérationnelle : utiliser la certification DPF, mais garder les CCT en solution de repli et réaliser des AITD également pour les destinataires certifiés DPF. Pour les fournisseurs américains, le CLOUD Act et FISA 702 restent des risques à traiter dans l'AITD. La Suisse est considérée comme offrant un niveau de protection adéquat depuis 2000 (décision 2000/518/CE) ; la Commission européenne l'a confirmé le 15.1.2024 lors de son premier réexamen des décisions d'adéquation plus anciennes. Le Swiss-US DPF s'applique depuis le 15.9.2024.

Spécificités DACH et durcissement suisse

Au sein de l'espace DACH, les autorités de contrôle divergent. L'autorité de protection des données de Hambourg défend la thèse selon laquelle le simple stockage d'un LLM ne constitue pas un traitement (document de discussion, 15.7.2024) ; l'avis 28/2024 du CEPD la contredit implicitement. Pour les déployeurs, la position sûre consiste à considérer le modèle comme pouvant contenir des données personnelles et à concentrer le travail de conformité sur les couches contrôlées par le déployeur (index RAG, mémoire, logs), où la suppression est techniquement possible.

En Suisse, l'art. 21 de la nLPD encadre les décisions individuelles automatisées autrement que l'art. 22 du RGPD : il ne les interdit pas, mais exige que le responsable du traitement informe la personne concernée, lui donne sur demande la possibilité de faire valoir son point de vue et fasse revoir la décision par une personne physique si elle le demande. Le durcissement tient à la responsabilité pénale personnelle : quiconque viole intentionnellement le devoir d'information peut, sur plainte, être puni selon l'art. 60 nLPD d'une amende allant jusqu'à 250 000 CHF, et ce en tant que personne physique, par exemple un membre de la direction ou le DPO. Pour les prestataires financiers soumis à la FINMA s'ajoutent les notifications d'externalisation et les analyses liées au secret bancaire, qui poussent de nombreux déployeurs vers le cloud souverain.

Ce qui est en train de changer

Le 19.11.2025, la Commission européenne a proposé l'omnibus numérique. L'omnibus numérique relatif au règlement sur l'IA, proposé en parallèle, est en revanche en vigueur depuis le 27.7.2026 (règlement (UE) 2026/1744, voir la section sur l'art. 9). Le volet protection des données de l'omnibus numérique général déplacerait précisément les leviers de cette page : une notion relative de données personnelles à l'art. 4(1), un intérêt légitime expressément encadré pour le développement et l'exploitation de l'IA (nouvel art. 88c), une exception pour les données sensibles qui se retrouvent incidemment dans les données d'entraînement (art. 9) et une refonte de l'art. 22 sous forme de liste exhaustive des cas autorisés. Rien de tout cela n'est adopté. Au 12.10.2026, le Conseil n'avait toujours pas de mandat de négociation : le vote au Comité des représentants permanents a été reporté le 7.10, et le 11.10, le texte de compromis n'a été ni discuté ni voté. Au Parlement, le vote en commission sur le projet de rapport était à cette date toujours attendu. Tant qu'aucune décision n'est adoptée, le RGPD s'applique sans changement.

La CJUE s'est déjà prononcée sur les données pseudonymisées. Dans l'arrêt CEPD/CRU (C-413/23 P, 4.9.2025), elle a jugé que, pour un destinataire qui ne peut pas réidentifier les personnes avec des moyens raisonnablement disponibles, les données pseudonymisées ne sont pas des données personnelles. Chez le responsable du traitement capable d'établir la correspondance, elles restent personnelles, et elles le redeviennent dès qu'une personne disposant de moyens de réidentification les obtient. Pour les embeddings, cela signifie que quiconque conserve les textes sources ou la correspondance avec les personnes traite des données personnelles.

Perspectives pratiques

La conformité au RGPD des agents IA n'est pas un document ponctuel, mais un principe d'architecture : sépare la couche d'inférence (API managée avec contrat de sous-traitance « sans entraînement ») des couches contrôlées par le déployeur, qui doivent rester entièrement effaçables, et ajoute une couche de filtrage pour les demandes DSAR et celles fondées sur l'art. 17. Quiconque intègre dès le départ la base légale, l'architecture liée à l'art. 22, une cascade complète de contrats de sous-traitance, l'AIPD et la résidence des données évite les constats d'audit les plus fréquents : des memory stores non protégés aux flux MCP non déclarés, en passant par des logs de prompts sans politique de suppression. Pour la mise en œuvre contractuelle et technique concrète, les responsables du traitement devraient toujours solliciter un conseil juridique spécialisé ; cette vue d'ensemble ne le remplace pas.