AI & Analytics Legends La plateforme de connaissance SAP Analytics
Fiche concept

Red-teaming IA et évaluation de sécurité — Prompts adverses, jailbreaks, évaluation des dommages

Red-teaming IA et évaluation de sécurité — Prompts adverses, jailbreaks, évaluation des dommages — illustration de section Analytics Legends pour la base de connaissances SAP Analytics (concepts, études, Academy)

À jour au 2026-10-06

Qu'est-ce que Red-teaming IA et évaluation de sécurité ?

Le red-teaming est désormais une exigence de conformité, pas une curiosité de recherche — la documentation Art. 9/15 du règlement IA européen pour un système à haut risque représente 200 à 800 personne-jours, et le périmètre minimum pour les déploiements SAP compte cinq contrôles précis.

De quoi il s'agit

Le red-teaming IA est le sondage adverse structuré d'un modèle et de son système déployé pour mettre au jour les comportements non sûrs, biaisés, fuiteurs ou vulnérables aux jailbreaks AVANT toute exposition production. En 2026 ce n'est plus une curiosité de recherche — sous les articles 9 (gestion des risques) et 15 (exactitude, robustesse, cybersécurité) du règlement européen sur l'IA, les fournisseurs de systèmes à haut risque doivent démontrer la couverture red-team; l'effort documentaire des articles 9 à 49 atteint 200 à 800 personne-jours par système à haut risque, selon l'étude applied-AI de Munich citée dans le registre de recherche Analytics Legends.

Une campagne red-team comporte quatre chantiers. Le sondage de capacités met au jour ce que le modèle sait faire — y compris des capacités non voulues par le fournisseur (écriture de code d'exploitation, synthèse d'instructions biothreat, production de CSAM). Le sondage d'injection de prompts et de jailbreaks teste si les prompts système, les frontières de contexte récupéré et les garde-fous d'utilisation d'outils peuvent être contournés par une entrée utilisateur hostile. L'évaluation des biais et dommages exécute des suites de scénarios (BBQ, RealToxicityPrompts, HarmBench, DecodingTrust) et met en évidence les disparités de performance entre axes démographiques. L'évaluation des mésusages sonde des usages spécifiques à haut risque (manipulation électorale, fraude, harcèlement ciblé) et documente le taux de refus plus le taux de fuite résiduel.

Pourquoi c'est important

  • Le coût est chiffré, pas abstrait : l'étude applied-AI de Munich citée évalue l'effort documentaire Art. 9-49 à 200-800 personne-jours par système à haut risque.
  • La méthodologie est déjà codifiée par les labos (RSP d'Anthropic, preparedness framework d'OpenAI, Frontier Safety Framework de DeepMind) et les organismes de normes (NIST AI RMF, MITRE ATLAS, OWASP LLM Top 10) — ce n'est pas improvisé.
  • Pour SAP spécifiquement, le périmètre red-team minimum nomme cinq contrôles concrets : injection de prompt sur les frontières de contenu récupéré, fuite de données cross-tenant via Joule, taux de refus sur les requêtes RH/paie, biais dans le screening candidats, et résistance jailbreak OWASP LLM-01.

Points clés

  • Quatre volets de travail — sondage de capacités, injection de prompts/jailbreak, évaluation des biais et nuisances, évaluation du mésusage ; chacun documenté dans le registre des risques de l'article 9.
  • Obligations de l'AI Act européen — art. 9 (gestion des risques) + art. 15 (exactitude, robustesse, cybersécurité) exigent une couverture red-team démontrée pour les systèmes à haut risque d'ici le 2 décembre 2027 (Omnibus numérique, en vigueur depuis le 27 juillet 2026) (annexe III) / le 2 août 2028 (intégré au produit). Selon le registre de recherche Analytics Legends.
  • Cadres — Responsible Scaling Policy d'Anthropic, Preparedness d'OpenAI, Frontier Safety Framework de DeepMind, NIST AI RMF 1.0, MITRE ATLAS, OWASP LLM Top 10.
  • Suites d'évaluation — BBQ (biais), RealToxicityPrompts, HarmBench, DecodingTrust, ToxiGen ; à compléter par des scénarios propres au domaine.
  • Périmètre spécifique SAP — injection de prompts via le contenu récupéré, franchissement de frontière de tenant par l'usage d'outils Joule, taux de refus sur données sensibles, biais de screening de candidats, résistance au jailbreak OWASP LLM-01.
  • Les modèles de fondation tabulaires (SAP-RPT-1.6, TabPFN-3.5-Plus, tous deux actuels en septembre 2026) nécessitent un test statistique de parité démographique/d'impact disparate, pas des suites de biais textuelles, quand ils notent ou classent des personnes.

