Développer un système d'IA conforme au RGPD : la checklist opérationnelle de la CNIL

Intelligence artificielle et droit Publié le 28/07/2025 Dimitri Jorand

La CNIL publie une checklist pour développer un système d'IA conforme au RGPD : finalité, base légale, données d'entraînement, droits des personnes, sécurité et analyse d'impact.

La CNIL a publié le 22 juillet 2025 des recommandations pratiques pour aider les organismes qui développent un système d'intelligence artificielle à respecter le RGPD. Ce texte s'adresse en priorité aux équipes qui conçoivent ou font concevoir un système d'IA : direction des systèmes d'information, chef de projet innovation, délégué à la protection des données, direction qualité dans un établissement de santé ou médico-social. Il ne remplace pas l'AI Act, il l'accompagne.

Pour un CHU qui souhaite entraîner un modèle de tri des demandes de rendez-vous, pour un GHT qui teste un outil d'aide à la rédaction de comptes rendus, ou pour une association gestionnaire d'un EHPAD qui envisage un assistant de planification des soins, la question n'est plus de savoir si le RGPD s'applique. Il s'applique dès qu'une donnée à caractère personnel entre dans la chaîne, de l'entraînement jusqu'à l'usage final. La question est de savoir comment documenter, sécuriser et justifier chaque choix.

Cet article traduit les recommandations de la CNIL en une checklist opérationnelle, utilisable par une direction qualité, une DSI ou un DPO pour instruire un dossier avant de lancer, ajuster ou arrêter un projet d'IA.

Finalité et base légale : le point de départ non négociable

Avant toute collecte, la CNIL rappelle qu'un système d'IA doit répondre à une finalité déterminée, explicite et légitime. Un établissement de santé public ou privé ne peut pas entraîner un modèle « au cas où il serait utile un jour ». La finalité conditionne ensuite le choix de la base légale parmi les six prévues par le RGPD : consentement, contrat, obligation légale, intérêt public, intérêts vitaux ou intérêt légitime.

Dans le secteur sanitaire et médico-social, l'intérêt public ou la mission de santé publique sont souvent mobilisés pour les traitements portant sur des données de santé, mais cette base légale doit être articulée avec les exigences spécifiques de l'article 9 du RGPD sur les catégories particulières de données. Un centre hospitalier qui développe un outil de repérage précoce de la dénutrition doit documenter précisément pourquoi cette base légale est retenue, et non une autre.

Données d'entraînement : minimisation et qualité documentées

La CNIL insiste sur le principe de minimisation dès la phase de constitution du jeu de données d'entraînement. La logique consiste à justifier chaque catégorie de donnée retenue au regard de la finalité fixée, plutôt qu'à collecter le plus de données possible pour améliorer les performances. Un SSIAD qui entraîne un outil de priorisation des tournées doit pouvoir expliquer pourquoi telle variable est nécessaire et telle autre ne l'est pas.

La qualité et la représentativité des données d'entraînement doivent également être documentées, car elles conditionnent la loyauté du traitement et la réduction des biais. La CNIL recommande de conserver une trace des choix de constitution, de nettoyage et d'annotation du jeu de données, y compris lorsque cette tâche est confiée à un sous-traitant.

Le cas des données issues du web ou de sources tierces

Lorsque des données sont réutilisées à partir de sources tierces, l'organisme qui développe le système doit vérifier la licéité de la collecte initiale et la compatibilité de cette réutilisation avec la finalité poursuivie. Un organisme de formation qui alimente un assistant pédagogique avec des contenus existants doit s'assurer que ces contenus ne comportent pas de données personnelles collectées sans base légale adaptée.

Information des personnes et exercice des droits

Les personnes dont les données sont utilisées, que ce soit pour l'entraînement ou pour l'usage courant du système, doivent être informées de manière claire. Cette information porte sur la finalité, la base légale, la durée de conservation et les destinataires des données. Elle doit préciser si un système d'IA intervient dans une décision qui les concerne, notamment lorsqu'il existe un effet significatif sur la personne.

Le RGPD garantit aussi le droit d'accès, de rectification, d'opposition et, dans certains cas, le droit de ne pas faire l'objet d'une décision entièrement automatisée. Pour un système d'IA déployé dans un EHPAD ou une MAS, cela implique de prévoir un mécanisme humain de revue des décisions automatisées avant qu'elles n'affectent la prise en charge d'un résident.

Sécurité et analyse d'impact relative à la protection des données

