Red-teaming : vers des tests de robustesse de l’IA dans l’intérêt du public

Le Red-teaming consiste à réunir des équipes multidisciplinaires pour procéder à des attaques fictives pour éprouver la robustesse de la sécurité d’un système informatique. Dans le domaine de l’IA, cela consiste à identifier les vulnérabilités des réponses d’un modèle de langage pour les corriger. Mais les questions méthodologiques auxquelles sont confrontées ces équipes sont nombreuses : comment et quand procéder ? Qui doit participer ? Comment intégrer les résultats… Les questions d’enjeux ne sont pas moindres : quels intérêts sont protégés ? Qu’est-ce qu’un comportement problématique du modèle et qui est habilité à le définir ? Le public est-il un objet à sécuriser ou une ressource utilisée ?…   

Un rapport publié par Data & Society et AI Risk and Vulnerability Alliance (ARVA), par les chercheurs Ranjit Singh, Borhane Blili-Hamelin, Carol Anderson, Emnet Tafesse, Briana Vecchione, Beth Duckles et Jacob Metcalf, tente d’esquisser comment produire un red-teaming dans l’intérêt public.

À ce jour, la plupart des expériences de red-teaming en IA générale comportent quatre étapes : 

• Organiser un groupe de penseurs critiques.
• Leur donner accès au système. 
• Les inviter à identifier ou à susciter des comportements indésirables. 
• Analyser les données probantes pour atténuer les comportements indésirables et tester les futurs modèles. 

Actuellement, la méthode dominante pour réaliser la troisème étape est l’incitation manuelle et automatisée, qui consiste à tester les comportements erronés des modèles par l’interaction. Pour les chercheurs, qui ont recueilli les avis de participants à des équipes de red-teaming, si cette approche est précieuse, le red-teaming doit impliquer une réflexion critique sur les conditions organisationnelles dans lesquelles un modèle est construit et les conditions sociétales dans lesquelles il est déployé. Le red-teaming dans d’autres domaines, comme la sécurité informatique, révèle souvent des lacunes organisationnelles pouvant entraîner des défaillances du système. Les évaluations sociotechniques de l’IA générale gagneraient à s’inspirer davantage des pratiques existantes en matière de red-teaming et d’ingénierie de la sécurité. 

Pour les chercheurs, les événements de Red-Teaming soulignent trop souvent encore l’asymétrie de pouvoir et limitent l’engagement du public à la seule évaluation des systèmes déjà construits, plutôt qu’aux systèmes en développement. Ils favorisent trop l’acceptation du public, le conduisant à intégrer les défaillances des systèmes, plutôt qu’à les résoudre ou les refuser. Enfin, ils restreignent la notion de sécurité et ne prennent pas suffisamment en cause les préjudices qu’ils peuvent causer ou les modalités de recours et de réparation proposé au grand public. 

Le rapport dresse une riche histoire des pratiques d’amélioration de la sécurité informatique et de ses écueils, et de la faible participation du public, même si celle-ci a plutôt eu tendance à s’élargir ces dernières années. Reste que cet élargissement du public est encore bien timide. Il s’impose surtout parce qu’il permet de répondre au fait que l’IA générative couvre un large champ d’usages qui font que chaque prompt peut être une attaque des modèles. “L’objectif du red-teaming est de compenser le manque de bonnes évaluations actuelles pour les modèles génératifs”, explique une spécialiste, d’autant qu’il permet de créer “une réflexivité organisationnelle”, notamment du fait que les interactions avec les modèles sont très ouvertes et nécessitent d’élargir les perspectives de sécurité. Mais les pratiques montrent également la difficulté à saisir ce qui relève des défaillances des modèles, d’autant quand ce sont les utilisateurs eux-mêmes qui sont considérés comme des adversaires. Pourtant, dans ces pratiques de tests de robustesse adverses, les risques n’ont pas tous le même poids : il est plus simple de regarder si le modèle génère des informations privées ou du code vulnérable, plutôt que d’observer s’il produit des réponses équitables. En fait, l’une des grandes vertus de ces pratiques, c’est de permettre un dialogue entre développeurs et publics experts, afin d’élargir les enjeux de sécurité des uns à ceux des autres.

Le rapport souligne cependant que l’analyse automatisée des vulnérabilités se renforce (voir “Comment les IA sont-elles corrigées ?”), notamment via l’utilisation accrue de travailleurs du clic plutôt que des équipes dédiées et via des systèmes spécialisés dédiés et standardisés, prêts à l’emploi, afin de réduire les coûts de la correction des systèmes et ce même si ces attaques-ci pourraient ne pas être aussi “novatrices et créatives que celles développées par des humains”. Le risque c’est que le red-teaming ne devienne performatif, une forme de “théâtre de la sécurité”, d’autant que le régulateur impose de plus en plus souvent d’y avoir recours, comme c’est le cas de l’AI Act européen. Or, comme le pointe un red-teamer, “ce n’est pas parce qu’on peut diagnostiquer quelque chose qu’on sait comment le corriger”. Qui détermine si le logiciel respecte les règles convenues ? Qui est responsable en cas de non-respect des règles ? L’intégration des résultats du red-teaming est parfois difficile, d’autant que les publications de leurs résultats sont rares. D’où l’importance des plateformes qui facilitent le partage et l’action collective sur les problèmes d’évaluation des systèmes d’IA, comme Dynabench. 

“Nous devons repenser la relation entre l’IA et la société, passant d’une relation conflictuelle à une relation co-constitutive”, plaident les chercheurs. C’est la seule à même d’aider à dépasser la confusion actuelle sur la fonction du red-teaming, qu’elle relève des conflits de méthodes, de pouvoir, d’autorité ou d’expertise. Les meilleures pratiques ne le sont pas nécessairement. Le Titanic a été construit selon les meilleures pratiques de l’époque. Par définition, le red-teaming consiste à examiner les réponses des modèles de manière critique, mais uniquement selon les meilleures pratiques du moment. Le red-teaming a tendance à porter plus d’attention aux méthodes holistiques de red-teaming (comme les simulations) qu’à ceux qui se concentrent sur l’évaluation des dommages causés par l’IA aux utilisateurs normaux. Trop souvent encore, le red-teaming consiste à améliorer un produit plus qu’à améliorer la sécurité du client, alors que le red-teaming élargi aux publics consiste à mieux comprendre ce qu’ils considèrent comme problématique ou nuisible tout en leur permettant d’être plus conscients des limites et défaillances. Pour les chercheurs, nous avons plus que jamais besoin “d’espaces où le public peut débattre de ses expériences avec les systèmes d’IA générale”, d’espaces participatifs, disaient déjà une précédente recherche de plusieurs de ces mêmes chercheurs. Le risque, c’est que cet élargissement participatif que permet certains aspects du red-teaming ne se referme plus qu’il ne s’étende.