IA : Garantir la sécurité du développement d’un système d’IA

L’obligation de sécurité prévue par le RGPD repose sur la mise en place de mesures adéquates au regard des risques pour les droits et libertés des personnes physiques concernées. A cette fin, il convient de conduire une analyse des risques qui permettra de sélectionner les mesures de sécurité pertinentes.

Dans le cas du développement d’un système d’IA, cette analyse peut conduire à inclure des spécificités concernant les sources de risques (comme par exemple le fournisseur d’une base de données réutilisée), les supports visés (comme par exemple des bibliothèques logicielles) ou encore les impacts sur les personnes (comme par exemple des discriminations).

Du fait du développement parfois très récent de nombreuses approches pour développer des systèmes d’IA, il est recommandé de porter une vigilance particulière sur l’utilisation de composants (tels que les bases de données, bibliothèques, et infrastructures) n’ayant pas fait l’objet d’une évaluation de sécurité approfondie. Cette vigilance doit être accrue pour des usages faisant porter des risques importants sur les droits et libertés des personnes, comme l’utilisation de données sensibles ou la poursuite de finalités présentant des risques élevés. La liste des annexes II et III du projet de Règlement sur l’Intelligence artificielle fournit une information utile pour déterminer si les usages concernés sont à haut risque.  

A cette fin, il est recommandé de réaliser une analyse d’impact sur la protection des données (AIPD). Cette analyse peut être obligatoire dans certains cas, comme décrit dans la fiche « Réaliser une analyse d’impact si nécessaire ». L’AIPD est un outil qui permet de répertorier de manière transversale les risques et les mesures qui leur sont adaptées, et ainsi de lister les mesures existantes et celles qu’il convient de prendre.

Les objectifs de sécurité à viser lors du développement d’un système d’IA concernent :

• la confidentialité des données : dans le cas de données à accès restreint, mais également lorsqu’elles sont publiquement accessibles (puisque l’annotation qui leur est apportée peut comporter des données personnelles), un manque de sécurité de la base de données peuvent conduire à des pertes de confidentialité des données. Des atteintes sont également susceptibles d’avoir lieu lors de la manipulation du modèle entraîné sur les données (et indépendamment de ces dernières). En effet, des risques de mémorisation de données, de reconstruction ou encore d’inférence d’appartenance existent et peuvent conduire à une divulgation des données d’entraînement. Ces pertes de confidentialité peuvent avoir des conséquences graves pour les personnes concernées, notamment sur leur réputation, ou encore conduire à de l’hameçonnage, ou phishing. Prendre en compte les risques sur la confidentialité des données est critique en intelligence artificielle, où les données sont généralement en grande quantité et peuvent contenir des données personnelles, hautement personnelles ou sensibles sur les personnes.
   
• la performance et l’intégrité du système : bien que les risques liés à une mauvaise performance du système ne se manifestent qu’en phase de déploiement, la majorité des mesures doit être prise lors de la phase de développement. En effet, un risque sur l’intégrité des données, un manque de fiabilité des données, des outils ou des protocoles utilisés, des failles dans les procédures de développement, de test, ou d’ordre organisationnel peuvent conduire à des conséquences graves pour les utilisateurs – c’est-à-dire les organismes opérant le système d’IA en phase de déploiement – et utilisateurs finaux - c’est-à-dire les personnes sur lesquelles la sortie produite par le système trouve à s’appliquer. Par ailleurs, les systèmes intégrant des fonctionnalités d’apprentissage en continu doivent faire l’objet d’une vigilance renforcée sur le maintien dans le temps des performances et leurs effets sur les personnes.
   
• la sécurité générale du système d’information : les fonctionnalités des systèmes d’IA reposent généralement en grande partie sur les modèles utilisés, mais les risques les plus vraisemblables aujourd’hui portent sur les autres composants du système (comme les sauvegardes, interfaces et communications). Il peut ainsi être plus aisé pour attaquant d’exploiter une vulnérabilité du logiciel pour accéder aux données d’entrainement que de mener une attaque par inférence d’appartenance. Les risques et mesures correspondantes portant sur les systèmes d’information sont décrits dans le guide de la CNIL sur la sécurité des données personnelles.

