Ce qu’il faut retenir
- Une AIPD évalue les risques élevés qu’un traitement de données personnelles fait peser sur les droits et libertés. Elle n’est pas réservée aux systèmes classés à haut risque par l’AI Act.
- La nécessité et la proportionnalité se testent avant les mesures de sécurité : finalité, données, personnes, sources, destinataires, durée et alternatives moins intrusives.
- Les risques propres à l’IA incluent inférences, biais, mémorisation, contenu faux sur une personne, fuite, injection, réidentification et automatisation indue. Ils doivent être formulés comme des scénarios causaux.
- L’AIPD et la FRIA peuvent partager des preuves mais n’ont ni le même déclencheur ni exactement le même objet. Les références croisées évitent la duplication sans fusionner les décisions.
- Si le risque résiduel demeure élevé en l’absence de mesures, le responsable du traitement examine la consultation préalable de l’autorité selon l’article 36 du RGPD.
Un système d’IA peut être peu risqué au sens de la classification de l’AI Act et traiter pourtant des données personnelles à grande échelle, créer des inférences ou rendre une erreur difficile à corriger. À l’inverse, un système à haut risque n’implique pas automatiquement que chaque traitement associé présente exactement le même risque RGPD. Les deux analyses doivent dialoguer sans être confondues.
Une bonne AIPD ne commence pas par une liste de mesures techniques. Elle commence par les personnes : que pourrait-il leur arriver, par quelle chaîne, et que peuvent-elles faire pour comprendre, prévenir ou corriger l’effet ?
Décider si l’AIPD est requise
L’article 35 du règlement (UE) 2016/679 exige une analyse d’impact lorsqu’un type de traitement, notamment par le recours à de nouvelles technologies et compte tenu de sa nature, portée, contexte et finalités, est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques. Le texte cite notamment l’évaluation systématique et approfondie fondée sur un traitement automatisé produisant des effets juridiques ou similaires, certains traitements à grande échelle de catégories particulières et la surveillance systématique à grande échelle d’une zone accessible au public.
Le responsable du traitement documente son analyse même lorsqu’il conclut que l’AIPD n’est pas requise. La fiche indique finalité, personnes, données, volume, automatisation, innovation, vulnérabilité, rapprochements, transferts et effets. Elle s’appuie sur les listes et orientations de l’autorité compétente, avec une date.
Une AIPD doit être conduite avant le traitement. Elle peut commencer pendant la conception et s’enrichir pendant la recette, mais elle ne doit pas servir à régulariser après la mise en production une architecture déjà irréversible.
Le développement et le déploiement peuvent constituer des traitements distincts ou des phases avec des responsables et finalités différents. Les jeux d’entraînement, la recette, les journaux et la production sont cartographiés séparément. Le dossier sur le choix du bon problème avant d’ajouter des données aide à vérifier que la finalité justifie réellement le traitement.
Décrire le traitement réel
La description couvre les opérations, pas seulement le modèle. Elle suit les données depuis la collecte jusqu’à la suppression : sources, import, préparation, enrichissement, entraînement ou adaptation, inférence, affichage, décision, journalisation, support, correction et archivage.
Pour chaque flux :
- catégories de personnes et de données ;
- source directe, tierce ou inférée ;
- finalité et base juridique examinée ;
- destinataires, sous-traitants et lieux ;
- durée et règle de suppression ;
- droits et mécanisme d’exercice ;
- décision ou action influencée ;
- versions du modèle, corpus et règles.
Les données inférées sont visibles. Un score, une catégorie, un résumé ou une probabilité concernant une personne est une donnée personnelle lorsqu’il se rapporte à elle, même si l’entrée était moins sensible. Les sorties fausses ne sortent pas du RGPD parce qu’elles sont inexactes.
Le registre des systèmes IA fournit finalité, rôle, versions et propriétaires. Le registre des traitements apporte base, personnes, données, destinataires et durées. L’AIPD les relie mais ne remplace aucun des deux.
Cartographier les acteurs
Identifiez responsable, responsables conjoints éventuels, sous-traitants, fournisseurs de modèles, hébergeurs et destinataires. Un fournisseur qui propose une finalité propre ou réutilise des données peut avoir un rôle différent de celui annoncé commercialement. La qualification dépend des faits et des contrats.
Chaque acteur fournit les informations nécessaires. Le responsable du traitement ne délègue pas son AIPD au fournisseur. Une AIPD générique de plateforme peut informer l’analyse, mais elle ne connaît pas le produit, les personnes et décisions de l’assureur.
Tester nécessité et proportionnalité
Avant de demander comment sécuriser une donnée, demandez pourquoi elle est nécessaire. Pour chaque variable, traitement et durée, reliez la contribution à la finalité. « Améliorer le modèle » est trop vague. Précisez la mesure attendue, l’alternative et le point d’arrêt.
Le test compare des options :
- ne pas utiliser l’IA ou ne pas traiter la donnée ;
- utiliser une règle ou un modèle moins intrusif ;
- traiter localement ou avec pseudonymisation ;
- réduire les variables, le volume, les destinataires ou la durée ;
- limiter la sortie à une aide sans effet direct ;
- augmenter la validation et la possibilité de contestation.
La proportionnalité examine l’équilibre entre la finalité et l’ingérence : attentes raisonnables, vulnérabilité, transparence, contrôle, effet, réversibilité et garanties. Une performance légèrement meilleure ne justifie pas automatiquement une donnée plus intrusive.
Les données de santé, biométriques ou autres catégories particulières exigent l’analyse de l’article 9 et des règles sectorielles. L’AIPD ne crée pas une base juridique. Elle documente l’analyse et les garanties.
Vérifier les durées
Les durées diffèrent selon les objets : donnée source, jeu d’apprentissage, sortie, journal technique, preuve de décision et sauvegarde. « Suppression du compte » ou « durée du contrat » est rarement une justification suffisante pour tous les flux.
La suppression d’une donnée d’un jeu peut ne pas retirer son influence d’un modèle déjà entraîné. Le dossier explique la capacité technique, les procédures de réentraînement ou autres mesures et l’information donnée. Il ne promet pas un effacement mathématique instantané impossible à démontrer.
Ajouter les risques propres à l’IA
Un risque est formulé comme une chaîne : source de risque, événement, faiblesse, personne, conséquence. « Biais » ou « fuite » seuls ne suffisent pas.
| Scénario | Conséquence possible | Preuve à chercher |
|---|---|---|
| Donnée sous-représentée produit plus d’erreurs pour une situation | Refus, retard, coût ou traitement inégal | Résultats ventilés, cas limites, corrections |
| Le modèle mémorise ou restitue un extrait | Divulgation à un utilisateur non autorisé | Tests d’extraction, journaux, isolation et filtrage |
| Une sortie invente un fait sur une personne | Décision erronée, réputation ou difficulté de rectification | Sources, abstention, droit de correction, trace |
| Une pièce contient une injection | Contournement des consignes ou exfiltration | Tests adversariaux, séparation contenu/instruction, droits d’outil |
| Un jeu pseudonymisé est réidentifié | Atteinte à la confidentialité | Analyse de liens, accès, granularité, tests |
| Une inférence sensible est créée sans nécessité | Profilage, discrimination ou surprise | Inventaire sorties, variables et usages secondaires |
Les données synthétiques en assurance réduisent certains usages de données réelles mais ne garantissent pas l’anonymat. Leur méthode, source, risque de mémorisation et possibilité de rapprochement sont évalués.
Ajoutez les risques socio-techniques : automatisation de fait, pression de délai, interface trompeuse, absence de recours, contournement et dépendance. Un modèle correct peut être utilisé dans un processus injuste.
Tester les attaques sans créer de nouvelles expositions
Les tests de fuite et d’injection utilisent un environnement isolé, des données contrôlées et des droits minimaux. Les résultats sensibles sont restreints. L’équipe ne copie pas des dossiers réels dans un service externe pour prouver qu’il est dangereux.
Chaque test indique modèle, version, prompt, corpus, outils, résultat et correction. Un échec corrigé est rejoué ainsi que des cas voisins. L’absence d’échec sur un petit jeu ne prouve pas la sécurité générale.
Distinguer droits, risque métier et performance
Une mauvaise performance peut augmenter le risque pour une personne, mais les concepts ne se confondent pas. Un modèle moins précis peut rester sans effet si chaque sortie est vérifiée ; un modèle très précis peut créer un risque élevé s’il surveille massivement ou produit une décision difficile à contester.
Le registre des risques sépare :
- droits et libertés : confidentialité, non-discrimination, autonomie, accès, rectification, recours ;
- risque métier : perte financière, erreur opérationnelle, réputation, indisponibilité ;
- performance : erreur, calibration, latence, robustesse, coût.
Les liens entre colonnes sont documentés. Une fuite peut créer un risque juridique et réputationnel ; cela ne justifie pas de remplacer le dommage pour la personne par une perte d’entreprise dans l’AIPD.
Examiner les décisions automatisées
Lorsqu’un système produit ou prépare une décision concernant une personne, l’équipe décrit le degré d’intervention humaine, l’effet juridique ou significatif, les informations disponibles et la possibilité de contester. L’article 22 du RGPD et les règles sectorielles sont analysés lorsque leurs conditions peuvent être réunies.
Une intervention nominale ne suffit pas. Si la personne valide presque toujours, ne voit pas les éléments ou ne peut pas changer le résultat, le processus peut rester substantiellement automatisé. L’AIPD examine le temps, la compétence, les taux de désaccord et les incitations.
Les informations fournies aux personnes restent compréhensibles et utiles. Une explication technique générale ne permet pas forcément de corriger une donnée ou de présenter un élément contraire. Le parcours de recours est testé de bout en bout.
Associer les personnes et leurs représentants
L’article 35 prévoit, le cas échéant, de recueillir l’avis des personnes concernées ou de leurs représentants, sans préjudice des intérêts commerciaux ou de la sécurité. Le dossier décide si une consultation est pertinente, qui peut représenter les situations affectées et comment les retours modifient l’analyse.
Une consultation ne cherche pas seulement l’acceptabilité. Elle peut révéler une difficulté de compréhension, un canal inaccessible, une conséquence ignorée ou une attente raisonnable différente. L’échantillon, les questions et les limites sont documentés.
Si aucune consultation n’est menée alors qu’elle paraissait pertinente, la raison est expliquée et une autre preuve est recherchée. L’urgence commerciale n’est pas une justification suffisante.
Évaluer vraisemblance, gravité et mesures
Pour chaque scénario, estimez vraisemblance et gravité avant mesures, puis après mesures. La méthode est stable, expliquée et suffisamment granulaire. Une matrice rouge-orange-verte sans critères n’est pas une analyse.
La vraisemblance tient compte de l’exposition, de la capacité de l’adversaire ou de l’erreur, de la fréquence, de la détectabilité et des antécédents. La gravité tient compte du type de conséquence, du nombre de personnes, de la durée, de la réversibilité et de la vulnérabilité. Les incertitudes sont notées.
Chaque mesure comprend responsable, date, preuve et limite :
| Mesure | Preuve | Limite |
|---|---|---|
| Minimisation des variables | Schéma et test d’absence | Une inférence peut recréer une information |
| Contrôle d’accès | Matrice, test et journaux | Un compte légitime peut être détourné |
| Source obligatoire | Jeu de fidélité et blocage sans citation | La source peut être mauvaise ou obsolète |
| Contrôle humain | Cas, temps, désaccord et autorité | Biais d’automatisation et surcharge |
| Canal de contestation | Test de parcours et délai | Les personnes peuvent ne pas connaître le canal |
Le contrôle humain effectif est une mesure seulement s’il dispose de compétence, information, temps et autorité. Un clic obligatoire ne réduit pas automatiquement le risque.
Décider sur le risque résiduel
Le risque résiduel décrit ce qui peut encore arriver après les mesures, à qui et comment. Il ne se réduit pas à un chiffre. Le comité examine les scénarios élevés, les mesures non testées, les preuves manquantes et les conditions de mise en service.
Les décisions possibles sont : abandonner, modifier la finalité, réduire données ou autonomie, ajouter des mesures, piloter sur un périmètre, consulter l’autorité ou autoriser avec surveillance. Chaque décision a un propriétaire et un événement de réexamen.
Une mesure promise mais non mise en œuvre n’abaisse pas le risque. Une mesure testée sur un autre environnement n’est pas automatiquement transférable. Le dossier distingue prévu, implémenté, testé et surveillé.
Une table de décision par scénario
| Scénario | Risque initial | Mesure testée | Résiduel et décision |
|---|---|---|---|
| Réponse fausse sur une personne | Élevé si elle influence une décision | Source obligatoire, abstention, revue et rectification | Autoriser seulement les tâches et seuils testés |
| Injection dans une pièce | Élevé avec outils ou données connectés | Isolation, filtrage, droits minimaux et sondes | Interdire l’action autonome si le test échoue |
| Réidentification | Variable selon granularité et accès | Réduction, séparation, contrôle d’accès et test | Réduire le jeu ou renoncer si le risque demeure élevé |
| Biais de canal | Effet inégal et difficile à détecter | Évaluation ventilée, données et recours | Piloter avec revue ou exclure le canal |
Les niveaux du tableau sont illustratifs ; l’AIPD réelle utilise les critères de l’organisation et les faits du traitement. La décision ne peut pas être copiée d’un cas à l’autre.
Vérifier l’efficacité dans le temps
Une mesure produit un indicateur relié au risque : part de sorties sans source bloquées, délai de rectification, demandes d’accès abouties, incidents par version, taux d’abstention ou écarts ventilés. Chaque indicateur a un responsable, une fréquence et une limite.
La baisse d’un indicateur ne prouve pas toujours la réduction du risque. Moins de contestations peut signifier une amélioration ou un canal inaccessible. Les métriques sont rapprochées d’échantillons qualitatifs et d’événements.
Articuler AIPD et FRIA
L’article 27 du règlement IA prévoit, dans les cas concernés, une analyse d’impact sur les droits fondamentaux. Son paragraphe 4 permet de s’appuyer sur une AIPD existante et de la compléter. Cette articulation n’autorise pas à changer le titre d’un document.
L’AIPD part du traitement de données et du risque pour les droits et libertés au titre du RGPD. La FRIA part du déploiement d’un système à haut risque dans les situations prévues par l’AI Act et couvre plus largement les droits fondamentaux, le processus, les personnes affectées, la surveillance et les plaintes. Les titulaires, déclencheurs et notifications diffèrent.
Utilisez une matrice de références :
| Preuve commune | AIPD | FRIA |
|---|---|---|
| Flux et données | Nécessité, base, destinataires, durées | Rôle dans le processus et effets |
| Personnes | Personnes concernées et droits RGPD | Personnes et groupes affectés |
| Risques | Traitement et droits/libertés | Déploiement et droits fondamentaux |
| Mesures | Protection des données et exercice des droits | Mesures techniques, humaines, gouvernance et plainte |
La feuille de route AI Act pour l’assurance aide à qualifier rôles et calendrier avant de décider si une FRIA est applicable. Une AIPD peut rester nécessaire même lorsque le système n’est pas à haut risque au sens de l’AI Act.
Relier les autres dossiers de preuve
L’AIPD référence le registre IA, l’architecture sécurité, les contrats, les tests et la qualification juridique. Elle n’en copie que les conclusions nécessaires, avec version et propriétaire. Une référence cassée ou un document sans date est une lacune.
Le dossier fournisseur apporte rétention, sous-traitants, lieux, sécurité et versions. L’homologation ou l’analyse sécurité apporte menaces, accès et continuité. Le registre de traitements apporte bases, destinataires et durées. L’AIPD relie ces pièces aux scénarios pour les personnes.
Une table de preuves indique : identifiant, affirmation, source, date, version, responsable, résultat et limite. Elle facilite le réexamen sans dupliquer des pages qui divergent ensuite.
Définir les événements de révision
L’article 35 prévoit un réexamen lorsque le risque présenté par le traitement change. Pour l’IA, les déclencheurs incluent nouvelle finalité, population, donnée, modèle, fournisseur, sous-traitant, région, outil, niveau d’autonomie, incident, plainte ou performance différente.
Les versions silencieuses sont surveillées. Si le fournisseur remplace un alias, l’équipe exécute des sondes et détermine les sections affectées. Une nouvelle fonction d’outil peut créer un destinataire ou une action qui n’existait pas.
La revue périodique confirme que les hypothèses, mesures, droits et durées restent valides. Elle ne se contente pas d’une nouvelle date. Les changements et décisions sont consignés.
Préparer la consultation préalable
L’article 36 du RGPD prévoit la consultation préalable de l’autorité lorsque l’AIPD indique que le traitement présenterait un risque élevé si le responsable ne prenait pas de mesures pour l’atténuer. La qualification et le dossier doivent être examinés avec le DPO et le conseil compétent ; ce guide ne remplace pas cet avis.
Avant la décision, vérifiez que les mesures possibles ont été réellement étudiées et que le risque résiduel n’est pas artificiellement abaissé. Si une mesure dépend d’une technologie non disponible ou d’un contrôle humain sans capacité, elle n’est pas effective.
Le dossier de consultation rassemble responsabilités, finalités, moyens, mesures, AIPD, coordonnées du DPO et autres informations prévues. Il conserve les échanges et adapte le projet aux avis reçus. Consulter n’est pas transférer la décision à l’autorité.
Plan de travail
- Qualifier le besoin d’AIPD et dater la décision.
- Décrire phases, flux, acteurs, personnes, données et décisions.
- Vérifier bases, nécessité, proportionnalité, transparence et droits.
- Formuler les scénarios IA et socio-techniques.
- Évaluer vraisemblance, gravité et incertitude avant mesures.
- Associer mesures, preuves, responsables, délais et limites.
- Tester sécurité, biais, contenu faux, fuite, injection et recours.
- Évaluer le risque résiduel et les options de réduction.
- Relier FRIA, registre, sécurité et dossier fournisseur par versions.
- Consulter DPO, personnes ou représentants lorsque pertinent.
- Décider du lancement, des limites ou de la consultation préalable.
- Fixer surveillance et événements de révision.
Le résultat attendu n’est pas une formule « risques acceptables ». C’est une décision démontrable : traitement nécessaire pour telle finalité, sur tel périmètre, avec telles mesures testées, telles limites et telles conditions de réouverture.
Sources officielles
- EUR-Lex — règlement (UE) 2016/679, notamment articles 35 et 36.
- CNIL — recommandation sur l’application du RGPD au développement des systèmes d’IA.
- CNIL — liste de vérification IA, fiche sur l’AIPD.
- G29/CEPD — lignes directrices WP248 rev.01 sur l’AIPD, hébergées par la CNIL.
- EUR-Lex — règlement (UE) 2024/1689 consolidé au 27 juillet 2026, article 27, paragraphe 4.
Mesurer le risque pour les personnes, pas seulement le modèle
Un atelier peut transformer vos flux et scénarios en mesures testables, puis articuler AIPD et FRIA sans doublon. Échangeons sur l’AIPD de votre système IA.
