Les garde-fous IA sont des contrôles techniques et opératoires qui limitent les entrées, sorties, accès aux données et actions d’un système IA. Ils incluent frontières d’entrée, permissions de recherche, schémas structurés, validation déterministe, politiques de contenu, listes d’outils, approbations, limites, surveillance et incidents. Un garde-fou n’est pas un modèle ou filtre unique. Son efficacité dépend de la menace, du contexte et de la conséquence qu’il vise.
Les équipes ajoutent souvent une modération générique et déclarent le produit protégé. Ce contrôle peut manquer une instruction indirecte dans un document, valider les mots tout en permettant un outil dangereux ou bloquer un vocabulaire métier légitime. La fausse confiance est grave lorsque le modèle accède aux données privées ou modifie un système. Les garde-fous échouent aussi si personne ne mesure leurs décisions, traite les exceptions ou actualise les tests après changement.
Commencez par actifs, acteurs, actions et échecs plausibles, puis placez le contrôle fiable le plus fort près de chaque conséquence. Utilisez autorisation et règles déterministes pour permissions et effets irréversibles. Traitez les classificateurs comme preuves probabilistes, pas comme autorité. Concevez abstention, revue et reprise comme états normaux. Évaluez les garde-fous sur cas représentatifs et adverses dans tout le système, pas seulement sur des prompts isolés.
Couches de contrôle
Protéger le chemin des données et actions, pas seulement la conversation
Les contrôles d’entrée bornent taille, type et usages interdits, mais le système reçoit aussi des instructions par documents, pages et outils. La recherche applique les permissions avant le contexte du modèle. La sortie peut exiger schéma, citations ou valeurs valides. L’outil doit autoriser l’opération exacte contre l’état courant et vérifier le résultat observé. Les limites de débit et budgets contiennent répétition et coût.
La revue humaine est un contrôle si la personne voit les preuves, comprend la décision et peut intervenir. La surveillance l’est si un responsable répond au signal. Le NIST AI RMF Core structure cartographie, mesure et gestion du risque sur le cycle. Utilisez-le pour relier couches techniques, responsabilité, opérations et changement au lieu de traiter les garde-fous comme une fonction isolée.
| Frontière | Exemple de contrôle | Question |
|---|---|---|
| Identité et données | Moindre privilège et recherche filtrée | Cet utilisateur peut-il voir la source? |
| Entrée et contexte | Type, taille, provenance et contenu | Cette entrée peut-elle influencer? |
| Sortie | Schéma, preuves et validation métier | Le résultat est-il soutenu? |
| Action | Liste, approbation, idempotence et limites | Cet effet peut-il arriver maintenant? |
| Opérations | Surveillance, incident et retour arrière | L’équipe peut-elle récupérer? |
Limites
Les garde-fous réduisent le risque sans prouver la sûreté
Les contrôles probabilistes commettent des erreurs, peuvent être manipulés et dérivent. Les contrôles déterministes ne sont fiables que pour les cas et états encodés. Un détecteur de sortie ne compense pas des droits trop larges, et un outil sécurisé ne rend pas bonne une mauvaise politique. Documentez le risque résiduel et décidez s’il est acceptable dans le contexte visé.
OWASP décrit l’injection de prompt comme un risque majeur, y compris les instructions indirectes dans le contenu externe. Aucune phrase de prompt ne la résout. Bornez le contenu non fiable, séparez instruction et donnée quand possible, réduisez les privilèges, validez les effets et testez des attaques réalistes. Pour une action lourde, contenez l’échec du modèle au lieu d’exiger une détection parfaite.
- Nommer la menace de chaque contrôle.
- Garder l’autorisation déterministe et externe.
- Tester les attaques indirectes et en plusieurs étapes.
- Mesurer le travail légitime bloqué.
- Concevoir le confinement en cas de détection ratée.
Ce qui caractérise un bon résultat
Résultats concrets pour garde-fous IA
- Chaque garde-fou renvoie à un risque, un actif et une conséquence.
- L’autorisation reste hors du modèle et suit le moindre privilège.
- Entrées, contenu récupéré, sorties et outils ont des contrôles séparés.
- Faux positifs et faux négatifs sont mesurés par segment.
- L’escalade humaine reçoit preuve et décision bornée.
- Chaque version reteste le comportement protégé et la reprise.
Modèle opératoire
Comment exécuter le travail
- 01
Modéliser contexte et menaces
Listez utilisateurs, personnes touchées, classes de données, modèles, sources, outils et actions aval. Décrivez abus, erreur accidentelle, contenu adverse et panne de dépendance avec probabilité et conséquence.
- 02
Affecter les contrôles aux frontières
Choisissez contrôles d’entrée, identité, recherche, sortie, outil, approbation et opérations par menace. Préférez contrats typés, droits et invariants déterministes. Dites ce que chaque contrôle ne protège pas.
- 03
Construire le jeu d’évaluation
Collectez cas permis, interdits, ambigus, multilingues, limites et adverses. Incluez instructions indirectes dans documents et résultats d’outils. Définissez l’action système attendue, pas seulement une classe de texte.
- 04
Diffuser, observer et réviser
Exécutez la régression avant promotion et une diffusion bornée. Surveillez blocages, passages, dérogations, appels, effets et incidents. Étudiez friction et dommage manqué, puis versionnez ensemble politique, contrôle et évaluation.
Évaluation
Les questions qui changent la décision
- Quel actif ou quelle action crée la conséquence matérielle?
- Un contrôle déterministe applique-t-il la politique plus sûrement?
- Quelles données le runtime peut-il lire sous l’identité actuelle?
- Quels champs exigent schéma, source ou validation croisée?
- Quelles actions exigent aperçu, approbation, transaction ou compensation?
- Quelle preuve montrera l’efficacité après changement?
Modes d’échec
Où les équipes perdent le contrôle
Un filtre contrôle le prompt mais pas le contenu récupéré ou fourni par outil.
Un classificateur devient l’autorité finale pour accès ou paiement.
La sortie respecte la politique de mots mais contient un fait sans preuve.
Le surblocage crée des contournements hors du produit contrôlé.
Les journaux captent le sensible sans contexte pour expliquer.
Un changement de fournisseur ou prompt arrive sans régression.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- cas bloqués, permis et escaladés par raison
- faux positifs et négatifs par segment de tâche
- recherches non autorisées et tentatives d’action
- affirmations sans preuve et échecs de schéma
- dérogation, appel et délai de résolution humaine
- dérive après changement de modèle, politique, source ou outil
Questions
Questions fréquentes
Que sont les garde-fous IA?
Ce sont des contrôles techniques et opératoires qui bornent entrées, accès aux données, sorties et actions. Ils incluent permissions, schémas, validation, politiques, limites d’outils, approbations, surveillance et reprise.
Empêchent-ils les hallucinations?
Ils peuvent réduire les affirmations sans preuve par recherche, citations, schémas, contrôles, abstention et revue, sans garantir les faits. Évaluez sur des cas représentatifs et contenez la conséquence des erreurs manquées.
Un modèle de modération suffit-il?
Généralement pas en production. Il peut soutenir la politique de contenu, mais identité, permissions, recherche, validation métier, autorité des outils, surveillance et reprise ont besoin de contrôles propres. La classification par modèle reste probabiliste.
Comment tester les garde-fous IA?
Testez des cas permis, interdits, ambigus, multilingues et adverses à travers tout le produit. Mesurez action attendue, faux blocage, dommage manqué, effets des outils, dérogations et reprise après chaque changement important.
Sources
Sources primaires
- AI Risk Management Framework Core National Institute of Standards and Technology
- LLM01 Prompt Injection OWASP Generative AI Security Project
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→