AIPD et projets d’intelligence artificielle — Ce que vous devez analyser avant de déployer un système d’IA

Votre entreprise déploie un chatbot de relation client alimenté par un LLM, un outil RH qui prédit les risques de départ des salariés, ou un système de détection de fraude fondé sur le profilage comportemental. Avant même la mise en production, deux obligations s’imposent simultanément.

• L’analyse d’impact relative à la protection des données (AIPD) au titre du RGPD.
• Et pour certains déployeurs, l’évaluation d’impact sur les droits fondamentaux (FRIA) au titre de l’AI Act.

Ces deux évaluations ne sont pas redondantes. Elles ont des périmètres distincts, des bases juridiques différentes, et pèsent sur des acteurs qui ne sont pas toujours les mêmes. Les confondre, ou n’en réaliser qu’une, expose à un double risque de sanction.

Ce guide explique concrètement ce que sont ces deux obligations, quand elles s’appliquent aux projets d’IA, comment les articuler, et ce qu’il se passe si vous ne les respectez pas.

1. L’AIPD face à l’IA : pourquoi presque tous les projets sont concernés

L’AIPD est une évaluation préalable et documentée des risques qu’un traitement de données personnelles peut engendrer pour les droits et libertés des personnes. Elle est prévue à l’article 35 du RGPD et doit être conduite avant le démarrage du traitement.

La quasi-totalité des systèmes d’IA traite des données personnelles : données d’entraînement, données des utilisateurs en production, logs d’interaction, profils comportementaux. Dès lors que le système présente un risque élevé pour les personnes — ce qui est presque systématiquement le cas en IA — l’AIPD est obligatoire.

Ce que l’AIPD oblige à documenter pour un projet IA

Une AIPD bien conduite sur un projet IA suit six étapes :

1. Décrire le système en détail : données utilisées (entraînement, inférence), finalités, architecture technique, sous-traitants et fournisseurs du modèle, durées de conservation.
2. Vérifier la licéité du traitement : quelle base légale pour les données d’entraînement et pour les données traitées en production ? Le système respecte-t-il les principes de minimisation et de limitation des finalités ?
3. Évaluer la nécessité et la proportionnalité : le recours à l’IA est-il vraiment indispensable ? Une solution moins intrusive existe-t-elle ? La complexité du modèle est-elle justifiée par l’objectif poursuivi ?
4. Identifier les risques spécifiques à l’IA : biais algorithmiques discriminatoires, opacité des décisions (boîte noire), risque de réidentification à partir des sorties du modèle, dérives d’usage non anticipées.
5. Définir des mesures d’atténuation des risques : pseudonymisation des données d’entraînement, audit régulier des biais, mécanismes de supervision humaine, clause contractuelle avec le fournisseur du modèle (article 28 du RGPD).
6. Prendre une décision documentée : le système peut être déployé en l’état, déployé sous conditions, ou doit être revu si les risques résiduels restent trop élevés.

2. Quand l’AIPD est-elle obligatoire pour un projet IA ?

L’article 35, §1 du RGPD pose le principe : l’AIPD est requise lorsqu’un traitement est « susceptible d’engendrer un risque élevé sur les droits et libertés des personnes concernées ». En matière d’IA, ce seuil est atteint dans la très grande majorité des cas.

2.1 Les trois déclencheurs automatiques

L’article 35, §3 du RGPD identifie trois situations pour lesquelles l’AIPD est toujours obligatoire. Les systèmes d’IA en activent fréquemment au moins un :

• Profilage avec décision automatisée à effet juridique ou significatif : tout système qui évalue des aspects personnels (solvabilité, comportement, santé, performances, risque de récidive…) et sur la base duquel sont prises des décisions ayant des effets sur la personne. Un modèle de scoring de crédit, un système de présélection de CV, un outil de détection de fraude : tous entrent dans cette catégorie.
• Traitement à grande échelle de données sensibles : un LLM entraîné sur des données de santé, un système de reconnaissance émotionnelle (données biométriques), un moteur de recommandation utilisant des données d’opinion politique. Les données sensibles sont listées à l’article 9 du RGPD.
• Surveillance systématique à grande échelle : une IA d’analyse comportementale sur flux vidéo, un système de monitoring des salariés en télétravail, ou le suivi en temps réel d’utilisateurs sur une plateforme digitale.

