AIPD et analyse d’impact sur les droits fondamentaux : ce que personne n’a écrit

Deux analyses d’impact coexistent sur les projets d’IA : l’analyse d’impact relative à la protection des données (AIPD) de l’article 35 du règlement général sur la protection des données, et l’analyse d’impact sur les droits fondamentaux (AIDF) de l’article 27 du règlement (UE) 2024/1689. Elles portent des noms voisins, elles se recoupent, et deux articles seulement les relient : l’article 26, paragraphe 9 dans un sens, l’article 27, paragraphe 4 dans l’autre. Aucune méthode officielle ne dit comment les mener ensemble.

AIPD et analyse d’impact de l’article 27 : quelle différence ?

Deux exercices distincts, sur deux fondements distincts, et le second ne remplace jamais le premier. L’analyse d’impact relative à la protection des données naît de l’article 35 du RGPD et pèse sur le responsable du traitement. L’analyse d’impact sur les droits fondamentaux naît de l’article 27 du règlement (UE) 2024/1689 et pèse sur le déployeur, dans un champ restreint.

Les deux différences que la CNIL relève elle-même sont exactement celles-là :

D’une part, elles diffèrent dans leur champ d’application. Dès lors que certains systèmes d’IA n’étant pas classifiés comme à haut risque reposeront sur des traitements présentant des risques pour la protection des données personnelles, ceux-ci nécessiteront la réalisation d’une AIPD.

D’autre part, il appartiendra au responsable du traitement en cause, que ce dernier concerne le développement ou le déploiement du système, de réaliser une AIPD, alors que les exigences de documentation du projet de règlement sur l’IA pèseront essentiellement sur le fournisseur du système d’IA.

Une précaution de lecture s’impose sur cette dernière citation : elle est extraite d’une fiche qui n’a pas été réécrite depuis 2024 et parle encore du « projet de règlement ». Son raisonnement sur le champ reste valable ; sa désignation du débiteur vise la documentation technique du fournisseur, non l’analyse de l’article 27, qui pèse bien sur le déployeur.

Quand une AIPD est-elle due sur un projet d’IA ?

Sur tout développement d’un système à haut risque impliquant des données personnelles, et au-delà. La CNIL pose une présomption large, et elle va plus loin que l’AI Act : elle vise aussi les modèles de fondation et les systèmes à usage général, que le règlement ne classe pourtant pas à haut risque par défaut.

La CNIL pose une présomption, et elle est large :

La CNIL considère que pour le développement de l’ensemble des systèmes à haut risque visés par le règlement sur l’IA, la réalisation d’une AIPD sera présumée nécessaire lorsque leur développement ou leur déploiement implique un traitement de données personnelles.

Et elle va plus loin que l’AI Act pour une catégorie que le règlement ne classe pourtant pas à haut risque par défaut :

la CNIL considère que le développement d’un modèle de fondation ou d’un système d’IA à usage général, en ce que leurs usages ne peuvent être identifiés de manière exhaustive, nécessite dans la majorité des cas la réalisation d’une AIPD lorsqu’il implique le traitement de données personnelles.

Le raisonnement est explicite : ces modèles ne sont pas à haut risque, mais « leur diffusion ainsi que leur utilisation à venir pourraient comporter des risques pour les personnes dont les données ont été traitées lors du développement, ou pour les personnes concernées par leur utilisation ».

Ce que cela veut dire pour un projet d’IA générative : le fait que le règlement ne classe pas votre modèle à haut risque ne dispense en rien de l’analyse d’impact du RGPD, et la CNIL vous dit à l’avance qu’elle la présume nécessaire.

Quand l’analyse de l’article 27 est-elle due ?

Une limite commune, puis deux branches. L’obligation ne vise que les systèmes à haut risque de l’article 6, paragraphe 2, c’est-à-dire ceux de l’annexe III, et jamais ceux de l’annexe I ; le point 2 de l’annexe III, infrastructures critiques, en est de surcroît expressément retiré. Dans ce périmètre, elle est due par les déployeurs qui sont des organismes de droit public ou des entités privées fournissant des services publics, et par tous les déployeurs des systèmes des points 5 b) et 5 c), solvabilité et assurance vie ou santé.

Conséquence rarement tirée : un employeur privé qui recrute avec un outil relevant du point 4 de l’annexe III n’est pas soumis à l’article 27. Une banque qui évalue une solvabilité l’est, même sans mission de service public.

Ce que l’analyse de l’article 27 doit contenir

