Sécurité des systèmes d’IA, les gestes qui sauvent

Plusieurs publications, comme par exemple celle proposée par la société Wavestone, listent les bonnes pratiques à la fois techniques et de gouvernance à mettre en œuvre pour sécuriser un système d’IA. La sécurité des systèmes d’IA étant un domaine de recherche en plein essor, on observera qu’à des mesures élémentaires peuvent être ajoutés des mécanismes de défense beaucoup plus raffinés, voire encore expérimentaux et connaissant des évolutions très rapides.

 

 

La mise en œuvre d’un système d’IA suppose avant toute chose d’avoir réfléchi à la façon de le faire. Si la mise en œuvre pratique peut bien souvent remettre en question certains choix de conception, la formalisation préalable des exigences permet de s’assurer que les solutions déployées sont bien cohérentes avec les exigences préalablement identifiées.

 

1.1 Penser l’architecture

 

En fonction de la tâche à réaliser (classer des images, extraire des informations de données textuelles, etc.) différents types de systèmes d’IA peuvent être déployés. Il convient donc de répondre à plusieurs questions afin de choisir celui qui est le plus approprié.

 

• Quel type de problème veut-on résoudre ?

Définir s’il s’agit de régression, de classification, de partitionnement de données, de segmentation, de génération de contenu, etc.

• Quel type de système souhaite-t-on mettre en œuvre ?

En fonction du problème à résoudre, préciser si on veut mettre en œuvre un système d’apprentissage supervisé, non-supervisé, par renforcement, en continu, fédéré, distribué, centralisé, etc.

• Quelles sont les implications de ces choix ?

Chaque système dispose de ses propres particularités et emporte donc des conséquences spécifiques. Les implications pour la vie privée d’un système d’apprentissage fédéré ou d’un système centralisé ne sont par exemple pas les mêmes, de même que les systèmes d’apprentissage en continu présentent des vulnérabilités différentes que les systèmes pour lesquels les modèles sont appris « une fois pour toute » (once and for all).

 

1.2 Séquencer le traitement

 

La puissance de l’apprentissage automatique (machine learning) tient à son pouvoir à établir des corrélations parmi de très grands volumes de données. Lors de la phase d’apprentissage, les modèles sont bien souvent entraînés avec plus de données que ce qui sera in fine strictement nécessaire, cela afin de déterminer les combinaisons qui s’avéreront les plus efficaces en pratique. Ensuite, une fois le modèle sélectionné et validé, il est possible de réduire le nombre et la nature des données utilisées au strict nécessaire. C’est ce sous-ensemble de données qui sera alors utilisé pour le passage en production du système d’IA.

 

Il convient donc de bien séquencer son traitement d’IA pour séparer clairement :

• La phase de R&D : phase au cours de laquelle une exploration sera menée pour caractériser le meilleur système permettant de résoudre la tâche étudiée (en termes d’architecture, de données utilisées, de choix de paramètres et d’hyperparamètres, etc.) et réaliser son entraînement.
• La phase de production : phase consécutive à celle de R&D et qui verra le système d’IA utilisé pour la tâche pour laquelle il a été entrainé.

 

Il est essentiel d’avoir une bonne idée de ce découpage en phases car celles-ci doivent répondre à des exigences différentes. Elles peuvent être rattachées à deux finalités différentes au titre de la protection des données (et donc recourir à deux bases légales différentes). En fonction des architectures choisies, ce découpage en phase peut s’avérer plus délicat à réaliser. A titre d’exemple, un système d’apprentissage en continu peut être vu comme une succession de phases de R&D et de production.

 

1.3 Avoir une approche privacy by design

 

En fonction de son domaine d’emploi, de son architecture et des données qui l’alimentent, un système d’IA peut présenter des risques plus ou moins importants pour la vie privée. Dans certains cas, ceux-ci peuvent être atténués par la mise en œuvre de mesures protectrices dès la conception du système. Il est possible de jouer sur différents leviers en pratique :

 

