AIPD et RGPD sur un projet d'IA : quand elle est due, et comment elle s'articule avec l'article 27 de l'AI Act

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 RGPD, et l’analyse d’impact sur les droits fondamentaux (AIDF) de l’article 27 du règlement (UE) 2024/1689. La première est due depuis 2018, dès qu’un traitement de données personnelles présente un risque élevé ; la seconde ne vise qu’un sous-ensemble de déployeurs de systèmes à haut risque, à partir du 2 décembre 2027. 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.

L’AIPD au sens du RGPD : ce que l’article 35 impose

L’AIPD n’est pas propre à l’intelligence artificielle. C’est une obligation générale du RGPD, applicable depuis le 25 mai 2018, qui pèse sur le responsable du traitement. Trois choses du texte suffisent pour un projet d’IA : le déclencheur, les cas où elle est requise, et ce qu’elle contient.

Le déclencheur : un risque élevé, « en particulier par le recours à de nouvelles technologies »

« Lorsqu’un type de traitement, en particulier par le recours à de nouvelles technologies, et compte tenu de la nature, de la portée, du contexte et des finalités du traitement, est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques, le responsable du traitement effectue, avant le traitement, une analyse de l’impact des opérations de traitement envisagées sur la protection des données à caractère personnel. »

Source : RGPD, article 35, paragraphe 1

Deux mots cadrent le sujet. « Nouvelles technologies » : le texte de 2016 ne nomme pas l’IA, et il n’en a pas besoin, le critère étant le risque que la technique fait courir, pas son nom. « Avant le traitement » : l’AIPD se fait en amont, pas en régularisation. Le même paragraphe ajoute : « Une seule et même analyse peut porter sur un ensemble d’opérations de traitement similaires qui présentent des risques élevés similaires. » Un même outil déployé sur plusieurs services peut donc faire l’objet d’une seule AIPD.

Les trois cas où elle est requise « en particulier », et pourquoi ils ne sont pas cumulatifs

Le paragraphe 3 nomme trois cas :

« a) l’évaluation systématique et approfondie d’aspects personnels concernant des personnes physiques, qui est fondée sur un traitement automatisé, y compris le profilage, et sur la base de laquelle sont prises des décisions produisant des effets juridiques à l’égard d’une personne physique ou l’affectant de manière significative de façon similaire; b) le traitement à grande échelle de catégories particulières de données visées à l’article 9, paragraphe 1, ou de données à caractère personnel relatives à des condamnations pénales et à des infractions visées à l’article 10; ou c) la surveillance systématique à grande échelle d’une zone accessible au public. »

Source : RGPD, article 35, paragraphe 3

Le texte les introduit par « en particulier » et les sépare par « ou » : chacun suffit, et la liste n’est pas fermée. Des sources secondaires les présentent comme des critères cumulatifs ; c’est un contresens. Le cas a) est celui qui concerne le plus directement les projets d’IA : scoring, tri de candidatures, décision automatisée. Le paragraphe 4 charge en outre chaque autorité de contrôle de publier « une liste des types d’opérations de traitement pour lesquelles une analyse d’impact relative à la protection des données est requise » ; la CNIL tient cette liste, et son pendant des traitements dispensés.

Ce qu’elle contient, et quand la CNIL est saisie

Le paragraphe 7 fixe le contenu minimal : une description systématique des opérations et des finalités, « y compris, le cas échéant, l’intérêt légitime poursuivi » ; une évaluation de la nécessité et de la proportionnalité ; une évaluation des risques pour les droits et libertés ; et « les mesures envisagées pour faire face aux risques ». C’est une analyse de conformité, pas seulement un inventaire de risques : la base légale et la nécessité y sont examinées.

L’AIPD reste chez le responsable du traitement. L’article 36 n’impose la consultation préalable de l’autorité que dans un cas :

« Le responsable du traitement consulte l’autorité de contrôle préalablement au traitement lorsqu’une analyse d’impact relative à la protection des données effectuée au titre de l’article 35 indique que le traitement présenterait un risque élevé si le responsable du traitement ne prenait pas de mesures pour atténuer le risque. »

Source : RGPD, article 36, paragraphe 1

L’autorité rend alors un avis écrit « dans un délai maximum de huit semaines », prolongeable de six. Pour la méthode, les guides et le logiciel PIA, la page de la CNIL sur l’AIPD fait référence ; cette page-ci s’arrête à ce que le texte impose et se concentre sur ce qui change avec l’IA.

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

Le RGPD ne répond pas spécifiquement. La CNIL, si, et l’AI Act ajoute une obligation propre au déployeur.

La présomption de la CNIL pour tout le haut risque

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.

La condition est le traitement de données personnelles ; le périmètre est tout le haut risque de l’AI Act, annexe I comme annexe III. Autrement dit, dès qu’un système est classé à haut risque et touche des données personnelles, c’est l’absence d’AIPD qu’il faudra justifier.

Modèles de fondation et IA à usage général : plus loin que l’AI Act

La CNIL va plus loin que le règlement pour une catégorie qu’il 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 ». Pour un projet d’IA générative, le fait que le règlement ne classe pas le modèle à haut risque ne dispense donc de rien au titre du RGPD.