2.2 Les neuf critères du CEPD : la règle des deux critères

Les lignes directrices du CEPD ont défini neuf critères supplémentaires. Réunir au moins deux d’entre eux rend l’AIPD fortement recommandée et très souvent exigée en pratique. En matière d’IA, il est rare qu’un seul critère soit activé :

• Évaluation ou scoring : noter, prédire ou classer des personnes. C’est le cœur de la plupart des systèmes d’IA.
• Décision automatisée avec effet juridique ou significatif similaire : refus de crédit, non-recrutement, tarification différenciée, exclusion d’un service.
• Surveillance systématique : monitoring des comportements, des déplacements ou des communications.
• Données sensibles ou à caractère hautement personnel.
• Données traitées à grande échelle.
• Croisement de données : un LLM qui combine historique d’achat, localisation et données de navigation pour personnaliser une offre.
• Données concernant des personnes vulnérables : mineurs, patients, salariés.
• Usage innovant ou nouvelle technologie : IA générative, reconnaissance faciale, traitement du langage naturel, détection émotionnelle.
• Traitement susceptible de priver une personne d’un droit ou d’un service.

3. L’AI Act ajoute une deuxième évaluation : la FRIA

Pour les systèmes d’IA classés « à haut risque » au sens de l’AI Act (Annexe III du Règlement UE 2024/1689), certains déployeurs sont soumis à une obligation supplémentaire : la FRIA (Fundamental Rights Impact Assessment), prévue à l’article 27 de l’AI Act.

3.1 AIPD et FRIA : deux périmètres différents

La confusion entre les deux évaluations est fréquente. Ces deux obligations sont complémentaires : l’une ne remplace pas l’autre.

• L’AIPD (article 35 du RGPD) couvre exclusivement les risques liés au traitement de données personnelles. Elle répond à la question : que risquent les personnes dont je traite les données ?
• La FRIA (article 27 de l’AI Act) couvre l’ensemble des droits fondamentaux garantis par la Charte de l’UE — dignité humaine, non-discrimination, accès à la justice, liberté d’expression — y compris ceux qui n’ont aucun lien avec la protection des données. Elle répond à la question : ce système d’IA porte-t-il atteinte aux droits fondamentaux des personnes qu’il affecte ?

L’article 27, §4 de l’AI Act prévoit explicitement que l’AIPD et la FRIA se complètent : si certaines exigences de la FRIA sont déjà couvertes par l’AIPD, la FRIA complète l’AIPD pour les aspects spécifiques aux droits fondamentaux. Elle ne la remplace pas.

3.2 Qui est concerné par la FRIA ?

La FRIA ne s’impose pas à tous les déployeurs. L’article 27 la réserve à des catégories spécifiques :

• Les organismes de droit public (administrations, collectivités, établissements publics).
• Les opérateurs de services essentiels au sens de la directive NIS (eau, énergie, transport, banque, infrastructures numériques).
• Les établissements d’enseignement et de formation professionnelle.

Une entreprise privée standard qui déploie un système d’IA à haut risque — outil RH, système de scoring commercial — n’est en principe pas soumise à la FRIA formelle. Ses obligations au titre de l’AI Act relèvent de l’article 26 (supervision humaine, journalisation, information des personnes). Elle reste en revanche pleinement soumise à l’AIPD.

3.3 Systèmes d’IA à haut risque : ce que couvre l’Annexe III de l’AI Act

Sont classés à haut risque au sens de l’Annexe III, notamment :

