Le red teaming de l’IA est la tentative délibérée et systématique de mettre en défaut un système d’IA, en le sondant du point de vue d’un acteur malveillant afin de faire apparaître les faiblesses de sécurité, les sorties nuisibles et les violations de politiques avant qu’elles n’atteignent la production. Le terme est emprunté au red teaming traditionnel en cybersécurité, où une équipe offensive (la « red team ») attaque les défenses de sa propre organisation afin que l’équipe défensive (la « blue team ») puisse les améliorer. Pour les systèmes d’IA, cet état d’esprit adverse est appliqué aux modes de défaillance propres aux modèles d’apprentissage automatique : des modèles qui peuvent être manipulés par le langage, qui peuvent divulguer des données d’entraînement et qui peuvent produire des contenus dangereux ou trompeurs dans certaines conditions.
Contrairement au red teaming traditionnel, qui cible principalement l’infrastructure réseau, les vulnérabilités logicielles et les vecteurs d’ingénierie sociale humaine, le red teaming de l’IA doit tenir compte d’une surface d’attaque fondamentalement différente. Les tests d’intrusion traditionnels portent sur des systèmes déterministes où une entrée donnée produit de manière fiable une sortie donnée. Les modèles d’IA sont probabilistes : la même requête peut donner des résultats différents d’une session à l’autre, et de subtils changements de formulation peuvent provoquer des comportements radicalement différents. Les red teamers de l’IA doivent donc tester non seulement des exploits précis mais des catégories entières de comportement du modèle, ce qui exige souvent créativité et expertise métier plutôt que des outils prêts à l’emploi.
Cinq catégories d’attaques principales
1. Injection de requête : concevoir des entrées qui outrepassent les instructions système d’un modèle, l’amenant à ignorer ses garde-fous de sécurité, à révéler une configuration confidentielle ou à agir pour le compte d’un attaquant plutôt que de l’utilisateur légitime.
2. Jailbreaking : utiliser des scénarios de jeu de rôle, des cadrages hypothétiques, une manipulation en plusieurs étapes ou des structures de requête adverses pour contourner les politiques de sécurité du contenu et obtenir des sorties que le modèle a été explicitement entraîné à refuser.
3. Empoisonnement des données : insérer des exemples malveillants ou trompeurs dans le jeu de données d’entraînement ou d’affinage d’un modèle afin de dégrader ses performances, d’y introduire des portes dérobées ou de biaiser le modèle vers des sorties nuisibles spécifiques au moment de l’inférence.
4. Extraction de modèle : interroger systématiquement un modèle pour reconstruire une approximation fonctionnelle de ses poids ou de ses frontières de décision, permettant à des concurrents ou à des attaquants de voler des capacités d’IA propriétaires sans autorisation.
5. Entrées adverses : appliquer des perturbations mathématiquement conçues à des images, des sons ou du texte, imperceptibles pour les humains mais qui amènent de manière fiable le modèle à mal classer, mal transcrire ou produire des sorties incorrectes, une préoccupation particulièrement importante dans des domaines à fort enjeu comme l’imagerie médicale ou la détection de fraude.
Qui réalise le red teaming de l’IA
Le red teaming de l’IA est mené par trois grands groupes. Les équipes de sécurité internes dotées d’une expertise en IA réalisent des évaluations continues à mesure que les modèles sont mis à jour, en intégrant le red teaming au pipeline MLOps. Les chercheurs en sécurité de l’IA, employés par des organisations comme OpenAI, Anthropic, Google DeepMind et des organismes publics tels que l’UK AI Safety Institute, réalisent des évaluations préalables à la publication des modèles de pointe afin d’apprécier les risques au niveau des capacités. Les auditeurs tiers et les sociétés spécialisées en sécurité de l’IA fournissent des évaluations indépendantes, offrant un regard extérieur que les équipes internes peuvent manquer en raison d’un biais de familiarité.
Des cadres réglementaires émergents formalisent ces exigences. L’EU AI Act impose des tests adverses pour les systèmes d’IA à haut risque. L’Executive Order on AI des États-Unis (2023) exigeait des évaluations par red team pour les puissants modèles de fondation avant leur diffusion publique. L’AI Risk Management Framework du NIST inclut les tests adverses comme composante centrale de la fonction « Measure ». À mesure que les entreprises déploient des agents d’IA ayant accès à des systèmes sensibles, le red teaming de l’IA passe d’une activité préalable au déploiement à une discipline de sécurité continue, aussi fondamentale que le sont les tests d’intrusion pour les logiciels traditionnels.