Développement des systèmes d’IA : les recommandations de la CNIL pour respecter le RGPD

En pratique

Il existe trois types de situations.

Vous savez clairement quel sera l’usage opérationnel de votre système d’IA

Dans ce cas, cet objectif sera la finalité de la phase de développement comme de la phase de déploiement et d’utilisation.

Cela est toutefois plus complexe lorsque vous développez un système d’IA à usage général qui pourra être utilisé dans divers contextes et applications ou lorsque votre système est développé à des fins de recherche scientifique.

Pour les systèmes d’IA à usage général

Vous ne pouvez pas définir la finalité de manière trop générale comme, par exemple, « le développement et amélioration d’un système d’IA ». Il vous faudra être plus précis et faire référence :

• au « type » de système développé, comme, par exemple, le développement d’un modèle de langage de grande taille, d’un système de vision par ordinateur (computer vision) ou encore d’un système d’IA générative d’images, de vidéos, de sons, de code informatique, etc.
• aux fonctionnalités et capacités techniquement envisageables.

Bonne pratique :

Vous pouvez donner encore plus de précisions quant à l’objectif poursuivi, par exemple en déterminant :

• les capacités prévisibles les plus à risque ;
• les fonctionnalités exclues par conception ;
• les conditions d’utilisation du système d’IA : les cas d’usage connus de la solution ou encore les modalités d’utilisation (diffusion du modèle en open source, commercialisation, mise à disposition en SaaS ou par API, etc.).

Pour les systèmes d’IA développés à des fins de recherche scientifique

Vous pouvez définir un objectif moins détaillé, compte tenu des difficultés à le définir précisément dès le début de vos travaux. Vous pouvez alors fournir des informations complémentaires pour préciser cet objectif à mesure que votre projet progresse.

► Pour plus d’informations, voir la fiche n° 2

En pratique

Le règlement européen sur l’IA définit plusieurs rôles :

• le fournisseur de système d’IA qui développe ou fait développer un système et qui le met sur le marché ou le met en service sous son propre nom ou sa propre marque, à titre payant ou gratuit ;
• les importateurs, distributeurs et les utilisateurs (également appelés déployeurs) de ces systèmes.

Votre degré de responsabilité dépend d’une analyse au cas par cas. Par exemple :

• Si vous êtes un fournisseur à l’initiative du développement d’un système d’IA et que vous constituez la base de données d’apprentissage à partir de données que vous avez sélectionnées pour votre propre compte, vous pouvez être qualifié de responsable de traitement.
• Si vous constituez la base de données d’apprentissage d’un système d’IA avec d’autres responsables de traitement pour un objectif que vous avez défini ensemble, vous pouvez être qualifiés de responsables conjoints du traitement.
• Si vous êtes un fournisseur de système d’IA, vous pouvez être sous-traitant si vous développez un système pour le compte d’un de vos clients. Le client sera responsable de traitement s’il détermine l’objectif mais aussi les moyens, les techniques à utiliser. S’il ne vous donne qu’un objectif à atteindre et que c’est vous qui concevez le système d’IA, vous êtes responsable de traitement.
• Si vous êtes un fournisseur de système d’IA vous pouvez faire appel à un prestataire pour collecter et traiter les données selon vos instructions. Le prestataire sera votre sous-traitant. C’est le cas par exemple du prestataire qui doit constituer une base de données d’apprentissage pour un fournisseur de système d’IA qui lui indique précisément comment elle doit être élaborée.

► Pour plus d’informations, voir la fiche n° 3

Pour la suite :

• Si vous êtes responsable de traitement, toutes les étapes suivantes vous concernent directement, c’est vous qui êtes tenus d’en assurer le respect.
• Si vous êtes sous-traitant, vos principales obligations sont les suivantes :
  • Vous assurer qu’un contrat de sous-traitance de données personnelles a été conclu et qu’il est conforme à la réglementation ;
  • Respecter strictement les instructions du responsable de traitement et ne pas utiliser les données personnelles pour autre chose ;
  • Assurer rigoureusement la sécurité des données que sous traitez ;
  • Evaluer à votre niveau le respect du RGPD (cf. les étapes suivantes) et alerter le responsable de traitement s’il vous semble qu’il y a un problème.