Six éléments la composent : une description des processus concernés ; la période et la fréquence d’utilisation ; les catégories de personnes et groupes concernés ; les risques spécifiques de préjudice, compte tenu des informations fournies par le fournisseur au titre de l’article 13 ; « une description de la mise en œuvre des mesures de contrôle humain, conformément à la notice d’utilisation » ; et les mesures à prendre en cas de matérialisation des risques, « y compris les dispositifs relatifs à la gouvernance interne et aux mécanismes de plainte internes ».

Elle est notifiée systématiquement, là où le RGPD ne saisit l’autorité que par la consultation préalable de l’article 36, et seulement en cas de risque résiduel élevé : ses résultats sont transmis à l’autorité de surveillance du marché, avec le modèle rempli. Les déployeurs « peuvent être exemptés » de cette notification lorsque le système a été autorisé par dérogation au titre de l’article 46, paragraphe 1 : c’est une possibilité laissée à l’appréciation, pas une exemption acquise.

Peut-on mutualiser les deux analyses ?

Oui, dans les deux sens, mais par des mécanismes différents, et jamais par substitution. L’article 27, paragraphe 4 permet à l’analyse de l’article 27 de s’appuyer sur l’AIPD ; l’article 26, paragraphe 9 impose le mouvement inverse, en faisant servir les informations de la notice d’utilisation à l’AIPD. L’article 27, paragraphe 4 permet au déployeur d’inclure des renvois à son AIPD, ou d’en intégrer les parties pertinentes, lorsqu’une obligation est déjà remplie par elle. Une AIPD ne remplace pas l’analyse de l’article 27.

C’est la disposition qui organise le sens allant de l’AIPD vers l’analyse de l’article 27, et il faut la lire au mot près :

Si l’une des obligations prévues au présent article est déjà remplie au moyen de l’analyse d’impact relative à la protection des données réalisée en application de l’article 35 du règlement (UE) 2016/679 […], le déployeur peut, lorsqu’il procède à l’analyse d’impact sur les droits fondamentaux visée au paragraphe 1 du présent article, inclure des renvois aux sections pertinentes de cette analyse d’impact relative à la protection des données ou en intégrer les parties pertinentes dans l’analyse d’impact relative aux droits fondamentaux.

Trois choses en découlent.

Ce paragraphe ne joue que dans un sens. Il autorise l’analyse de l’article 27 à s’appuyer sur celle du RGPD, et pas l’inverse. Le sens inverse existe, mais il est organisé ailleurs : voir ci-dessous.

Ce n’est pas une dispense. Le déployeur reste tenu de produire l’analyse de l’article 27 ; il est seulement autorisé à ne pas réécrire ce qui existe déjà.

La condition est que l’obligation soit « déjà remplie ». Un renvoi ne vaut que si la section visée traite effectivement le point de l’article 27, ce qui suppose de vérifier ligne à ligne, pas de renvoyer en bloc.

L’autre sens, que l’article 26, paragraphe 9 organise

Le règlement ne se contente pas d’autoriser l’analyse de l’article 27 à puiser dans l’AIPD. Il impose aussi le mouvement inverse, et c’est une obligation, pas une faculté :

Le cas échéant, les déployeurs de systèmes d’IA à haut risque utilisent les informations fournies en application de l’article 13 du présent règlement pour se conformer à leur obligation de procéder à une analyse d’impact relative à la protection des données en vertu de l’article 35 du règlement (UE) 2016/679 ou de l’article 27 de la directive (UE) 2016/680.

Trois écarts avec l’article 27, paragraphe 4, qu’il faut voir.

Les trois écarts avec l’article 27, paragraphe 4

Le verbe. L’article 27, paragraphe 4 dit « peut » ; l’article 26, paragraphe 9 dit « utilisent ». Le premier ouvre une facilité, le second énonce une obligation, tempérée par le seul « le cas échéant ».

Le champ. L’article 27, paragraphe 4 ne concerne que les déployeurs soumis à l’analyse de l’article 27, un sous-ensemble étroit. L’article 26, paragraphe 9 vise tous les déployeurs de systèmes à haut risque, annexe I comprise, dès lors qu’ils doivent une AIPD.

L’objet transféré. Ce n’est pas l’analyse de l’article 27 qui alimente l’AIPD, ce sont les informations fournies par le fournisseur au titre de l’article 13, dont la notice d’utilisation est le véhicule. Le déployeur ne récupère donc pas un raisonnement déjà fait : il récupère de la matière technique et doit encore construire son AIPD dessus.

