Les pirates éthiques de l’IA de Microsoft fournissent quelques réponses, ainsi que d’autres questions.
Le groupe responsable de l’équipe rouge de plus de 100 produits d’IA générative chez Microsoft a conclu que le travail de création de systèmes d’IA sûrs et sécurisés ne sera jamais terminé.
Dans un article publié cette semaine, les auteurs, dont Mark Russinovich, directeur technique de Microsoft Azure, ont décrit une partie du travail de l’équipe et ont fourni huit recommandations conçues pour « aligner les efforts de l’équipe rouge sur les risques du monde réel ».
L’auteur principal Blake Bullwinkel, chercheur au sein de l’équipe rouge de l’IA chez Microsoft, et ses 25 co-auteurs ont écrit dans l’article : « À mesure que les systèmes d’IA générative (genAI) sont adoptés dans un nombre croissant de domaines, l’équipe rouge de l’IA est devenue une solution. pratique centrale pour évaluer la sûreté et la sécurité de ces technologies.
À la base, ont-ils déclaré : « L’équipe rouge de l’IA s’efforce d’aller au-delà des références de sécurité au niveau du modèle en émulant des attaques du monde réel contre des systèmes de bout en bout. Cependant, de nombreuses questions restent ouvertes sur la manière dont les opérations de red teaming devraient être menées et une bonne dose de scepticisme quant à l’efficacité des efforts actuels de red teaming en matière d’IA.
Le document note que, lors de sa création en 2018, la Microsoft AI Red Team (AIRT) s’est principalement concentrée sur l’identification des vulnérabilités de sécurité traditionnelles et des attaques d’évasion contre les modèles classiques de ML. « Depuis lors », a-t-il déclaré, « la portée et l’ampleur de l’équipe rouge de l’IA chez Microsoft se sont considérablement élargies en réponse à deux tendances majeures. »
La première, dit-il, est que l’IA est devenue plus sophistiquée, et la seconde est que les récents investissements de Microsoft dans l’IA ont abouti au développement de nombreux autres produits nécessitant une équipe rouge. « Cette augmentation de volume et la portée élargie de l’équipe rouge de l’IA ont rendu les tests entièrement manuels peu pratiques, nous obligeant à intensifier nos opérations à l’aide de l’automatisation », ont écrit les auteurs.
« (Pour atteindre) cet objectif, nous avons développé PyRIT, un framework Python open source que nos opérateurs utilisent largement dans les opérations de red teaming. En augmentant le jugement humain et la créativité, PyRIT a permis à AIRT d’identifier plus rapidement les vulnérabilités les plus importantes et de couvrir une plus grande partie du paysage des risques.
Sur la base de leurs expériences, Bullwinkel et l’équipe d’auteurs ont partagé huit leçons qu’ils ont apprises et les ont développées dans le document à travers des explications détaillées et des études de cas. Ils comprenaient :
Comprendre ce que le système peut faire et où il est appliqué : La première étape d’une opération d’équipe rouge en matière d’IA consiste à déterminer les vulnérabilités à cibler, ont-ils déclaré. Ils suggèrent : « en partant des impacts potentiels en aval, plutôt que des stratégies d’attaque, il est plus probable qu’une opération produise des résultats utiles liés aux risques du monde réel. Une fois ces impacts identifiés, les équipes rouges peuvent travailler à rebours et définir les différentes voies qu’un adversaire pourrait emprunter pour les atteindre.
Vous n’avez pas besoin de calculer des dégradés pour casser un système d’IA : Pour prouver ce point, l’article cite une étude sur l’écart entre la recherche et la pratique du ML contradictoire. L’étude révèle « que même si la plupart des recherches sur le ML contradictoire se concentrent sur le développement et la défense contre des attaques sophistiquées, les attaquants du monde réel ont tendance à utiliser des techniques beaucoup plus simples pour atteindre leurs objectifs ». Les attaques basées sur les gradients sont puissantes, affirment les auteurs, « mais elles sont souvent peu pratiques ou inutiles. Nous recommandons de donner la priorité aux techniques simples et d’orchestrer les attaques au niveau du système, car celles-ci sont plus susceptibles d’être tentées par de véritables adversaires.
L’équipe rouge de l’IA n’est pas une analyse comparative de la sécurité : Selon les auteurs, les deux sont distincts mais « à la fois utiles et peuvent même être complémentaires. En particulier, les benchmarks facilitent la comparaison des performances de plusieurs modèles sur un ensemble de données commun. L’équipe rouge de l’IA nécessite beaucoup plus d’efforts humains, mais peut découvrir de nouvelles catégories de préjudices et sonder les risques contextualisés. Les nouveaux préjudices résultant des nouvelles capacités des systèmes d’IA peuvent ne pas être entièrement compris, l’équipe doit donc les définir et créer des outils pour les mesurer.
L’automatisation peut aider à couvrir une plus grande partie du paysage des risques : Selon les auteurs, « la complexité du paysage des risques liés à l’IA a conduit au développement d’une variété d’outils capables d’identifier les vulnérabilités plus rapidement, d’exécuter automatiquement des attaques sophistiquées et d’effectuer des tests à une échelle beaucoup plus grande ». L’automatisation dans l’équipe rouge de l’IA joue un rôle essentiel, ce qui a conduit au développement d’un framework open source, PyRIT.
L’élément humain de l’équipe rouge de l’IA est crucial : L’automatisation est peut-être importante, mais les auteurs ont souligné que, même si « une automatisation comme PyRIT peut soutenir les opérations d’équipe rouge en générant des invites, en orchestrant des attaques et en notant les réponses », les humains sont nécessaires pour leur connaissance culturelle et thématique, ainsi que pour leur intelligence émotionnelle. Ils ont noté que « ces outils sont utiles mais ne doivent pas être utilisés dans le but de mettre l’humain hors de la boucle ».
Les méfaits de l’IA responsable (RAI) sont omniprésents mais difficiles à mesurer : L’essentiel ici : les dommages causés par le RAI sont plus ambigus que les vulnérabilités de sécurité et tout cela est lié aux « différences fondamentales entre les systèmes d’IA et les logiciels traditionnels ». La plupart des recherches sur la sécurité de l’IA, notent les auteurs, se concentrent sur les utilisateurs adverses qui brisent délibérément les garde-fous, alors qu’en réalité, affirment-ils, les utilisateurs inoffensifs qui génèrent accidentellement du contenu préjudiciable sont tout aussi importants, voire plus.
Les LLM amplifient les risques de sécurité existants et en introduisent de nouveaux : Le conseil ici ? L’intégration de modèles d’IA génératifs dans diverses applications a introduit de nouveaux vecteurs d’attaque et modifié le paysage des risques de sécurité. Les auteurs ont écrit que « nous encourageons donc les équipes rouges de l’IA à prendre en compte à la fois les risques existants (généralement au niveau du système) et les risques nouveaux (généralement au niveau du modèle). »
Le travail de sécurisation des systèmes d’IA ne sera jamais terminé : L’idée selon laquelle il est possible de garantir ou de « résoudre » la sécurité de l’IA grâce aux seuls progrès techniques est irréaliste et néglige les rôles que peuvent jouer l’économie, les cycles de réparation et de réglementation, ont-ils déclaré. Dans cette optique, le document souligne qu’« en l’absence de garanties de sûreté et de sécurité, nous avons besoin de méthodes pour développer des systèmes d’IA aussi difficiles à briser que possible. Une façon d’y parvenir consiste à utiliser des cycles de réparation et de réparation, qui effectuent plusieurs cycles d’équipe rouge et d’atténuation jusqu’à ce que le système soit robuste face à un large éventail d’attaques.
Les auteurs du rapport ont conclu que l’équipe rouge de l’IA est une pratique naissante et en évolution rapide pour identifier les risques de sûreté et de sécurité posés par les systèmes d’IA. Mais ils ont également soulevé un certain nombre de questions.
« Comment devrions-nous rechercher les capacités dangereuses des LLM, telles que la persuasion, la tromperie et la réplication ? » ont-ils demandé. « En outre, quels nouveaux risques devrions-nous rechercher dans les modèles de génération vidéo et quelles capacités pourraient émerger dans des modèles plus avancés que l’état de l’art actuel ? »
Deuxièmement, ils ont demandé comment les équipes rouges pouvaient ajuster leurs pratiques pour s’adapter à différents contextes linguistiques et culturels. Et troisièmement, ils se demandent de quelle manière les pratiques des équipes rouges devraient être standardisées pour permettre aux équipes de communiquer plus facilement leurs conclusions.
Ils ont également déclaré : « Alors que les entreprises, les instituts de recherche et les gouvernements du monde entier se demandent comment procéder à des évaluations des risques liés à l’IA, nous fournissons des recommandations pratiques basées sur notre expérience en matière de collaboration avec plus de 100 produits genAI chez Microsoft. … Nous encourageons les autres à s’appuyer sur ces leçons et à répondre aux questions ouvertes que nous avons soulignées.