En pratique

Vous devez vous interroger sur la base légale la plus adaptée à votre situation.

Si vous collectez les données directement auprès des personnes et qu’elles sont libres d’accepter ou de refuser sans subir de préjudice (tel que le fait de renoncer au service), le consentement est souvent la base légale la plus appropriée. Selon la loi, il doit être libre, spécifique, éclairé et univoque.

Recueillir le consentement est cependant souvent impossible en pratique. Par exemple, lorsque vous collectez des données accessibles en ligne ou réutilisez une base de données ouverte (open source), sans contact direct avec les personnes concernées, d’autres bases légales seront, généralement, plus adaptés :

• Les acteurs privés devront analyser s’ils respectent les conditions pour se fonder sur l’intérêt légitime. Ils doivent pour cela justifier de trois conditions :
  • l’intérêt poursuivi est légitime c’est-à-dire légal, défini de manière précise et réel ;
  • il faut pouvoir établir que les données personnelles sont vraiment nécessaires à l’entraînement du système, parce qu’il n’est pas possible de n’utiliser que des données ne se rapportant pas à des personnes physiques ou des données anonymisées. ;
  • l’utilisation de ces données personnelles ne doit pas porter une « atteinte disproportionnée » à la vie privée des personnes. Cela s’apprécie au cas par cas, en fonction de ce que révèlent les données utilisées, qui peut être plus ou moins privé ou sensible, et de ce qui est fait des données. ;

À noter : une fiche pratique spécifique à la base légale de l’intérêt légitime sera prochainement publiée.

• Les acteurs publics doivent vérifier si le traitement s’inscrit dans leur mission d’intérêt public telle que prévue par un texte (par exemple une loi, un décret, etc.) et s’il y contribue de manière pertinente et appropriée.

Les bases légales du contrat et de l’obligation légale peuvent être plus exceptionnellement mobilisées, si vous démontrez en quoi votre traitement est nécessaire pour répondre à l’exécution du contrat ou de mesures précontractuelles ou à une obligation légale (suffisamment précise) à laquelle vous êtes soumis.

► Pour plus d’informations, voir la fiche n° 4

 En pratique

Les règles vont dépendre des situations.

Le fournisseur réutilise des données qu’il a lui-même déjà collectées

Vous pouvez vouloir réutiliser les données que vous avez initialement collectées pour un autre objectif. Dans ce cas, si vous n’aviez pas prévu et informé les personnes concernées de cette réutilisation, vous devez vérifier que ce nouvel usage est compatible avec l’objectif initial, sauf si vous êtes autorisé par les personnes concernées (elles ont consenti) ou par un texte (par exemple une loi, un décret etc.).

Vous devez effectuer ce qu’on appelle un « test de compatibilité », qui doit prendre en compte :

• l’existence d’un lien entre l’objectif initial et celui de constitution de base de données pour l’apprentissage d’un système d’IA ;
• le contexte dans lequel les données personnelles ont été collectées ;
• le type et la nature des données ;
• les éventuelles conséquences pour les personnes concernées ;
• l’existence de garanties appropriées (par exemple, la pseudonymisation des données).

À noter : si vous souhaitez réutiliser des données dans un objectif de production de statistiques ou de recherche scientifique, le traitement est présumé compatible avec l’objectif initial. Aucun test de compatibilité n’est donc nécessaire dans ce cas.

Le fournisseur réutilise des données publiquement accessibles (open source)

Dans ce cas, vous devez vous assurer que vous n’êtes pas en train de réutiliser une base de données dont la constitution était manifestement illicite (par exemple, provenant d’une fuite de données). Une analyse au cas par cas doit être effectuée.

La CNIL recommande aux réutilisateurs de vérifier et de documenter (par exemple, dans l’analyse d’impact sur la protection des données) les éléments suivants :

