IA : Analyser le statut d’un modèle d’IA au regard du RGPD
Les modèles d’IA peuvent relever du RGPD s’ils mémorisent des données personnelles issues de leur entraînement. La CNIL propose une méthode à destination des fournisseurs pour évaluer si leurs modèles sont soumis au RGPD ou non.
Les modèles d’IA peuvent être anonymes : le RGPD ne leur est alors pas applicable.
Dans certains cas, les modèles d’IA mémorisent une partie des données utilisées pour leur apprentissage, il devient alors possible d’en extraire des données personnelles, si celles-ci étaient présentent dans le jeu d’entraînement. Quand cette extraction a lieu avec des moyens raisonnablement susceptibles d’être mis en œuvre, ces modèles entrent dans le champ d’application du RGPD. La CNIL aide les fournisseurs de modèles à déterminer si cela est le cas ou non.
De quoi parle-t-on ?
Objectif de la fiche
Cette fiche, destinées aux fournisseurs, détaille la méthodologie pour évaluer et documenter la vraisemblance de réidentification de personnes physiques à partir d’un modèle d’IA entraîné sur des données personnelles ou d’un système d’IA se fondant sur un modèle ne pouvant être considéré comme anonyme.
À l’issue de cette analyse, sauf si cette vraisemblance est insignifiante, le RGPD s’appliquera aux traitements concernant le modèle ou le système. Dans cette fiche, on appellera statut d’un modèle ou de l’utilisation d’un système, la conclusion de l’analyse vis-à-vis de l’applicabilité du RGPD.
La conduite de cette analyse permettra, le cas échéant, de tirer les conséquences de l’application du RGPD, notamment grâce à une évaluation précise de la vraisemblance de réidentification associée à chaque typologie de données personnelles de la base d’entraînement. Une future fiche pratique viendra préciser les conséquences de l’application du RGPD à un traitement concernant un modèle d’IA.
Les deux figures ci-dessous résument la conduite de l’analyse dans les deux situations suivantes :
- Figure 1 : Conduire l’analyse en tant que fournisseur ou mandataire du statut d’un modèle d’IA.
- Figure 2 : Conduire l’analyse en tant que déployeur du statut d’un système d’IA basé sur un modèle non anonyme.
Figure 1 - Conduire l'analyse du statut d'un modèle d'IA
Cliquer sur l'image pour accéder à la version PDF
Figure 2 - Conduire l'analyse du statut d'un système d'IA basé sur un modèle non anonyme
Cliquer sur l'image pour accéder à la version PDF
Modèles et systèmes d’IA concernés
Un modèle d’IA est une représentation statistique des caractéristiques de la base qui a servi à l’entraîner. De nombreux travaux académiques ont prouvé que, dans certains cas, cette représentation est suffisamment fine pour conduire à une divulgation de données d’entraînement. Cette reconstitution peut se manifester par une régurgitation des données lors de l’utilisation dans le cas des systèmes d’IA génératifs, ou suite à une attaque telle que celles décrites dans l’article LINC « Petite taxonomie des attaques des systèmes d’IA ». Comme précisé dans l’avis du comité européen de la protection des données (CEPD) (voir encadré), lorsqu’il est possible, intentionnellement ou non, qu’un modèle ou un système d’IA régurgite ou fasse l’objet d’extractions de données personnelles à l’aide de moyens raisonnablement susceptibles d’être utilisés, le RGPD s’applique aux traitements concernant le modèle ou le système d’IA.
L’analyse de statut concerne donc tout modèle d’IA entraîné sur des données personnelles ou tout système d’IA qui intègre un modèle d’IA non anonyme. Si l’analyse de statut d’un modèle d’IA conclut à son exclusion du champ d’application du RGPD, alors un système d’IA reposant exclusivement sur ce modèle en est lui aussi exclu.
Focus sur l’avis 28/2024 du CEPD relatif à certains aspects de la protection des données liés au traitement des données à caractère personnel dans le contexte des modèles d'IA
Le CEPD a adopté un avis sur l'utilisation de données personnelles pour le développement et le déploiement de modèles d'IA. Cet avis examine 1) quand et comment les modèles d'IA peuvent être considérés comme anonymes, 2) si et comment l'intérêt légitime peut être utilisé comme base juridique et 3) les conséquences, au titre du RGPD, lorsqu’un modèle d'IA est développé en utilisant des données personnelles qui ont été traitées de manière illicite.
En ce qui concerne le statut des modèles d’IA, l'avis rappelle que la question de savoir si un modèle est anonyme doit être évaluée au cas par cas par les autorités chargées de la protection des données. Il précise notamment :
- qu’un modèle spécifiquement conçu pour produire ou inférer des informations sur des personnes physiques présentes dans son jeu d’entraînement contient, par conséquent, des données personnelles. Il est soumis au RGPD.
- que, pour qu'un modèle entraîné notamment sur des données personnelles, mais qui n’est pas conçu spécifiquement pour produire ou inférer des informations sur ces personnes, soit anonyme, il doit être très peu vraisemblable (1) pour quelqu’un d'identifier directement ou indirectement les personnes dont les données ont été utilisées pour créer le modèle à partir des paramètres du modèle (« white-box attacks »), et (2) d'extraire ces données personnelles du modèle par le biais de requêtes.
L'avis fournit une liste non prescriptive et non exhaustive de méthodes permettant de démontrer l'anonymat sur laquelle s’appuie cette fiche méthode.
Nécessité d’analyser le statut du modèle ou du système d’IA
Tout responsable de traitement doit documenter, de manière adéquate, la conformité de ses traitements de données personnelles (conformément au principe de responsabilité), par exemple dans une analyse d’impact sur la protection des données.
Ainsi, lorsque l’entraînement d’un modèle d’IA se fait à partir d’une base contenant des données personnelles, une analyse doit être réalisée systématiquement pour déterminer si le RGPD s’applique au modèle d’IA afin, le cas échéant, d’en tirer les conséquences.
Le fournisseur du modèle (auquel cette fiche s’adresse) sera le plus souvent responsable de ce traitement de développement dès lors qu’il détermine la finalité et les caractéristiques du modèle (sa destination, ses fonctionnalités, le contexte de déploiement, etc.) ainsi que les données personnelles d’entrainement. Lorsque ce dernier conclut que le modèle d’IA n’est pas soumis au RGPD, la documentation de l’analyse du statut du modèle doit pouvoir être présentée aux autorités de protection des données, telles que la CNIL. Elle doit démontrer que la vraisemblance de réidentification de personnes physiques dont les données sont contenues dans la base d’entraînement à partir du modèle ou système est insignifiante.
La documentation doit donc détailler les mesures prises lors de l’entraînement du modèle afin de limiter la vraisemblance de réidentification à partir d’un accès à celui-ci, et dans la plupart des cas, inclure les résultats de la conduite de tests d’attaques en réidentification.
Lorsqu’un modèle d’IA ne peut pas être considéré comme anonyme, il peut être envisagé d’atténuer la vraisemblance de réidentification des personnes, en intégrant celui-ci dans un système d’IA qui implémente des mesures robustes visant à en empêcher l’extraction. Dans certains cas, ces mesures peuvent permettre de sortir l’utilisation du système du champ d’application du RGPD. Le fournisseur d’un tel système devra donc conduire et documenter son analyse qui devra, dans tous les cas, comporter les résultats de la conduite de tests d’attaques en réidentification sur le système.
Lorsqu’un fournisseur de système d’IA intégrant un modèle d’IA non anonyme prétend que son utilisation n’est plus soumise au RGPD, la CNIL recommande de partager ou publier une documentation suffisante pour permettre à ses utilisateurs de vérifier ce statut, et ainsi démontrer qu’ils ne traitent pas de données personnelles contenues dans le modèle. Pour les fournisseurs de modèles d’IA analysés comme anonymes, partager cette analyse est une bonne pratique.
Pour la diffusion d’un modèle d’IA non anonyme par son fournisseur, les obligations applicables (y compris de documentation) seront détaillées dans une fiche ultérieure. Elles s’appliqueront aussi lorsque le modèle concerné est partagé à un tiers qui entend l’encapsuler dans un système pour le sortir du champ d’application du RGPD.
Conséquences lorsque les modèles ou système d’IA ne sont pas considérés comme anonymes
Le fournisseur d’un modèle ou d’un système d’IA soumis au RGPD devra respecter ses obligations au titre du RGPD et, en France, de la loi Informatique et libertés.
Il en ira de même pour tout acteur de la chaine (autre fournisseur de système d’IA, distributeur, déployeur, etc.) qui devra, pour les manipuler ou les utiliser, respecter les obligations RGPD.
Cela impliquera de s’assurer de la licéité du traitement, d’informer les personnes, de permettre l’exercice des droits, de garantir la sécurité du modèle, etc.
En pratique, la conformité du modèle au RGPD repose grandement sur le fournisseur, une future fiche pratique aidera les acteurs à déterminer leurs obligations. L’application de ces exigences, ainsi que le niveau des garanties associées, dépendront de la nature des données personnelles contenues dans le modèle et susceptibles d’en être extraites.
Mise en œuvre de l’analyse
Documenter la conduite de l’analyse du statut d’un modèle d’IA ou d’un système basé sur un modèle non anonyme
Cette section vise à guider le responsable de traitement dans la documentation de l’analyse du statut d’un modèle d’IA ou de l’utilisation d’un système basé sur un modèle non anonyme. Le tableau suivant fournit une liste non exhaustive d’informations à inclure dans la documentation concernant un modèle ou un système.
| Type d’infor mation |
Document | Condition pour inclure l'information dans la la documentation de l'analyse du statut | |
|---|---|---|---|
| Cas d’un modèle IA entraîné sur des données personnelles | Cas de l’utilisation d’un système d’IA basé sur modèle IA non anonyme | ||
| Gouvernance Générale | Toute information concernant une AIPD, y compris toute évaluation ou décision qui a permis de conclure que celle-ci n’était pas nécessaire | Dès que l’information existe | Dès que l’information existe |
| Tout conseil ou avis formulé par le délégué à la protection des données (DPO) (quand un DPO a ou aurait dû être désigné) | Dès que l’information existe | Dès que l’information existe | |
| Documentation concernant les risques résiduels | Inclure, le cas échéant, la documentation qu’il est prévu de transmettre au responsable de traitement déployant le système et/ou aux personnes concernées, en particulier, la documentation concernant les mesures prises pour réduire la vraisemblance de réidentification et concernant les possibles risques résiduels | Inclure, le cas échéant, la documentation qu’il est prévu de transmettre au responsable de traitement déployant le système par son fournisseur. | |
| Gouvernance Technique | Toute information sur les mesures techniques et organisationnelles prises lors de la conception pour réduire la vraisemblance de réidentification, y compris les scénarii par un ensemble large d’attaquants (du plus faible au plus fort) et l’évaluation des risques sur lesquels ces mesures sont basées. | Inclure les mesures spécifiques prises pour chaque source ou type de sources de données d’entraînement, y compris quand cela est pertinent les URLs des sources sur lesquels ces mesures ont été prises par le responsable de traitement (ou bien déjà prises par le distributeur en cas de données mises à disposition par un tiers) | Inclure les mesures spécifiques prises pour chaque source ou type de sources de données mémorisées par le modèle, y compris quand cela est pertinent les URLs des sources sur lesquels ces mesures ont été prises par le responsable de traitement (ou bien déjà prises par le distributeur en cas de modèle mis à disposition par un tiers) |
| Les mesures techniques et opérationnelles prises à toute étape du cycle de vie qui ont soit : (i) contribuées à ou ; (ii) vérifiées l’absence de données personnelles dans le modèle ou à travers l’utilisation du système. | Dès que l’information existe | Dès que l’information existe | |
| Résistance aux attaques | La documentation ex-ante démontrant la résistance théorique aux techniques de réidentification | Dès que l’information existe, pourra inclure en particulier une analyse théorique au regard de l’état de l’art (par exemple prenant en compte le ratio entre la quantité de données d’entraînement et la taille du modèle, ou qui visent à étudier la capacité intrinsèque d’un modèle à mémoriser des données) | Dès que l’information existe, pourra inclure en particulier une analyse théorique au regard de l’état de l’art (par exemple prenant en compte l’existence de techniques permettant de contourner des mesures comme des filtres sur les sorties) |
|
Les résultats des tests des attaques en réidentification ex-post :
|
Dans la plupart des cas, déterminée notamment par un faisceau d'indices. Voir ci-dessous. | Dans tous les cas. | |
Caractériser la nécessité de conduire le test d’attaques en réidentification sur un modèle d’IA
Un faisceau d’indices permet d’évaluer s’il est nécessaire de conduire un test d’attaques en réidentification pour déterminer le statut du modèle. C’est au responsable du traitement d’évaluer le risque révélé par un ou plusieurs de ces indices. Parfois, un seul indice suffit à montrer que le risque de mémorisation est élevé, mais dans d’autres cas, ce même indice peut avoir moins de poids. Il faudra alors examiner les autres critères. Cette liste d’indices est indicative et peut évoluer au regard de l’état de l’art, ainsi que de la compréhension scientifique du phénomène de mémorisation dans les modèles.
Vérifier l’absence de ces indices n’apporte pas de certitude sur l’absence de mémorisation, et ne permet jamais d’exclure le besoin d’un test d’attaques en réidentification : ils constituent des indications conduisant à considérer qu’une analyse plus poussée doit être réalisée.
Par exemple, dans le cas de l’IA générative, la régurgitation de certaines données d’entraînement, non nécessairement personnelles, peut parfois être démontrée par des tests rapides (comme des requêtes ciblées). Ce test permet de conclure positivement sur la mémorisation mais ne permet pas de l’exclure si aucune donnée n’est régurgitée. Cela vaut également pour les critères listés plus bas : lorsqu’un indice n’est pas vérifié, il ne permet pas individuellement de considérer que la vraisemblance de réidentification est suffisamment faible et les autres indices doivent également être considérés.
| Faisceaux d’indices de la présence de données personnelles dans le modèle |
|---|
| Indices portant sur le jeu de données d’entraînement |
|
Le caractère identifiant et précis des données dans le jeu d’entraînement, comme la présence de noms, prénoms, photographies du visage, extraits de voix, adresses ou dates de naissance exactes. Pour atténuer cet indice : Envisager la suppression des informations identifiantes, ou dans la mesure du possible, le recours à des techniques de généralisation, d’agrégation, de perturbation aléatoire ou de pseudonymisation des données. |
|
L’hétérogénéité des données, ou bien la présence de données rares ou aberrantes, aussi appelées outliers, correspondant à des personnes uniques ou dont les caractéristiques statistiques sont minoritaires dans la base d’entraînement. Ces données, en sortant de la distribution statistique théorique des données d’entraînement, sont plus susceptibles de causer un surapprentissage. L’entraînement du modèle aura tendance à conduire à leur mémorisation en priorité. Pour atténuer cet indice : Conduire une pré-analyse statistique du jeu de données d’entraînement afin d’identifier puis de supprimer les données rares ou aberrantes, ou bien procéder à des agrégations afin de lisser la distribution statistique des données d’entraînement. |
|
La duplication des données d’apprentissage, c’est-à-dire la présence de répétitions exactes ou approximatives dans les données d’entraînement, puisque celle-ci est souvent un facteur conduisant au surapprentissage et à la mémorisation de ces données. En étant représentées plusieurs fois dans la distribution statistique théorique des données d’entraînement, les données personnelles dupliquées auront tendance à être mémorisées en priorité. Pour atténuer cet indice : Procéder au filtrage du jeu de données d’entraînement afin d’en supprimer les doublons exacts et approximatifs par déduplication. |
| Indices portant sur l’architecture du modèle et son entraînement |
|
Le grand nombre de paramètres du modèle au regard du volume de données d’entraînement. Un plus grand nombre de paramètres aura tendance à permettre une modélisation plus fine des données d’entraînement et ainsi à l’apprentissage des caractéristiques des données et plus seulement de leur distribution statistique. Il est à noter que le seuil du nombre de paramètres indiquant un risque élevé de mémorisation est à déterminer en fonction du contexte, et notamment de la fonctionnalité du modèle ou encore du volume de données d’apprentissage. Pour atténuer cet indice : Recourir, notamment sur la base de l’état de l’art, à des modèles utilisant moins de paramètres. |
|
Un potentiel surapprentissage, par une métrique pertinente, c’est-à-dire le fait pour un modèle d’avoir appris une distribution statistique trop proche des données d’entraînement. Pour atténuer cet indice :
|
|
L’absence de garanties de confidentialité dans l’algorithme d’apprentissage, telle que la confidentialité différentielle (differential privacy). Pour atténuer cet indice : Mettre en place des mesures limitant l’impact d’une donnée sur l’apprentissage, tels que : les algorithmes permettant de garantir des niveaux de confidentialité différentielle satisfaisants (par exemple, en rajoutant du bruit au gradient dans l’optimisation de la fonction de coût du modèle). |
|
L'utilisation de données personnelles lors de l’ajustement du modèle, ou fine-tuning, et l’apprentissage par transfert, ou transfer learning. Cette phase, au même titre que l’entraînement d’un modèle ab initio, peut conduire à la mémorisation des données d’apprentissage. Pour atténuer cet indice : Envisager l’anonymisation des données d’ajustement, ou l’utilisation d’algorithmes apportant des garanties formelles de confidentialité pour l’ajustement (par exemple exprimées en termes de confidentialité différentielle) |
| Indices portant sur les fonctionnalités et usages du modèle |
|
Les fonctionnalités visant à reproduire des données similaires aux données d’entraînement, telles que la génération de contenus ou la synthèse de données textuelles. Dans le cas particulier de l’IA générative, la génération par requêtes (prompts) de données non nécessairement personnelles contenues dans le jeu d’entraînement (texte, image, audio, vidéo), se rapportant vraisemblablement aux données d’entraînement. |
| La réalisation d’attaques réussies sur le type de modèle développé dans un contexte comparable, tel que documenté par des publications scientifiques ou des articles de presse. |
Les exemples ci-dessous visent à illustrer la mise en œuvre pratique de ce faisceau d’indice :
- Un grand modèle de langage est entrainé par un organisme sur des jeux de données textuelles colossaux librement diffusés sur internet. L’organisme a réutilisé ces jeux de données tels quels, sans opérer de modification sur les contenus. La présence de données personnelles dans les jeux de données peut être suspectée étant donné la grande diversité de sources dont elles proviennent, l’absence de mesures visant à les anonymiser, ainsi que la fonctionnalité du modèle. Ce faisceau d’indices permet de conclure à la nécessité de la conduite du test d’attaques en réidentification.
- Un modèle utilisé dans le champ de la santé environnementale afin de prédire le risque pour une population exposée à certains polluants atmosphériques de développer un cancer du poumon est entraîné sur les données géographiques de patients, leurs antécédents médicaux et habitudes de vies. Certaines zones dans la région étudiée étant sous-représentées dans la base de données, les données de certains patients constituent des données rares, ou outliers, dans la distribution géographique de l’ensemble de la cohorte. Au regard du risque qu’un attaquant puisse utiliser les scores de prédiction obtenus en réalisant des inférences sur le modèle entraîné sur les données de ces personnes afin de savoir si elles ont un cancer du poumon, le critère correspondant à la présence de données rares est jugé suffisant pour considérer la conduite du test d’attaques en réidentification comme nécessaire.
- Une base de données de consommation énergétique collectée auprès de plusieurs foyers est utilisée pour entraîner un réseau de neurones à reconnaître les appareils ménagers utilisés. Si un appareil n’est trouvé que chez un petit nombre de ces foyers (il s’agit d’une donnée rare), le réseau de neurones entraîné pourrait être significativement plus confiant dans ses prédictions lorsqu’il est utilisé sur les données des foyers de la base d’apprentissage possédant l’appareil. Cette différence peut permettre de déterminer les foyers dans lesquels la collecte a eu lieu (attaque par inférence d’appartenance). Deux critères sont ici remplis : la présence de données rares et l’utilisation d’un modèle au nombre de paramètres importants. La conduite du test d’attaques en réidentification est jugée nécessaire.
Réaliser des tests d’attaques en réidentification sur un modèle d’IA
Dans la plupart des cas, notamment sur le fondement du faisceau d’indices précédent, il sera nécessaire de soumettre un modèle d’IA entraîné sur des données personnelles à des attaques en réidentification, qui peuvent constituer des moyens raisonnablement susceptibles d’être mis en œuvre pour réidentifier des personnes. Ces tests d’attaques visent à estimer la vraisemblance de réidentification de personnes physiques à partir du modèle. Pour conclure au caractère anonyme du modèle, cette vraisemblance d’extraction par des moyens raisonnables doit être insignifiante.
-
Détermination des moyens raisonnablement susceptibles d’être mis en œuvre
pour extraire des données d’un modèle d’IA
La caractérisation des moyens raisonnablement susceptibles d’être mis en œuvre par le responsable du traitement ou par toute autre personne est une étape essentielle pour conduire l’analyse du statut du modèle. Cette caractérisation doit se baser sur des critères objectifs, qui peuvent inclure :
- les informations supplémentaires qui permettraient une réidentification, et qui seraient accessibles à la personne ;
- le coût et le temps nécessaires à une telle personne pour obtenir ces informations supplémentaires ;
- l’état de l’art technologique disponible et en développement, notamment concernant les techniques d’extraction de données à partir de modèles d’IA.
L’évaluation des moyens raisonnablement susceptibles d’être mis en œuvre doit tenir compte de la possibilité d’un accès au modèle non seulement par le responsable du traitement, mais également par des tiers qui n’auraient pas dû y avoir accès. Bien que des mesures visant à réduire la vraisemblance d’extraction de données personnelles puissent être prises aussi bien durant les traitements de développement que ceux de déploiement d’un modèle d’IA, l’évaluation du caractère anonyme du modèle doit également prendre en compte la possibilité d’un accès direct à celui-ci.
La simple restriction d'accès aux données (et/ou au modèle) ne garantit pas de manière systématique leur anonymat. Cependant, un accès limité peut réduire la vraisemblance de réidentification (sans toutefois la rendre insignifiante automatiquement). En effet, les moyens raisonnablement susceptibles d’être mis en œuvre afin d’en extraire des données personnelles peuvent dépendre du contexte de développement et déploiement d’un modèle. Ainsi, les niveaux de tests et de résistance aux attaques requis peuvent varier en fonction de ce contexte. La conclusion de l’analyse peut donc être différente entre un modèle publiquement accessible à un nombre illimité d’utilisateurs et un modèle interne à une entreprise avec un accès limité à un petit nombre d’employés, comme il est détaillé dans la suite de cette fiche sur l’analyse des systèmes d’IA basés sur des modèles non anonymes.
Les critères exposés ci-dessus tiennent compte des spécificités techniques des modèles d’IA et de leur mode de conception. Ils ne seront par conséquent pas automatiquement transposables à l’analyse de l’anonymisation dans d’autres domaines. Par ailleurs, les garanties juridiques et contractuelles visant à limiter l’accès ou l’usage d’un modèle ne remplacent pas les techniques d’anonymisation qui pourraient être mises en place sur le jeu de donnée d’entraînement ou lors de la phase d’apprentissage, mais les complètent.
-
Test du modèle d’IA et résistance aux attaques
La liste suivante fournit des critères pouvant permettre d’apprécier la vraisemblance d’extraction à partir de techniques d’attaques de données personnelles d’un modèle d’IA entraîné sur de telles données.
La pertinence de l’étendue, la fréquence, la quantité et la qualité des tests d’extraction de données que le responsable de traitement a menés sur le modèle doivent s’évaluer au regard de l’état de l’art, ainsi que des moyens raisonnablement susceptibles d’être mis en œuvre vis-à-vis du modèle. Ces tests peuvent inclure notamment :
- Des tests de régurgitation de données d’entraînement, dans le cas de modèles d’IA générative ;
- Des attaques par inférence d’appartenance ;
- Des attaques par exfiltration ;
- Des attaques par inversion de modèle ;
- Des attaques par reconstruction ;
- Une mesure de la capacité intrinsèque de mémorisation de l’architecture du modèle.
Il faut noter que la résistance à une technique implémentant une de ces types d’attaque ne saurait préjuger d’une résistance à une autre technique.
-
Recommandations concernant le déroulement de la conduite des tests et attaques
Certains types d’attaques présentées plus haut nécessitent des connaissances et des ressources techniques exigeantes pour être mises en œuvre. Il est donc recommandé de mener les attaques sur le modèle d’IA par difficulté d’implémentation croissante. Lorsqu’une attaque permet l’extraction de données personnelles du modèle d’IA, il faut alors déterminer quelle typologie de données personnelles est concernée par cette extraction. Le responsable de traitement peut alors, au choix :
- Arrêter l’analyse à ce stade, en considérant que toutes les typologies de données présentes dans le jeu d’entraînement peuvent être extraites avec la vraisemblance donnée par l’attaque la plus facile ayant réussi sur une typologie particulière ;
- Poursuivre l’analyse en conduisant tous les tests et attaques constituant des moyens raisonnablement susceptibles d’être mis en œuvre, afin d’établir la vraisemblance d’extraction associée à chaque typologie de données d’entraînement. Approfondir les tests en réidentification peut par exemple permettre de séparer la vraisemblance d’extraction des données de pré-entraînement et d’ajustement, qui peuvent présenter des risques différents pour les personnes concernées.
- Arrêter la conduite de l’analyse, en considérant dans les conséquences de l’application du RGPD que toutes les typologies de données d’entraînement, y compris les données sensibles issues de la phase d’ajustement mais qui n’ont pas été extraites à ce stade de l’analyse, peuvent être extraites du modèle avec des attaques simples, et donc, une vraisemblance haute ;
- Poursuivre la conduite de l’analyse à l’aide d’attaques plus difficiles à mettre en œuvre, afin d’évaluer précisément la vraisemblance d’extraction des données sensibles, pour affiner l’analyse des conséquences de l’application du RGPD. Les garanties à mettre en œuvre ne seront effectivement pas les mêmes selon que les données personnelles contenues dans le modèle sont des données publiquement accessibles par ailleurs, ou des données confidentielles et sensibles issues de la phase d’ajustement.
À l’issue de la conduite de cette analyse, le responsable de traitement est donc en mesure de caractériser si le RGPD s’applique à son modèle. Si cela s’avère être le cas, des conséquences diverses peuvent s’ensuivre. Une future fiche pratique viendra préciser les conséquences de l’application du RGPD à traitement concernant un modèle d’IA prochainement.
Réduire la vraisemblance de réidentification à partir d’un système d’IA basé sur un modèle non anonyme
Quand un système d’IA est basé sur un modèle d’IA qui entre dans le champ d’application du RGPD, il est possible de mettre en place des mesures, qui, si elles sont suffisamment efficaces et robustes, pourraient permettre de rendre insignifiante la vraisemblance de réidentification de personnes. L’utilisation de ce dernier pourrait alors sortir du champ d’application du RGPD, sous réserve des résultats de l’analyse qui doit être menée. Pour ce faire, le fournisseur du système d’IA qu’il envisage de rendre anonyme devra évaluer la vraisemblance de réidentification, notamment à partir de tests d’attaques sur celui-ci. Cette partie vise à guider cette analyse.
La liste suivante détaille des mesures susceptibles de diminuer la vraisemblance de réidentification à partir d’un système d’IA intégrant un modèle pour lequel cette vraisemblance n’est pas insignifiante. Cette liste est indicative, et ne préjuge pas de l’existence d’autres mesures suffisamment robustes permettant d’atténuer cette vraisemblance.
| Mesures réduisant la vraisemblance de réidentification au niveau d'un système |
|---|
| Impossibilité d’accès direct ou de récupération du modèle à partir d’interactions avec le système. Il doit être impossible pour tout utilisateur du système, même malveillant, d’accéder directement au modèle ou de le récupérer à l’aide de moyens raisonnablement susceptibles d’être mis en œuvre. |
|
Les restrictions d’accès au système, comme par exemple :
|
|
Les modifications apportées aux sorties du modèle permettant de limiter le risque de réidentification de personnes à partir d’un accès au système par ses utilisateurs. Il est possible par exemple de :
|
|
Les mesures de sécurité visant à empêcher ou à détecter des tentatives d’attaques, comme le chiffrement du modèle, la journalisation des accès, modifications et utilisations du modèle, ou encore l’utilisation de méthodes d’authentification forte. |
Réaliser des tests d’attaque en réidentification sur un système d’IA basé sur un modèle non anonyme
Ces tests visent à estimer la vraisemblance d’extraction de données personnelles à partir d’une utilisation du système, et de tout moyen raisonnablement susceptible d’être mis en œuvre, y compris des méthodes d’attaques dont le résultat est probabiliste. Pour considérer que l’utilisation du système d’IA ne relève pas du RGPD, cette vraisemblance d’extraction doit être insignifiante.
-
Détermination des moyens raisonnablement susceptibles d’être mis en œuvre
pour extraire des données d’un système d’IA
Comme pour l’analyse du statut des modèles, la caractérisation des moyens raisonnablement susceptibles d’être mis en œuvre est une étape essentielle pour conduire l’analyse du statut de l’utilisation du système. Cette caractérisation doit se baser sur des critères objectifs, qui peuvent inclure :
- le contexte dans lequel le système d’IA est déployé, ce qui peut inclure les limitations d’accès ainsi que les protections juridiques ;
- l’étendue de l’accès au fonctionnement interne du modèle à travers une utilisation du système ;
- les informations supplémentaires qui permettraient une réidentification, et qui seraient accessibles à la personne, y compris au-delà des sources publiquement accessibles ;
- le coût et le temps nécessaires à une telle personne pour obtenir ces informations supplémentaires ;
- l’état de l’art technologique disponible et en développement, notamment concernant les techniques d’extraction de données à partir des systèmes d’IA.
L’évaluation des moyens raisonnablement susceptibles d’être mis en œuvre doit tenir compte de la possibilité d’un accès au système par toute personne, en considérant le cas de personnes qui n’auraient pas dû y avoir accès. Il est à noter que la simple restriction d'accès au modèle et/ou au système ne garantit pas de manière systématique leur anonymat. Un accès limité peut réduire la vraisemblance de réidentification (sans toutefois la rendre insignifiante automatiquement).
Par ailleurs, les garanties juridiques et contractuelles visant à limiter l’accès ou l’usage d’un modèle ne remplacent pas les techniques d’anonymisation, mais peuvent les compléter. Ainsi, les niveaux de tests et de résistance aux attaques requis peuvent varier en fonction de ce contexte. La conclusion de l’analyse peut donc être différente entre un système d’IA publiquement accessible à un nombre illimité d’utilisateurs et un système interne à une entreprise avec un accès limité à un petit nombre d’employés, bien que cette mesure ne saurait se substituer à la minimisation de la vraisemblance d’extraction de données personnelle à partir du modèle.
-
Test du système d’IA et résistance aux attaques
Cette partie vise à guider l’évaluation de la vraisemblance de réidentification par des attaques, à travers une utilisation du système par toute personne.
La pertinence de l’étendue, la fréquence, la quantité et la qualité des tests d’extraction de données que le responsable de traitement a menés sur le système doit s’évaluer au regard de l’état de l’art, ainsi que des moyens raisonnablement susceptibles d’être mis en œuvre pour réidentifier des personnes à partir d’une utilisation du système, y compris dans un futur proche. Ces tests peuvent inclure notamment :
- Des tests visant à obtenir un accès partiel ou direct au modèle d’IA à travers l’utilisation du système ;
- Des tests de régurgitation de données d’entraînement, dans le cas de modèles d’IA générative ;
- Des attaques par inférence d’appartenance ;
- Des attaques par exfiltration ;
- Des attaques par inversion de modèle ;
- Des attaques par reconstruction.
Il faut noter que la résistance à une technique implémentant un de ces types d’attaque ne saurait préjuger d’une résistance à une autre technique.
-
Recommandations concernant le déroulement de la conduite des test et attaques
Certains types d’attaques présentées plus haut nécessitent des connaissances et des ressources techniques exigeantes pour être mises en œuvre. Il est donc recommandé de mener les attaques sur le système d’IA par difficulté d’implémentation croissante. Lorsqu’une attaque permet l’extraction de données personnelles du système d’IA, il faut alors déterminer quelle typologie de données personnelles est concernée par cette extraction. Le responsable de traitement peut alors, au choix :
- Arrêter l’analyse à ce stade, en considérant que toutes les typologies de données présentes dans le modèle peuvent être extraites avec la vraisemblance donnée par l’attaque la plus facile ayant réussi sur une typologie particulière ;
- Poursuivre l’analyse en conduisant tous les tests et attaques constituant des moyens raisonnablement susceptibles d’être mis en œuvre, afin d’établir la vraisemblance d’extraction associée à chaque typologie de données d’entraînement. Approfondir les tests en réidentification peut par exemple permettre de séparer la vraisemblance d’extraction des données de pré-entraînement et d’ajustement, qui peuvent présenter des risques différents pour les personnes concernées.
Cas où les modèles d’IA ou les systèmes qui les intègrent sont exclus à tort du champ du RGPD
Une réidentification de personnes physiques depuis un modèle peut se matérialiser alors que son fournisseur avait considéré sa vraisemblance comme insignifiante, par exemple si celui-ci ignorait une vulnérabilité ou du fait de l’évolution des techniques d’extraction de données.
Pour cette raison, au titre de leurs obligations de sécurité, la CNIL recommande aux fournisseurs de veiller régulièrement à la validité de leur analyse (en prenant notamment en compte l’évolution de l’état de l’art), et d’anticiper les éventuelles violations de données susceptibles de survenir.
Une bonne pratique consiste à prévoir des modalités de remontée d’information par les utilisateurs en cas d’incident (par exemple à travers une fonctionnalité au sein de l’interface du système ou au moyen d’un formulaire de contact, une gestion des versions des modèles). Cette pratique est complémentaire des obligations du règlement européen sur l’IA (RIA) qui prévoient une surveillance des fournisseurs après la mise sur le marché pour les systèmes d'IA à haut risque (article 72 du RIA) et une remontée de ces risques par les déployeurs de tels systèmes (article 26 du RIA).
Lorsqu’une extraction de données personnelles a lieu, il convient d’empêcher toute exploitation de la vulnérabilité, et, lorsque cela est possible, d’examiner si la vulnérabilité de réidentification a été exploitée, et par qui. Le fournisseur devra aussi envisager s’il s’agit d’une violation de données (au sens de l’article 33 du RGPD) et d’en tirer les conséquences, en particulier de documenter cette violation de données (notamment sur la nature des données, le mode de distribution et les conséquences qui en résultent), notifier la CNIL dans les 72 heures si cette violation est susceptible d’engendrer des risques pour les personnes, voire d’informer les personnes si les risques en question sont élevés (article 34 du RGPD), en documentant.
En fonction de la gravité de l’incident, et des éventuels manquements au RGPD qui en résulteraient, la CNIL pourrait exiger le ré-entraînement ou la suppression du modèle en cause.
