DPIA/PIA pour projets IA : méthode validée CNIL

L’avis est tombé fin 2024 : pour le CEPD (Comité européen de la protection des données), un modèle d’IA entraîné sur des données personnelles ne peut être considéré comme « anonyme » si ces données peuvent être extraites ou « régurgitées ».

Pour les DPO et les équipes techniques, c’est un tournant. Votre analyse d’impact (AIPD/DPIA) classique, conçue pour un CRM ou une application web, est désormais obsolète face à un LLM. Le risque n’est plus seulement théorique ; il est technique et prouvable.

La pression de la direction pour déployer des copilotes internes ou des IA génératives est maximale, mais le casse-tête de conformité s’intensifie. Comment prouver que votre modèle ne mémorisera pas des données clients ? Comment gérer une demande d’effacement (unlearning) ? Comment justifier la base légale de l’entraînement ?

Cet article n’est pas un énième rappel des principes du RGPD. C’est un guide opérationnel pour transformer votre DPIA IA d’un document de conformité « papier » en un véritable outil de pilotage des risques techniques.

Nous vous fournissons une méthodologie en 6 étapes alignée sur les dernières recommandations CNIL 2025 et, surtout, une grille d’évaluation gratuite à télécharger. Elle intègre les points de contrôle spécifiques aux LLM : tests de régurgitation, filtres d’encapsulation, protocoles d’unlearning et preuves d’accountability.

À retenir :

• Le DPIA IA est (presque) toujours obligatoire. Les critères du CEPD (grande échelle, usage innovant, ADM) sont quasi systématiquement remplis.
• Le risque a changé. Il n’est plus seulement dans la base de données, il est dans le modèle (mémorisation, inférence, biais).
• La preuve doit être technique. Vous avez besoin de protocoles de tests (tests de régurgitation, membership inference) pour prouver que vos mesures sont efficaces.

Quand un DPIA est-il obligatoire en IA ?

Avant de plonger dans la technique, évacuons la première question : « En ai-je vraiment besoin ? ». La réponse courte est : oui, très probablement.

Le CEPD a établi neuf critères pour identifier les traitements susceptibles d’engendrer un risque élevé pour les droits et libertés. Si votre projet d’IA remplit au moins deux de ces neuf critères, le DPIA est obligatoire.

Or, les projets d’IA, et en particulier les LLM, cochent ces cases presque par nature :

• Collecte à grande échelle : L’entraînement d’un modèle, même « petit », se fait souvent sur des volumes de données (textes, logs, tickets clients) qui dépassent largement l’activité humaine normale.
• Usages innovants : L’utilisation de LLM, de la reconnaissance faciale ou de l’apprentissage fédéré est explicitement citée comme une « utilisation innovante » ou l’application de « nouvelles solutions technologiques ».
• Décisions automatisées (ADM) : Si votre IA est utilisée pour trier des CV, évaluer une demande de crédit, ou même modérer des contenus avec un « effet juridique ou similaire », le DPIA est requis.
• Données sensibles ou personnes vulnérables : Le simple risque que votre modèle infère des données sensibles (opinions politiques, santé) à partir de données non sensibles, ou qu’il traite avec des données d’employés (personnes vulnérables), peut déclencher l’obligation.

Point de Vue Stratégique

Ne cherchez pas à éviter le DPIA. Considérez-le comme votre première ligne de défense stratégique. Dans le contexte de l’AI Act, ce document sera la pierre angulaire de votre gouvernance. L’exigence de la CNIL n’est pas un frein ; c’est une méthode pour cartographier vos risques avant qu’ils ne deviennent des crises publiques ou des sanctions.

Cadre RGPD appliqué au développement IA

Un DPIA ne part pas de zéro. Il s’ancre dans les principes fondamentaux du RGPD, mais appliqués aux spécificités de l’IA. Les fiches pratiques 2025 de la CNIL sont claires : le RGPD s’applique à chaque étape du cycle de vie du modèle.

Voici les points de contrôle juridiques à valider avant de parler technique.