• Explorer la possibilité de déployer des architectures respectueuses de la vie privée. Certaines pratiques de mises en œuvre des systèmes d’IA peuvent apporter des garanties pour la confidentialité des données. Les approches d’apprentissage fédéré (federated learning) par exemple peuvent parfois apporter plus de garanties qu’un système centralisé en limitant la circulation des données (voir à ce sujet l’article Chacun chez soi et les données seront bien gardées : l’apprentissage fédéré).
• Renforcer l’environnement d’exécution du système d’IA. Les modalités relatives aux conditions pratiques de déploiement des systèmes doivent garantir une bonne sécurisation. A titre d’exemple, des environnements de confiance (trusted execution environment) peuvent être mis en œuvre.
• Utiliser les ressources offertes par la cryptographie. 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. En fonction des cas d’usage, il pourra par exemple être pertinent d’explorer les possibilités offertes par le calcul multipartite sécurisé (secure multi-party computation), le transfert inconscient (oblivious transfer) ou encore le chiffrement homomorphe (homomorphic encryption).
• Utiliser des méthodes d’anonymisation. Certaines méthodes d’anonymisation comme la confidentialité différentielle (differential privacy) peuvent être introduites et utilisées à différents endroits de la chaîne de traitement. Le recours à des techniques d’anonymisation réduit en pratique les risques de violation de données et de vol ou de rétro-ingénierie du modèle. Celle-ci peut par exemple être appliquée pour :
  • Perturber les données utilisées lors de la phase d’apprentissage
  • Perturber les paramètres du modèle appris, par exemple, injecter du bruit dans le processus de mise à jour des paramètres comme proposé par (Long et al, 2017)
  • Perturber la fonction de perte utilisée lors de la phase d’apprentissage
  • Perturber l’entrée soumise au système en phase de production
  • Perturber la sortie fournie par le système en phase de production

A noter qu’un compromis entre utilité et protection du modèle contre les attaques en confidentialité doit être trouvé (Rahman et al, 2018).

• S’assurer que les règles élémentaires de SSI sont bien mises en œuvre. Il existe des frameworks spécialisés pour le développement de système d’IA sécurisés comme SecML proposé par (Melis et al, 2019). Il est par ailleurs essentiel de garder à l’esprit que les systèmes d’IA sont avant tout des systèmes informatiques et qu’ils doivent ainsi répondre aux mêmes exigences de sécurisation. Le Guide de la sécurité des données personnelles de la CNIL présente les mesures élémentaires à mettre en œuvre, y compris pour un système d’IA. 

 

 

Un système d’IA implique l’exploitation de différents objets. On peut en particulier en distinguer trois :

• Les données : utilisées à la fois pour l’élaboration du modèle en phase de R&D et l’exploitation en phase de production
• Les modèles : créés à partir des données, ils peuvent parfois être le résultat d’un enrichissement et d’une adaptation de modèles existants en utilisant les technologies d’apprentissage par transfert (transfer learning)
• Le code : « incarnation » informatique du système d’IA, il peut être produit spécifiquement pour la tâche à remplir ou être dérivé de ressources existantes (code disponible en open source par exemple). Il fait quasi systématiquement appel à des briques existantes (librairies, exemples disponibles, etc.)

 

2.1 Les données

 

2.1.1 S’assurer de la légalité

Les données étant au cœur du fonctionnement des systèmes d’IA, il est essentiel de s’assurer que la collecte et le traitement de celles-ci ainsi que leur usage sont conformes à la réglementation en vigueur, et notamment à celle liée à la protection des données lorsque ces données sont à caractère personnel (RGPD, Loi Informatique et Libertés, directive ePrivacy, directive « Police-Justice », etc.).

 

Une analyse de conformité concernant l’accès à ces données pour le développement et l’utilisation d’un système d’IA est donc indispensable. Comme tout traitement de données, celui-ci doit donc être caractérisé et décrit comme le veut la réglementation en vigueur (finalité, base légale, durée de conservation, exercice des droits, mesures de sécurité). En fonction de la finalité du traitement, la réalisation d’une Analyse d’impact relative à la protection des données peut s’avérer indispensable.

 

2.1.2 S’assurer de la qualité

Les données, utilisées dans des jeux d’entraînement, de validation ou de test, doivent également répondre à des exigences de qualité afin de construire le meilleur système possible. Il convient donc d’être attentif à différents aspects, par exemple :

- L’adéquation des données au problème à résoudre

- La manière dont les données ont été collectées, qui peut apporter un éclairage sur celles-ci

- La représentativité des données pour le problème à résoudre

- La présence d’éventuels biais dans les données

- La disponibilité et la quantité de données disponibles

- Les éventuels problèmes dans les données (données manquantes, non-renseignées, aberrantes, etc.)

 

La phase de nettoyage des données (data sanitization) est une étape essentielle pour la constitution d’un jeu de données utilisable par un système d’IA. Un suivi (monitoring) des sources de données et des mécanismes de seuillage visant à limiter l’utilisation de données issues d’une même source (zone géographique, individu, IP, etc.) peuvent également être mis en œuvre pour réduire les risques de sur-représentation de certaines catégories de données.

 

