Incursion dans la caisse à outils de la sécurité des grands modèles de langage (1/2) : risques visés et sécurité dès la conception

L’utilisation d’agents conversationnels implique trois catégories de risques particuliers pour les données personnelles :

1.  la reconstruction des données d’entrainement lors de l’utilisation,
2.  le traitement des données fournies dans l’invite de ces outils,
3.  ainsi que celui des sorties qui peuvent parfois directement concerner un individu.

Au regard des utilisations qui en sont constatées actuellement (de la synthèse de documents médicaux aux petites amies artificielles), la nécessité de protéger les données entrées dans l’invite semble tomber sous le sens. Les risques concernant les sorties sont également déjà observés lorsqu’un agent est interrogé sur une personne et génère des informations fausses, et parfois toxiques, le concernant. Enfin, étant acté que les données d’entraînement peuvent être mémorisées par les modèles d’IA lors de leur entraînement, la protection de ces données lors de l’utilisation des modèles pose question. Des solutions, comme l’anonymisation des données d’entraînement ou le désapprentissage machine, existent afin de limiter ces risques en amont du déploiement d’un système, mais elles possèdent des limitations. Lorsque les données d’entraînement ne peuvent être anonymisées à cause, par exemple, de la détérioration des performances du modèle, ou que les solutions envisagées n’apportent pas le niveau de sécurité souhaité, les mesures activables lors de l’utilisation du modèle peuvent être une garantie additionnelle permettant un déploiement plus sécurisé.

Ces deux articles portent en particulier sur les Grands Modèles de Langage, ou GML (LLM en anglais), mais certaines des techniques utilisées pourraient s’étendre à d’autres catégories de contenus, ainsi qu’à des systèmes multimodaux. Dans ce premier article, les risques que ces techniques tentent de réduire, ainsi que les mesures de sécurité portant sur la conception du système sont abordées en se concentrant sur les questions liées à la protection des données personnellesLe second article recense quant à lui les techniques observées pour sécuriser les systèmes lors de leur utilisation. Il détaille certaines de leurs capacités et limitations telles que décrites dans la littérature académique.

A quels risques répond-on ?

Par des opérations réalisées sur le modèle lui-même, sur les données d’entrée ou les réponses du GML, les mesures de sécurité s’appliquent dans de nombreux cas d’usages. Les risques évalués ci-dessous ne concernent toutefois que la protection des données personnelles, qu’elles soient traitées pour l’entraînement ou lors de l’utilisation.

La divulgation de données personnelles 

Par régurgitation

Tout d’abord, les sorties produites par les GML (ou générations) peuvent contenir des données personnelles ou confidentielles provenant des données d’entraînement. Cette génération peut s’apparenter à une reproduction lorsque ces informations sont présentes dans le jeu d’apprentissage et qu’elles ont été mémorisées lors de l’apprentissage, comme montré notamment par Carlini et al., 2021, ou par la reproduction d’articles du New York Times par ChatGPT, comme relaté par The Verge. On parle alors d’une régurgitation. Cette catégorie de risques peut avoir des conséquences importantes sur la confidentialité des données personnelles, notamment lorsqu’un GML a été entrainé sur des données sensibles ou dont la divulgation pourrait avoir des conséquences graves pour les personnes.

Par inférence d’appartenance ou inversion de modèle

Les risques liés à la protection des données personnelles ne s’arrêtent pas à la régurgitation. Certaines attaques comme les attaques par inférence d’appartenance (Membership Inference Attacks en anglais), ou par inversion de modèle peuvent permettre de divulguer des informations sur les personnes dont les données sont utilisées pour l’entraînement. Ces attaques sont décrites en détail dans l’article « Petite taxonomie des attaques des systèmes d’IA ». Elles pourraient permettre de reconstituer un courrier médical utilisé pour l’entraînement, ou encore d’apprendre qu’une personne souffre d’une pathologie particulière propre à la cohorte médicale à laquelle elle appartient.

L’insertion de portes dérobées

Une autre catégorie d’attaques concerne l’insertion de portes dérobées, ou backdoors, lors de l’entraînement. Il s’agit pour un GML de lui apprendre à reproduire un comportement particulier comme la génération d’un texte particulier en l’entraînant sur des données choisies ou conçues pour cela. Ces attaques n’ont généralement pas pour objectif d’accéder aux données d’entraînement, mais plutôt de contourner un dispositif de sécurité ou d’inciter l’utilisateur à divulguer certaines informations. Elles sont souvent indétectables dans le comportement normal des GML (d’où leur nom) mais peuvent être activées lorsqu’une certaine requête est fournie, comme illustré par Rando et Tramèr, 2024 dans le cas des données utilisées pour le RLHF (apprentissage par renforcement à partir de la rétroaction humaine). Elles peuvent se fonder sur la génération de code malicieux, qui une fois exécuté permettra un accès à l’attaquant, ou lui fournira des informations confidentielles comme des jetons d’accès. D’autres attaques plus généralistes peuvent générer un texte malveillant invitant l’utilisateur à communiquer des informations confidentielles.