La CNIL rappelle que la sécurité du système d'IA doit couvrir l'ensemble du cycle de vie : collecte, entraînement, hébergement, mise à jour, désactivation. Un incident de sécurité sur un modèle entraîné avec des données de santé constitue une violation de données au sens du RGPD, avec les obligations de notification qui en découlent.

Quand le traitement présente un risque élevé pour les droits et libertés, une analyse d'impact relative à la protection des données, l'AIPD, est obligatoire avant le déploiement. C'est très souvent le cas pour les systèmes d'IA traitant des données de santé à grande échelle, ou pour les traitements combinant profilage et décision automatisée. Cette analyse doit être conduite en amont, pas comme une formalité de régularisation après coup.

Responsable de traitement et sous-traitant : deux rôles à ne pas confondre

La checklist de la CNIL ne peut être instruite correctement que si les rôles sont clarifiés. Le responsable de traitement, généralement l'établissement de santé, l'association gestionnaire ou la collectivité territoriale, détermine les finalités et les moyens du traitement. L'éditeur du système d'IA, lorsqu'il traite des données pour le compte de l'établissement selon ses instructions, agit comme sous-traitant au sens du RGPD.

Cette distinction est cruciale au moment de la contractualisation : le contrat doit préciser les obligations du sous-traitant, les garanties de sécurité, les conditions de réutilisation des données pour d'autres finalités que celle du client, et les modalités de restitution ou de suppression des données en fin de contrat. Un CHU qui recourt à un éditeur d'IA générative pour la rédaction de comptes rendus doit vérifier que les données de ses patients ne servent pas à réentraîner un modèle mutualisé sans base légale distincte.

RGPD et AI Act : deux cadres cumulatifs, pas concurrents

Le RGPD encadre le traitement des données à caractère personnel. L'AI Act encadre le système d'IA en tant que tel, sa classification par niveau de risque et les obligations qui en découlent pour le fournisseur et pour le déployeur. Un établissement peut respecter le RGPD et rester en défaut au regard de l'AI Act, et inversement. Les deux textes doivent être instruits ensemble, avec des interlocuteurs qui se coordonnent : DPO pour le RGPD, référent IA ou chef de projet conformité pour l'AI Act.

Pour situer un système d'IA dans la grille de risque de l'AI Act, la lecture de notre article sur prescription sociale : comprendre le dispositif avant de l'intégrer à un parcours complète utilement cette checklist RGPD. Le décryptage publié par DEMETER sur le calendrier de l'AI Act permet de situer ces obligations dans le temps, sans se substituer aux textes officiels.

Exemples sectoriels : deux situations concrètes

Premier exemple : un GHT développe en interne un outil de priorisation des demandes d'imagerie à partir de données cliniques. La finalité est claire, la base légale s'appuie sur une mission d'intérêt public, mais le jeu de données d'entraînement mélange initialement des données issues de plusieurs établissements sans convention claire. La checklist CNIL impose de formaliser cette mutualisation, d'informer les patients et de vérifier si une AIPD est requise avant la mise en production.

Deuxième exemple : une association gestionnaire de plusieurs FAM confie à un prestataire le développement d'un assistant de rédaction des projets personnalisés. Le prestataire agit comme sous-traitant. Le contrat doit exclure toute réutilisation des données des résidents pour entraîner un modèle destiné à d'autres clients, sauf anonymisation réelle et vérifiée. L'emploi d'un simple pseudonyme ne suffit pas.

Objections fréquentes

« Nos données sont déjà pseudonymisées, donc le RGPD ne s'applique plus » est une objection fréquente et inexacte : la pseudonymisation réduit le risque, elle ne fait pas sortir la donnée du champ du RGPD tant qu'une réidentification reste possible. Autre objection courante : « L'éditeur nous assure que son outil est conforme », ce qui ne dispense pas l'établissement, en tant que responsable de traitement ou déployeur, de vérifier lui-même les garanties apportées et de les documenter dans son propre registre.

1. Cadrer la finalité. Formaliser par écrit l'objectif du système d'IA et le périmètre des données concernées.
2. Choisir et justifier la base légale. Documenter le choix parmi les six bases du RGPD, en lien avec l'article 9 pour les données de santé.
3. Constituer le jeu de données d'entraînement. Vérifier la minimisation, la licéité de la source et la qualité des données.
4. Informer les personnes concernées. Préparer une information claire sur l'usage de l'IA et le rôle éventuel de décisions automatisées.
5. Sécuriser le système. Auditer les mesures techniques et organisationnelles sur tout le cycle de vie du traitement.
6. Réaliser l'analyse d'impact si nécessaire. Documenter le risque et les mesures de réduction avant tout déploiement.
7. Formaliser les rôles contractuels. Clarifier responsable de traitement et sous-traitant dans un contrat écrit.
8. Décider go ou no-go. Trancher sur la base du dossier documenté, avec traçabilité de la décision.