1. Finalité et Base Légale : Le casse-tête de l’entraînement

Vous devez définir une finalité claire (ex: « améliorer le support client », « optimiser le tri des candidatures »). La complexité réside dans la base légale, surtout pour l’entraînement.

• Le consentement est souvent impraticable à grande échelle.
• L’intérêt légitime (Article 6(1)f) est la piste la plus explorée, mais elle exige une documentation rigoureuse (un Legitimate Interest Assessment ou LIA) prouvant que les intérêts de votre entreprise ne portent pas une atteinte disproportionnée aux droits des personnes.

2. Scraping et Réutilisation (Test de Compatibilité)

Si vous entraînez votre modèle sur des données publiquement accessibles (scraping) ou si vous réutilisez une base de données interne pour une nouvelle finalité (ex: utiliser les logs de facturation pour entraîner une IA de prédiction de churn), vous devez effectuer un test de compatibilité.

Conseil DPO

Le Test de Compatibilité en pratique

Documenter ce test est crucial. Vous devez évaluer :

• Le lien entre la finalité initiale (ex: facturation) et la nouvelle (ex: entraînement IA).
• Le contexte de la collecte (les personnes s’attendaient-elles à cet usage ?).
• La nature des données (sont-elles sensibles ?).
• Les conséquences pour les personnes (y a-t-il un risque de discrimination ?).
• Les garanties mises en place (anonymisation, pseudonymisation, chiffrement).

Source : Inspiré des lignes directrices CNIL sur la réutilisation des données.

3. Minimisation et Conservation des données

Le principe de minimisation est contre-intuitif pour les data scientists, qui veulent plus de données. Votre rôle est d’imposer le « juste nécessaire ».

• Minimisation à la source : N’annotez et n’intégrez que les données strictement requises.
• Anonymisation/Pseudonymisation : C’est une mesure clé. Mais attention, l’EDPB considère que si un LLM peut régurgiter une donnée, elle n’était pas vraiment anonyme.
• Durée de conservation : Les jeux de données d’entraînement ne doivent pas être conservés indéfiniment. Définissez une politique de purge pour les données brutes une fois le modèle entraîné et validé.

4. Transparence et Droits des personnes

Comment informez-vous les personnes que leurs données (par exemple, leurs conversations avec votre chatbot) servent à entraîner un modèle ? Votre politique de confidentialité doit être mise à jour.

De plus, vous devez préparer l’exercice des droits (accès, rectification, effacement). C’est là que l’IA pose un défi majeur : comment « effacer » une personne d’un modèle déjà entraîné ? C’est tout l’enjeu de l’unlearning, que nous verrons dans les mesures techniques.

Méthodologie DPIA IA en 6 étapes

Le DPIA classique (contexte, risques, mesures) reste valable, mais il doit être « augmenté » pour l’IA. Voici une méthodologie en 6 étapes intégrant les risques spécifiques aux LLM.

Étape 1 : Cartographie du traitement

Décrivez précisément le cycle de vie de l’IA:

• Données : Nature, sources (scraping, internes, tiers), sensibilité, volume.
• Acteurs : Qui fournit le modèle (OpenAI, Mistral) ? Qui l’intègre (vous) ? Qui annote les données (sous-traitant) ?
• Phases : Collecte, préparation/annotation, entraînement, évaluation, déploiement (API, RAG), supervision humaine.

Étape 2 : Identification des risques (au-delà du RGPD)

C’est ici que le DPIA IA diffère. En plus des risques RGPD classiques (accès illégitime, fuite), vous devez évaluer les risques inhérents au modèle:

• Régurgitation / Mémorisation : Le modèle peut-il « recracher » des données personnelles vues lors de l’entraînement (un nom, un numéro de CB, un extrait de dossier médical) ?
• Membership Inference : Peut-on deviner si les données d’un individu spécifique ont été utilisées pour l’entraînement ?
• Extraction d’attributs : Peut-on inférer des données sensibles (ex: orientation sexuelle) à partir d’interactions anodines ?
• Biais et Discrimination : Le modèle produit-il des résultats inéquitables pour certains groupes ? (Ex: tri de CV pénalisant).
• Hallucinations préjudiciables : Le modèle peut-il inventer des faits faux mais crédibles sur une personne, portant atteinte à sa réputation ?