Certains facteurs sont à considérer pour évaluer le niveau de risque portant sur le système d’IA considéré. Ces facteurs portent sur :

• La nature des données : les mesures de sécurité devraient être adaptées à la gravité des conséquences qu’une faille de sécurité pourrait avoir pour les personnes.

• La maîtrise sur les données, modèles et outils utilisés : l’IA est un domaine dans lequel le recours à des ressources ouvertes, ou à des protocoles décentralisés comme l’apprentissage fédéré, est fréquent, toutefois la fiabilité des sources n’est pas toujours vérifiée. L’utilisation de ces outils non vérifiés augmente la vraisemblance d’une faille de sécurité.

• Les modalités d’accès au système (tel que l’accès restreint, en tant que service ou SaaS, la diffusion du modèle en source ouverte, l’exposition au Web) et le contenu des sorties du système (tel que des indicateurs sur le fonctionnement du système, ou des scores de confiance) : les modalités d’accès augmentent la surface d’attaque et peuvent en faciliter la mise en œuvre. Les informations sur le fonctionnement du système facilitent quant à elle les attaques comme les attaques par inférence d’appartenance ou d’attribut. Ces modalités et informations augmentent ainsi la vraisemblance d’une vulnérabilité.

• Le contexte d’utilisation prévu pour le système d’IA : la gravité d’une vulnérabilité dépend de la criticité du système dans le traitement global, tant dans sa disponibilité que dans le rôle accordé à ses sorties, ainsi que de la maturité technique de ses utilisateurs. Lorsque le système d’IA interagit avec d’autres composant d’un système d’information, la qualité de ses sorties peut avoir une importance cruciale pour la sécurité. Ainsi, l’intégration efficace et robuste du système d’IA dans les systèmes d’information et sa maîtrise par l’utilisateur peuvent réduire la vraisemblance d’une faille de sécurité.

Les mesures suivantes peuvent être envisagées pour garantir la sécurité du système d’IA. Elles concernent les données d’entraînement, le développement, le fonctionnement du système, ainsi que des mesures transversales.

Comme indiqué précédemment, les mesures listées ici le sont à titre indicatif et ne doivent pas nécessairement être mises en place pour tous les développement des systèmes d’IA : il revient au responsable de traitement de déterminer les mesures nécessaires pour limiter les risques qu’il aura identifié, compte tenu de son contexte.

Mesures portant sur les données d’entraînement

La qualité et la fiabilité d’un système d’IA repose principalement sur les données utilisées pour son entraînement. Les mesures recommandées à leur sujet et pour leur sécurité sont donc primordiales. Les mesures suivantes sont particulièrement recommandées :

• Vérifier la fiabilité des sources de données d’entraînement et de leurs annotations : cette vérification peut avoir lieu à la collecte (ou à l’acquisition si la collecte est réalisée par un tiers), et doit être poursuivie tout au long du cycle de vie du système d’IA lorsqu’une évolution peut être attendue (comme lorsque les données sont collectées en continu, ou lorsqu’un risque existe sur l’intégrité des données).
   
• Vérifier la qualité des données d’entraînement et de leurs annotations : mettre en œuvre, ou vérifier que la collecte a été réalisée dans des conditions rigoureuses, puis étudier la qualité des données lors de la collecte puis au cours de leur cycle de vie permet de limiter les risques d’une perte de qualité des données (en particulier lorsqu’une dérive des données pourrait avoir lieu, comme dans le cas de l’apprentissage continu notamment, ou lorsque la collecte repose sur des capteurs dont la performance pourrait être détériorée).
   
• Vérifier l’intégrité des données d’entraînement et de leurs annotations tout au long de leur cycle de vie : cette vérification doit être réalisée régulièrement, et viser à détecter les failles les plus courantes tel que les tentatives d’empoisonnement des données. Ces vérifications peuvent être mises en œuvre par des techniques de contrôle itératif de l’apprentissage, par apprentissage actif (ou active learning) notamment, comme décrit dans l’article Linc « Sécurité des systèmes d’IA : les gestes qui sauvent ».
   
