Recommandations CNIL sur l'IA : le guide pratique 2026

L’essentiel. La CNIL a publié, entre 2024 et 2025, une série de fiches pratiques encadrant le développement des systèmes d’IA sous l’angle du RGPD. À retenir : l’intérêt légitime (Art. 6(1)(f)) est la base légale la plus courante pour l’entraînement, sous réserve du triple test ; le web scraping n’est pas interdit mais doit être encadré (sources, robots.txt, droit d’opposition) ; et la documentation des choix de conception est le point de conformité le plus surveillé. Ce guide traduit ces recommandations en actions concrètes.

Vous développez ou intégrez un système d’IA et vous cherchez ce que la CNIL attend concrètement ? Ses fiches pratiques constituent aujourd’hui le référentiel le plus complet pour concilier IA et protection des données en France. Elles ne créent pas d’obligations nouvelles : elles précisent comment appliquer le RGPD à un projet d’IA, de la constitution des jeux de données à l’exercice des droits. Voici comment les lire et les mettre en œuvre, sans jargon.

Un corpus construit par vagues successives

Les recommandations de la CNIL sur l’IA n’ont pas été publiées d’un bloc. Elles se sont construites progressivement, au fil de consultations publiques et de retours du terrain.

Première vague (2024) — les fondamentaux. Les premières fiches couvrent les questions structurantes : quand le RGPD s’applique-t-il à un système d’IA, comment définir les finalités, choisir la base légale, appliquer la minimisation et informer les personnes. Message central : un système d’IA reposant sur des données personnelles n’échappe pas au RGPD ; les principes de l’article 5 s’appliquent intégralement, y compris à la phase d’entraînement.

Deuxième vague (juin 2025) — intérêt légitime et web scraping. La CNIL ajoute deux fiches très attendues des développeurs : l’une sur l’intérêt légitime comme base de l’entraînement, l’autre sur le moissonnage de données en ligne (web scraping).

Troisième vague (juillet 2025) — sécurité, annotation, statut du modèle. La CNIL finalise le corpus avec des fiches sur la sécurité des systèmes d’IA, l’annotation des données et le statut juridique du modèle entraîné. C’est cette dernière question qui a suscité le plus de débats : un modèle entraîné constitue-t-il en lui-même un traitement de données personnelles ? La réponse est nuancée et dépend de la capacité du modèle à restituer des données identifiantes.

Les thèmes clés en un coup d’œil

Thème	Ce que la CNIL attend
Qualification	Déterminer si des données personnelles sont traitées, par phase (entraînement / inférence)
Base légale	Intérêt légitime le plus souvent, avec triple test documenté
Minimisation	Privilégier données anonymisées ou synthétiques quand c’est possible
Données d’entraînement	Documenter provenance, base légale, catégories, durée de conservation
Web scraping	Sources documentées, robots.txt, exclusion des données sensibles, opposition
Annotation	Former les annotateurs, proscrire les annotations non pertinentes, tracer
Sécurité	Contrer empoisonnement, extraction de données, injection de prompts
Droits	Information adaptée, droit d’opposition effectif, gestion de l’effacement

Base légale : l’intérêt légitime et le triple test

Pour la phase de développement, la CNIL considère que l’intérêt légitime (Art. 6(1)(f)) est la base légale la plus adaptée dans la majorité des cas : le consentement est rarement praticable lorsque les données proviennent de sources multiples et massives. Encore faut-il réaliser et documenter le triple test.

• Légitimité. L’intérêt poursuivi doit être licite, déterminé de façon claire et réel. Un outil d’aide au diagnostic, un système de détection de fraude ou un assistant conversationnel sont des exemples d’intérêts potentiellement légitimes.
• Nécessité. Le traitement de données personnelles doit être strictement nécessaire à la finalité. Si des données anonymisées ou synthétiques permettent un résultat comparable, elles doivent être privilégiées : c’est là que le principe de minimisation (Art. 5(1)©) prend toute sa force.
• Mise en balance. Les intérêts du responsable ne doivent pas prévaloir sur les droits des personnes. La CNIL invite à évaluer la nature des données (sensibles ou non), les attentes raisonnables des personnes, l’impact du traitement et les garanties (pseudonymisation, limitation d’accès, droit d’opposition).