• la description de la base de données mentionne leur source ;
• la constitution ou la diffusion de la base de données ne résulte pas manifestement d’un crime ou d’un délit ou a fait l’objet d’une condamnation ou d’une sanction publique de la part d’une autorité compétente qui a impliqué une suppression ou une interdiction d’exploitation ;
• il n’y a pas de doutes flagrants sur le fait que la base de données est licite en s’assurant en particulier que les conditions de collecte des données soient suffisamment documentées ;
• la base de données ne contient pas de données sensibles (données de santé ou révélant des opinions politiques par exemple) ou de données d’infraction ou, si elle en contient, il est recommandé de mener des vérifications supplémentaires pour s’assurer que ce traitement est licite.

L’organisme qui a mis en ligne la base de données est censé s’être assuré que cette publication respectait le RGPD, et en est responsable. En revanche, vous n’avez pas à vérifier que les organismes qui ont constitué et diffusé la base de données aient respecté toutes les obligations prévues par le RGPD : la CNIL estime que les quatre vérifications mentionnées ci-dessus suffisent généralement à permettre la réutilisation de la base pour l’entraînement d’un système d’IA, à condition de respecter les autres recommandations de la CNIL. Si vous recevez des informations, notamment de personnes dont les données sont contenues dans la base, qui mettent en lumière des problèmes de licéité de la base de données utilisées, vous devrez investiguez davantage.

Le fournisseur réutilise des données acquises auprès d’un tiers (courtiers en données ou data brokers, etc.)

Pour le tiers qui partage des données personnelles, parfois contre rémunération, il existe deux types de situations.

Soit le tiers a collecté les données dans l’objectif de constituer une base de données pour l’apprentissage de système d’IA. Il doit s’assurer de la conformité du traitement de transmission des données au regard du RGPD (définition d’un objectif explicite et légitime, exigence d’une base légale, information des personnes et gestion de l’exercice de leurs droits, etc.).

Soit le tiers n’a pas initialement collecté les données pour cet objectif. Il doit alors s’assurer que la transmission de ces données poursuit un objectif compatible avec celui ayant justifié leur collecte. Il devra donc réaliser le « test de compatibilité » présenté plus haut.

Le réutilisateur des données a, quant à lui, plusieurs obligations :

• Il doit s’assurer qu’il n’est pas en train de réutiliser une base de données manifestement illicite en faisant les mêmes vérifications que celles énoncées dans la partie ci-dessus. La conclusion d’un accord entre le détenteur initial des données et le réutilisateur est recommandée afin de faciliter ces vérifications.
• En plus de ces vérifications, il doit s’assurer de sa propre conformité au RGPD dans le traitement de ces données.

► Pour plus d’informations, voir la fiche n° 4

En pratique

La méthode à employer

Vous devez privilégier la technique permettant d’atteindre le résultat recherché (ou du même ordre) en utilisant le moins de données personnelles possible. En particulier, le recours à l’apprentissage profond ne doit donc pas être systématique.

Le choix du protocole d’apprentissage utilisé peut, par exemple, permettre de limiter l’accès aux données aux seules personnes habilitées, ou encore de ne donner accès qu’à des données chiffrées.

La sélection des données strictement nécessaires

Le principe de minimisation n’interdit pas d’entraîner un algorithme avec des volumes très importants de données, mais implique :

• d’avoir une réflexion en amont afin de recourir aux seules données personnelles utiles au développement du système ; et
• à mettre, par la suite, en œuvre les moyens techniques pour ne collecter que celles-ci.

La validité des choix de conception

Afin de valider les choix de conception, il est recommandé à titre de bonne pratique de :

• mener une étude pilote, c’est-à-dire réaliser une expérimentation à petite échelle. Des données fictives, synthétiques, anonymisées peuvent être utilisées à cette fin ;
• interroger un comité éthique (ou un « référent éthique »). Ce comité doit garantir que les enjeux en matière d’éthique et de protection des droits et libertés des personnes sont bien pris en compte. Il peut ainsi formuler des avis sur tout ou partie des projets, outils, produits, etc. de l’organisme susceptibles de poser des problématiques éthiques.