• Journaliser et gérer les versions des jeux de données (ou versioning) : suivre et documenter les modifications apportées aux jeux de données permet de détecter une tentative d’intrusion ou de modification de la base de données, et ainsi de prévenir une divulgation malveillante ou un empoisonnement des données. Il est également recommandé de conserver des traces de la version du jeu sur laquelle un modèle a été entraîné.
   
• Recourir à des données fictives ou de synthèse : lorsque le recours à des données réelles n’est pas nécessaire, comme pour les tests de sécurité, l’intégration, ou pour certains audits, recourir à des données fictives limite les risques pour les individus. Les techniques, avantages et limitations de la synthèse de données sont décrites dans l’article Linc en deux parties « Données synthétiques ».
   
• Chiffrer les sauvegardes et les communications : utiliser les protocoles de cryptographie à l’état de l’art permettent de limiter la gravité des conséquences d’une intrusion, notamment lorsque des points d’accès exposés au Web sont prévus comme dans le cas du logiciel en tant que service (Software as a service ou SaaS), ou dans le cas de l’apprentissage fédéré. Les progrès scientifiques récents dans le domaine de la cryptographie peuvent permettre d’obtenir des garanties fortes pour la protection des données.
   
• Contrôler les accès aux données : lorsque les données ne sont pas diffusées en source ouverte, restreindre l’accès aux données et prévoir des procédures d’authentification pour l’accès aux données, selon des niveaux d’habilitation différenciés selon les types d’accès (utilisateur, ou administrateur notamment) permet de prévenir certaines intrusions malveillantes, et ainsi de réduire le risque d’une perte d’intégrité, de disponibilité ou de confidentialité.

• Anonymiser ou pseudonymiser les données : la suppression de certaines données (par caviardage par exemple), l’ajout de perturbations aléatoires (par confidentialité différentielle par exemple), la généralisation (par l’agrégation des données ou la diminution de la précision) sont autant de catégories de mesures à considérer selon les typologies de données traitées et le contexte d’utilisation du modèle. De tels procédés peuvent en particulier permettre de visualiser ou d’exporter des extraits anonymisés du jeu de données, ou d’anonymiser des résultats de requêtes.

• Cloisonner les jeux de données sensibles : lorsque les données d’apprentissage contiennent une part importante de données sensibles (comme par exemple une base de données de santé), il est recommandé de prévoir un cloisonnement logique au niveau de leur stockage, par exemple via un chiffrement distinct de celui du système dans lequel elles sont hébergées, ainsi que des modalités d’accès dédiées (comptes et droits d’accès spécifiques au projet).
   
• Prévenir les pertes de contrôle sur les données par des mesures organisationnelles : encadrer et assurer le suivi des exports et partages de données permet de garder la main sur le parcours des données, notamment en conservant une trace des destinataires des données. Le suivi des données après leur diffusion ou leur partage peut être assuré grâce à des méthodes telles que le tatouage numérique qui permettra a posteriori de vérifier la provenance des données, et ainsi d’identifier l’origine d’une perte de confidentialité. Des mesures similaires, de tatouage numérique ou de signature, notamment par le hachage, peuvent également être appliquées aux modèles entraînés afin de garantir leur traçabilité.

Mesures portant sur le développement du système

De la réflexion en amont de la conception à l’intégration du modèle dans un système, plusieurs mesures de sécurité sont à prendre en considération :

• Tenir compte de la protection des données dans les choix de conception du système : la méthodologie à suivre pour cette phase préliminaire est décrite dans la fiche 6. La minimisation des données, qui est une démarche obligatoire, résultant de cette phase aura des conséquences bénéfiques pour la sécurité en limitant les conséquences pour les personnes ;
   