Il est par ailleurs primordial que l’intégrité des données collectées et utilisées par le système d’IA soit assurée. Cela est valable tant pour la phase de R&D que pour la phase de production, et les données ne doivent pas pouvoir être altérées de façon non prévue par le concepteur du système (principe d’exactitude). La chaîne d’acquisition des données doit donc être conçue pour garantir une protection de bout en bout, en limitant les canaux d’entrée, en appliquant une gestion d’accès stricte ou encore en chiffrant les flux de données.

 

Dans le cas de jeux de données réutilisés, et en particulier en ce qui concerne ceux disponibles en open source, un devoir de vigilance s’impose, ces jeux pouvant ne pas apporter de garanties de qualité satisfaisantes mais également avoir été infectés dans le but de mener une attaque sur le système d’IA.

 

2.1.3 S’assurer de la désensibilisation

Le fonctionnement des systèmes d’IA, basés sur l’utilisation de quantités de données importantes voire très importantes, met en tension certains principe du RGPD, notamment celui de la minimisation des données. Par ailleurs, et comme présenté précédemment, la phase de conception du système d’IA ou phase de R&D peut nécessiter l’accès à des typologies de données plus larges que celles qui seront finalement utilisées en production.

 

Toutefois, il est indispensable de faire en sorte que les données ne soient pas excessives. Il ne faut pas conserver dans les jeux de données des informations dont il est certains qu’elles ne doivent pas être exploitées. Ainsi, l’élaboration d’un système d’IA visant à produire un diagnostic médical ne devra jamais être réalisé sur des données directement nominatives. Le recours à des mécanismes de pseudonymisation (tel que pour des documents textuels) ou de filtrage/obfuscation (par exemple, numéro à 16 chiffres pour les cartes bleues) est donc indispensable.

 

Par ailleurs, afin de s’affranchir de certaines contraintes relatives à la protection des données personnelles, le recours à des données anonymisées ou de synthèse peut s’avérer très efficace. L’anonymisation étant une notion mouvante et complexe, il convient toutefois de s’assurer au préalable que celle-ci a été bien réalisée (voir à ce sujet la Fiche pratique de la CNIL).

 

2.1.4 S’assurer de la traçabilité

Il est indispensable d’être en mesure d’assurer la traçabilité des données utilisées par les systèmes d’IA (en particulier en phase de R&D) et de documenter leur provenance et les conditions de leur collecte. En plus de permettre d’assurer la légalité, ces éléments de connaissance permettront en effet au concepteur du système d’IA de disposer d’informations pour améliorer la qualité de son système.

 

Par ailleurs, certaines technologies actuellement en développement visent à opérer une traçabilité des données et ainsi à être en mesure d’observer si elles ont été utilisées pour l’apprentissage d’un modèle. On parle ainsi de données « radioactives » (Sablayrolles et al., 2020). Ces recherches, généralement plutôt motivées par des questions de propriété intellectuelle, pourront trouver à s’appliquer dans le cas des données personnelles.

 

2.2 Les modèles

 

La conception d’un système d’IA peut dans bien des cas être opérée à l’aide de modèles d’IA existants. En effet, les contraintes introduites par l’apprentissage profond rendent celui-ci coûteux à la fois en ressources calculatoires, en quantité de données nécessaires et en temps. Dans de nombreux domaines d’application, on a donc recours aux technologies d’apprentissage par transfert (transfer learning) pour faciliter la création de modèle (par exemple, pour les modèles de langage, de vision, etc.).

 

Concrètement, il s’agit d’utiliser un modèle appris sur de très grandes catégories de données et de l’adapter au problème visé à l’aide de données spécifiques à celui-ci mais dont la quantité nécessaire est bien moindre que si un apprentissage complet devait être réalisé. A titre d’exemple, la détection de tumeurs cancéreuses peut se faire à l’aide du modèle généraliste GoogLeNet adapté à ce cas d’usage.

 

Comme décrit dans l’article Petite taxonomie des attaques des systèmes d’IA, un attaquant peut se servir d’un modèle en open source qu’il aura infecté pour introduire des portes dérobées (backdoors) ou des chevaux de Troie. Il est donc indispensable, lorsqu’on a recours à un modèle mis en œuvre par un tiers de s’assurer :

• De la fiabilité de la source auprès de laquelle on le récupère
• De disposer d’éléments de connaissance relatifs à la constitution de celui-ci
• De disposer de la dernière version du modèle en question

 

2.3 Le code

 