L’organisation de la collecte

Vous devez vous assurer que les données collectées sont pertinentes compte tenu des objectifs poursuivis. Plusieurs étapes sont fortement recommandées :

• Le nettoyage des données : cette étape vous permet de constituer une base d’apprentissage de qualité et ainsi renforcer l’intégrité et la pertinence des données en réduisant les incohérences, et ainsi que le coût de l’apprentissage.
• L’identification des données pertinentes : cette étape vise à optimiser les performances du système tout en évitant les sous- et sur-apprentissage. En pratique, elle vous permet de vous assurer que certaines classes ou catégories inutiles pour la tâche visée ne sont pas représentées, que les proportions entre les différentes classes d’intérêt sont bien équilibrées, etc. Cette procédure vise également à identifier les données non pertinentes pour l’apprentissage (qui devront alors être supprimées de la base).
• La mise en œuvre de mesures pour intégrer dès leur conception les principes de protection des données personnelles : cette étape vous permet d’appliquer des transformations sur les données (telles que des mesures de généralisation et/ou de randomisation, anonymisation des données, etc.) pour limiter l’impact pour les personnes.
• Le suivi et la mise à jour des données : les mesures de minimisation pourraient devenir obsolètes au cours du temps. En effet, les données collectées pourraient perdre leurs caractères exact, pertinent, adéquat et limité, en raison d’une possible dérive des données, d’une mise à jour de celles-ci ou de l’évolution des techniques. Vous devrez donc conduire une analyse régulière pour assurer le suivi de la base de données constituée.
• La documentation des données utilisées pour le développement d’un système d’IA : celle-ci vous permet de garantir la traçabilité des jeux de données utilisés que la grande taille peut rendre difficile. Vous devez tenir cette documentation à jour en fonction des modifications apportées à la base de données. La CNIL fournit ici un modèle de documentation.

► Pour plus d’informations, voir les fiches n° 6 et n°7

En pratique

Vous devez fixer une durée de conservation des données utilisées pour le développement du système d’IA :

• Pour la phase de développement : la conservation des données doit faire l’objet d’une planification en amont et d’un suivi dans le temps. Les personnes concernées doivent être informées de la durée de conservation des données (par exemple dans les mentions d’information) ;
• Pour la maintenance ou l’amélioration du produit : lorsque les données n'ont plus à être accessibles pour les tâches quotidiennes des personnes en charge du développement du système d’IA, elles doivent en principe être supprimées. Elles peuvent toutefois être conservées pour la maintenance du produit ou son amélioration si des garanties sont mises en œuvre (support cloisonné, restriction des accès aux seules personnes habilitées, etc.).

À noter : la conservation des données d’apprentissage peut permettre d’effectuer des audits et faciliter la mesure de certains biais. Dans ces cas, une conservation prolongée des données peut être justifiée, sauf si la conservation d’informations générales sur les données suffit (par exemple, la documentation réalisée sur le modèle proposé dans la section Documentation, ou encore des informations sur la distribution statistique des données). Cette conservation doit être limitée aux données nécessaires, et s’accompagner de mesures de sécurité renforcées.

► Pour plus d’informations, voir la fiche n° 7

En pratique

La réalisation d’une AIPD pour le développement de systèmes d’IA

Il est fortement recommandé de réaliser une AIPD pour le développement de votre système d’IA notamment lorsque deux des critères suivants sont remplis :

• des données sensibles sont collectées ;
• des données personnelles sont collectées à large échelle ;
• des données de personnes vulnérables (personnes mineures, en situation de handicap, etc.) sont collectées ;
• des ensembles de données sont croisés ou combinés;
• de nouvelles solutions technologiques sont mises en œuvre ou une utilisation innovante est faite.

Par ailleurs, si des risques importants existent (par exemple : de mésusage des données, de violation de données, ou de discrimination), une AIPD doit être réalisée même si deux des critères précédents ne sont pas remplis.