• Se conformer aux bonnes pratiques de sécurité du domaine : utiliser des bibliothèques, outils (de programmation, comme les environnements de développement, de développement, comme les outils de gestion des versions ou versionning, ou encore d’accès à des données, comme les API), modèles pré-entraînés et fichiers de configuration vérifiés permettra de limiter les risques d’attaque ou de défaillance. La présence de portes dérobées, ou backdoors, dans ces fichiers doit faire l’objet d’une attention particulière. Une vérification de leur fiabilité ainsi que le respect des mises à jour est recommandé. Enfin, plusieurs bonnes pratiques de développement sont recommandées, comme :
  • l’utilisation de formats sécurisés pour la sauvegarde des fichiers de configuration et des modèles tels que les safetensors (plutôt que des formats favorisant les attaques par injection de code, comme les fichiers YAML ou pickle) ;
  • l’interdiction d’utiliser des fonctions trop permissives qui pourraient exécuter du code malveillant non détecté ;
  • le nettoyage et la revue du code informatique ;
  • la vigilance aux alertes remontées par les outils ;
  • la compilation du code du système (plutôt que l’utilisation du tracing ou du scripting) afin d’empêcher l’altération du comportement du système une fois déployé ;
• Recourir à un environnement de développement contrôlé, reproductible et facilement déployable : de nombreux outils tels que les conteneurs ou les machines virtuelles permettent de faciliter le contrôle sur l’environnement de développement en automatisant sa configuration. En complément, un environnement sécurisé de test, souvent appelé bac à sable, devrait être utilisé en cas de doutes ;
   
• Mettre en œuvre une procédure de développement et d’intégration continus : cette procédure obligatoire, reposant sur un environnement spécifique et des tests unitaires exhaustifs et robustes et dont la modification est restreinte par une authentification, notamment pour les modifications apportées au code de production, permettra de limiter le risque de l’insertion d’une faille dans le système ;
   
• Construire un recueil documentaire : cette documentation à l’intention des développeurs et des utilisateurs du système, pourra porter sur :
  • la conception du système, et notamment les données et modèles utilisés ainsi que les analyses ayant conduit à leur sélection et à leur validation, et les résultats de ces analyses ;
  • le fonctionnement du système durant tout son cycle de vie, ses performances, l’analyse de ses biais et des performances obtenues, ses conditions d’utilisations et limitations d’usage, comme les cas où la performance peut être insuffisante ;
  • les équipements matériels nécessaires pour l’utilisation du système, la latence attendue ou encore la capacité maximale pour les systèmes accessibles en SaaS ;
  • les mesures de protection implémentées, portant notamment sur la gestion des accès, des secrets ou encore sur les mesures de chiffrement.
• Conduire des audits de sécurité : ces analyses pourront être conduites en interne ou par des tiers (comme des prestataires ou des développeurs appartenant à une communauté), reposer sur des référentiels reconnus (voir la section ressources utiles ci-dessous) , et mettre en œuvre les tentatives d’attaque les plus courantes sur l’exemple du « red teaming ».

La CNIL a en outre publié un guide RGPD de l’équipe de développement recensant un ensemble de bonnes pratiques applicables de manière plus générale.

Mesures portant sur le fonctionnement du système 

Bien que les risques sur le fonctionnement du système portent sur la phase de déploiement (dont la sécurité sera abordée dans des publications ultérieures), il est plus opportun de prendre en compte certains d’entre eux lors de la phase de développement. Ces mesures incluent de :

• Porter à la connaissance de l’utilisateur les limitations du système en laboratoire et dans les contextes d’usage prévus : une explicitation des conditions d’utilisation garanties ou recommandées et des conditions limitant la performance ou exclues (que ce soit en termes d’usage ou de conditions de fonctionnement) est recommandée ;
   
• Prévoir la délivrance d’informations permettant à l’utilisateur d’interpréter les résultats : ces informations devraient notamment permettre d’identifier une éventuelle erreur (comme un score de confiance, ou des informations sur la logique et le cheminement interne au système, tel qu’une carte de saillance pour la détection, en tenant compte du risque d’une exploitation de ces informations par un attaquant). Une interface ou un canal de communication dédiés peuvent également permettre de recueillir les retours des utilisateurs, afin d’identifier et de corriger des défauts du système observés en phase de déploiement. Ces informations peuvent également être collectées en prévoyant une journalisation spécifique des sorties du système, en particulier lorsque celui-ci est intégré dans un système d’information ;
   