Étape 3 : Définition des mesures de mitigation

Listez les mesures juridiques, organisationnelles et techniques pour réduire chaque risque identifié à l’étape 2. (Nous détaillons les mesures techniques dans la section suivante).

Étape 4 : Tests et validation des mesures

Ne vous contentez pas d’affirmer qu’une mesure existe. Prouvez qu’elle fonctionne.

• Mesure : « Nous avons un filtre anti-régurgitation. »
• Preuve : « Résultats du red teaming montrant un taux de régurgitation de données sensibles inférieur à 0,01%. »

Cette validation technique est un sujet en soi, qui requiert des protocoles de tests LLM (régurgitation, extraction, membership) spécifiques.

Étape 5 : Décision et validation (Go/No-Go)

Le DPO et les métiers évaluent le risque résiduel. Est-il acceptable ? Si le risque reste élevé (ex: un modèle de diagnostic médical avec un fort taux de biais), une consultation de la CNIL peut être nécessaire.

Étape 6 : Plan de revue et cycle de vie

Le DPIA n’est pas un « one-shot ». C’est un document vivant. Définissez des déclencheurs de revue :

• Changement majeur du modèle (re-entraînement).
• Nouvelle source de données.
• Découverte d’une faille de sécurité (ex: prompt injection réussie).

Ce cycle de vie est au cœur de votre Gouvernance & Conformité IA (AI Act + RGPD).

Mesures techniques recommandées (L’expertise de l’architecte IA)

Un DPIA n’est robuste que si les mesures d’atténuation sont techniquement solides. Au-delà du cadre juridique, la preuve de la conformité se joue au niveau de l’architecture technique. Voici les mesures essentielles à documenter.

La CNIL elle-même recommande un arsenal de mesures spécifiques pour l’IA, que nous devons traduire en actions concrètes.

1. Mesures sur les données (en amont)

• Données Synthétiques : La mesure de minimisation la plus forte. Si vous pouvez entraîner le modèle sur des données entièrement fabriquées qui miment la structure des vraies données, vous éliminez le risque à la source.
• Anonymisation & Differential Privacy (DP) : L’anonymisation classique (masquer les noms) est fragile. La DP est une méthode statistique qui ajoute un « bruit » mathématique aux données, rendant impossible de savoir si un individu spécifique était dans le set, tout en préservant les grands motifs statistiques.

2. Mesures sur le modèle (pendant l’entraînement)

• Apprentissage Fédéré (Federated Learning) : Le modèle « voyage » vers les données (ex: sur les téléphones des utilisateurs) pour s’entraîner localement, et seule une mise à jour agrégée et anonymisée remonte au serveur central. Les données brutes ne quittent jamais l’appareil.
• Unlearning (Désapprentissage) : C’est la réponse technique au droit à l’effacement. Plutôt que de devoir ré-entraîner tout le modèle (ce qui coûte des millions), les techniques d’unlearning visent à « extraire » chirurgicalement la contribution d’une donnée spécifique du modèle. C’est complexe, mais crucial à documenter.

3. Mesures sur le déploiement (en aval)

C’est souvent le plus critique pour les IA que vous intégrez (ex: via RAG).

• Filtres de Prompts et d’Outputs : (L’encapsulation) C’est votre « pare-feu » applicatif.
  • Filtre d’entrée (Prompt) : Bloque les tentatives d’injection de prompt ou les demandes visant à extraire des PII.
  • Filtre de sortie (Output) : Scanne la réponse du LLM avant de l’afficher à l’utilisateur pour détecter et masquer toute PII (numéro de sécu, nom) qu’il aurait pu régurgiter.
  • Le choix de ces outils est stratégique, comme le montre notre Comparatif des solutions de filtres de prompts et outputs.