Pour aider à réaliser une AIPD, la CNIL met à disposition le logiciel open source PIA dédié.

Les critères de risque introduits par la proposition de règlement européen sur l’IA

La CNIL considère que, pour le développement des systèmes à haut risque visés par le règlement européen sur l’IA et impliquant des données personnelles, la réalisation d’une AIPD est en principe nécessaire.

À noter : la réalisation de l’AIPD pourra reposer sur la documentation exigée par le règlement sur l’IA sous réserve de comporter les éléments prévus par le RGPD (article 35 du RGPD).

Le périmètre de l’AIPD

Il existe deux types de situations pour le fournisseur d’un système d’IA, selon l’objectif du système d’IA (voir « définir un objectif (finalité) pour le système d’IA »).

• Vous savez clairement quel sera l’usage opérationnel de votre système d’IA

Il est recommandé de réaliser une AIPD générale pour l’ensemble du cycle de vie, qui comprend les phases de développement et de déploiement. Attention, si vous n’êtes pas l’utilisateur/déployeur du système d’IA, c’est ce dernier qui aura la responsabilité de réaliser l’AIPD pour la phase de déploiement (même s’il pourra s’appuyer sur le modèle d’AIPD que vous aurez proposé).

• Si vous développez un système d’IA à usage général

Vous ne pourrez réaliser une AIPD que sur la phase de développement. Cette AIPD doit être fournie aux utilisateurs de votre IA pour leur permettre de conduire leur propre analyse.

Les risques liés à l’IA à prendre en compte dans une AIPD

Les traitements de données personnelles reposant sur des systèmes d’IA présentent des risques spécifiques que vous devez prendre en compte :

• les risques liés à la confidentialité des données susceptibles d’être extraites depuis le système d’IA ;
• les risques pour les personnes concernées liés à des mésusages des données contenues dans la base d’apprentissage (par vos employés qui y ont accès ou en cas de violation de données) ;
• le risque d’une discrimination automatisée causée par un biais du système d’IA introduit lors du développement ;
• le risque de produire du contenu fictif erroné sur une personne réelle, notamment dans le cas des systèmes d’IA génératives ;
• le risque de prise de décision automatisée quand l’agent utilisant le système n’est pas en capacité de vérifier sa performance en conditions réelles ou de prendre une décision contraire à la sortie du système sans que cela ne lui porte préjudice (en raison d’une pression hiérarchique par exemple) ;
• le risque d’une perte de contrôle des utilisateurs sur leurs données publiées et librement accessibles en ligne ;
• les risques liés aux attaques connues spécifiques aux systèmes d’IA (par exemple, les attaques par empoisonnement des données) ;
• les risques éthiques systémiques et graves liés au déploiement du système.

Les mesures à prendre en fonction des résultats de l’AIPD

Une fois le niveau de risque déterminé, votre AIPD doit prévoir un ensemble de mesures visant à le réduire et à le maintenir à un niveau acceptable, par exemple :

• des mesures de sécurité (par exemple, le chiffrement homomorphe ou l’utilisation d’un environnement d’exécution sécurisé) ;
• des mesures de minimisation, (par exemple le recours à des données synthétiques) ;
• des mesures d’anonymisation ou de pseudonymisation (par exemple la confidentialité différentielle) ;
• des mesures de protection des données dès le développement (par exemple l’apprentissage fédéré) ;
• des mesures facilitant l’exercice des droits ou les recours pour les personnes (par exemple techniques de désapprentissage machine, mesures d’explicabilité et de traçabilité des sorties du systèmes d’IA, etc.) ;
• des mesures d’audit et de validation (par exemple des attaques fictives).

D’autres mesures, plus génériques, pourront également être appliquées : mesures organisationnelles (encadrement et limitation de l’accès aux bases de données d’apprentissage et pouvant permettre une modification du système d’IA, etc.), mesures de gouvernance (mise en place d’un comité éthique, etc.), mesures de traçabilité des actions ou documentation interne (charte information, etc.).

► Pour plus d’informations, voir la fiche n°5