L’article 6 pose le cadre général de la licéité ; notre guide de l’article 6 du RGPD détaille chacune des six bases légales.

Données d’entraînement : documenter, toujours

Les fiches insistent sur la documentation de la constitution des jeux de données. Pour chaque jeu, le responsable de traitement doit pouvoir justifier :

• la provenance (collecte directe, bases ouvertes, web scraping, achat) ;
• la base légale applicable à chaque source ;
• les catégories de données incluses et exclues ;
• les mesures de minimisation appliquées (suppression de champs identifiants, pseudonymisation) ;
• la durée de conservation des données après l’entraînement.

Ce dernier point est particulièrement suivi : conserver les données d’entraînement « au cas où », sans finalité précise, contrevient au principe de limitation de la conservation. Leur maintien ne se justifie que si un ré-entraînement ou une amélioration du modèle est réellement prévu.

Web scraping : autorisé mais encadré

La collecte de données accessibles en ligne n’est pas interdite par principe, mais elle doit s’accompagner de garanties. La CNIL recommande notamment de :

• documenter les sources moissonnées ;
• respecter les fichiers robots.txt et les conditions d’utilisation ;
• exclure les données manifestement sensibles (Art. 9) ;
• mettre en place un mécanisme d’opposition accessible et effectif.

Ces exigences sont directement transposables dans une procédure interne de collecte, à conserver avec la documentation du jeu de données.

Annotation : qualité et transferts

La phase d’annotation détermine la qualité du modèle et sa conformité. La CNIL recommande de former les annotateurs aux enjeux de protection des données, de proscrire les annotations sans lien avec la fonction du système (par exemple annoter l’origine ethnique dans un système de reconnaissance d’objets) et de tracer les protocoles d’annotation.

L’annotation est souvent externalisée, parfois hors UE. Dans ce cas, deux cadres se cumulent :

• un contrat de sous-traitance conforme à l’article 28 du RGPD avec le prestataire (voir aussi notre analyse du rôle du sous-traitant) ;
• un encadrement du transfert hors UE. Pour un importateur situé dans un pays sans décision d’adéquation, les clauses contractuelles types de la Commission (décision 2021/914) demeurent l’outil de référence, complétées d’une analyse des risques (transfer impact assessment). Pour les importateurs américains certifiés, le Data Privacy Framework offre, selon l’état du droit consulté en juillet 2026, un cadre d’adéquation dont la stabilité juridique reste discutée.

Sécurité des systèmes d’IA

La CNIL détaille des risques propres à l’IA : empoisonnement des données d’entraînement (data poisoning), extraction de données personnelles à partir du modèle (model inversion, membership inference) et manipulation des résultats par injection de prompts (prompt injection).

Les mesures recommandées s’ajoutent aux obligations générales de sécurité (Art. 32) : chiffrement des données au repos et en transit, contrôle d’accès aux modèles et aux jeux de données, journalisation des accès et des requêtes, tests de robustesse spécifiques. La CNIL mentionne également des travaux, conduits avec l’ANSSI, visant à développer des méthodes d’audit technique des modèles d’IA, susceptibles de déboucher sur des outils de vérification concrets.

Le statut du modèle entraîné : un point encore débattu

La fiche la plus commentée du corpus porte sur une question théorique aux conséquences très pratiques : un modèle d’IA entraîné constitue-t-il, en lui-même, un traitement de données personnelles ? La réponse conditionne l’application du RGPD au modèle une fois l’entraînement achevé — et donc l’exercice des droits sur ce modèle.

