Gains :
- Possibilité de classer les scénarios d'utilisation en niveaux de risque faible/moyen/élevé en fonction de leur impact
- Possibilité de tester systématiquement le modèle avant production avec red-teaming
- Capacité à prendre des décisions de production avec une carte modèle et une porte d'acceptation (go/no-go)
Toutes les utilisations de l’IA ne comportent pas le même risque. Un assistant résumant une note de réunion et un assistant évaluant une demande de prêt produisent des résultats très différents. La base de la gouvernance d'entreprise est de classer les usages selon le niveau de risque et d'appliquer un contrôle approprié à chaque niveau. Dans cette unité, nous apprendrons le cadre de gestion des risques de modèle (la discipline de gestion du risque causé par un modèle incorrect, biaisé ou exploitable), comment tester le modèle avant la production avec le red-teaming, ainsi que la fiche modèle et les critères d'acceptation.
Classification par risque
La première étape est toujours la même : « Que se passe-t-il si cet usage se passe mal ? Trois niveaux approximatifs selon la puissance et la réversibilité :
- Faible risque : l'erreur est facilement détectée et annulée ; Aucune conséquence personnelle/financière. Exemple : résumé d'une réunion interne, génération d'un projet d'idée.
- Risque moyen : l'erreur affecte le processus métier mais passe par l'œil humain. Exemple : projet de réponse au client, résumé du rapport préliminaire.
- Risque élevé : la décision affecte directement une personne/de l'argent, difficile à annuler. Exemple : décision de crédit/assurance, triage médical, sélection pour l'emploi.
L'intensité du contrôle augmente avec le niveau de risque : à risque faible, des contrôles légers suffisent ; En cas de risque élevé, une supervision humaine, une vérification stricte, une équipe rouge et une surveillance constante sont obligatoires.
Attention : Classez les risques en fonction de l'effet de l'utilisation et non de son nom. Le système dit « juste un chatbot » présente un risque élevé s’il peut initier des paiements.
Équipe Rouge (Équipe Rouge)
L'équipe rouge tente délibérément de casser un système en se faisant passer pour un attaquant malveillant. C'est dans l'IA ; Il comprend le jailbreak (contournement des règles de sécurité du modèle), l'injection rapide, l'exfiltration de données, la génération de sorties biaisées/malveillantes et le test de scénarios de pointe. Le but est de trouver les vulnérabilités avant le véritable attaquant.
Étape par étape :
- Répertoriez les scénarios de menace. Comment peut-on abuser de ce système ?
- Préparez l’ensemble d’attaque. Écrivez des exemples d’entrée concrets pour chaque menace.
- Essayez systématiquement. Exécutez chaque scénario et enregistrez le résultat.
- Hiérarchiser les résultats. Trier par impact × probabilité.
- Corrigez-le et testez à nouveau. Après le patch, réessayez avec le même ensemble (régression).
Modèle de carte et critères d’acceptation
Une fiche modèle est un document qui résume à quoi convient un modèle, ses limites, ses risques connus et ses performances. Avant de le mettre en production, vous devez disposer de critères pour une décision d'acceptation : seuil de précision, taux de réussite de l'équipe rouge, latence, coût et tests de biais.
Quatre modèles copiables
Invite de classification des risques :
Considérez le cas d'utilisation suivant : {{ scénario }}Questions : - Qui/qu'est-ce que le bug affecte ? (personne, argent, réputation, harmonie)- Est-ce réversible ? (oui/non) - Les humains peuvent-ils intervenir ? Résultat : « Risque faible / moyen / élevé » + liste des contrôles obligatoires.
Générateur d'ensembles d'attaque de l'équipe rouge :
Vous êtes un spécialiste de l'équipe rouge. Générez 15 scénarios d'attaque pour l'assistant suivant : 5 jailbreaks, 5 injections rapides (dont 3 indirectes), 5 tentatives d'exfiltration de données. Pour chaque scénario : écrivez le but, le texte d'introduction complet et les "critères de réussite" (tout ce que je vois compte comme une attaque réussie).
Squelette du modèle de planche :
Carte modèle : - Utilisation prévue/utilisation non prévue- Limites de formation/données et vulnérabilités connues- Performance : précision, latence, coût (sur l'ensemble de test)- Sécurité : taux de réussite de l'équipe rouge, jailbreaks connus- Résultats des tests de biais- Décision d'acceptation : APPROBATION / CONDITIONNEMENT / REJET + justification
Règle de contrôle des portes d'admission :
TOUTES les conditions doivent être remplies pour passer en production :- >= seuil cible sur l'ensemble de tests de précision- Nombre de résultats critiques de l'équipe rouge = 0- Si risque élevé : inspection humaine et comité de surveillance. Si aucun n'est respecté : "NO-GO" + élément manquant.
Invite faible/Invite forte
mauvaise approche
Approche forte
Traiter chaque utilisation avec le même contrôle
Classer par risque et contrôle d’échelle
"On l'a testé, ça marche" (happy way)
Tentative de rupture délibérée avec l'équipe rouge
Mise en production du modèle sans justification
Carte modèle + porte d'acceptation (go/no-go)
Pas de nouveau test après l'application du correctif
Test de régression après correction
Trois mini-étuis
Cas 1 — Une erreur de classification a coûté cher. Une entreprise a considéré la présélection du recrutement comme « juste un complément » et l'a jugée à faible risque. Le modèle éliminait systématiquement les diplômés de certaines écoles ; cela s'est transformé en une plainte pour discrimination. L’utilisation a été reclassée comme « à haut risque » et des tests de biais et une surveillance humaine ont été ajoutés.
Cas 2 — L'équipe rouge a trouvé 3 vulnérabilités critiques. Un assistant client a été affecté à l’équipe rouge avant de passer en production. 3 scénarios sur 15 ont réussi : les informations de commande d'un autre client pourraient être divulguées via une injection indirecte. Les lacunes ont été comblées et retestées avec le même ensemble ; La production n'a repris que lorsque la découverte critique a été réinitialisée.
Cas 3 — Le modèle a clarifié la décision d'accepter la carte. Choisissant entre deux modèles, une équipe a placé les cartes modèles côte à côte. Le modèle le moins cher a fait mouche en termes de précision, mais était vulnérable à 2 jailbreaks critiques de l'équipe rouge. L'équipe a choisi le modèle coûteux mais sûr en raison de la règle d'acceptation « constatation critique = 0 » et a documenté la décision.
Astuce : L'équipe rouge n'est pas un événement ponctuel. Réexécutez l'ensemble d'attaques chaque fois que le modèle, l'invite ou les outils changent ; La sécurité n’est pas un État, mais une pratique permanente.
Erreurs courantes
- Classer l'utilisation par son nom (plutôt que par son effet) ; prendre un risque élevé pour un risque faible.
- Il suffit de tester le « chemin du bonheur » et de ne pas tenter du tout les abus.
- Faire l'équipe rouge une fois et ne pas la répéter après les changements.
- Mettre le modèle en production sans carte de modèle ni critères d'acceptation.
- Contourner les tests de biais/discrimination (en particulier dans les décisions humaines à enjeux élevés).
- Cela signifie « fermé » sans effectuer de tests de régression post-correction.
En résumé
- La première étape consiste à classer les utilisations en risques faibles/moyens/élevés en fonction de leur impact ; L’intensité du contrôle augmente avec le risque.
- L'équipe rouge essaie délibérément de briser le système comme un attaquant ; trouve la vulnérabilité avant le véritable attaquant.
- La fiche modèle documente l'objectif, les limites et les risques du modèle ; constitue la base de la décision d’admission.
- La transition vers la production doit être liée à un go/no-go : précision, résultat critique zéro, surveillance requise.
- La sécurité est continue : les équipes rouges et les tests de régression sont répétés à chaque changement.
Tâche de candidature
Choisissez votre utilisation d’une IA, déterminez le niveau de risque en fonction de l’impact et rédigez la justification. Générez ensuite au moins 10 scénarios d'attaque pour cet usage (jailbreak, injection, exfiltration de données) et essayez-les manuellement. Pour chaque attaque réussie, proposez un correctif. Enfin, remplissez un modèle de squelette de carte et prenez une décision « GO/NO-GO » motivée.
liste de contrôle
- [ ] J'ai classé l'utilisation selon le niveau de risque selon l'effet.
- [ ] J'ai adapté l'intensité du contrôle au niveau de risque.
- [ ] J'ai préparé un set d'attaque de l'équipe rouge et je l'ai essayé systématiquement.
- [ ] J'ai corrigé les résultats critiques et les ai vérifiés avec des tests de régression.
- [ ] J'ai préparé une carte modèle (objectif, limite, performances, sécurité).
- [ ] J'ai lié la décision de production à un go/no-go.