• Trusted Execution Environments (TEE) : Ce sont des enclaves sécurisées au niveau du processeur. Les données et le modèle sont chiffrés même en cours d’utilisation (en mémoire RAM), les rendant inaccessibles à l’administrateur système ou à un attaquant.
• Architecture RAG (Retrieval-Augmented Generation) : Le RAG est en soi une mesure de sécurité. Au lieu d’entraîner le LLM sur vos documents (risqué), vous le laissez « lire » les documents pertinents (et dont l’accès est contrôlé) en temps réel pour fonder sa réponse. L’accès à l’information est géré avant d’appeler le LLM.

Pour une sécurité de bout en bout, ces mesures doivent s’intégrer dans un cadre plus large, détaillé dans notre guide Sécurité IA (Art. 32 RGPD) : référentiels ANSSI, ENISA et OWASP.

Validation CNIL et preuves d’accountability

Votre DPIA est rédigé. Les mesures techniques sont en place. Votre travail de DPO est maintenant de prouver que tout cela fonctionne et de le maintenir à jour. C’est le principe d’accountability.

L’ère de la conformité déclarative (« croyez-nous sur parole ») est révolue. L’EDPB et la CNIL exigent des preuves tangibles.

1. La « Sainte Trinité » documentaire

Votre DPIA IA doit être le document central qui pointe vers trois autres piliers :

• ROPA (Registre des Activités de Traitement) : Votre registre RGPD doit être mis à jour avec ce nouveau traitement IA, sa finalité, ses catégories de données, et un lien vers le DPIA.
• LIA (Legitimate Interest Assessment) : Si vous utilisez l’intérêt légitime comme base légale (probable), le LIA doit être annexé au DPIA.
• Versions du DPIA : Utilisez l’outil PIA de la CNIL ou un autre système pour versionner votre analyse. Vous devez montrer l’évolution du risque (brut vs. résiduel) à mesure que vous ajoutez des mesures.

2. Les preuves techniques (la Checklist LLM)

C’est le point le plus important pour l’accountability des LLM. Vous devez organiser et journaliser des tests techniques.

Encadré : Checklist de Tests LLM pour votre DPIA

Voici les tests à mener et à annexer à votre DPIA pour prouver l’efficacité de vos mesures.

• Tests de Régurgitation :
  • Quoi : Tenter activement de faire « recracher » au modèle des PII connues de son set d’entraînement (noms, emails, extraits de contrats).
  • Preuve : Un rapport de red teaming avec le score de succès/échec.
• Tests de Biais et d’Équité :
  • Quoi : Soumettre au modèle des scénarios identiques ne variant que sur un critère sensible (ex: CV masculin vs. féminin).
  • Preuve : Rapport de métriques d’équité (ex: « égalité des chances »).
• Tests de Membership Inference :
  • Quoi : Tenter de déterminer si une donnée précise a fait partie du set d’entraînement.
  • Preuve : Rapport de tests statistiques (ex: score de confiance de l’inférence).
• Journalisation et Seuils :
  • Quoi : Mettre en place une journalisation minimisée (logs anonymisés) des prompts et des outputs pour détecter les tentatives d’attaque ou les réponses problématiques.
  • Preuve : Définir un seuil de non-régression (ex: « si les filtres bloquent >5% de réponses pour PII, une alerte est levée et le DPIA est revu »).

Outils gratuits et comparatif des pratiques

Vous n’êtes pas seul pour mener cette analyse. Plusieurs autorités fournissent des outils gratuits pour vous guider, chacun avec ses forces et ses faiblesses.

• L’Outil PIA de la CNIL (Le Formalisme)
  • C’est quoi ? Un logiciel gratuit (à installer ou en version web) pour vous guider pas à pas dans la rédaction d’un DPIA conforme RGPD.
  • Pour : Il est parfait pour le formalisme, la structure juridique, la gestion des versions et l’export d’un rapport présentable à l’autorité.
  • Contre : Il n’est pas spécifique à l’IA. Vous devrez « forcer » les risques LLM (régurgitation, biais) dans les champs de risques génériques.
  • Notre conseil : Utilisez-le comme réceptacle final pour votre analyse.