Comme l’élaboration de tout programme informatique, la conception de systèmes d’IA repose sur le développement de code. Cependant, la conception de systèmes d’IA étant une tâche très complexe, elle repose bien souvent sur l’utilisation de ressources existantes. Si comme dans d’autres domaines de l’informatique, il est quasiment impossible de se passer de l’utilisation de librairies de références (TensorFlow, Keras, Scikit-Learn, etc.), il est également fréquent de réutiliser des parties de codes sources produites par d’autres.

 

Comme pour les modèles d’IA disponibles en open source, il est nécessaire de s’assurer :

• De la fiabilité de la source auprès de laquelle on récupère ces éléments
• De disposer d’éléments de connaissance relatifs à leur production
• De s’assurer qu’ils n’aient pas été corrompus (en inspectant le code récupéré)

 

Le Guide RGPD du développeur de la CNIL précise les bonnes pratiques de développement à mettre en œuvre de façon générale pour satisfaire les impératifs de protection des données.

 

Par ailleurs, dans le cadre de contrat passé entre un organisme et un fournisseur externe de solutions d’IA, l’usage qui peut être fait du code source propriétaire peut être très précisément encadré. Ces questions sont abordées dans la partie 5.3.

 

La phase d’apprentissage des systèmes d’IA est une étape clé et une de leurs spécificités. Il s’agit donc de consacrer un effort tout particulier à l’élaboration de celle-ci afin d’assurer que l’apprentissage est correctement réalisé, que le modèle est robuste mais également qu’il n’offre pas de prises à un éventuel attaquant. Une protection du processus d’apprentissage doit donc être réalisée et cela à deux niveaux : au niveau des données utilisées pour l’entraînement du système et au niveau de la méthode d’apprentissage mise en œuvre.

 

3.1 Au niveau des données d’entrainement

 

Outre les questions relatives à la qualité des données collectées pour être utilisées lors de l’apprentissage d’un système d’IA (voir point 2.1.2), il convient de s’assurer que celles-ci ne servent pas les desseins d’un attaquant.

 

3.1.1 Surveiller l’impact des données

Comme présenté dans l’article Petite taxonomie des attaques des systèmes d’IA, les attaques par infection, et notamment celle par empoisonnement (poisoning attacks), permettent aux attaquants d’exercer un contrôle des systèmes d'IA de façon dissimulée en contaminant les données (pour abaisser la qualité du modèle produit, pour intégrer une porte dérobée, etc.). L’état de l’art scientifique propose plusieurs méthodes pour se prémunir contre de telles attaques et consolider le modèle d’IA produit, telles que :

 

• Contrôle itératif de l’apprentissage (iterative learning control) : étudie l’impact de chaque donnée sur le fonctionnement du modèle. On parle également de défense RONI (Reject On Negative Impact) permettant de supprimer du jeu d’apprentissage les données ayant un impact négatif sur la précision du modèle (Nelson et al, 2008).
• Apprentissage actif (active learning) : fait intervenir un opérateur pendant le processus d’apprentissage pour lui demander de qualifier certaines données (Settles, 2010). Il s’agit d’une méthode d’apprentissage semi-supervisée.  

 

Des méthodes moins complexes peuvent également être mises en œuvre pour assurer le contrôle des données pendant la phase d’apprentissage tel que le contrôle de l’intégrité des données ou la définition de listes noires (blacklists) recensant des mots clés ou patterns à retirer systématiquement du jeu d’apprentissage (par exemple le vocabulaire injurieux dans le cas d’un chatbot).

 

3.1.2 Consolider son jeu de données

En plus des attaques par infection, certaines attaques dites par manipulation visent à dégrader la qualité des sorties produites en fournissant au système en production des données corrompues. Pour se prémunir de telles attaques, la littérature scientifique propose différentes stratégies telles que :

• Augmentation de données (data augmentation) : cette méthode permet d’augmenter la quantité de données en ajoutant des copies légèrement modifiées de données existantes. Cela permet une « régularisation » du modèle d’IA. Cette technique est efficace, sauf si les données sont limitées. Il peut alors manquer certaines informations sur les données qui n’ont pas été utilisées pour l’entraînement, et les résultats peuvent donc s’avérer biaisés.
• Randomisation : ajoute un bruit aléatoire à chaque donnée utilisée pour l’entraînement. L’ajout de ce bruit rend plus difficile pour un attaquant de prédire la perturbation à ajouter à une entrée pour arriver à ses fins. L’intensité du bruit à ajouter doit être optimisée pour obtenir le meilleur compromis entre l’exactitude de l’algorithme et sa robustesse.
• Entraînement contradictoire (adversarial training) : utilise des exemples contradictoires (adversarial examples) la plupart du temps générées à l’aide de réseaux antagonistes génératifs (GANs pour generative adversarial networks). L’entrainement d’un modèle avec de telles données doit permettre au système d’ignorer le bruit susceptible d’avoir été ajouté par un attaquant et à n'apprendre qu'à partir de caractéristiques robustes.

 

