Planification du Red Teaming pour l’IA
Le processus de Red Teaming est une bonne pratique dans le développement responsable d’applications et de systèmes qui utilisent des grands modèles de langage (LLM). Le Red Teaming complète le travail systématique de mesure et d’atténuation effectué par les développeurs et aide à découvrir et identifier les préjudices. Les équipes rouges aident également à activer les stratégies de mesure pour valider l’efficacité de l’atténuation.
Lorsque vous planifiez votre approche du red teaming des modèles de langage et des applications activées par l’IA, tenez compte des objectifs suivants :
- Assurez-vous que les protocoles de sécurité logicielle appropriés sont suivis pour l’application : l’IA ne vous exempte pas des pratiques de sécurité traditionnelles
- Testez le modèle de base LLM et déterminez s’il existe des lacunes dans les systèmes de sécurité existants, en fonction du contexte de votre application
- Fournir des commentaires sur les échecs que les tests découvrent pour améliorer les performances
Le processus d’association rouge IA comporte quatre phases : recruter l’équipe, concevoir des tests contradictoires, effectuer des tests et produire des résultats de rapport.
Recruter l'équipe rouge
Le succès de l'équipe rouge d’IA dépend des personnes que vous recrutez. Lors de la sélection des membres de l’équipe rouge, suivez ces principes :
- Sélectionnez une expérience et une expertise variées : recherchez les membres de l’équipe rouge avec différents antécédents, domaines d’expertise et cas d’usage pour le système cible. Par exemple, si vous recherchez un chatbot de santé, une infirmière a une approche différente de celle d’un administrateur de systèmes qui gère l’infrastructure du chatbot.
- Incluez à la fois les mentalités adverses et bénignes : contrairement aux équipes rouges traditionnelles dotées uniquement d'experts en sécurité, les équipes rouges IA doivent également inclure des utilisateurs ordinaires. Les utilisateurs réguliers peuvent découvrir des comportements dangereux par le biais de modèles d’interaction naturels que les professionnels de la sécurité peuvent ne pas penser à tester. Par exemple, une infirmière peut convaincre un chatbot de libérer des données confidentielles sur les patients d’une manière qu’un professionnel de la sécurité n’envisagerait pas.
- Affecter des membres de l’équipe à des risques et fonctionnalités spécifiques : attribuez des membres avec une expertise spécifique pour détecter des types spécifiques de risques (par exemple, les experts en sécurité sondent pour les jailbreaks et l’extraction de métaprompts. Pour plusieurs rondes, envisagez de faire pivoter les affectations pour apporter de nouvelles perspectives tout en permettant un ajustement.
- Fournissez des objectifs clairs : donnez à chaque membre de l’équipe des instructions claires couvrant l’objectif, les fonctionnalités du produit à tester, les types de problèmes à examiner, les attentes temporelles et la façon d’enregistrer les résultats.
Fournissez un moyen cohérent d’enregistrer les résultats, notamment la date, un identificateur unique pour la reproductibilité, l’invite d’entrée et une description ou une capture d’écran de la sortie.
Concevoir des tests contradictoires
Étant donné qu’une application est générée à l’aide d’un modèle de base, testez les deux couches :
- Le modèle de base LLM avec son système de sécurité en place, généralement par le biais d’un point de terminaison d’API, pour identifier les lacunes qui doivent être abordées dans le contexte de votre application
- L’application compatible avec l’IA via son interface utilisateur, pour tester le système complet, y compris les mécanismes de sécurité au niveau de l’application
Les équipes rouge doivent tester les deux couches avant et après que les atténuations ont été mises en place.
Effectuer des tests
Commencez par tester le modèle de base pour comprendre la surface des risques et guider le développement d’atténuation. Testez de manière itérative avec et sans atténuations pour évaluer leur efficacité. Utilisez à la fois des mesures manuelles et des mesures systématiques et testez l’interface utilisateur de production autant que possible pour répliquer l’utilisation réelle.
Structurez vos tests autour de ces activités :
Déterminer l’étendue du préjudice
Commencez par des stratégies d’organisation sur l’intelligence artificielle et la sécurité ou l’IA responsable, ainsi que les réglementations de conformité. Collaborez avec vos équipes juridiques et stratégiques pour identifier les préjudices les plus importants pour cette application. Le résultat est une liste hiérarchisée de préjudices avec des exemples.
Les red teamers créatifs trouvent souvent des dommages qui n’ont pas été prédits par les stratégies organisationnelles. Plusieurs organisations ont subi des dommages de réputation lorsque le public a découvert des résultats d’IA problématiques qui n’ont pas été testés. Une équipe rouge créative est plus susceptible de découvrir ces problèmes avant la mise en production.
Étendre la liste via des tests ouverts
Compléter la liste pilotée par les politiques avec des préjudices détectés par l’exploration créative. Hiérarchiser les dommages pour les tests itératifs en fonction de la gravité et du contexte dans lequel ils sont susceptibles de s’exposer. Ajoutez chaque nouveau préjudice détecté à la liste principale pour les prochaines séries de tests.
Retester après l’application d’atténuations
Testez la liste complète des dommages connus avec des atténuations en place. Vous pouvez découvrir de nouveaux préjudices ou constater que les atténuations existantes sont insuffisantes. Mettez à jour la liste des préjudices et soyez ouvert à l’évolution des priorités en fonction des résultats.
Automatiser à grande échelle
Le red teaming manuel est essentiel mais difficile à étendre. Complétez-le avec des outils de red teaming automatisés, des frameworks qui automatisent l'analyse adversariale des modèles et applications d'intelligence artificielle. Par exemple, l’outil d’identification des risques open source Python (PyRIT) fournit :
- Analyses automatisées : simule la détection contradictoire à l’aide d’invites de départ organisées par catégorie de risque, avec des stratégies d’attaque qui contournent les alignements de sécurité
- Scoring : génère un taux de réussite d’attaque (ASR) : pourcentage d’attaques réussies, ce qui vous donne une posture de risque mesurable
- Création de rapports : produit des cartes de performance des techniques d’attaque et des catégories de risques, suivies au fil du temps pour la conformité et la surveillance continue
Pour les agents IA en particulier, les outils automatisés peuvent tester des catégories de risques difficiles à atteindre par le biais de tests d’invite manuels seuls, notamment les actions interdites, les fuites de données sensibles par le biais d’appels d’outils et l’adhésion aux tâches.
Exécutez des outils automatisés dans un environnement hors production configuré avec des ressources de type production. Utilisez-les comme complément aux tests manuels : l’automatisation expose les risques à grande échelle, tandis que les experts humains fournissent une analyse plus approfondie.
Rapporter des résultats
Soyez stratégique dans la collecte de données pour ne pas surcharger les équipes rouges, tout en capturant des informations critiques. Pour les exercices plus petits, une feuille de calcul partagée fonctionne bien. Pour les tests systématiques à grande échelle, les outils automatisés fournissent une collecte et des métriques de résultats structurées.
Partagez des rapports réguliers avec les principales parties prenantes qui incluent :
- Principaux problèmes identifiés
- Lien vers les données brutes
- Le plan de test pour les prochaines séries
- Reconnaissance des membres de l'équipe rouge
Clarifier que l’association rouge expose et augmente la compréhension de la surface des risques, ce n’est pas un remplacement pour les mesures systématiques et le travail d’atténuation rigoureux. Les lecteurs ne doivent pas interpréter des exemples spécifiques comme une métrique pour l’omniprésence de ce préjudice.