• Le Guide d’auto-évaluation IA de la CNIL (La Gouvernance)
  • C’est quoi ? Une grille de maturité (sous forme de guide) pour évaluer la conformité RGPD de votre système IA sur tout son cycle de vie.
  • Pour : Excellent pour la partie « Gouvernance » de votre DPIA. Il pose les bonnes questions sur les rôles, les responsabilités, et l’information des personnes.
  • Contre : Ce n’est pas un outil de DPIA, mais une checklist de maturité. Il identifie ce qu’il faut faire, pas comment évaluer le risque résiduel.
  • Notre conseil : Utilisez-le pour remplir les sections « Gouvernance » et « Mesures Organisationnelles » de notre grille téléchargeable.
• Les Checklists LLM de l’EDPB (Le Risque Technique)
  • C’est quoi ? Des rapports et avis (comme celui de décembre 2024) qui listent spécifiquement les risques de confidentialité des LLM (inférence, extraction, etc.).
  • Pour : C’est la source d’autorité la plus à jour sur les risques techniques spécifiques aux LLM.
  • Contre : C’est une doctrine, pas un outil. C’est à vous de la traduire en points de contrôle.
  • Notre conseil : C’est la source que nous avons utilisée pour construire la section « Évaluation des Risques Spécifiques IA » de notre grille Ikendo.

Conclusion : L’outil parfait n’existe pas. La meilleure pratique consiste à combiner l’Outil PIA CNIL pour le rapport final, le Guide d’auto-évaluation pour la gouvernance, et notre Grille Ikendo pour le pilotage technique quotidien et la preuve des tests LLM.

FAQ : Les questions essentielles sur le DPIA et l’IA

Voici les réponses directes aux questions les plus fréquentes que se posent les DPO et les équipes techniques.

1. Quand l’AIPD est-elle obligatoire pour un projet IA et comment interpréter “usage innovant/grande échelle” ?

L’AIPD (ou DPIA) est obligatoire si vous cochez au moins 2 des 9 critères du CEPD. Pour l’IA, c’est presque automatique :

• « Usage innovant » : L’utilisation de LLM, d’apprentissage fédéré ou de toute technique d’IA avancée est considérée comme innovante par la CNIL.
• « Grande échelle » : Ce critère s’évalue par le nombre de personnes, le volume de données ou la durée du traitement. L’entraînement d’un modèle sur des milliers d’interactions client ou de documents RH est considéré comme « grande échelle ». Si vous combinez les deux (un LLM entraîné sur vos données client), l’obligation est claire.

2. Quelle base légale pour entraîner un modèle sur des données publiques et comment réaliser le test de compatibilité ?

La base légale la plus souvent envisagée est l’intérêt légitime (Article 6.1.f RGPD). Pour l’utiliser, vous devez prouver (via un LIA) que votre intérêt est réel, nécessaire, et qu’il ne l’emporte pas sur les droits des personnes. Si les données ont été « scrapées », vous devez aussi prouver que les personnes pouvaient raisonnablement s’attendre à cette réutilisation. Le test de compatibilité évalue le lien entre la finalité initiale (publication) et la nouvelle (entraînement), la nature des données, et les garanties que vous ajoutez (anonymisation, filtres) pour protéger les individus.

3. Comment tester régurgitation/extraction/membership et fixer des seuils de non-régression ?

Ces tests relèvent du red teaming :

• Régurgitation : Utiliser des prompts ciblés pour tenter de faire « recracher » au modèle des données sensibles (PII) qu’il a vues en entraînement.
• Extraction / Membership Inference : Tests statistiques plus complexes visant à confirmer si un point de donnée précis (ex: « l’email jean.dupont@societe.com ») était dans le set d’entraînement. Les seuils de non-régression sont votre « ligne rouge » interne, à documenter dans le DPIA. Exemple : « Si nos tests mensuels de régurgitation dépassent un taux de succès de 0,1% sur les PII, le modèle est mis en quarantaine et une revue du DPIA est lancée. »