Si ces méthodes visent en priorité à empêcher les attaques par empoisonnement des données d’apprentissage, aucune n’apporte de garanties formelles de la capacité à se prémunir de toutes. Même si un compromis acceptable entre performance et robustesse doit toujours être trouvé, l’idée est qu’elles permettent d’améliorer la capacité de généralisation du modèle entrainé.

 

3.2 Au niveau de la méthode d’apprentissage

 

Parallèlement au travail sur les données utilisées, il est également indispensable de sécuriser et durcir le processus d’apprentissage lui-même. Pour cela, des méthodes classiques peuvent être utilisées :

• Validation croisée (Cross validation) : permet d’estimer la fiabilité d’un modèle en utilisant une technique d’échantillonnage. Cette technique est efficace, sauf si les données sont limitées. Il peut alors manquer certaines informations présentes dans les données qui n’ont pas été utilisées pour l’entraînement, et les résultats peuvent donc être biaisés.
• Amorçage (Bootstraping) : permet d'estimer des valeurs statistiques sur une population, en faisant la moyenne des estimations obtenues sur de nombreux échantillons issus de cette population (par exemple pour estimer la moyenne, l'écart-type ou même un intervalle de confiance pour les paramètres du modèle, ou pour estimer ses performances). Cette méthode consiste à tirer de manière aléatoire uniforme des observations l'une après l'autre, et en les remettant dans l'échantillon d'origine une fois qu'elles ont été choisies.  
• Normalisation de lot (Batch normalization) : cette technique spécifique à l’entrainement de réseaux de neurones profonds standardise (centre-réduit) les entrées soumises à une couche du réseau pour chaque mini-batch (la couche d’entrée, mais également les couches cachées). Cela a pour effet de stabiliser le processus d’apprentissage et réduire la durée de l’entraînement du réseau. A noter que d’autres types de normalisation existent : la normalisation des poids (Weight normalization), des couches (Layer normalization) ou encore par groupe (Group normalization).
• Quantification (Quantization) : cette technique, également utilisée pour l'apprentissage profond, est un processus d'approximation d'un réseau de neurones complexe qui utilise des nombres à virgule flottante par un réseau de nombres d'un ensemble « discret » d'assez petite taille. Cette troncature réduit considérablement les besoins en mémoire et le coût de calcul des réseaux neuronaux.
• Élagage (Pruning) : cette technique consiste à supprimer certaines connexions dans un réseau de neurones profond afin d'augmenter la vitesse d'inférence et de réduire la taille de stockage du modèle. En général, les réseaux neuronaux sont très sur-paramétrés. L'élagage d'un réseau peut être considéré comme la suppression des paramètres inutilisés.
• Décrochage ou abandon (Dropout) : cette technique de régularisation vise à réduire le surapprentissage dans les réseaux de neurones. Pour cela, des neurones sont sélectionnés aléatoirement et ignorés pendant la phase d’apprentissage. Ces neurones ignorés sont temporairement supprimés lors de la passe avant (forward), et leurs poids ne sont pas mis à jour lors de la passe arrière (backward). Contrairement à l’élagage, les neurones ne sont pas définitivement supprimés.

 

Par ailleurs différentes stratégies d’apprentissage ont pu être proposées dans la littérature scientifique pour durcir les modèles et minimiser les prises offertes à un éventuel attaquant. De nombreuses méthodes d’apprentissage ensemblistes ont en particulier été élaborées et prolongent les méthodes classiquement utilisées (bagging, boosting ou forêts aléatoires). Ces techniques reposent sur la combinaison de multiples algorithmes pour accroître les performances du modèle, et parvenir à un niveau de précision bien supérieur à celui qui serait obtenu si on utilisait n’importe lequel de ces algorithmes pris séparément :

 

