- EDSA : un système IA, y compris LLM, n’est pas anonyme en soi ; l’anonymat doit être évalué au cas par cas en fonction de facteurs techniques, de conception et de gouvernance.
- Les exploitants et les responsables en aval ont des obligations élevées en matière de vérification et de documentation ; ils doivent démontrer que les modèles n’ont pas été développés par un traitement illicite.
Le Comité européen de la protection des données a adopté, en date du 17 décembre 2024, une Avis 28/2024 sur certains aspects de la protection des données liés au traitement des données à caractère personnel dans le cadre des modèles IA publiée.
L’autorité de contrôle irlandaise avait demandé au CEPD de rendre un avis sur des questions de portée générale concernant le traitement des données personnelles au cours des phases de développement et de mise en œuvre des modèles d’IA, en particulier
- quand et comment un modèle d’IA peut être considéré comme “anonyme”.
- comment les responsables de traitement peuvent démontrer l’intérêt légitime comme base juridique dans la phase de développement et de déploiement ; et
- quelles sont les conséquences d’un traitement illicite lors de la phase de développement sur l’exploitation du modèle.
L’avis, quelque peu long, ne veut ni ne peut répondre à ces questions de manière exhaustive, mais il vise à fournir un cadre aux autorités de contrôle. Elle ne traite pas non plus des questions liées aux données personnelles sensibles, aux décisions individuelles automatisées, à la conformité aux finalités selon l’article 6, paragraphe 4, du RGPD, aux analyses d’impact sur la protection des données et au principe de privacy by design.
Le message clé de l’EDSA est intéressant et convaincant, à savoir que un système AI – même un LLM – n’est pas per se est anonymeIl ne s’agit pas d’une obligation légale, mais de vérifier au cas par cas, selon les critères connus, si des données personnelles peuvent être extraites ou communiquées lors de l’exploitation.
Il apparaît également clairement que le développement et l’utilisation d’un LLM en conformité avec le droit sont exigeants. Cela vaut en particulier en raison des obligations de documentation ou du principe de responsabilité, mais aussi en raison des exigences élevées en matière de transparence lors de l’utilisation des données personnelles et de la Responsabilité de l’exploitant (déployeur) d’un système IADans la mesure où un système n’est pas anonyme, il doit vérifier de manière appropriée que le système ou le modèle n’a pas été développé par un traitement illicite. Il ne suffit pas de se fier à la déclaration de conformité du fournisseur d’accès requise par l’AI Act.
Dans une première section, l’EDSA clarifie son Compréhension de certains termes telles que les First-Party Data (données collectées directement) et les Third-Party Data (données collectées par des tiers). La compréhension des systèmes d’intelligence artificielle (AIS) et des modèles d’intelligence artificielle (AIM) est également abordée, mais malheureusement sans définir ces termes plus précisément au sens de l’AI Act (voir à ce sujet notre FAQ). Dans l’Opinion, il ne s’adresse toutefois qu’aux modèles qui sont entraînés avec des données personnelles.
Un LLM peut contenir des données personnelles
Sur le point âprement discuté de savoir si un AIM, et en particulier un LLM, contient des données personnelles (à ce sujet voir ici), l’EDSA dit ceci :
Tout d’abord, certains AIM sont conçus pour faire des déclarations sur des personnes spécifiques – ils ne sont certainement pas anonymes :
… certains modèles d’IA sont spécialement conçus pour fournir des données personnelles concernant les individus dont les données personnelles ont été utilisées pour former le modèle ou, d’une manière ou d’une autre, pour rendre de telles données disponibles. Dans ces cas, ces modèles d’IA incluront de manière inhérente (et typiquement nécessaire) des informations relatives à une personne physique identifiée ou identifiable… ces types de modèles IA ne peuvent pas être considérés comme anonymes. Ce serait le cas, par exemple, (i) d’un modèle génératif finement réglé sur les enregistrements vocaux d’un individu pour mimer sa voix ; ou (ii) de tout modèle conçu pour répondre avec des données personnelles issues de la formation lorsqu’on lui demande des informations sur une personne spécifique.
Mais d’autres AIM, qui ne sont pas conçus dans ce but, ne sont pas non plus fondamentalement anonymes, car l’extraction de données d’entraînement personnelles n’est pour le moins pas à exclure. Cela dépend donc de la Cas individuel à l’égard de l’entreprise. Ce qui est déterminant, c’est la possibilité de de mettre en valeur le contenu informatif:
… pour qu’une SA puisse convenir avec le contrôleur qu’un modèle d’IA donné peut être considéré comme anonyme, elle doit au moins vérifier qu’elle a reçu des preuves suffisantes que, par des moyens raisonnables : (i) des données à caractère personnel, relatives aux données de formation, ne peut pas être extraite du modèleet (ii) toute sortie produite lors de la requête le modèle ne concerne pas les sujets de données dont les données personnelles ont été utilisées pour entraîner le modèle.
Cela nécessite probablement une examen approfondi en tenant compte notamment des facteurs suivants :
- les caractéristiques des données de formation, de l’AIM et de la méthode de formation
- le contexte de publication ou d’exploitation de l’AIM
- toute information supplémentaire accessible permettant l’identification
- le coût et le temps nécessaires à l’obtention de ces informations supplémentaires
- la technologie disponible et les développements technologiques
- qui a accès à l’AIM
- Mesures pour garantir l’anonymat
Il convient d’examiner les spécificités de l’AIM, tout d’abord Questions de design:
- Les données d’entrée utilisées
- la préparation de ces données, y compris une pseudonymisation ou un filtrage des données personnelles en amont de l’entraînement, le cas échéant
- la procédure de développement, en particulier les techniques de protection de la vie privée telles que la protection différentielle de la vie privée (Differential Privacy)
- Mesures dans le modèle lui-même pouvant contribuer à réduire l’extraction de données personnelles
Au niveau de la Gouvernance chez le développeur il faut ensuite tenir compte du fait que les mesures prises ont été mises en œuvre et contrôlées de manière robuste. Enfin, il convient également d’examiner comment l’AIM testé et, plus généralement, la Documentation chez le développeur ; pour ce qui est de leur objet, on trouvera d’autres indications dans l’Opinion.
Intérêt légitime
L’AESP rappelle tout d’abord les principes généraux et les exigences du RGPD, dans la mesure où une référence aux personnes n’est pas exclue, notamment aussi la question de la transparence ou de l’information et de la limitation des finalités. En ce qui concerne la base juridique de l’intérêt légitime (article 6, paragraphe 1, point f), du RGPD), l’AESD rappelle qu’elle doit a priori ne peut justifier que les traitements nécessaires à la réalisation de l’intérêt, ce qui implique une Contrôle de proportionnalité (voir à ce sujet CJCE, affaire C‑621/22).
Au final, il y a une mise en balance des intérêts, et ici les références au contexte d’un LLM restent vagues. L’EDSA mentionne toutefois des risques lors d’un entraînement à grande échelle (il pense alors au scraping) :
Par exemple, la collecte de données à grande échelle et sans discrimination par des modèles d’IA au cours de la phase de développement peut créer une sens de la surveillance pour les sujets de données, en particulier compte tenu des difficultés à empêcher les données publiques d’être scannées. Cela peut conduire les individus à s’autocensurer, et présente des risques d’atteinte à leur liberté d’expression […].
Sur le site Utilisation d’un AIM ou d’un AIS, il faut tenir compte de l’objectif ; les systèmes de filtrage ou de recommandation, les systèmes qui peuvent entraver l’accès au travail ou avoir un effet discriminatoire et les systèmes qui sont même utilisés de manière malveillante sont par exemple potentiellement délicats.
Mais il faut aussi tenir compte du fait qu’un Agir positivement sur l’AIS peut, par exemple, supprimer des contenus nuisibles ou faciliter l’accès à l’information.
L’EDSA mentionne d’autres facteurs qui doivent être pris en compte, par exemple le type de données ou leur volume et les attentes des personnes concernées, mais reste assez vague. Un point est toutefois intéressant :
Le site Attentes des personnes concernées peuvent influencé par une déclaration de confidentialité de la protection des données. C’est ce qu’a déclaré la Conférence allemande sur la protection des données dans la Orientation sur le publipostage (“les attentes de la personne concernée ne peuvent pas être élargies par les informations obligatoires prévues par le RGPD”). Toutefois, il ne suffit pas nécessairement de mentionner dans une déclaration de protection des données la possibilité d’utiliser des données personnelles à des fins de formation. Par exemple, les personnes concernées ne sont pas nécessairement conscientes que les données personnelles sont utilisées pour adapter les réponses d’un AIS à leurs besoins et pour offrir des services sur mesure – en d’autres termes, l’AESA attend un peu plus de contexte dans les informations relatives à la protection des données.
Mesures d’atténuation
Enfin, l’EDSA cite – parfois de manière redondante – des mesures susceptibles de réduire les risques pour les personnes concernées :
- Mesures techniques qui, dans l’idéal, permettent même d’obtenir l’anonymat
- Mesures au niveau des données d’entrée et de la conception du modèle
- Pseudonymisation
- Masquage (remplacement par des données fictives, par exemple des faux noms)
- Mesures de protection des droits des personnes concernées :
- l’intervalle de temps entre la collecte et l’utilisation des données personnelles
- Droit d’opt-out
- Accorder le droit à l’effacement en dehors de l’art. 17 RGPD
- Mesures pour “désapprendre” les données personnelles
- Transparence :
- fournir des informations supplémentaires sur les sources et la sélection des données
- Information par le biais de campagnes médiatiques, de présentations visuelles, de FAQ et de rapports de transparence, par exemple.
- dans le cadre du web scraping :
- Exclusion des données sensibles
- Exclusion de données de sites web sensibles
- prise en compte automatisée des contradictions de scraping
- Limitations de la collecte de données en fonction du temps et de la source
- Droit d’opt-out par le biais de listes correspondantes
- dans l’entreprise :
- Protection contre la reproduction de données personnelles par des filtres
- protection contre la réutilisation (par ex. par watermarking)
- Faciliter les droits des personnes concernées (effacement et suppression des données personnelles)
Effet de l’absence de base juridique pendant la phase d’entraînement
Dans une autre section, l’EDSA aborde la question de savoir si et comment l’absence de base juridique – pendant la phase de formation – affecte les opérations en aval. A cet égard, l’EDSA distingue des scénarios :
Scénario 1 – Utilisation par le même responsable:
- Si un responsable utilise illégalement des données personnelles pour le développement d’un AIM et qu’il utilise ensuite lui-même les données du modèle, par exemple lors de la mise à disposition du modèle, il convient d’examiner au cas par cas la question de la protection des données. de se demander si les phases de développement et d’exploitation ont des objectifs distincts. et constituent donc des activités de traitement distinctes.
- En cas d’examen séparé, l’illégalité du premier traitement doit être “prise en compte” lors de l’examen de l’intérêt légitime dans la phase d’exploitation – l’EDSA ne statue donc pas d’interdiction per se.
Scénario 2 – Traitement ultérieur par un autre responsable du traitement:
- Dans ce cas, il convient tout d’abord de définir clairement les rôles et les responsabilités des parties, et d’envisager une responsabilité commune. Cela doit être réglé par contrat.
- De même, il convient d’examiner au cas par cas l’effet du traitement illicite lors de l’entraînement. Le deuxième responsable qui intervient doit vérifier de manière appropriée (Accountability) que l’AIM n’est pas développé par un traitement illicite a été fait. En d’autres termes, l’EDSA impose au client du fournisseur une tâche de vérification sans aucun doute exigeante dans la pratique. En particulier, il peut ne pas être suffisant de se fier uniquement à la déclaration de conformité requise par l’AI Act (!).
Scénario 3 – Développement illicite suivi de l’anonymisation et du traitement par le même responsable ou un autre :
- Dans la mesure où le modèle est réellement anonyme, le RGPD ne s’y applique pas.
- Le RGPD s’applique si, par la suite, des données personnelles sont à nouveau traitées. Une illégalité initiale n’a cependant pas d’effet sur ce nouveau traitement.