La génération d’hallucinations

La production d’informations fausses est parfois due à leur présence dans le corpus d’entraînement, mais elle peut aussi avoir pour cause le caractère purement probabiliste du fonctionnement des GML. Lorsque le modèle génère une réponse factuellement fausse en sélectionnant la suite de jetons, ou tokens, la plus probable, on parle d’hallucinations. Celles-ci peuvent poser problème au regard de la protection de la vie privée lorsque l’information générée concerne des personnes physiques. Ce risque a notamment été illustré récemment lorsqu’un journaliste s’est vu attribuer par l’IA de Copilot des crimes sur lesquels il avait enquêté, comme relaté dans cet article dans The Conversation.

La génération de réponses toxiques

Les sorties des GML peuvent également ne pas être conformes aux attentes des déployeurs et de leurs utilisateurs, et proposer des contenus haineux, violent ou extrémiste. La production de ces contenus peut être due à deux causes principales :

• La présence de contenu similaire dans le jeu d’entraînement conduisant le modèle à les reproduire lors de l’utilisation,
• Une demande expresse de l’utilisateur de générer de tels contenus. Cette demande peut se faire de manière directe, ou via l’utilisation de procédés de contournement des protections mises en place : on parle dans ce deuxième cas de débridage système ou « jailbreak », comme illustré par Perez et Ribeiro, 2022 ou Wei et al., 2023.

Ces générations peuvent être utilisées afin de produire du contenu en masse à diffuser sur les réseaux sociaux, de contribuer à la communication d’acteurs extrémistes, ou de faciliter certains actes malveillant (comme la production de code informatique malicieux). Elles peuvent aussi atteindre à la réputation d’une personne lorsqu’elles concernent un individu.

 Le détournement des données fournies dans l’invite

Enfin, les risques peuvent être liés à la divulgation de données protégées dans l’invite de l’outil. Ces informations pourraient être récupérées par le déployeur du système à des fins malveillantes, ou détournées de leur finalité première. D’une manière générale, ces données protégées encourent un risque lorsqu’elles sont partagées à des acteurs n’ayant pas à y avoir accès, notamment du fait que ces acteurs sont alors en charge de la sécurité des informations qui leur sont fournies. La sécurité des données d’entrée fournies aux agents est ainsi également dans le périmètre de notre étude.

Chacun de ces risques est visé dans cet article, toutefois, l’angle choisi portant sur la technique et non sur les risques, seules certaines des solutions permettant de s’en prémunir seront abordées. Parmi ces techniques, une distinction peut être effectuée entre celles portant

• sur la sécurité du système dans son ensemble : détaillées dans la suite de cette page, 
• sur les requêtes (les données d’entrée inscrites dans l’invite de l’agent) : détaillées dans le second article,
• sur les sorties produites par le GML : également détaillées dans le second article.

Un chatbot sécurisé en vaut deux

Les mesures correctrices venant s’appliquer lors de l’utilisation de l’outil, c’est-à-dire au dernier moment, sont promues par les industriels et ont un intérêt certain. Toutefois, certaines techniques sont applicables dès la phase de conception du système et leur utilité ne doit pas être négligée. La suite de cet article recense ces techniques, sans chercher à les détailler ou à en évaluer l’efficacité.

La diversité ne manque pas dans ce champ, tel qu’en témoignent les recensement effectués par Patel et al., 2024, Yao et al., 2024, Chawin ou Yan et al., 2024. Cependant, ces mesures présentent généralement des inconvénients liés à la performance du modèle obtenu, à leur coût (en ressources et en compétence), ou à la gouvernance (seuls les développeurs de modèles seront généralement à même de les mettre en œuvre ou de les proposer). De plus, en majorité, aucune garantie formelle n’est apportée par ces solutions qui peuvent également faire l’objet d’attaques, bien qu’elles permettent d’éliminer une grande partie des risques dans un scénario idéal. Ainsi, les techniques de filtrage trouvent leur intérêt puisqu’il s’agit de solutions pouvant être ajoutées à un modèle sur étagère, et pouvant être implémentées plus facilement par les déployeurs, notamment grâce à des outils ouverts.

Les mesures portants sur les données d’entraînement, comme