• Micromodèles : technique permettant de réaliser l’entrainement sur de multiples modèles et évaluer leur pertinence (et la possibilité que certains soient infectés par des données corrompues) par un vote majoritaire  au moment de l’inférence  (Cretu et al., 2008).
• Distillation défensive (defensive distillation) : technique qui s’éloigne des approches d’apprentissage ensembliste mais utilise un modèle de référence (maître ou teacher) afin d’entraîner un second modèle « lissé » introduisant une faible incertitude (élève ou student). Le second modèle est plus robuste et donne moins de prise à un attaquant cherchant à exploiter des vulnérabilités (Papernot et al., 2016).
• Private Aggregation of Teacher Ensembles (PATE) : technique ensembliste utilisant la confidentialité différentielle (differential privacy). Des modèles maîtres bruités permettent l’entrainement, par un vote majoritaire sur les sorties qu’ils produisent, d’un modèle élève qui sera celui utilisé par le système. L’idée sous-jacente est que ce modèle ne laissera que très peu de prise à une attaque en confidentialité (Papernot et al., 2017).
• Apprentissage contradictoire ensembliste (ensemble adversarial training) : technique visant à contrer les attaques par exemples contradictoires et en particulier leur propriété de transférabilité. Pour cela, le modèle est entraîné en utilisant des exemples contradictoires créés à partir du modèle lui-même, mais également des exemples transférés à partir de modèles pré-entraînés (Tramer et al., 2020).

 

Enfin, on peut noter que de plus en plus de travaux s’intéressent à la façon de permettre à un individu d’exercer son droit d’opposition sur un modèle d’apprentissage automatique comme prévu par le RGPD. L’exercice de ce droit suppose qu’un apprentissage présentant des propriétés appropriées soit effectué. On parle ainsi de machine unlearning et plusieurs approches d’apprentissage comme par exemple SISA (Sharded, Isolated, Sliced, and Aggregated) commencent à être proposées (Bourtoule et al., 2020).

 

S’il est essentiel de prendre en compte les risques spécifiques à un système d’IA avant de le mettre en production, il faut également garder à l’esprit que celui-ci est avant toute chose un système informatique au sens classique du terme. Sa sécurisation et sa robustesse passent donc également par l’application des mesures de sécurité « classiques ». Les bonnes pratiques de développement web présentées dans le Guide RGPD du développeur de la CNIL et dans d’autres initiatives comme l’Open Web Application Security Project (OWASP) trouvent donc à s’appliquer. En particulier, il s’agira à la fois de protéger le processus d’alimentation du système d’IA en phase de production et de maîtriser les sorties qu’il produira, ces deux étapes pouvant donner lieu à des actions malveillantes. En pratique, le recours à des experts en sécurité informatique (pentester, red teamer, blue hat, etc.) est recommandé. Il s’agit ainsi de s’assurer de la fiabilité et de la robustesse du système d’IA en réalisant différents tests et attaques (intrusion, contournement, etc.).

 

4.1 Contrôler les entrées

 

En premier lieu, il est essentiel qu’un système d’IA n’expose que ce qui est strictement nécessaire à son bon fonctionnement. L’accès au système doit donc être strictement limité aux seules personnes ayant nécessité d’y accéder. Un fonctionnement en mode « boîte noire » (black box) ne permettant aux utilisateurs que de fournir des entrées et d’observer des sorties est donc généralement à privilégier.

 

Des « sas de décontamination » peuvent être mis en œuvre afin de :

• S’assurer du bon format des fichiers soumis : il s’agit de vérifier le type de données, l’exhaustivité des informations entrées ou extraites, etc.
• Vérifier la cohérence des données : il s’agit de mesurer un éventuel écart par rapport aux données anticipées, à des données historisées, etc.
• Détecter l’ajout de bruit dans les données (noise prevention) : il s’agit de détecter l’éventuel présence d’une entrée corrompue par exemple en comparant la prédiction obtenue de la donnée nettoyée avec la donnée soumise (Akhtar et al, 2018).
• Compresser les caractéristiques (feature squeezing) : il s’agit de réduire l’information dans la donnée soumise à un minimum de caractéristiques suffisantes pour réaliser la tâche et ainsi de ne pas permettre l’ajout d’informations corrompues. La comparaison des sorties produites sur la donnée d’origine et sur sa version compressée permet ainsi de détecter avec une haute précision les exemples contradictoires puisqu’une grande différence de comportement est observée. Cela est en particulier adapté aux traitements de vision par ordinateur (Xu et al, 2017).

 

Par ailleurs, il est vivement recommandé de durcir les API (interface de programmation applicative) qui permettent l’utilisation du système d’IA en ligne par exemple afin de :

• Limiter le nombre de requêtes qui pourraient être soumises par un utilisateur
• S’assurer que l’utilisateur est un humain par exemple par l’utilisation de CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart)
• Imposer à chaque requête un coût calculatoire important (à la manière des fonctions à dérivation de clé utilisées utilisées pour le hachage en cryptographie)
• Analyser les comportements des utilisateurs. Les comportements suspects peuvent faire l’objet de détection et de blocage. On parle alors d’analyse UEBA (analyses comportementales des utilisateurs et des entités ou User and Entity Behavior Analytics).