• Les systèmes utilisés dans les infrastructures critiques.
• Les systèmes de sélection et d’évaluation dans l’enseignement.
• Les systèmes utilisés dans les processus de recrutement et de gestion RH (présélection, évaluation des performances, promotions, licenciements).
• Les systèmes d’évaluation de l’éligibilité à des services publics et privés essentiels (crédit, assurance, santé).
• Les systèmes utilisés dans les procédures judiciaires et l’application des lois.
• Les systèmes de contrôle des frontières et d’immigration.

4. Comment articuler AIPD et FRIA en pratique ?

Le CEPD et la Commission européenne travaillent conjointement sur des lignes directrices dédiées à l’articulation entre le RGPD et l’AI Act, dont l’adoption est prévue courant 2026. En attendant, l’état de la doctrine permet de dégager une méthode.

4.1 La logique du socle commun + deux branches

La bonne pratique est de structurer la démarche en trois temps :

• Socle commun : description du système d’IA, données traitées, finalités, acteurs impliqués, architecture technique. Ce travail est nécessaire à l’AIPD comme à la FRIA. Il ne doit être fait qu’une seule fois.
• Branche AIPD : analyse centrée sur les risques pour les données personnelles. Base légale, minimisation, droits des personnes, sécurité, durées de conservation, gestion des sous-traitants. Structure : template CEPD du 10 mars 2026.
• Branche FRIA (si applicable) : élargissement à l’ensemble des droits fondamentaux — non-discrimination, dignité, accès à la justice, libertés fondamentales. Analyse des biais algorithmiques sous l’angle des droits.

4.2 Apport du template CEPD du 10 mars 2026 pour les projets IA

Le template harmonisé adopté par le CEPD constitue la base méthodologique de référence pour l’AIPD. Il est particulièrement adapté aux projets IA sur deux points.

• La distinction entre risque inhérent et risque résiduel est centrale pour les systèmes d’IA : avant de déployer des mesures d’atténuation (supervision humaine, audit de biais, limitation des données d’entraînement), il faut d’abord évaluer le risque tel qu’il existe nativement dans le modèle. Cette approche en deux temps interdit de masquer des risques réels derrière des mesures dont l’effectivité n’est pas démontrée.
• La consultation des personnes concernées (article 35, §9 du RGPD) prend un relief particulier en matière d’IA : les personnes affectées par un algorithme sont souvent les mieux placées pour identifier des risques de discrimination ou d’exclusion que le développeur ne peut pas toujours anticiper.

4.3 Le rôle du fournisseur du système d’IA

Les obligations de documentation technique de l’AI Act (article 9 — système de gestion des risques ; article 11 — documentation technique) pèsent principalement sur le fournisseur du système d’IA, c’est-à-dire celui qui le développe et le met sur le marché.

En revanche, l’AIPD au titre du RGPD et la FRIA au titre de l’article 27 de l’AI Act pèsent sur le déployeur — l’entreprise ou l’organisme qui utilise le système dans un contexte spécifique. Lorsqu’une entreprise est à la fois fournisseur et déployeur — ce qui est fréquent pour les développements internes — elle cumule les deux niveaux d’obligations.

5. Sanctions : que risque-t-on en cas de manquement ?

Un projet d’IA déployé sans AIPD, ou avec une AIPD manifestement insuffisante, expose à un double régime de sanction : celui du RGPD et celui de l’AI Act.

5.1 Les sanctions au titre du RGPD

L’article 83, §4 du RGPD classe les manquements à l’obligation d’AIPD dans le premier niveau de sanctions : jusqu’à 10 millions d’euros, ou 2 % du chiffre d’affaires annuel mondial.

En pratique, l’absence d’AIPD s’accompagne souvent d’autres manquements — défaut de base légale, sécurité insuffisante, biais algorithmiques non traités — qui relèvent du second niveau de l’article 83, §5 : jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial. Les deux niveaux se cumulent régulièrement dans les décisions publiées.

