AIPD vs analyse d'impact IA : ce qui change vraiment

Le point de départ pour un DPO

Le réflexe d'un responsable conformité formé au RGPD, quand il découvre la clause 6.1.4 d'ISO/IEC 42001, est de considérer que l'AIPD suffit. L'idée se défend en apparence : les deux exercices parlent d'impact, les deux évaluent des atteintes possibles, les deux produisent une documentation. En pratique, ils ne posent pas la même question et ne mobilisent pas les mêmes catégories d'analyse^[1].

Un guide indépendant résume la règle en une ligne : le risque, c'est ce que l'IA peut faire à vous, l'organisation, l'impact, c'est ce qu'elle peut faire à eux, les personnes concernées^[7]. Cette formulation s'applique aussi à la frontière avec l'AIPD, à un détail près : l'AIPD RGPD est déjà tournée vers les personnes, mais uniquement dans la dimension de la protection de leurs données.

La SMIA vue par ISO/IEC 42001 introduit un objet nouveau : le système d'IA lui-même, avec son cycle de vie, ses effets externes et ses parties prenantes affectées au-delà des personnes concernées au sens du RGPD^[7]. C'est ce déplacement du centre d'analyse qui explique la plupart des malentendus.

Périmètre : données personnelles ou système d'IA

L'AIPD, telle que définie à l'article 35 du RGPD, s'active dès qu'un traitement de données personnelles est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques. Un glossaire technique reprend cette définition et rappelle qu'elle porte sur des traitements à haut risque de données personnelles^[8]. Le déclencheur est donc le traitement, et son objet est la donnée.

L'analyse d'impact IA de la clause 6.1.4 a un déclencheur différent : elle porte sur le système d'IA en tant que tel, indépendamment de la présence ou non de données personnelles dans les entrées. Un guide spécialisé le formule sans détour : un système de vision industrielle qui ne traite aucune donnée personnelle relève quand même d'une analyse d'impact au titre d'ISO/IEC 42001^[7].

Ce décalage a une conséquence concrète pour un DPO. Sur un même projet, il peut y avoir zéro AIPD à faire, parce qu'aucune donnée personnelle n'entre en jeu, et pourtant une analyse d'impact IA obligatoire. L'inverse est plus rare mais possible : un traitement de données à risque élevé qui repose sur une IA très simple pourra requérir une AIPD approfondie et une analyse d'impact IA plus légère, calibrée sur la faible criticité du modèle.

Les deux analyses se déclenchent sur des critères différents, ce qui explique qu'elles ne se substituent pas.

AIPDTraitement de données personnelles à risque élevé (art. 35 RGPD)^[8]

6.1.4Système d'IA dans le périmètre du SMIA, y compris sans donnée personnelle^[7]

Un projet peut relever de l'une, de l'autre, ou des deux.

Méthode et référentiel de rattachement

Les deux exercices s'appuient sur des référentiels distincts. L'AIPD suit la méthode définie par le RGPD, complétée par les lignes directrices du régulateur national et, souvent, par la méthode publiée par la CNIL. Le référentiel structure l'AIPD autour des données, des finalités, des mesures de sécurité et des risques pour les personnes concernées^[8].

L'analyse d'impact IA au titre de la clause 6.1.4 s'opérationnalise selon un standard dédié, ISO/IEC 42005, publié en mai 2025 selon un cabinet spécialisé, à recouper sur la source officielle^[7]. Ce texte propose une démarche par système, incluant l'inventaire des parties affectées, les scénarios de préjudice, la sévérité, les mesures d'atténuation et le résidu.

La différence de méthode se lit dans l'unité d'analyse. L'AIPD s'organise autour d'un traitement, avec ses catégories de données et ses transferts. L'analyse d'impact IA s'organise autour d'un système d'IA, avec son contexte de déploiement, ses populations d'utilisateurs et ses effets attendus ou non^[7]. Le glissement n'est pas cosmétique : il change les questions, les entretiens, les preuves à produire.

Pour un DPO qui veut approfondir le versant risque organisationnel, l'entrée est plutôt du côté de la clause 6.1.2 sur l'appréciation des risques IA. Pour la structure documentaire de l'analyse d'impact elle-même, un exemple concret aide à visualiser les sections attendues : voir la page pilier sur l'analyse d'impact des systèmes d'IA.

Contenus attendus des deux livrables

Une AIPD conforme au RGPD contient classiquement : la description du traitement, l'évaluation de la nécessité et de la proportionnalité, l'évaluation des risques pour les droits et libertés, les mesures envisagées pour traiter ces risques. Le référentiel décrit un processus systématique d'évaluation des risques pour les droits et libertés des personnes physiques dans le cadre d'un traitement à haut risque^[8].

L'analyse d'impact IA couvre un champ plus large. Un guide indépendant liste, à titre de contenu attendu : un inventaire des parties affectées, des scénarios de préjudice couvrant l'équité, les droits fondamentaux, la sécurité et l'autonomie, la sévérité, les mesures d'atténuation et la position résiduelle^[7]. Un autre cabinet ajoute que cette pièce est probablement la plus substantielle d'un projet ISO 42001, plus longue et plus détaillée qu'une AIPD^[1].

Le point commun réel entre les deux documents tient à la logique de raisonnement : identifier ce qui peut nuire à un tiers, coter, atténuer, tracer. Le point de divergence tient au type de préjudices considérés. L'AIPD reste centrée sur les préjudices liés au traitement de données, l'analyse d'impact IA élargit aux préjudices liés à la logique décisionnelle du système, à ses effets d'échelle et à sa capacité de discrimination indépendamment de toute donnée personnelle^[3].