Enfin, si les données soumises en phase de production doivent ensuite être réutilisées pour un ré-apprentissage du modèle d’IA, la mise en place d’un « bac à sable » (sandbox) peut permettre de vérifier que le réentrainement apporte bien les gains de performance escomptés. Il s’agit de suivre l’évolution des performances du modèle et donc de ne pas exposer ce dernier de façon définitive à des risques de dérive (drift) et d’infection, par exemple à des attaques par empoisonnement ou porte dérobées.

 

4.2 Maîtriser les sorties

 

S’il est indispensable de contrôler les entrées soumises à un système d’IA, de façon symétrique, il faut également s’assurer que les sorties produites sont bien protégées et n’offrent pas de prises à un éventuel attaquant. En effet, comme illustré dans l’article Petite taxonomie des attaques des systèmes d’IA, un attaquant pourra exploiter les sorties d’un système d’IA pour de multiples buts : voler le modèle, l’inverser, mener une attaque par inférence d’appartenance, etc. Pour cela, il est conseillé de :

 

• Réduire la « verbosité » des sorties : il s’agit par exemple de n’exposer que des labels inférés et non pas les scores de confiance du système ou alors de produire une version grossière de ceux-ci (e.g. confiance faible / moyenne / forte) et pas des scores bruts. Il est alors plus compliqué pour un attaquant d’inférer le fonctionnement du système d’IA visé. Si elles ne permettent pas de contrer toutes les attaques, les techniques de masquage de gradient (gradient masking) sont une étape importante de défense des systèmes d’IA (Papernot et al, 2017).
• Adapter les sorties : un modèle d’IA fournissant par définition toujours une réponse aux requêtes qui lui seront soumises, il s’agit de proposer une classe « abstention » / « ne sait pas » lorsque la prise de décision est incertaine.
• Détecter les sorties suspectes : il s’agit de comparer un résultat produit par rapport à des indicateurs de référence et lever une alerte en cas de doute (par exemple un historique d’interactions passées). La manière de traiter les anomalies doit ensuite être définie au cas par cas : arrêt du traitement, demande de réauthentification, alertes du superviseur du traitement, etc.
• Proposer une modération manuelle : dans certains cas, il peut être utile de soumettre les sorties produites à un opérateur afin que celui-ci s’assure du bon fonctionnement du système d’IA avant de renvoyer une réponse.

 

En fonction de la finalité du système d’IA, de son domaine d’emploi, des personnes à qui il se destine, de la stratégie d’apprentissage déployée (continue, ponctuelle, « une fois pour toutes »), etc. des risques différents sont susceptibles d’advenir. Il est donc recommandé de i) documenter les choix de conception, ii) superviser le fonctionnement du système, iii) identifier les personnes clés et encadrer le recours à des sous-traitants et iv) mettre en œuvre une stratégie de gestion des risques. L’article P[ɑ̃]nser la sécurité des systèmes d’IA précise comment peut être pensée une telle stratégie.

 

5.1 Documenter les choix de conception

 

La documentation est la pierre angulaire de la mise en œuvre d’un système d’IA sûr et résilient. Cette documentation doit refléter le cheminement qui a permis d’aboutir aux choix de conception mis en œuvre dans le système en production. Elle doit également être alimentée et mise à jour régulièrement et cela tout au long de l’utilisation du système d’IA. Pour ce faire, la CNIL propose aux professionnels un Guide d’auto-évaluation de son système d’IA avec un focus particulier sur l’utilisation de données à caractère personnelles. Par ailleurs, différentes ressources peuvent être mobilisées pour documenter son système et s’assurer de l’absence « d’angles morts ». On peut citer à titre d’exemples :

• La Certification de processus pour l’IA du Laboratoire national de métrologie et d’essais (LNE)
• L’outil ALTAI (Assessment List on Trustworthy Artificial Intelligence) développé par le groupe d’experts de haut niveau sur l’IA (GEHN IA) mis en place par la Commission européenne
• Le référentiel d’évaluation data sciences responsables et de confiance de l’association Labelia
• Le guide pratique pour des IA éthiques du syndicat professionnel Numeum
• L’outil d’évaluation de l'incidence algorithmique mis en œuvre par le gouvernement du Canada

 

5.2 Superviser le fonctionnement du système

 