• Prévoir la possibilité de stopper le système : cette mesure sera obligatoire pour les utilisations relevant de la prise de décision automatisée (article 22 du RGPD) et ayant certaines conséquences sur les individus ;
   
• Contrôler les sorties des IA : les productions des systèmes d’IA, et notamment des systèmes  génératifs, peuvent être problématiques, contenir des données personnelles, ou être trompeuses. Des mesures, telles que des filtres sur les sorties, l’apprentissage par renforcement à partir de la rétroaction humaine (Reinforcement Learning from Human Feedback, ou RLHF) ou encore le tatouage numérique (ou watermarking) du contenu généré, dont l’efficacité est démontrée notamment sur les images, permettent de réduire la vraisemblance de leur production.

Mesures transversales

Ces mesures concernent le développement du système dans son ensemble :

• Mettre en œuvre et suivre un plan d’action pour la sécurité : inscrire les mesures à prendre en compte dans un plan d’action permettra de vérifier leur mise en œuvre et la réduction effective des risques tout au long du développement du système, et jusqu’à la suppression sécurisée des données ;
   
• Constituer une équipe de développement aux compétences pluridisciplinaires : solliciter des expertises et avis diversifiés permettra d’identifier les failles de sécurité dans l’ensemble du cycle de vie des données. Il est recommandé :
  • d'inclure des employés aux compétences complémentaires (comme dans l’analyse et l’ingénierie des données, l’interface et l’expérience utilisateur, le contrôle qualité, l’administration des infrastructures informatiques, ou encore liées au besoin métier) au processus de développement ;
  • de veiller à la formation des développeurs et analystes des données sur les bonnes pratiques de sécurité concernant la gestion des données d’entraînement et le développement des modèles, et sur les vulnérabilités les plus courantes ;
• Gérer les habilitations, tracer les accès, analyser les traces : même quand les données proviennent de sources ouvertes, les annotations qui leur sont apposées peuvent constituer une information à protéger. Restreindre les accès aux bases de données et aux modèles aux personnes autorisées selon leur profil d’habilitation et tenir une liste des utilisateurs à privilèges, journaliser les accès, modifications, ajouts et suppressions aux bases de données, et analyser ces traces (en temps réel de façon automatisée ou, à défaut, de manière régulière) permet de réduire la vraisemblance et la gravité d’une intrusion en l’empêchant ou en la détectant au plus tôt.

Les ressources suivantes seront utiles afin de sécuriser le système d’IA dans son ensemble, en prenant notamment en considération les risques spécifiques à l’IA :

• Le guide méthodologique EBIOS-RM de l’ANSSI,
• Les recommandations de sécurité pour un système d’IA générative de l’ANSSI,
• Les ressources sur la réalisation d’une AIPD de la CNIL,
• Le guide sur la sécurité des données personnelles de la CNIL,     
• Le dossier « Sécurité des systèmes d’IA » du Linc,
• Le rapport « Artificial Intelligence Cybersecurity Challenges » de l’Agence de l’Union Européenne pour la cybersécurité (ENISA),
• Les lignes directrices sur la sécurité de l’IA du Bureau fédéral pour la sécurité de l’information allemand (BSI),
• Le guide « AI Security and privacy » de l’association OWASP,
• Les « Guidelines for secure AI system development » du National Cyber Security Centre (Angleterre),
• La cartographie des attaques sur les systèmes d’IA, ou « Adversarial Threat Landscape for Artificial Intelligence Systems » (ATLAS) de l’entreprise MITRE,
• Le projet « Privacy Library Of Threats 4 Artificial Intelligence » ou Plot4AI,
• Les guide « Data-Centric System Threat Modeling », et « Adversarial Machine Learning » du National Institute of Standards and Technology (Etats-Unis),
• Le guide « Rapid risk assessment » de l’entreprise Mozilla.