L’utilisation de l’intelligence artificielle dans le secteur de la santé soulève une question fondamentale pour tout responsable de traitement : puis-je confier des données de santé à une IA sans consulter la CNIL, dès lors que mon analyse d’impact relative à la protection des données (AIPD) conclut à un niveau de risque maîtrisé ? Et selon que les données sont réelles, pseudonymisées ou anonymisées, la réponse change-t-elle ?
L’AIPD : un outil d’évaluation, pas un blanc-seing
L’analyse d’impact relative à la protection des données (AIPD), prévue par l’article 35 du RGPD, est obligatoire lorsqu’un traitement est « susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques ». Le traitement de données de santé à grande échelle, combiné à l’usage de technologies innovantes comme l’IA, coche systématiquement plusieurs critères de la liste des traitements nécessitant une AIPD.
L’AIPD permet d’identifier les risques, d’évaluer leur gravité et leur vraisemblance, et de définir les mesures techniques et organisationnelles destinées à les atténuer. Son résultat peut aboutir à deux conclusions distinctes.
La première : le risque résiduel est acceptable. Le responsable de traitement a identifié des mesures suffisantes (chiffrement, contrôle d’accès, minimisation, clauses contractuelles, etc.) pour ramener le risque à un niveau que l’organisation peut assumer. Dans ce cas, le traitement peut être mis en œuvre sans consulter la CNIL.
La seconde : le risque résiduel reste élevé. Malgré les mesures envisagées, le responsable de traitement n’est pas en mesure de ramener le risque à un niveau acceptable. L’article 36 du RGPD impose alors une consultation préalable de la CNIL avant toute mise en œuvre du traitement. La CNIL dispose d’un délai de huit semaines, pouvant être prolongé de six semaines, pour rendre son avis.
L’AIPD n’est donc pas un mécanisme de dispense automatique. Elle constitue un processus d’évaluation dont le résultat détermine si la consultation de la CNIL est requise ou non.
Données de santé réelles : un terrain miné
Lorsque des données de santé au sens de l’article 9 du RGPD (pathologies, diagnostics, prescriptions, résultats d’examens, données génétiques, etc.) sont confiées en clair à un système d’intelligence artificielle, le niveau de risque est intrinsèquement élevé. Plusieurs facteurs se cumulent.
Le caractère sensible des données constitue le premier facteur de risque. Les données de santé bénéficient d’une protection renforcée et leur traitement est interdit par principe, sauf exceptions limitativement énumérées par l’article 9.2 du RGPD.
La complexité technologique de l’IA est le deuxième facteur. Les modèles de langage ou d’apprentissage automatique posent des questions spécifiques : opacité des algorithmes, risque de mémorisation des données d’entraînement, difficulté à garantir l’effacement effectif, transferts potentiels vers des serveurs situés hors de l’Union européenne.
Le volume et la variété des données traitées constituent le troisième facteur. L’IA nécessite souvent de grands volumes de données pour fonctionner efficacement, ce qui amplifie les conséquences potentielles d’une violation.
Dans ce scénario, il est très probable que l’AIPD aboutisse à un risque résiduel élevé, sauf si des garanties exceptionnelles sont mises en place : hébergement certifié HDS en France ou dans l’UE, absence totale de transfert hors UE, chiffrement de bout en bout, accords de sous-traitance conformes à l’article 28 du RGPD, garantie contractuelle que les données ne sont pas utilisées pour entraîner le modèle, et journalisation exhaustive des accès.
En pratique, confier des données de santé réelles à une IA grand public (type ChatGPT, Gemini ou autre) sans architecture dédiée rendra quasi systématiquement nécessaire la consultation préalable de la CNIL.
La pseudonymisation : une réduction du risque, pas une élimination
La pseudonymisation, définie à l’article 4.5 du RGPD, consiste à traiter les données de manière à ce qu’elles ne puissent plus être attribuées à une personne précise sans le recours à des informations supplémentaires, conservées séparément et soumises à des mesures techniques et organisationnelles.
Un point essentiel : les données pseudonymisées restent des données à caractère personnel au sens du RGPD. Elles demeurent donc soumises à l’ensemble des obligations du règlement, y compris celles relatives aux données sensibles si elles concernent la santé.
La pseudonymisation agit cependant comme un levier significatif dans l’AIPD. Elle réduit la vraisemblance du risque de réidentification et limite les conséquences en cas de violation de données. Concrètement, si la table de correspondance est correctement protégée et séparée du jeu de données transmis à l’IA, le risque résiduel peut être abaissé de manière substantielle.
Pour autant, la pseudonymisation seule ne dispense jamais de réaliser l’AIPD. Elle peut, en revanche, contribuer à ce que le résultat de cette AIPD soit favorable, c’est-à-dire que le risque résiduel soit jugé acceptable, évitant ainsi la consultation de la CNIL. Cela dépend de la robustesse de la pseudonymisation, de la nature des données transmises, du prestataire IA retenu et de l’ensemble des mesures complémentaires déployées.
L’anonymisation : la sortie du champ du RGPD
L’anonymisation constitue un traitement irréversible qui rend définitivement impossible la réidentification de la personne concernée, par quelque moyen que ce soit et par quiconque. Le considérant 26 du RGPD est explicite : les données anonymisées ne sont plus des données à caractère personnel.
Si les données confiées à l’IA sont véritablement anonymisées, le RGPD ne s’applique plus. Il n’y a alors ni obligation de réaliser une AIPD, ni consultation préalable de la CNIL au titre du RGPD, ni nécessité de justifier d’une base légale pour le traitement.
La difficulté réside dans la qualification même de l’anonymisation. Le Groupe de travail Article 29 (devenu le CEPD) a posé dans son avis 05/2014 trois critères cumulatifs pour qu’une anonymisation soit considérée comme effective : l’individualisation (il ne doit pas être possible d’isoler un individu dans le jeu de données), la corrélation (il ne doit pas être possible de relier entre eux des enregistrements relatifs à un même individu), et l’inférence (il ne doit pas être possible de déduire avec quasi-certitude de nouvelles informations sur un individu).
En matière de données de santé, l’anonymisation réelle est particulièrement difficile à atteindre. Les données médicales sont souvent si spécifiques (combinaison de pathologie, âge, localisation, antécédents) que la suppression des identifiants directs ne suffit pas à empêcher la réidentification. La CNIL a régulièrement rappelé que la simple suppression du nom et du prénom ne constitue pas une anonymisation.
Si le responsable de traitement peut démontrer que l’anonymisation est effective et irréversible, il est effectivement dispensé de toute obligation RGPD vis-à-vis de l’IA. Mais cette démonstration doit être rigoureuse et documentée, car toute anonymisation défaillante requalifie les données en données pseudonymisées, avec les obligations qui en découlent.
Il faut cependant nuancer cette « liberté » apparente : en droit français, la sortie du champ du RGPD ne signifie pas absence de toute contrainte. Le secret médical, le Code de la santé publique et d’autres réglementations sectorielles continuent d’encadrer l’utilisation de données issues de dossiers de santé, y compris après anonymisation (voir la section dédiée plus loin dans cet article).
Tableau de synthèse
| Critère | Données réelles | Données pseudonymisées | Données anonymisées |
|---|---|---|---|
| Nature juridique | Données personnelles sensibles | Données personnelles sensibles | Hors champ du RGPD |
| AIPD obligatoire | Oui | Oui | Non |
| Consultation CNIL possible | Très probable si risque résiduel élevé | Possible mais évitable avec des mesures robustes | Non requise |
| Base légale requise | Oui (art. 6 + art. 9.2) | Oui (art. 6 + art. 9.2) | Non |
| Niveau de risque intrinsèque | Très élevé | Élevé mais réduit | Nul au sens du RGPD, mais encadré par le droit français |
| Possibilité de confier à une IA | Sous conditions très strictes | Sous conditions strictes | Libre au regard du RGPD, mais sous réserve du respect du secret médical, du Code de la santé publique et des restrictions contractuelles |
Cas pratique : utilisation d’une IA du marché via API et obligation de consultation de la CNIL
Lorsqu’un responsable de traitement utilise une IA commerciale via une API (OpenAI, Mistral, Anthropic, Google, etc.), la question de la consultation de la CNIL dépend de ce qui transite réellement par l’API, de qui réalise l’opération de protection des données et du moment où cette opération intervient. Le tableau ci-dessous détaille les six scénarios les plus courants.
| Scénario | Description | Données transitant par l’API | AIPD obligatoire | Consultation CNIL probable | Risque principal | Observations |
|---|---|---|---|---|---|---|
| 1. Données brutes non anonymisées | Les données de santé sont envoyées en clair à l’API, sans aucun traitement préalable. | Données de santé identifiantes (nom, pathologie, diagnostic, etc.) | Oui | Oui, quasi systématiquement | Le fournisseur d’IA accède aux données en clair. Risque de mémorisation, de transfert hors UE, d’usage pour l’entraînement du modèle. Risque résiduel très élevé. | C’est le scénario le plus risqué. La consultation de la CNIL sera nécessaire dans la très grande majorité des cas, sauf architecture dédiée exceptionnelle (hébergement HDS, garanties contractuelles renforcées, absence de transfert). |
| 2. Données anonymisées par l’API elle-même | Les données de santé identifiantes sont envoyées à l’API, qui applique un processus d’anonymisation avant traitement. | Données de santé identifiantes à l’envoi. L’anonymisation intervient côté fournisseur. | Oui | Oui, très probable | Le transfert initial contient des données personnelles de santé en clair. L’anonymisation par le fournisseur ne change rien au fait que les données ont transité sous forme identifiante. Le responsable de traitement n’a aucune maîtrise sur le processus d’anonymisation du tiers. | Ce scénario est un piège fréquent. Que l’IA anonymise « après réception » ne dispense de rien : le traitement de données personnelles de santé a bien eu lieu lors du transfert. Le responsable de traitement ne peut pas se prévaloir de l’anonymisation réalisée par un tiers pour s’affranchir de ses obligations. |
| 3. Données reçues déjà anonymisées | Les données ont été anonymisées de manière irréversible avant tout envoi à l’API. Le jeu de données transmis ne contient aucune donnée personnelle. | Données anonymisées (aucune donnée personnelle) | Non au titre du RGPD | Non au titre du RGPD, mais attention au droit français | Si l’anonymisation est réellement irréversible, le RGPD ne s’applique plus. Cependant, d’autres textes français encadrent la réutilisation de données de santé, même anonymisées (voir section dédiée ci-dessous). | La sortie du champ du RGPD ne signifie pas liberté totale. Le Code de la santé publique, le secret médical, les règles du SNDS, l’article L. 4113-7 CSP (interdiction d’exploitation commerciale des données de prescription même anonymisées), et les obligations contractuelles ou éthiques continuent de s’appliquer. La charge de la preuve de l’anonymisation effective repose sur le responsable de traitement. |
| 4. Données pseudonymisées par l’API elle-même | Les données de santé identifiantes sont envoyées à l’API, qui applique un processus de pseudonymisation avant traitement. | Données de santé identifiantes à l’envoi. La pseudonymisation intervient côté fournisseur. | Oui | Oui, très probable | Même logique que le scénario 2 : les données personnelles de santé ont transité en clair vers le fournisseur. La pseudonymisation ultérieure par le prestataire ne rétroagit pas sur le transfert initial. Le responsable de traitement reste pleinement responsable. | La pseudonymisation « côté serveur » ne protège pas le transfert. Les données ont été exposées au fournisseur sous forme identifiante. Le risque résiduel reste élevé et justifie dans la plupart des cas une consultation de la CNIL. |
| 5. Données pseudonymisées par le responsable de traitement avant envoi | Le responsable de traitement pseudonymise les données en interne, puis envoie le jeu de données pseudonymisé à l’API. La table de correspondance reste en interne. | Données de santé pseudonymisées (codes, identifiants techniques, sans identifiants directs) | Oui | Possible mais évitable | Les données restent des données personnelles (la réidentification est possible via la table de correspondance). Cependant, le fournisseur d’IA n’a pas accès à cette table, ce qui réduit significativement le risque. | C’est le scénario de compromis le plus réaliste. L’AIPD est obligatoire mais son résultat peut conclure à un risque résiduel acceptable si les mesures sont robustes : séparation stricte de la table de correspondance, hébergement HDS, clauses contractuelles conformes, interdiction d’utilisation pour l’entraînement. La consultation de la CNIL peut alors être évitée. |
| 6. Données reçues déjà pseudonymisées par un tiers | Le responsable de traitement reçoit des données déjà pseudonymisées par un autre acteur (hôpital, SPST, laboratoire) et les envoie à l’API. | Données de santé pseudonymisées | Oui | Possible mais évitable | Les données restent des données personnelles. Le risque dépend de la robustesse de la pseudonymisation réalisée par le tiers et de la capacité du responsable de traitement à le vérifier. | Le responsable de traitement doit s’assurer de la qualité de la pseudonymisation réalisée par le tiers (audit, documentation, engagement contractuel). S’il n’a pas accès à la table de correspondance et que la pseudonymisation est robuste, le risque est comparable au scénario 5. L’AIPD doit néanmoins intégrer le risque lié à la confiance accordée au tiers. |
Le point clé : c’est le moment du transfert qui compte
L’enseignement fondamental de ce tableau est que ce qui transite par l’API au moment de l’appel détermine le niveau de risque, et non ce que le fournisseur fait ensuite des données. Si des données de santé identifiantes quittent le système d’information du responsable de traitement pour atteindre un serveur tiers, le traitement de données sensibles a eu lieu, quelles que soient les opérations réalisées ensuite par le fournisseur.
Les scénarios 2 et 4, où c’est l’IA qui anonymise ou pseudonymise, sont particulièrement trompeurs. Certains fournisseurs mettent en avant ces fonctionnalités comme argument de conformité, mais elles n’allègent en rien les obligations du responsable de traitement au titre du RGPD. La donnée a circulé en clair, le risque a existé, l’AIPD doit en tenir compte.
À l’inverse, les scénarios 3, 5 et 6, où la protection intervient avant le transfert, permettent de réduire significativement le risque résiduel et, dans certains cas, de s’affranchir de la consultation de la CNIL.
Données anonymisées : sortir du RGPD ne signifie pas tout se permettre
C’est une erreur fréquente et dangereuse : considérer que l’anonymisation des données de santé ouvre un espace de liberté totale. Si le RGPD ne s’applique effectivement plus aux données véritablement anonymisées, le droit français impose d’autres contraintes qui survivent à l’anonymisation.
Le secret médical (article L. 1110-4 du Code de la santé publique). Le secret médical ne protège pas seulement des « données personnelles » au sens du RGPD. Il couvre l’ensemble des informations venues à la connaissance du professionnel de santé dans l’exercice de sa profession. Le processus même d’anonymisation constitue un traitement qui doit respecter le secret médical. Un médecin ou un SPST ne peut pas extraire des données de dossiers médicaux pour les anonymiser et les transmettre librement à un tiers commercial, même si le résultat final est anonyme. L’extraction initiale engage le secret professionnel.
L’interdiction d’exploitation commerciale des données de prescription (article L. 4113-7 du Code de la santé publique). Ce texte interdit la constitution et l’utilisation à des fins de prospection ou de promotion commerciales de fichiers composés à partir de données issues directement ou indirectement des prescriptions médicales ou des données personnelles de santé. Et la CNIL le rappelle : cette interdiction s’applique même lorsque les données ont été rendues anonymes à l’égard des patients, dès lors que ces fichiers permettent d’identifier directement ou indirectement le professionnel prescripteur. En d’autres termes, anonymiser les patients ne suffit pas si le prescripteur reste identifiable.
Le cadre du SNDS et du Health Data Hub. Les données issues du Système National des Données de Santé, même anonymisées, ne peuvent être réutilisées que pour des finalités d’intérêt public : recherche, études, évaluation, innovation en santé. Leur réutilisation à des fins de promotion commerciale, d’exclusion de garanties d’assurance ou de modification de contrats est explicitement interdite par l’article L. 1461-1 du Code de la santé publique. L’accès à ces données reste soumis à l’autorisation de la CNIL et à l’avis du CESREES (Comité éthique et scientifique pour les recherches, les études et les évaluations dans le domaine de la santé), même pour des jeux de données anonymisés.
Les engagements contractuels et éthiques. En pratique, les données de santé sont souvent collectées dans un cadre contractuel ou institutionnel qui prévoit des restrictions de réutilisation. Un SPST qui collecte des données dans le cadre du suivi de santé au travail ne peut pas les réutiliser pour une finalité différente sans vérifier la compatibilité de cette nouvelle finalité avec le cadre initial, et ce indépendamment du statut anonymisé ou non des données. Les comités d’éthique et les chartes de bonne pratique imposent également des limites.
Le futur Espace Européen des Données de Santé (EHDS). Le règlement EHDS, en cours de déploiement, prévoit un cadre d’utilisation secondaire des données de santé, y compris anonymisées. Les données pseudonymisées ne pourront être accessibles que si les données anonymisées sont insuffisantes pour atteindre l’objectif visé. Toute tentative de réidentification sera explicitement interdite. Ce cadre renforcera encore les obligations entourant la réutilisation des données de santé en Europe.
En résumé, l’anonymisation libère du RGPD mais pas du droit de la santé. Un responsable de traitement qui anonymise des données de santé pour les confier à une IA doit vérifier la licéité de son opération non seulement au regard de la protection des données personnelles, mais aussi au regard du secret médical, du Code de la santé publique, des éventuelles restrictions d’accès au SNDS, et de ses engagements contractuels. L’anonymisation est un levier de conformité RGPD, pas un passe-droit universel.
Comment travailler concrètement avec une IA sur des données de santé ?
La question n’est plus de savoir si l’IA sera utilisée dans le secteur de la santé, mais comment l’utiliser dans le respect du cadre réglementaire. Plusieurs approches permettent de concilier innovation et conformité.
Approche 1 : l’anonymisation préalable
La stratégie la plus sûre du point de vue du RGPD consiste à anonymiser les données avant de les soumettre à l’IA. Cette approche permet de sortir du champ du RGPD pour la phase de traitement par l’IA. Elle est particulièrement adaptée à l’analyse statistique, la recherche épidémiologique, l’entraînement de modèles ou la détection de tendances, où l’identification individuelle n’est pas nécessaire.
Attention toutefois : comme détaillé dans la section précédente, l’anonymisation ne libère pas des obligations issues du Code de la santé publique, du secret médical ou des restrictions spécifiques au SNDS. Le processus d’anonymisation lui-même doit être réalisé dans le respect de ces cadres.
La difficulté est aussi que l’anonymisation peut réduire l’utilité des données pour certains cas d’usage. Si l’IA doit fournir une aide au diagnostic individuel, l’anonymisation n’est évidemment pas compatible avec l’objectif poursuivi.
Approche 2 : la pseudonymisation renforcée
Pour les cas d’usage nécessitant un lien avec le patient (aide au diagnostic, suivi thérapeutique, personnalisation des soins), la pseudonymisation renforcée représente un compromis opérationnel. Le responsable de traitement confie à l’IA un jeu de données dans lequel les identifiants directs sont remplacés par des codes, la table de correspondance étant conservée dans un environnement séparé et sécurisé.
Cette approche exige une AIPD rigoureuse, des garanties contractuelles solides avec le fournisseur d’IA (article 28 du RGPD), un hébergement conforme (idéalement certifié HDS), et une documentation complète du dispositif.
Approche 3 : l’IA souveraine ou on-premise
Le déploiement de modèles d’IA en local (on-premise) ou sur des infrastructures souveraines certifiées HDS permet de garder la maîtrise complète du cycle de vie des données. Les données de santé ne quittent jamais l’infrastructure du responsable de traitement ou de son hébergeur certifié.
Des solutions existent avec des modèles open source (Mistral, LLaMA, etc.) déployables sur des serveurs dédiés. Cette approche élimine le risque de transfert hors UE et le risque que les données soient utilisées pour l’entraînement du modèle par un tiers.
L’AIPD reste obligatoire, mais le niveau de risque résiduel est significativement réduit, rendant la consultation de la CNIL moins probable.
Approche 4 : l’utilisation de l’IA comme outil d’aide sans accès aux données brutes
Il est possible d’utiliser l’IA comme un assistant sans lui confier directement de données de santé identifiantes. Le professionnel de santé consulte l’IA pour obtenir des informations générales (protocoles, interactions médicamenteuses, aide à la rédaction) sans transmettre les données du patient. Cette approche ne pose aucune difficulté au regard du RGPD puisqu’aucune donnée personnelle n’est traitée par l’IA.
Le rôle du DPO dans ce processus
Le DPO joue un rôle central dans l’ensemble de cette démarche. Il doit être consulté lors de la réalisation de l’AIPD (article 35.2), émettre un avis sur la méthodologie, les risques identifiés et les mesures envisagées. Il doit également veiller à la bonne qualification des données (anonymisées, pseudonymisées ou réelles), car cette qualification conditionne l’ensemble des obligations applicables.
Le DPO doit aussi s’assurer que le choix du prestataire IA a fait l’objet d’une évaluation de conformité, que les clauses contractuelles sont conformes à l’article 28, et que les transferts éventuels hors UE sont encadrés par des garanties appropriées (chapitre V du RGPD).
Enfin, c’est au DPO de recommander, le cas échéant, la consultation préalable de la CNIL lorsque l’AIPD révèle un risque résiduel élevé que le responsable de traitement ne parvient pas à atténuer.
Et enfin
Le résultat de l’AIPD peut effectivement dispenser de consulter la CNIL, mais uniquement si ce résultat démontre que le risque résiduel est maîtrisé. Ce n’est pas l’AIPD en elle-même qui dispense de la consultation, c’est la capacité du responsable de traitement à démontrer que les mesures mises en œuvre ramènent le risque à un niveau acceptable.
Pour les données de santé confiées à une IA, la nature des données (réelles, pseudonymisées ou anonymisées) influence directement ce résultat. L’anonymisation effective constitue la seule hypothèse où le RGPD ne s’applique plus, mais elle ne libère pas des obligations issues du Code de la santé publique, du secret médical et des règles spécifiques au SNDS. La pseudonymisation réduit le risque sans l’éliminer. Et les données réelles en clair exposent à un risque résiduel qui nécessitera dans la plupart des cas une consultation de la CNIL.
Travailler avec une IA sur des données de santé est possible, à condition de choisir l’architecture appropriée, de documenter rigoureusement sa conformité, et de ne jamais considérer l’AIPD comme une simple formalité administrative. C’est un outil de pilotage du risque, et son résultat engage la responsabilité de l’organisme.
Article rédigé dans le cadre de l’activité de DPO PARTAGE. Pour toute question relative à l’utilisation de l’IA en lien avec des données de santé, contactez votre DPO.