Il est essentiel de s’assurer que le système d’IA ne dévie pas du comportement attendu et cela tout au long de sa durée de vie. Pour cela, il est indispensable d’anticiper dès le stade de la conception, la manière de suivre les évolutions du système et les indicateurs qui permettront d’opérer ce suivi. Développer une méthode d’évaluation rigoureuse est donc essentiel. Par ailleurs, il est indispensable de déployer un processus de maintien en conditions opérationnelles. Il s’agit d’assurer la conformité de la fonctionnalité d'IA aux spécifications définies après son déploiement et tout au long de sa phase d'exploitation.

Cette supervision est particulièrement critique pour la mise en place de systèmes d’apprentissage en continu, dans lesquels le modèle est mis à jour au gré de l’utilisation du système. Une mesure de l’évolution des performances du système au regard de paramètres clés ou la mise en place d’audits réguliers doivent être envisagés avant d’activer un apprentissage en continu.

Des exigences de traçabilité doivent donc être mises en œuvre. Les bonnes pratiques de traçabilité traditionnelles ne prennent pas en compte les complexités induites par l’apprentissage automatique. Il est ainsi essentiel de définir des exigences de traçabilité spécifiques, permettant notamment de garder des informations concernant les données soumises au système, paramètres qui conduisent aux décisions prises par les systèmes, etc.

 

5.3 Identifier les personnes clés et encadrer le recours à des sous-traitants

 

La mise en place d’une chaîne algorithmique complète est un exercice délicat qui mobilise les compétences de nombreux individus alliant des savoir-faire complémentaires. Il est donc nécessaire de déterminer ces compétences qui participent à la capacité des processus de conception, au développement du système d’IA, à son évaluation et au maintien en condition opérationnelle, au paramétrage des fonctionnalités d’IA et à la capacité à atteindre les résultats attendus.

Par ailleurs, un organisme peut dans certains cas décider d’avoir recours à des solutions d’IA développées par des fournisseurs externes. Il convient dans ce cas d’être vigilant car l’utilisation du système peut engager la responsabilité de l’organisme, notamment en matière de protection des données personnelles.  Il convient donc d’encadrer par un contrat la relation et les engagements du ou des sous-traitants afin notamment de préciser :

• Le cadre dans lequel le système d’IA doit évoluer
• Les exigences attendues et les modalités de contrôle et d’évaluation
• Les modalités de prise en compte des impératifs de protection des données personnelles
• Les mécanismes de gestion des risques déployés
• Le niveau de documentation souhaité
• Les modalités d’accès et d’utilisation des ressources (possibilité pour le sous-traitant de réutiliser les données, le modèle appris, etc.)
• Les besoins de réversibilité en fin de contrat
• La gestion des questions de propriété intellectuelle

 

5.4 Mettre en œuvre une stratégie de gestion des risques

 

Comme détaillé dans l’article P[ɑ̃]nser la sécurité des systèmes d’IA, une stratégie de gestion des risques et de résilience aux erreurs et éventuelles attaques doit être mise en place tout au long du processus de conception, développement, déploiement et mise en production du système d’IA. Elle doit être adaptée spécifiquement au problème à résoudre et alignée avec les impacts potentiels. En pratique, cette stratégie doit être élaborée en fonction de la sensibilité du traitement, des typologies de données traitées (données structurées, image, parole, texte, etc.), des stratégies d’apprentissage (continue, ponctuelle, « une fois pour toute »), des modalités d’exposition du système (interne, public, etc.), des étapes d’évaluation du système, etc.

 

Une telle stratégie doit permettre de responsabiliser les organismes en leur permettant de construire des systèmes d’IA sûrs et résilients et de démontrer leur conformité aux réglementations en vigueur comme par exemple le Règlement général sur la protection des données (RGPD). Il s’agit donc d’allier analyse de nature juridique concernant la mise en œuvre du système et mise à plat de mesures techniques et organisationnelles nécessaires pour le protéger ainsi que les actifs associés (données, modèles, paramétrisation, etc.). Cette stratégie doit permettre de :

• recenser de manière exhaustive et précise les différents systèmes d’IA déployés dans l’organisme
• sensibiliser et responsabiliser les équipes impliquées
• valider les choix de conception
• mesurer les risques impliqués relativement à la protection des données personnelles (éventuellement présents de façon résiduelle)
• préciser les modalités de sauvegarde et de gestion des données
• assurer la confidentialité, intégrité et disponibilité en déployant les mesures adéquates (restriction d’accès, chiffrement, etc.)
• définir un plan de continuité de l’activité

 

Les procédures et organisations mises en place pour assurer la conformité au RGPD ou la sécurité des systèmes d’information peuvent notamment être mobilisées pour inclure la gestion des risques spécifiques liés à l’utilisation de systèmes d’IA.