La démocratisation de l’empoisonnement des données par l’IA et comment protéger votre organisation

Les organisations intelligentes ont passé les trois dernières années à protéger leurs outils d’IA contre les attaques qualifiées de type injection rapide. L’hypothèse a été que l’empoisonnement du modèle fondateur, le véritable cerveau derrière les systèmes d’IA, nécessite une expertise technique, un accès privilégié ou un groupe de menace coordonné. Cette hypothèse n’est plus valable et marque un changement significatif dans la façon dont les organisations doivent penser à la sécurité de l’IA en général et à la désinfection des données de formation en particulier.

Des preuves récentes montrent qu’environ 250 documents ou images peuvent fausser le comportement d’un grand modèle de langage, quelle que soit sa taille. C’est très différent des hypothèses antérieures selon lesquelles il faudrait des milliers, voire des millions de points de données corrompus pour faire dévier un modèle. Cette nouvelle barre, 250, est suffisamment basse pour que les activistes, les influenceurs ou les concurrents puissent manipuler les résultats du modèle sans très peu de compétences techniques.

Les communautés en ligne ont déjà commencé à tester et même à empoisonner les données de formation de certains LLM. Il existe un sous-reddit spécifique qui encourage les utilisateurs à publier des faits fabriqués dans le but d’influencer les modèles d’IA. Il y a quelques années, ce genre d’effort n’aurait pas été pris au sérieux. Désormais, le domaine de la cybersécurité sait que la manipulation de l’IA est bien plus facile et accessible, et que le risque est bien plus grand que celui des gens qui s’amusent sur Reddit. Les criminels, les auteurs de menaces, les États-nations et même les individus peuvent générer du contenu sur des sites connus pour être ingérés dans les données de formation des LLM et empoisonner les données. Les adversaires peuvent injecter rapidement et facilement des données nuisibles ou biaisées dans le pipeline de formation ou dans le processus de réglage fin.

Même si nous comprenons depuis longtemps que les déchets entrants sont synonymes de déchets sortants, une autre expérience montre que les effets de données médiocres persistent longtemps après la fin de l’exposition. Une équipe de l’Université Purdue, de l’Université A&M du Texas et de l’Université du Texas à Austin a constaté qu’il existe des signes évidents de déclin des capacités à mesure que les modèles ingèrent du contenu indésirable, et que l’ajout ultérieur de données propres n’a pas complètement inversé le déclin. Tout système qui s’entraîne ou est réglé sur des données publiques est vulnérable à cette dérive du modèle à long terme si aucun contrôle de sécurité n’est mis en œuvre pour protéger le modèle.

En plus de la dégradation du modèle, des portes dérobées peuvent également être insérées dans les données de formation, ce qui permet aux attaquants de faire en sorte qu’un modèle fondamental se comporte de manière prévisible. Anthropic a publié un article sur ce sujet en octobre, dans lequel ils ont injecté une porte dérobée qui pourrait déclencher l’exfiltration de données. Ce type d’attaque est potentiellement très difficile à détecter, et la porte dérobée peut déclencher diverses actions de la part du modèle, pas seulement l’exfiltration de données.

Ces évolutions montrent clairement que l’empoisonnement des données s’étend bien au-delà des attaques ciblées hautement techniques. Un détaillant qui gère un chatbot IA orienté client pourrait voir ses réponses changer si quelqu’un soumettait à plusieurs reprises des avis synthétiques ou des plaintes exagérées, à moins que des contrôles de sécurité ne soient en place pour détecter ce type d’attaque. Les systèmes financiers pourraient faire apparaître des commentaires déformés sur une entreprise si suffisamment de bavardages falsifiés inondaient le flux de données sur lequel le modèle s’appuie pour obtenir de nouvelles données. Même l’économie d’influence présente des opportunités de manipulation des résultats, puisque des éloges ou des critiques répétés à l’égard d’un produit peuvent finir par convaincre un modèle que le sentiment est répandu.

Pour les organisations qui développent des outils d’IA, cela signifie que le paysage des menaces s’est élargi d’une manière qui nécessite des routines et des protections supplémentaires.

L’une des protections les plus fiables consiste à établir une version propre et validée du modèle avant le déploiement. Vous pouvez considérer cela comme une version « or » de votre modèle de confiance que vous utilisez comme base de référence pour les contrôles d’anomalies. Cette version Gold devient le point de référence que les équipes peuvent rapidement vérifier ou restaurer si nécessaire à tout moment, ce qui n’est pas sans rappeler la restauration d’un appareil aux paramètres d’usine. Si le modèle commence à produire des résultats inattendus ou montre des signes précoces de dérive, le retour à la ligne de base propre évite le coût du temps d’incertitude lié à la tentative de retracer les entrées qui ont provoqué le changement.

Un programme de réinitialisation régulier peut également limiter l’impact d’un empoisonnement ; ramener le système à un état de propreté connu, peut-être une fois par semaine, peut empêcher l’accumulation de longues périodes d’entrées non vérifiées ou manipulées.

La surveillance des données qui entrent dans le modèle est une autre étape importante. Les équipes doivent rechercher des schémas anormaux, des phrases répétées, des explosions soudaines de soumissions similaires ou des tentatives coordonnées pour orienter le modèle dans une direction spécifique. Ce type de surveillance existe déjà dans le domaine de la sécurité des réseaux et des applications et son extension aux entrées du modèle permet de détecter précocement les manipulations. Considérez-le comme un filtrage par injection rapide. Les filtres d’applications Web (WAF) protègent les bases de données contre les attaques par injection SQL. Vous aurez également besoin d’un filtre LLM pour empêcher l’empoisonnement du modèle. Empêcher la saisie de données inutiles peut limiter le risque de manipulation du modèle.

Les outils de détection des menaces IA qui simulent des attaques avancées spécifiques à l’IA prennent également en charge ce type d’évaluation. Vous devriez faire effectuer des tests contradictoires sur vos outils d’IA, comme vous le faites pour vos applications Web et vos applications mobiles. De nouvelles solutions de sécurité arrivent sur le marché, qui identifient également les vulnérabilités cachées des systèmes basés sur l’IA. Des outils de sécurité capables de simuler des attaques par injection rapide, un empoisonnement du modèle de données et même de tester le modèle avec des entrées déformées sont à venir pour aider à se défendre contre ces attaques.

En réfléchissant à vos projets d’IA, vous souhaitez changer votre état d’esprit pour intégrer ces nouvelles menaces. L’intégrité des modèles doit être traitée comme un pilier central de votre stratégie de sécurité de l’IA, vos équipes sachant à quel point ce type d’empoisonnement de modèle est devenu facile et accessible. De nombreuses équipes se concentrent fortement sur la confidentialité et le contrôle d’accès, mais ces mesures de protection n’ont aucun effet si le modèle apprend à partir de données peu fiables ou manipulées. Quiconque construit un outil d’IA qui interagit avec les contributions du public ou le contenu généré par les utilisateurs doit supposer que des tentatives d’influencer son comportement se produiront et se préparer en conséquence.

Les outils d’IA deviennent essentiels à la prise de décision dans tous les secteurs, ce qui rend l’intégrité des données plus importante que jamais. Les équipes qui prennent ces risques au sérieux dès le départ seront en mesure de maintenir la fiabilité de leurs systèmes, même si les informations qui les entourent deviennent de plus en plus faciles à manipuler.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?