La position de la CNIL est nuancée. Un modèle n’est pas, par principe, une base de données de personnes ; il encode des paramètres statistiques. Mais certains modèles peuvent, dans certaines conditions, restituer des données personnelles identifiantes présentes dans le jeu d’entraînement (phénomène de mémorisation). Dans ce cas, le modèle doit être regardé comme comportant des données personnelles, avec les conséquences qui en découlent. À l’inverse, un modèle dont il est démontré qu’il ne permet pas, par des moyens raisonnables, de réidentifier des personnes peut être considéré comme anonyme.

En pratique, cela signifie qu’il faut tester la capacité de restitution du modèle (attaques d’extraction, requêtes ciblées) et documenter le résultat. Cette évaluation détermine si les obligations RGPD continuent de s’appliquer au modèle après son entraînement, et notamment la manière de traiter les demandes d’effacement.

Qualification : distinguer entraînement et déploiement

La première question que la CNIL invite à se poser reste : mon système traite-t-il des données personnelles, et à quelle phase ? La réponse n’est pas toujours évidente. Un modèle de langage entraîné sur des textes publics contenant des noms traite des données personnelles ; un modèle de classification de pièces industrielles peut n’en traiter aucune si aucune donnée identifiante n’entre dans le processus.

Il faut distinguer les phases : entraînement (constitution du jeu, apprentissage), validation/test, puis déploiement (inférence, usage opérationnel). Les obligations, et parfois la base légale, diffèrent d’une phase à l’autre : la base retenue pour l’entraînement n’est pas nécessairement celle du déploiement. Un système peut ainsi reposer sur l’intérêt légitime pour l’entraînement, puis sur le consentement ou le contrat pour l’usage opérationnel auprès d’un client. Cartographier ces phases est le préalable à toute analyse de conformité sérieuse.

Information des personnes et exercice des droits

Informer chaque personne dont les données servent à l’entraînement est matériellement impossible lorsque les données proviennent du web. La CNIL admet des modalités adaptées : mention d’information publiée sur le site du responsable, formulaire d’opposition, communication auprès de relais sectoriels.

Le droit d’opposition (Art. 21) doit rester effectif : pour un traitement fondé sur l’intérêt légitime, il ne peut pas être systématiquement refusé ; chaque demande s’examine, et un rejet suppose des « motifs légitimes et impérieux ».

Le droit à l’effacement soulève une difficulté technique : peut-on retirer les données d’une personne d’un modèle déjà entraîné ? La CNIL reconnaît que le « désapprentissage » (machine unlearning) n’est pas toujours possible. À défaut, des mesures compensatoires peuvent être envisagées : filtrage des sorties, limitation des requêtes susceptibles de générer des données identifiantes.

Enfin, lorsqu’un système prend des décisions produisant des effets juridiques ou significatifs sur des personnes, les garanties de l’article 22 sur la décision automatisée s’appliquent.

AIPD : quand est-elle obligatoire ?

Un système d’IA traitant des données à grande échelle, impliquant du profilage, l’évaluation systématique de personnes ou des données sensibles nécessite le plus souvent une analyse d’impact. La méthode est détaillée dans notre guide de l’AIPD et sa déclinaison pour l’AIPD appliquée à l’intelligence artificielle. L’AIPD n’est pas qu’une formalité : elle constitue aussi le document de référence pour démontrer la conformité en cas de contrôle.

Articulation avec le règlement européen sur l’IA (AI Act)

Les recommandations CNIL portent sur le volet données personnelles. Le règlement européen sur l’IA ajoute des obligations propres au produit, applicables selon un calendrier échelonné : interdictions de certaines pratiques, obligations de transparence, exigences renforcées pour les systèmes à haut risque. Ces échéances sont récapitulées dans notre calendrier de l’AI Act, et la classification des risques IA permet de situer votre système.

Pour un système à haut risque, les deux cadres se recoupent partiellement : documentation technique, gestion des risques, gouvernance des données, transparence. Plutôt que de maintenir deux démarches parallèles, il est recommandé de construire un référentiel de conformité unique couvrant RGPD et AI Act — une articulation qu’un logiciel RGPD permet de structurer et de tenir à jour. L’actualité IA 2026 suit les évolutions de ce double cadre.