4. Quelles mesures art. 32 adaptées aux systèmes IA (TEE, chiffrement, SBOM, logs minimisés) ?

L’Article 32 (sécurité) s’applique pleinement. Pour l’IA, la CNIL insiste sur:

• TEE (Trusted Execution Environments) : Pour chiffrer les données pendant l’entraînement ou l’inférence.
• Chiffrement : Standard pour les données au repos (stockage) et en transit.
• SBOM (Software Bill of Materials) : Une « liste d’ingrédients » de votre IA, listant les librairies open source, les modèles de base, et leurs versions, pour tracer les failles de sécurité.
• Logs minimisés : Journaliser les requêtes et les réponses à des fins de sécurité, mais en anonymisant ou pseudonymisant les PII dans ces logs.

5. Comment traiter les demandes d’accès/effacement et mettre en œuvre l’unlearning ?

C’est le défi majeur.

• Accès : Vous devez être capable d’expliquer comment les données de la personne ont été utilisées (information) et, si possible, quelles logiques ont mené à une décision la concernant.
• Effacement (Unlearning) : Le « vrai » unlearning (retirer une donnée d’un modèle) est techniquement très complexe et coûteux. Une approche proportionnée, à documenter dans le DPIA, peut consister à :
  1. Ajouter la donnée à une liste de « blocage » pour le prochain ré-entraînement.
  2. Mettre en place un filtre en sortie pour que l’information, même si régurgitée, ne soit jamais affichée.
  3. Ne procéder à un ré-entraînement complet (incluant l’effacement) que lors des cycles de mise à jour planifiés du modèle.

Votre DPIA, du fardeau légal à l’atout stratégique

L’analyse d’impact IA n’est plus, en 2025, un simple exercice de conformité à archiver. C’est devenu le principal outil de pilotage pour déployer l’IA de manière responsable et défendable.

Face à des technologies (LLM) dont la capacité de mémorisation est un risque avéré, la seule réponse valable est la preuve technique. Votre DPIA doit refléter cette nouvelle réalité : il doit être alimenté par des tests de régurgitation, soutenu par des mesures techniques robustes (TEE, filtres, unlearning), et vivre au rythme des mises à jour de vos modèles.

C’est à cette seule condition que le DPO et le Head of Data pourront répondre « Oui » à la direction, en toute confiance.

Pour ne manquer aucune de nos analyses sur la gouvernance de l’IA, l’AI Act et les stratégies de conformité, abonnez-vous à notre newsletter « AI Governance ».

Et pour une vue d’ensemble, plongez dans notre dossier pilier : Gouvernance & Conformité IA (AI Act + RGPD).

Et vous, quel est le plus grand défi que vous rencontrez aujourd’hui en tentant de documenter vos projets IA ? Partagez votre expérience en commentaire.

À propos de l’auteur

Alain Lanoë est rédacteur en chef et analyste des futurs technologiques pour Ikendo.fr1. Fort de 15 ans d’expérience en conseil stratégique et en journalisme économique, il décrypte les mouvements de fond qui dessinent notre avenir numérique. Sa mission : transformer le bruit informationnel en signal stratégique pour aider les décideurs et les citoyens curieux à penser le monde qui vient, et pas seulement à le subir.

La section sur les mesures techniques a été validée en collaboration avec Julien Moreau, Ingénieur en Machine Learning et expert invité pour notre pôle « Technologies Profondes ».

Sources principales

• Comité Européen de la Protection des Données (CEPD) : Avis sur les risques de confidentialité des LLM (Déc. 2024).
• CNIL : Guide d’auto-évaluation IA pour la conformité RGPD (Édition 2025).
• CNIL : Fiches pratiques sur l’IA et le RGPD (Bases légales, minimisation, droits).
• CNIL : L’Outil PIA et sa méthodologie.