AIPD RGPD et analyse d'impact IA en un tableau

Question posée	AIPD : quels risques pour les personnes concernées liés au traitement de leurs données[8]. Analyse d'impact IA : quelles conséquences du système sur individus, groupes et société[7].
Déclencheur	AIPD : traitement de données personnelles à risque élevé. Analyse d'impact IA : présence d'un système d'IA dans le périmètre du SMIA[7].
Référence	AIPD : article 35 RGPD[8]. Analyse d'impact IA : clause 6.1.4 d'ISO/IEC 42001, méthodologie ISO/IEC 42005[7].
Champ des préjudices	AIPD : droits et libertés liés aux données. Analyse d'impact IA : équité, sécurité, autonomie, effets sociétaux, même sans donnée personnelle[7].
Recouvrement	Partiel : sur un traitement IA à base de données personnelles, une partie des scénarios est commune, jamais l'intégralité[3].

Articulation pratique entre AIPD et analyse d'impact IA

Sur un projet qui manipule des données personnelles et repose sur une IA, il faut les deux livrables. La question n'est pas de choisir mais d'ordonnancer. L'approche qui semble la plus lisible, dans les démarches observées, consiste à conduire d'abord l'analyse d'impact IA par système, puis à intégrer ses conclusions dans le raisonnement de l'AIPD sur les risques pour les personnes^[7].

Un guide décrit cette séquence de travail : inventorier les systèmes d'IA, réaliser l'analyse d'impact par système, replier les préjudices identifiés dans l'appréciation des risques organisationnels, sélectionner les contrôles de l'Annexe A dans la déclaration d'applicabilité^[7]. Dans une organisation dotée d'un DPO, la même séquence gagne à intégrer l'AIPD au point où les préjudices touchent des personnes concernées identifiables par leurs données.

L'inverse fonctionne moins bien. Partir de l'AIPD et tenter d'y ajouter des rubriques sur l'équité et la robustesse produit souvent un document hybride qui ne satisfait ni les exigences du RGPD ni celles de la clause 6.1.4. Un cabinet spécialisé mentionne d'ailleurs, parmi les non-conformités les plus fréquentes en Stage 1, le fait de traiter l'analyse d'impact comme une section du registre des risques^[7].

Pour situer cette articulation dans un cadre suisse ou européen, deux ressources utiles complètent la réflexion : l'analyse de la relation ISO 42001 et RGPD et le rapprochement avec la nLPD suisse.

Pièges fréquents observés

Le premier piège est la substitution. Le DPO produit une AIPD étendue et considère avoir traité la clause 6.1.4. L'auditeur ISO 42001 attend un document distinct, structuré selon la logique système et non selon la logique traitement, avec une section explicite sur les parties affectées non couvertes par le RGPD^[7].

Le deuxième piège est l'inverse, moins fréquent mais réel : l'équipe IA rédige une analyse d'impact IA riche et estime qu'elle vaut AIPD. Or l'AIPD porte des exigences propres, notamment sur la nécessité et la proportionnalité du traitement, sur la consultation du DPO et sur les mesures de sécurité, que l'analyse d'impact IA ne couvre pas dans les mêmes termes^[8].

Le troisième piège concerne la cadence. Les deux documents sont vivants. Un cabinet indique que les deux analyses doivent être rejouées sur événements déclencheurs, changement de version du modèle, nouvelle source de données, nouveau contexte de déploiement, incident, dérive détectée, et au moins annuellement^[7]. Une analyse figée à la date de mise en service est régulièrement citée comme non-conformité^[7].

Un dernier piège concerne le traitement des systèmes tiers. Beaucoup d'organisations utilisent une IA embarquée dans un produit fourni. La comparaison entre ISO 42001, ISO 27001, AI Act et nLPD montre que la dépendance à un tiers ne dispense pas de l'analyse d'impact : elle en modifie le contenu, avec des rubriques sur la gouvernance fournisseur et les garanties contractuelles.

Un exemple romand pour fixer les idées

Prenons une administration cantonale qui déploie un outil d'aide à la décision pour l'octroi d'aides sociales, avec une composante IA de scoring alimentée par des données personnelles. Le traitement de données déclenche une AIPD au titre de la nLPD et, si des personnes de l'UE sont concernées, au titre du RGPD^[8]. Le DPO regarde les finalités, la base légale, la proportionnalité, les catégories de données, les destinataires, les mesures de sécurité.

Le même système, examiné sous l'angle de la clause 6.1.4, appelle une analyse d'impact IA plus large : équité entre catégories de bénéficiaires, explicabilité de la décision au destinataire, robustesse face à des données atypiques, effet d'échelle sur des populations vulnérables, présence humaine dans la décision finale^[3]. Ces dimensions ne sont pas absentes de l'AIPD mais elles n'y occupent pas le centre.

La comparaison inverse est aussi instructive. Le même canton met en place une IA de maintenance prédictive sur son parc immobilier, à partir de capteurs sans donnée personnelle. Aucune AIPD n'est requise. En revanche, si le système est dans le périmètre du SMIA, une analyse d'impact IA reste attendue, portant notamment sur la sécurité, la fiabilité et les décisions de mise hors service^[7].

Enfin, une organisation romande qui envisage la certification aura tout intérêt à documenter clairement la frontière entre les deux exercices dans sa procédure. Le sujet est repris de manière opérationnelle dans notre article dédié à la méthode d'analyse d'impact IA, et la logique d'ensemble du dispositif est présentée sur le hub Risques et conformité.

Questions fréquentes

À lire ensuite