Comment appliquer les recommandations : checklist

• [ ] Déterminer si le système traite des données personnelles, phase par phase (entraînement, validation, inférence).
• [ ] Choisir et documenter la base légale (triple test si intérêt légitime).
• [ ] Cartographier les jeux de données : provenance, base légale, catégories, durée.
• [ ] Appliquer la minimisation (anonymisation, données synthétiques quand c’est possible).
• [ ] Encadrer le web scraping (sources, robots.txt, exclusion des données sensibles).
• [ ] Sécuriser l’annotation et contractualiser la sous-traitance (Art. 28) et les transferts.
• [ ] Mettre en place une information adaptée et un canal d’opposition effectif.
• [ ] Réaliser l’AIPD lorsque le risque est élevé.
• [ ] Documenter les choix de conception (privacy by design, Art. 25).
• [ ] Construire un référentiel unique RGPD + AI Act.

Ce qu’il faut retenir

• La CNIL a publié une série de fiches pratiques sur le développement des systèmes d’IA — c’est le référentiel RGPD/IA le plus complet en France.
• L’intérêt légitime est la base légale la plus courante pour l’entraînement, sous réserve d’un triple test documenté et d’un droit d’opposition effectif.
• Le web scraping est possible mais encadré (sources, robots.txt, exclusion des données sensibles, opposition).
• La documentation des choix de conception est le point de conformité le plus critique et le plus souvent négligé.
• Le RGPD et l’AI Act se cumulent : mieux vaut un référentiel unique qu’une double démarche.

FAQ

Les fiches pratiques de la CNIL sur l’IA sont-elles contraignantes ?

Ce sont des recommandations, pas des textes juridiquement contraignants. Elles reflètent toutefois l’interprétation de l’autorité de contrôle et constituent le standard qu’elle appliquera lors de ses contrôles. S’en écarter est possible, mais il faut alors documenter les raisons de l’écart et démontrer que le traitement reste conforme au RGPD.

L’intérêt légitime suffit-il pour entraîner un modèle sur des données personnelles ?

C’est une base légale valide, mais ce n’est pas un blanc-seing. Le responsable doit réaliser le triple test (légitimité, nécessité, mise en balance), le documenter et garantir un droit d’opposition effectif. La CNIL peut contester le recours à l’intérêt légitime si la mise en balance est insuffisante ou les garanties inadéquates.

Le web scraping est-il autorisé pour constituer un jeu de données ?

Il n’est pas interdit par principe, mais il doit être encadré : documentation des sources, respect des robots.txt et des conditions d’utilisation, exclusion des données manifestement sensibles et mise en place d’un mécanisme d’opposition accessible. Sans ces garanties, la collecte est fragile juridiquement.

Faut-il une AIPD pour tout projet d’IA ?

Non : l’AIPD n’est obligatoire que pour les traitements présentant un risque élevé pour les droits des personnes. Mais la plupart des projets d’IA traitant des données à grande échelle, avec profilage ou données sensibles, entrent dans cette catégorie. En cas de doute, la réaliser reste la meilleure option, ne serait-ce que comme document de conformité.

Comment articuler les recommandations CNIL avec l’AI Act ?

Les recommandations CNIL couvrent le volet données personnelles ; l’AI Act ajoute des obligations propres au produit (transparence, gestion des risques, documentation technique pour le haut risque). L’approche efficace consiste à bâtir un cadre unique s’appuyant sur les fiches CNIL pour le RGPD et sur l’AI Act pour la sécurité et la transparence du système.

Peut-on supprimer les données d’une personne d’un modèle déjà entraîné ?

Pas toujours : le « désapprentissage » n’est pas systématiquement réalisable techniquement. La CNIL admet, à défaut, des mesures compensatoires comme le filtrage des sorties ou la limitation des requêtes pouvant générer des données identifiantes. La question doit être anticipée dès la conception du système.