Une précaution de lecture : ces fiches de la CNIL ne couvrent que la phase de développement, relèvent du seul RGPD, et ne sont pas contraignantes. La CNIL y parle en autorité de protection des données, pas au titre de l’AI Act. Ce que la CNIL demande, et ce qu’elle ne couvre pas est détaillé sur une page dédiée.

Ce que l’AI Act ajoute : l’article 26, paragraphe 9, une obligation pour le déployeur

L’AI Act ne crée pas d’AIPD, mais il en dit quelque chose, 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. »

Source : Article 26, paragraphe 9

Les informations de l’article 13 sont celles que le fournisseur doit au déployeur, dont la notice d’utilisation est le véhicule. Un déployeur qui rédige une AIPD sur un système à haut risque sans avoir ouvert cette notice ne respecte pas l’article 26, paragraphe 9, quel que soit son secteur. Ce paragraphe vise tous les déployeurs de systèmes à haut risque, annexe I comprise, dès lors qu’ils doivent une AIPD, et il s’applique aux mêmes dates que le reste des obligations du haut risque.

L’autre analyse : l’article 27 de l’AI Act, et qui la doit

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. Les deux doivent, en revanche, une AIPD si le traitement présente un risque élevé.

Six éléments

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 ».

Deux de ces six éléments n’ont pas d’équivalent dans une AIPD : le contrôle humain tel que la notice le prescrit, et les mécanismes de plainte internes. C’est là que les renvois ne suffiront pas.

Notifiée à l’autorité de surveillance du marché

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. En France, l’autorité de surveillance du marché n’est désignée par aucun texte adopté au 6 novembre 2026.

Exigible le 2 décembre 2027, modèle toujours attendu

L’analyse de l’article 27 s’applique à la première utilisation d’un système à haut risque de l’annexe III, donc à partir du 2 décembre 2027. Le modèle de questionnaire que l’article 27, paragraphe 5 charge le Bureau de l’IA d’élaborer n’est pas publié au 6 novembre 2026 : la page de suivi de la Commission, inchangée depuis le 31 juillet 2026, le range parmi les travaux en cours, et la fiche de l’article 27 sur le Service Desk de la Commission ne renvoie vers aucun document. Les six éléments du paragraphe 1 suffisent à la construire sans l’attendre.

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

Deux exercices distincts, sur deux fondements distincts, et le second ne remplace jamais le premier.

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.

Mutualiser les deux analyses, dans les deux sens

Oui, dans les deux sens, mais par des mécanismes différents, et jamais par substitution.

De l’AIPD vers l’article 27 : le paragraphe 4, et son verbe

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. »

Source : Article 27, paragraphe 4, dans sa rédaction issue du règlement (UE) 2026/1744

Trois choses en découlent. 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. Et le paragraphe ne joue que dans ce sens : le mouvement inverse existe, mais il est organisé ailleurs.

De l’AI Act vers l’AIPD : l’article 26, paragraphe 9, et ses trois écarts

L’article 26, paragraphe 9, cité plus haut, impose le mouvement inverse. Trois écarts avec l’article 27, paragraphe 4, qu’il faut voir.

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.

L’annexe IV comme trame : ce que la CNIL admet

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, que l’article 35, paragraphe 7 impose d’examiner.

Ce qui manque au 6 novembre 2026

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’est pas publié, et la Commission le classe elle-même parmi ses travaux en cours.

Aucune ligne directrice ne traite l’articulation. La Commission européenne et le Comité européen de la protection des données (EDPB) préparent des lignes directrices conjointes sur l’articulation entre l’AI Act et le droit européen de la protection des données. Elles ne sont pas publiées : la Commission les classait encore parmi ses travaux en cours au 31 juillet 2026, aucune date n’est annoncée, et les actualités du Comité n’en disent rien au 4 novembre 2026.

La fiche de la CNIL date de 2024. Elle précède l’adoption du règlement, parle encore du « projet », et ne connaît pas l’article 27.

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

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 ; l’article 35, paragraphe 11 du RGPD demande un réexamen « au moins quand il se produit une modification du risque présenté par les opérations de traitement ».

Sur quoi cette page s’appuie

Les articles 35 et 36 du règlement (UE) 2016/679, extraits d’EUR-Lex le 6 novembre 2026 dans la version consolidée au 4 mai 2016 et versés au corpus de contrôle des citations. 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 paragraphes 4 et 5 de l’article 27, réécrits par l’omnibus, sont cités dans leur rédaction en vigueur. Toutes ces citations sont reproduites mot à mot et contrôlées par script.

Les recommandations de la CNIL sur l’IA, fiche consacrée à l’analyse d’impact, consultée le 24 août 2026 et relue le 6 novembre 2026, inchangée : 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é utilisé pour les textes officiels ; elles sont reproduites telles que relevées.

L’état du modèle de l’article 27 et des lignes directrices conjointes est constaté le 6 novembre 2026 sur la page de suivi de la Commission, sur la fiche de l’article 27 du Service Desk et sur les actualités du Comité européen de la protection des données.

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) 2016/679, articles 35 et 36, règlement (UE) 2024/1689, version consolidée au 27 juillet 2026, article 27 sur le Service Desk de la Commission, page de suivi des lignes directrices de la Commission et recommandations de la CNIL sur l’intelligence artificielle, consultés le 6 novembre 2026.

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