La CNIL a retenu à plusieurs reprises l’absence d’AIPD comme circonstance aggravante dans ses délibérations, notamment pour des dispositifs biométriques et des systèmes de profilage déployés sans analyse préalable.

5.2 Les sanctions au titre de l’AI Act

Le non-respect des obligations imposées aux déployeurs de systèmes à haut risque, dont la FRIA, peut être sanctionné au titre de l’AI Act. Les amendes peuvent atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial (article 99 de l’AI Act).

Les deux régimes — RGPD et AI Act — sont indépendants et se cumulent. Un même système d’IA défaillant peut donc faire l’objet de sanctions simultanées de la CNIL et de l’autorité de surveillance du marché désignée au titre de l’AI Act.

5.3 L’obligation de consultation préalable : le piège souvent oublié

L’article 36, §1 du RGPD prévoit que lorsque l’AIPD révèle des risques résiduels élevés que l’entreprise ne peut pas atténuer, elle doit consulter la CNIL avant tout début de traitement. Pour un projet d’IA, cela peut survenir lorsque les biais algorithmiques ne peuvent pas être réduits à un niveau acceptable ou que les risques de réidentification sont structurels.

L’autorité dispose d’un délai de huit semaines pour répondre, prorogeable de six semaines supplémentaires. Concrètement, un projet d’IA à risques non maîtrisés peut se retrouver bloqué pendant plusieurs mois. Mieux vaut l’anticiper que le découvrir après le déploiement.

6. Recommandations pratiques pour les équipes projets

6.1 Intégrer les évaluations dès la phase de conception

L’AIPD et la FRIA doivent être lancées avant le démarrage du traitement, idéalement au stade de la conception du système (privacy by design, article 25 du RGPD). Cela suppose d’intégrer le DPO et les équipes juridiques dans les phases amont du projet, et non comme validateurs de fin de chaîne.

6.2 Qualifier le système d’IA avant de choisir le niveau d’analyse

La première question à se poser est celle de la qualification : le système est-il classé à « haut risque » au sens de l’Annexe III de l’AI Act ? Est-il déployé par un acteur soumis à la FRIA ? Les réponses déterminent le niveau d’obligation. En cas de doute, la bonne pratique est de conduire les deux évaluations.

6.3 Documenter la chaîne de responsabilité avec le fournisseur du modèle

Lorsque le système d’IA s’appuie sur un modèle tiers (API, open source intégré, SaaS), l’AIPD doit identifier le fournisseur comme sous-traitant et vérifier qu’un contrat conforme à l’article 28 du RGPD est en place. Elle doit également évaluer les risques induits : où les données sont-elles traitées ? Le modèle est-il entraîné avec des données à caractère personnel ? Des transferts hors UE sont-ils impliqués ?

6.4 Prévoir la révision périodique

Les systèmes d’IA évoluent en permanence : mises à jour de modèle, nouvelles données d’entraînement, extension du périmètre d’usage. L’article 35, §11 du RGPD impose de réviser l’AIPD dès que le risque est susceptible d’avoir changé. Pour les systèmes IA, cette révision doit être intégrée dans le cycle de vie du système.

Références

• RGPD (Règlement UE 2016/679), articles 25, 28, 35, 36 et 83.
• Règlement (UE) 2024/1689 — AI Act, articles 9, 11, 26, 27 et 99 ; Annexe III.
• CEPD, Template DPIA v1.0, adopté le 10 mars 2026.
• CEPD / G29, Lignes directrices sur l’AIPD (WP248 rev.01).
• CEPD / G29, Lignes directrices sur le DPO (WP243 rev.01).
• CNIL, Liste des traitements soumis à AIPD (délibération n° 2018-327).
• CNIL, Questions-réponses sur l’articulation RGPD / AI Act.
• CEPD, Rapport annuel 2025 (publié avril 2026) — lignes directrices conjointes CEPD / Commission sur l’articulation AI Act / RGPD en cours de finalisation.