Ce que cela change en pratique : un déployeur qui rédige une AIPD sur un système à haut risque sans avoir ouvert la notice de l’article 13 ne respecte pas l’article 26, paragraphe 9, même s’il n’est pas soumis à l’article 27.

Que dit la CNIL sur l’AIPD des projets d’IA ?

Dans le même sens que l’article 26, paragraphe 9, mais en allant plus loin que lui, la CNIL accepte que l’AIPD s’appuie sur toute la documentation du règlement :

La réalisation de l’AIPD pourra reposer sur la documentation exigée par le règlement sur l’IA sous réserve de comporter les éléments prévus par le RGPD (article 35 du RGPD).

Elle recommande même d’utiliser comme référentiel « le règlement européen sur l’intelligence artificielle, et notamment son annexe IV détaillant la documentation technique qui doit accompagner la mise sur le marché des systèmes d’IA à haut risque ».

C’est l’articulation la plus opérationnelle du sujet : l’annexe IV comme trame documentaire commune, sous réserve de compléter ce que le RGPD exige et que l’annexe IV ne couvre pas, à commencer par la base légale et la nécessité du traitement.

Ce qui manque, et que nous ne comblons pas

Aucun modèle officiel n’existe pour l’analyse de l’article 27. Le Bureau de l’IA doit élaborer un questionnaire, « y compris au moyen d’un outil automatisé », qui « donne, le cas échéant, aux déployeurs la possibilité d’inclure des renvois aux sections pertinentes de l’analyse d’impact relative à la protection des données ». Il n’a pas été trouvé publié au 28 août 2026, et la Commission le classe elle-même parmi ses travaux en cours.

Aucune ligne directrice ne traite l’articulation. Des lignes directrices conjointes de la Commission et du Comité européen de la protection des données sur l’articulation entre l’AI Act et le droit de la protection des données sont annoncées, non publiées.

Nous ne proposons donc pas de méthode d’articulation présentée comme officielle. Ce qui suit est une lecture des deux textes, et rien de plus.

Comment procéder, en l’état ?

Cinq gestes, dans cet ordre

Commencer par l’AIPD, parce qu’elle est exigible depuis 2018 et que sa présomption de nécessité est large sur les projets d’IA. Elle sera de toute façon le document le plus ancien.

Ne pas attendre le modèle du Bureau de l’IA. L’analyse de l’article 27 est exigible au 2 décembre 2027, indépendamment de la publication de son modèle. Les six éléments du paragraphe 1 suffisent à la construire.

Construire la seconde par renvois explicites à la première, section par section, en vérifiant à chaque fois que la section visée traite bien le point de l’article 27. Un renvoi global serait une facilité que le texte n’autorise pas.

Traiter séparément ce que le RGPD ne couvre pas. L’article 27 vise les droits fondamentaux, pas seulement la protection des données : la description des mesures de contrôle humain et les mécanismes de plainte internes n’ont pas d’équivalent dans une AIPD.

Dater les deux, et prévoir leur mise à jour. L’article 27, paragraphe 2 impose de mettre à jour les informations dès qu’un élément change ou n’est plus à jour.

Sur quoi cette page s’appuie

Les articles 13, 26, 27 et 46 du règlement (UE) 2024/1689 dans sa version consolidée au 27 juillet 2026, telle que modifiée par le règlement (UE) 2026/1744 ; les articles 26 et 27 ont été extraits d’EUR-Lex le 28 août 2026 et les citations qui en sont faites sont reproduites mot à mot. L’article 35 du règlement général sur la protection des données. Les recommandations de la CNIL sur l’IA, fiche consacrée à l’analyse d’impact, consultée le 24 août 2026 : elles relèvent du seul RGPD et ne sont pas contraignantes.

Une réserve de méthode : les fiches de la CNIL sont publiées en HTML et leurs citations n’ont pas pu être contrôlées par le procédé de vérification utilisé pour les documents en PDF de la Commission européenne. Elles sont reproduites telles que relevées le 24 août 2026.

Un point reste ouvert, et c’est le sujet de cette page : hors de l’article 26, paragraphe 9 et de l’article 27, paragraphe 4, aucune source officielle ne dit comment mener les deux analyses ensemble. La méthode proposée ci-dessus est une lecture de ces deux articles, présentée comme telle.

Sources. Règlement (UE) 2024/1689, version consolidée au 27 juillet 2026, règlement (UE) 2016/679 et recommandations de la CNIL sur l’intelligence artificielle, consultés les 24 et 28 août 2026.

Ce contenu est une ressource d’information technique et réglementaire. Il ne constitue pas un conseil juridique.