Termes employés sur cette page

Red-teaming
Sondage adversarial structuré d'un système d'IA pour mettre au jour des comportements non sûrs, biaisés, fuiteurs ou vulnérables aux jailbreaks avant le déploiement en production ; codifié sous la gestion des risques de l'article 9 de l'AI Act pour les systèmes à haut risque.
Jailbreak
Schéma de prompt adversarial qui contourne l'entraînement à la sécurité d'un modèle ou les garde-fous du prompt système, le poussant à produire un contenu qu'il refuserait normalement ; catalogué par OWASP LLM-01 et suivi dans HarmBench.
Injection de prompt
Attaque où un contenu hostile intégré dans un résultat d'outil, un document récupéré ou une entrée utilisateur réécrit les instructions effectives du modèle ; risque n°1 de l'OWASP LLM Top 10 en déploiement production.
Responsible Scaling Policy (RSP)
L'engagement volontaire d'Anthropic à définir des seuils de niveau de sécurité IA (ASL) et à exiger des jalons de red-team, des contrôles de déploiement et des mesures de sécurité spécifiques avant de franchir chaque seuil ; imité par le Preparedness d'OpenAI et le Frontier Safety de DeepMind.
Parité démographique / impact disparate
Tests statistiques d'équité comparant le taux de résultat positif d'un modèle selon des groupes protégés ; la méthode d'évaluation de biais adaptée à un modèle de scoring tabulaire, distincte des suites de biais textuelles comme BBQ.
NIST AI RMF (Govern-Map-Measure-Manage)
La structure en quatre fonctions du NIST pour la gestion des risques IA ; un outil d'inventaire/classification comme l'AI Agent Hub de SAP couvre Govern/Map, tandis que Measure exige une véritable preuve de red-teaming ou d'évaluation.
MITRE ATLAS
Une base de connaissances des tactiques et techniques adversariales contre les systèmes d'IA, structurée sur le même modèle que le cadre MITRE ATT&CK pour la cybersécurité traditionnelle.

Sources

  1. Anthropic Responsible Scaling Policy
  2. EU AI Act — Regulation (EU) 2024/1689, Art. 9 (risk management) + Art. 15 (accuracy, robustness, cybersecurity)
  3. NIST AI Risk Management Framework 1.0
  4. OWASP Top 10 for Large Language Model Applications
  5. SAP Community — SAP-RPT-1.6, Tabular Orchestration and RPT Playground API now available (Sep 2026)
  6. SAP News Center — TabPFN-3.5-Plus now available in SAP AI Core (15 Sep 2026)
  7. Prior Labs — TabPFN 3.5 changelog
  8. MLflow — LLM/model evaluation documentation (custom fairness metrics pattern)
  9. Microsoft — Responsible AI Standard
  10. Microsoft / Azure — PyRIT, Python Risk Identification Tool for generative AI (GitHub)
  11. SAP News Center — AI agents work at scale: AI Governance Assistant, EU AI Act + NIST classification (22 Sep 2026)
  12. NIST — AI 600-1 Generative AI Profile (risk categories and red-teaming actions for generative AI)
  13. EU AI Act — Article 55, obligations for providers of general-purpose AI models with systemic risk (documented adversarial testing)
  14. Mazeika et al. — HarmBench: a standardized evaluation framework for automated red teaming and robust refusal (arXiv 2402.04249)
  15. NVIDIA — garak, LLM vulnerability scanner (probe catalogue for jailbreaks, prompt injection, leakage)

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →