Analyse d'impact (AIPD) pour les agents IA : obligation, seuils et méthode étape par étape

Une analyse d'impact relative à la protection des données (AIPD, en anglais DPIA) est obligatoire en vertu de l'article 35 du RGPD lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques. Pour les agents IA, elle est en pratique presque toujours nécessaire, car ces systèmes remplissent généralement plusieurs critères de risque à la fois, par exemple une technologie innovante combinée à du profilage, une décision automatisée ou le croisement de jeux de données issus de plusieurs sources.

Cet article fait partie du dossier « Déploiement d'agents IA conforme au RGPD » et propose une méthode étape par étape solide ainsi qu'une check-list des déclencheurs pour les responsables du traitement en Europe.

Réponses rapides

• Seuil : l'AIPD est obligatoire dès qu'un risque élevé est probable (article 35, paragraphe 1). L'article 35, paragraphe 3, cite trois cas types et l'article 35, paragraphe 4, oblige les autorités de contrôle à établir des listes obligatoires : en Allemagne, la liste de la DSK pour le secteur non public, en Autriche, le règlement DSFA-V de l'autorité de protection des données. En Suisse, l'obligation d'AIPD découle de l'article 22 de la LPD ; le RGPD ne s'y applique que dans les cas visés à l'article 3, paragraphe 2, du RGPD.
• L'IA dans les faits : en raison du profilage, de la décision automatisée et de la technologie innovante, les agents IA déclenchent presque toujours l'obligation d'AIPD.
• Procédure : l'AIPD suit un déroulement documenté : description du traitement comme élément obligatoire, puis nécessité/proportionnalité, identification des risques, évaluation des risques et mesures correctives. En cas de risque résiduel élevé, la consultation préalable au titre de l'article 36 suit.

Ce qu'est une AIPD selon l'article 35 du RGPD

L'article 35, paragraphe 1, du RGPD oblige le responsable du traitement à réaliser une AIPD lorsqu'un type de traitement, en particulier par le recours à de nouvelles technologies, est susceptible, compte tenu de sa nature, de sa portée, de son contexte et de ses finalités, d'engendrer un risque élevé pour les droits et libertés des personnes physiques. L'AIPD est donc un outil de gestion des risques en amont : elle est réalisée avant le début du traitement et documente si les risques sont maîtrisés et comment.

Important : le responsable du traitement (controller) reste chargé de l'AIPD, même s'il n'a pas développé lui-même l'agent IA. Dans son guide d'orientation « Künstliche Intelligenz und Datenschutz » (version 1.0, 6 mai 2024), la DSK constate qu'une AIPD sera souvent nécessaire lors de l'utilisation d'applications d'IA (point 39). Si le responsable n'est pas en même temps fournisseur du système d'IA, il dépend pour cela des informations du fournisseur sur son fonctionnement (point 40).

Quand l'AIPD devient obligatoire pour les agents IA

L'article 35, paragraphe 3, cite trois cas types prévus par la loi (présomptions) :

1. Évaluation systématique et approfondie d'aspects personnels, y compris le profilage, produisant des effets importants.
2. Traitement à grande échelle de catégories particulières de données (article 9) ou de données relatives aux condamnations pénales (article 10).
3. Surveillance systématique à grande échelle d'une zone accessible au public.

En outre, l'article 35, paragraphe 4, du RGPD oblige les autorités de contrôle à publier des listes des traitements pour lesquels une AIPD est obligatoire. Pour les responsables privés en Allemagne, c'est la liste obligatoire de la DSK pour le secteur non public (version 1.1 du 17 octobre 2018) qui s'applique, en Autriche le règlement DSFA-V de l'autorité de protection des données (BGBl. II Nr. 278/2018). En Suisse, l'obligation d'AIPD découle de l'article 22 de la LPD. Le RGPD ne s'applique aux responsables suisses que s'ils proposent des biens ou des services à des personnes dans l'UE ou y suivent leur comportement (article 3, paragraphe 2, du RGPD). Pour les agents IA, les entrées les plus pertinentes de la liste de la DSK sont les suivantes :

• Utilisation d'une IA qui traite des données personnelles pour piloter l'interaction avec les personnes concernées ou évaluer des aspects personnels (n° 11), par exemple dans le support client
• Croisement à grande échelle de données issues de plusieurs sources lorsqu'il sert à préparer des décisions produisant des effets juridiques, par exemple pour le scoring (n° 5), ou à rechercher des corrélations inconnues (n° 10)
• Profils complets sur les centres d'intérêt, les relations ou la personnalité (n° 9)
• Analyse automatisée d'enregistrements vidéo ou audio pour évaluer la personnalité (n° 13)
• Identification biométrique ou données génétiques, lorsqu'au moins un autre critère WP248 est rempli (n° 1 et 2)
• Analyse à grande échelle du comportement des salariés pour évaluer leur travail (n° 8)

La conséquence pratique : en raison d'un ou de plusieurs de ces points, les agents IA déclenchent presque toujours l'obligation d'AIPD.

Check-list des déclencheurs pour les agents IA

Si le traitement relève d'un cas type de l'article 35, paragraphe 3, ou figure sur une liste obligatoire au titre de l'article 35, paragraphe 4, l'AIPD est obligatoire. Pour les autres critères, les lignes directrices WP248 rev.01 posent une règle empirique : à partir de deux critères remplis, une AIPD doit être réalisée, et dans certains cas dès un seul. En cas de doute, il est conseillé de mener un examen préalable documenté des seuils (« threshold assessment ») qui justifie pourquoi aucune AIPD ne serait nécessaire ; cela répond au principe de responsabilité de l'article 5, paragraphe 2.

La méthodologie de l'AIPD étape par étape

La description du traitement est, selon l'article 35, paragraphe 7, point a), du RGPD, un élément obligatoire préalable de toute AIPD : une description systématique de l'agent IA avec un diagramme de flux de données qui représente chaque saut de données personnelles (utilisateur → runtime de l'agent → API du modèle → base vectorielle → serveur MCP → backend d'observabilité → logs), ainsi que l'architecture du système avec la cartographie des sous-traitants ultérieurs et l'attribution des rôles (responsable du traitement, responsables conjoints, sous-traitants, sous-traitants ultérieurs avec une chaîne ininterrompue au titre de l'article 28, paragraphe 4).

Sur cette base viennent les quatre étapes clés qui découlent de l'article 35, paragraphe 7, points b) à d), du RGPD. Elles correspondent aux lignes directrices WP248 rev.01 du groupe de travail « Article 29 », que le CEPD a confirmées. Le Kurzpapier n° 5 de la DSK les inscrit dans un cycle de préparation, de réalisation, de mise en œuvre et de réexamen :

1. Nécessité et proportionnalité. Le traitement est-il strictement nécessaire ? Des données anonymes, pseudonymisées ou synthétiques suffiraient-elles ? Le volume de données et la durée de conservation sont-ils minimisés ? Concrètement pour le RAG : indexation de chunks pseudonymisés et minimisation des payloads de contexte.
2. Identification des risques. Recensement des risques propres à l'IA (voir la section suivante), rapportés à chaque groupe de personnes concernées.
3. Évaluation des risques. Évaluation de chaque risque selon la probabilité multipliée par la gravité.
4. Traitement des risques et acceptation du risque résiduel. Mesures techniques au titre de l'article 32 (chiffrement, pseudonymisation, contrôles d'accès, journalisation, défense contre l'injection de prompt), mesures organisationnelles (formation, gouvernance) et mesures contractuelles (clauses du contrat de sous-traitance), ainsi que l'acceptation documentée du risque résiduel.

Les preuves de consultation requises en font partie : l'avis du délégué à la protection des données (article 35, paragraphe 2), l'implication du comité d'entreprise ou de la représentation du personnel le cas échéant (§ 87 BetrVG, ArbVG autrichien, règles suisses de participation) ainsi que, lorsque c'est possible, la consultation des groupes de personnes concernées (article 35, paragraphe 9).

Les risques propres à l'IA dans le registre des risques

Pour les agents IA, le catalogue des risques est nettement plus large que pour un traitement de données classique. L'AIPD doit au minimum prendre en compte :

• Hallucination : données personnelles inventées mais plausibles ; à la fois inexactes (article 5, paragraphe 1, point d) et sources de risque de réidentification
• Biais et discrimination dans les résultats de scoring et de classement
• Injection de prompt, y compris les attaques entre clients (cross-tenant) qui extraient des données d'autrui
• Fuites de mémoire entre sessions via une mémoire partagée ou des prompts système
• Régurgitation dans les sorties de données personnelles d'entraînement
• Dérive du périmètre (scope creep) et inférence non autorisée
• Exfiltration de données via les appels d'outils vers des sous-traitants ultérieurs non documentés
• Réidentification par inversion d'embeddings : les embeddings ne sont pas automatiquement anonymes et sont considérés comme des données personnelles pseudonymisées
• Risque lié à la chaîne d'approvisionnement à travers une pile de sous-traitants ultérieurs comptant cinq à huit niveaux

Le guide d'orientation de la DSK sur le RAG (2025) ajoute deux risques propres au RAG : les attaques par inférence d'appartenance (membership inference) et l'empoisonnement de données (data poisoning). La publication de la DSK « Datenschutzrechtliche Anforderungen an KI-Systeme » (17 juin 2025) fournit en outre la correspondance opérationnelle avec le modèle standard de protection des données (SDM).

Exemple concret chiffré : agent de service client

Une entreprise de taille intermédiaire (800 salariés) en Autriche prévoit un agent de service client basé sur Azure OpenAI. Chaque mois, l'agent traite environ 40 000 conversations, dont, selon les estimations, 30 % (soit environ 12 000) contiennent des données client identifiantes dans les prompts. Les décisions d'escalade sont dans un premier temps préparées de manière automatisée.

Dans l'AIPD, le risque « régurgitation dans les sorties de données personnelles d'entraînement » est évalué avec une probabilité « moyenne » et une gravité « élevée ». Mesures correctives : filtres de sortie, test de red teaming sur la mémorisation, mise en balance des intérêts documentée. Pour le risque « fuites de mémoire entre sessions », une isolation stricte entre clients fait passer la probabilité de « moyenne » à « faible ». La conservation des prompts dans le système propre est limitée à 30 jours, avec caviardage avant tout stockage durable. S'y ajoute la surveillance des abus de Microsoft : des employés habilités de Microsoft peuvent examiner les prompts et réponses signalés ; pour les déploiements dans l'EEE, ces employés se trouvent dans l'EEE. Avec un « Modified Abuse Monitoring » approuvé, cet examen humain est supprimé. Comme toute décision lourde de conséquences est escaladée à un humain et que l'agent prépare au lieu de décider, le risque résiduel au titre de l'article 22 descend à un niveau acceptable. Résultat : aucune consultation préalable au titre de l'article 36 n'est nécessaire.

Consultation préalable au titre de l'article 36

Si un risque résiduel élevé subsiste après toutes les mesures, l'autorité de contrôle doit être consultée avant le début du traitement, conformément à l'article 36. Dans le contexte des agents IA, c'est rare, mais plausible pour des agents de présélection RH ayant des effets importants sur les candidats, pour des agents autonomes de triage médical et pour des agents de souscription d'assurance. Si l'autorité estime que le traitement n'est pas conforme au RGPD, elle formule des recommandations écrites dans un délai pouvant aller jusqu'à huit semaines ; pour les traitements complexes, elle peut prolonger ce délai de six semaines (article 36, paragraphe 2, du RGPD). En droit suisse, c'est l'article 23 de la LPD qui s'applique : le PFPDT communique ses objections dans un délai de deux mois, ou de trois mois pour les traitements complexes.

Intégration avec la FRIA du règlement européen sur l'IA

Pour les déployeurs de systèmes à haut risque relevant de l'annexe III qui sont des organismes publics ou des entités privées fournissant des services publics, ou qui opèrent dans des domaines spécifiés, l'article 27 du règlement européen sur l'IA exige une analyse d'impact sur les droits fondamentaux (FRIA). Pour les systèmes de l'annexe III, cette obligation ne s'applique qu'à partir du 2 décembre 2027 : l'omnibus IA (règlement (UE) 2026/1744) a reporté à cette date, depuis le 2 août 2026, les obligations relatives au haut risque du chapitre III, sections 1 à 3, dont fait partie l'article 27. L'article 27, paragraphe 4, permet expressément que la FRIA complète l'AIPD du RGPD et réutilise les contenus qui se recoupent. Déroulement recommandé :

• Réaliser d'abord l'AIPD (ou en parallèle) selon la méthodologie du RGPD.
• L'enrichir des éléments propres à la FRIA : incidences sur les droits fondamentaux au-delà de la protection des données (non-discrimination, dignité, liberté d'expression, droit à un recours effectif), groupes de personnes concernés, préjudices, surveillance, mécanismes de plainte.
• Produire un seul document fusionné avec des renvois à l'article 35 du RGPD et à l'article 27 du règlement sur l'IA.

Remarque sur l'articulation : le droit à l'explication des décisions individuelles prévu à l'article 86 du règlement européen sur l'IA bénéficie aux personnes affectées, juridiquement ou de manière similaire et significative, par une décision fondée sur un système d'IA à haut risque relevant de l'annexe III (à l'exception du point 2, infrastructures critiques). Il ne s'applique que dans la mesure où le droit de l'Union, par exemple le RGPD, ne prévoit pas de droit équivalent (article 86, paragraphe 3). L'article 86 ne figure pas au chapitre III ; son entrée en application, fixée au 2 août 2026, n'a pas été reportée par l'omnibus IA. Le droit est toutefois rattaché aux systèmes à haut risque de l'annexe III, dont la classification au titre de l'article 6, paragraphe 2, ne s'applique qu'à partir du 2 décembre 2027 (article 113 du règlement sur l'IA dans sa version modifiée par l'omnibus IA). Reste à savoir si l'article 86 s'applique en pratique plus tôt.

Pour les agences et le B2B

Les agences marketing et les prestataires B2B qui déploient des agents IA pour leurs clients sont souvent sous-traitants. L'obligation d'AIPD incombe alors au client en tant que responsable du traitement, mais l'agence doit fournir une description solide du traitement et la cartographie des sous-traitants ultérieurs. Ce point est souvent sous-estimé. Si l'agence et le client sont responsables conjoints du traitement au sens de l'article 26 du RGPD, l'agence porte conjointement l'obligation d'AIPD. Qui apporte dès la phase d'offre un modèle d'AIPD, un diagramme de flux de données et un catalogue de mesures vérifié raccourcit nettement les cycles de validation et réduit la réserve la plus fréquente lors des audits : un déploiement de Copilot ou d'agents sans AIPD et sans consultation du comité d'entreprise. Blck Alpaca aide les entreprises en Europe à mettre en place l'AIPD, de l'examen des seuils jusqu'au document fusionné AIPD/FRIA.

Avertissement juridique : cet article est fourni à titre d'information générale et ne constitue pas un conseil juridique. Pour une appréciation contraignante d'un traitement concret par agent IA, fais appel à un conseil juridique qualifié et à ton autorité de contrôle compétente.