• La finalité du système d'IA est écrite et validée par la direction concernée.
• La base légale retenue est documentée et cohérente avec la nature des données.
• Le jeu de données d'entraînement est minimisé, tracé et sa qualité est vérifiée.
• L'information des personnes concernées est rédigée et accessible.
• Les modalités d'exercice des droits, y compris sur les décisions automatisées, sont opérationnelles.
• Une analyse d'impact a été réalisée si le risque le justifie.
• Le contrat avec le prestataire distingue clairement responsable de traitement et sous-traitant.
• La cohérence avec les obligations de l'AI Act a été vérifiée séparément.

Ce que votre organisation peut faire maintenant

Recensez les projets d'IA en cours de développement ou de test dans votre établissement, même ceux portés par un seul service. Pour chacun, vérifiez si la finalité, la base légale et le jeu de données d'entraînement sont documentés. Dans le cas contraire, engagez le DPO avant d'aller plus loin. Notre diagnostic AI Act et notre diagnostic de maturité IA peuvent servir de point d'entrée pour objectiver cet état des lieux, en complément du travail du DPO sur le volet RGPD.

Pour les équipes qui pilotent plusieurs projets, la mise en place d'un schéma directeur immobilier en santé : piloter un projet qui relie soins, usages et climat et d'une stratégie nationale IA et données de santé : les décisions à préparer dès maintenant évite de traiter chaque dossier de manière isolée. Notre article sur la IA dans l'éducation et la formation : les réflexes CNIL pour protéger les données approfondit certains points évoqués ici, notamment sur les données d'entraînement issues du dossier patient.

Conclusion

La checklist publiée par la CNIL le 22 juillet 2025 ne crée pas d'obligation nouvelle, elle donne une méthode pour appliquer des exigences déjà en vigueur. Pour un directeur d'établissement, un DPO ou un chef de projet IA, l'enjeu est de transformer cette méthode en réflexe : documenter la finalité, la base légale, les données d'entraînement, l'information des personnes et la sécurité avant chaque mise en production. Cette rigueur, articulée avec les obligations distinctes de l'AI Act, conditionne la capacité de l'organisation à déployer l'IA sans s'exposer à un contrôle mal préparé. Nos équipes accompagnent cette mise en conformité via un accompagnement conseil ou un audit dédié, à ajuster selon la maturité du projet.

Questions fréquentes

Le RGPD s'applique-t-il dès la phase d'entraînement d'un système d'IA ?

Oui, dès qu'une donnée à caractère personnel est utilisée pour entraîner un système d'IA, le RGPD s'applique. Cela inclut les données de santé, soumises aux exigences renforcées de l'article 9. L'établissement doit documenter la finalité et la base légale avant de constituer le jeu de données.

Qui est responsable de traitement quand un éditeur externe développe le système d'IA ?

En général, l'établissement de santé ou médico-social qui détermine la finalité reste responsable de traitement. L'éditeur qui traite les données selon les instructions du client agit comme sous-traitant. Cette répartition doit être formalisée dans le contrat, avec les garanties de sécurité associées.

Une analyse d'impact est-elle toujours obligatoire pour un projet d'IA en santé ?

Non, elle est obligatoire quand le traitement présente un risque élevé pour les droits et libertés des personnes, ce qui est fréquent pour les données de santé à grande échelle ou les décisions automatisées. Le DPO doit évaluer ce risque au cas par cas avant le déploiement.

La pseudonymisation suffit-elle à sortir un traitement du champ du RGPD ?

Non. La pseudonymisation réduit le risque mais ne fait pas sortir la donnée du champ du RGPD tant qu'une réidentification reste possible, même indirecte. Seule une anonymisation réelle et vérifiée peut avoir cet effet.

Le RGPD et l'AI Act imposent-ils les mêmes obligations ?

Non, ce sont deux cadres cumulatifs. Le RGPD encadre le traitement des données personnelles, l'AI Act encadre le système d'IA selon son niveau de risque et les obligations du fournisseur ou du déployeur. Un système peut être conforme à l'un et pas à l'autre.

Que doit vérifier un établissement avant de lancer un projet d'IA interne ?

Il doit vérifier que la finalité est écrite, que la base légale est choisie et justifiée, que les données d'entraînement sont minimisées et documentées, que l'information des personnes est prête et que la nécessité d'une analyse d'impact a été évaluée avec le DPO.