• l’anonymisation, par des procédés de confidentialité différentielle, ou differential privacy par exemple, ou  
• le nettoyage des données, visant à supprimer les données directement identifiantes non pertinentes, ou à éviter la mémorisation par la déduplication des données par exemple ;

 Les mesures portant sur l’architecture du modèle :

• Yao et al., 2024 fournit un recensement de publications tendant à montrer que certains modèles sont plus robustes aux attaques (notamment au débridage système), plus adaptés à l’utilisation de la confidentialité différentielle lors de l’apprentissage, ou bien que l’utilisation de graphes de connaissance ou d’architectures cognitives peut améliorer la sécurité ;

Les mesures portant sur le protocole d’apprentissage utilisé, comme

• la confidentialité différentielle appliquée lors de l’apprentissage qui permet d’obtenir un modèle anonyme quand la quantité de bruit ajoutée est suffisante (parfois au détriment de la qualité de la performance du modèle obtenu),
• le choix des hyperparamètres permettant de limiter la mémorisation lors de l’apprentissage, tel que décrit par Berthelier et al., 2023,
• les méthodes de généralisation, qui permettent de renforcer la robustesse aux attaques. Parmi celles-ci se trouve l’apprentissage adverse, illustré par le protocole proposé par Liu et al., 2020, qui fait de la robustesse aux attaques adverses un objectif de l’apprentissage directement intégré dans la fonction de coût,
• les techniques d’apprentissage décentralisé (comme l’apprentissage fédéré) qui permettent davantage de traçabilité sur les données d’entraînement (et ainsi d’éviter l’empoisonnement des données notamment),
• l’ajustement « off-site » (décrit par Xiao et al., 2023), où le développeur du modèle conserve le contrôle sur le modèle pré-entraîné et le déployeur le contrôle sur les données d’ajustement. Cette technique permet d’éviter à la fois la communication du GML pré-entraîné et des données d’ajustement,
• les techniques de chiffrement qui évitent la divulgation de secrets lors de l’entraînement ou complexifient les attaques portant sur le modèle (comme le chiffrement homomorphe qui est utile pour l’entraînement de certains modèles, ou les techniques de calcul multipartite sécurisé).

Les mesures portant sur le modèle pré-entraîné, comme

• le choix du modèle, lorsqu’un modèle pré-entraîné est sélectionné depuis l’étagère. Ce choix peut inclure des critères tel que la mise en œuvre des mesures précédentes lors de son développement, davantage de transparence dans son développement, une meilleure gouvernance, ou de meilleurs résultats obtenus dans un benchmark (tel que celui proposé par l’Université d’Edimbourg comparant le risque d’hallucinations de plusieurs GML, ou celui proposé par Mireshghallah et al., 2023 qui compare la propension de plusieurs modèles à respecter la confidentialité des informations contenues dans l’historique de conversation),
• les méthodes de désapprentissage machine, auxquelles un article du Linc a été consacré, et qui permettent d’effacer l’influence de certaines données sur les paramètres d’un modèle,
• l’apprentissage par renforcement : encore mouvant, ce domaine vise à ajuster le modèle de telle sorte à ce qu’il suive certaines règles sans que celles-ci ne lui soient imposées comme contraintes explicites. Elles nécessitent une rétroaction pouvant être de deux types :
  • humaine, dans le cas de la RLHF pour reinforcement learning from human feeback, où le modèle pré-entraîné est ajusté par un protocole spécifique. Ce protocole peut nécessiter l’entraînement d’un modèle tiers appelé modèle de récompense sur une base de données labelisées par l’humain. De plus, de nouvelles méthodes permettant de se passer de la phase d’apprentissage par renforcement émergent, comme la Direct Preference Optimization, proposée par Rafailov et al., 2023, qui intègre l’alignement dans la fonction de coût utilisée pour l’entraînement,
  • automatique, provenant d’une autre IA, dont le principe est le même que celui du RLHF, mais où la rétroaction est produite par un modèle paramétré pour suivre certains principes. Ces principes peuvent être contenus dans une « constitution », terme introduit par Bai et al., 2022.

Les mesures portant sur l’inférence, comme le choix des hyperparamètres tels que la température (qui permet d’augmenter artificiellement la probabilité de générer une réponse moins probable et ainsi de favoriser la créativité au détriment de la prédictibilité).

Ces mesures qui permettent de déployer un système sécurisé sont importantes mais ne sont pas applicables dans tous les cas, notamment selon la fonctionnalité du modèle, les catégories de données traitées, ou encore selon la maîtrise du déployeur sur le système. Ainsi des mesures complémentaires, visant à sécuriser le système dans lequel est intégré le modèle d’IA peuvent être utiles, afin de sécuriser le déploiement sur le vif. Pour en savoir plus, lisez la suite (Lien).