Dix garde-fous avant de mettre un agent IA sensible en production

Un agent devient sensible dès qu'une erreur peut affecter une personne, engager de l'argent, exposer une donnée, modifier un droit ou déclencher une action difficile à annuler. La bonne question n'est pas seulement « le modèle répond-il bien ? », mais « le système complet sait-il rester dans son autorité, montrer ses limites et organiser le recours ? »

Voici une revue concrète à conduire avant la production.

1. Définir une mission bornée

Écrivez ce que l'agent peut faire, ce qu'il peut seulement préparer et ce qui lui est interdit. « Préparer un projet de réponse à partir des documents validés » est testable. « Gérer la relation client » ne l'est pas.

2. Classer les actions par impact et réversibilité

Un brouillon modifiable, une recommandation, un envoi et une suppression ne demandent pas le même contrôle. Plus l'impact est fort ou l'annulation difficile, plus l'autorisation doit être explicite.

3. Appliquer le moindre privilège

Ne donnez pas à l'agent l'accès global « au cas où ». Séparez lecture, préparation et exécution. Utilisez des permissions limitées dans le temps et par périmètre lorsque c'est possible.

4. Maîtriser les sources

Identifiez les sources autorisées, leur fraîcheur et leur niveau d'autorité. Une information retrouvée ne devient pas vraie par le seul fait d'être disponible. Affichez la provenance utile à la vérification.

5. Versionner les composants

Conservez la version du modèle, du prompt, des règles, des outils et du schéma de données. Une sortie ne peut être expliquée si le système ne sait plus avec quelle configuration elle a été produite.

6. Construire des évaluations réalistes

Testez les cas normaux, les données ambiguës, les permissions retirées, les instructions malveillantes, les sources contradictoires et les demandes hors périmètre. Une démonstration réussie ne mesure pas le comportement dans les marges.

7. Prévoir le refus et le mode dégradé

L'agent doit savoir demander, limiter sa réponse, mettre en attente, transférer ou suspendre. Le scénario de panne doit préciser le message utilisateur et la personne responsable de la reprise.

8. Organiser la validation humaine

« Human in the loop » ne suffit pas. La personne doit posséder le contexte, le temps et l'autorité nécessaires. Montrez-lui les points incertains et les changements importants plutôt qu'un long résultat à relire passivement.

9. Tracer sans tout conserver

Reliez exécution, décision et résultat avec des identifiants. Ne stockez pas automatiquement tous les prompts et toutes les données sensibles. Définissez la finalité, l'accès, la durée et la suppression des traces.

10. Préparer le recours et l'arrêt

Un utilisateur doit pouvoir corriger, contester et demander une intervention. L'équipe doit pouvoir désactiver une capacité, isoler une version et retrouver les actions concernées sans arrêter tout le produit.

Le test de passage en production

Pour chaque garde-fou, attribuez un état : absent, documenté, testé ou observé en production. Un document ne vaut pas un test ; un test unique ne vaut pas un comportement suivi.

Bloquez la production si l'un de ces éléments manque pour une action importante : propriétaire du risque, règle d'autorité, recours humain, scénario de défaillance, journal minimal et mécanisme d'arrêt.

Ce qu'il faut mesurer après le lancement

• taux d'actions corrigées ou annulées ;
• escalades par type et délai de traitement ;
• sorties hors périmètre ;
• actions sensibles validées par le bon rôle ;
• incidents liés aux permissions ou aux données ;
• dérive des évaluations par version ;
• résultats métier, pas seulement disponibilité et latence.

Une métrique stable n'élimine pas le besoin de revue. Elle indique où regarder.

Fait, inférence et hypothèse

Fait direct : les cadres de gestion des risques recommandent gouvernance, évaluation, sécurité, protection des données et réponse aux incidents.

Inférence : une petite équipe peut appliquer ces principes sans construire une bureaucratie si elle relie chaque garde-fou à une action et à un propriétaire.

Hypothèse à tester : une revue de 45 minutes avant chaque nouvelle capacité sensible réduit les incidents évitables sans ralentir excessivement la livraison.

FAQ

Un agent qui ne fait que recommander est-il sensible ?

Oui, si sa recommandation influence une décision importante ou si l'utilisateur peut la suivre sans vérification réelle.

Faut-il appliquer les dix garde-fous dès le prototype ?

Pas au même niveau. Mais mission, données, autorité et critère d'arrêt doivent être explicites avant un test avec de vraies personnes.

Un bon modèle réduit-il le besoin de contrôles ?

Il peut réduire certaines erreurs, mais pas résoudre permissions, données périmées, actions irréversibles ou responsabilité.

Prochaine étape

Utilisez la revue agent sensible sur une seule capacité et notez la preuve disponible pour chaque garde-fou. Pour une revue extérieure du parcours et de son mode d'arrêt, écrivez à contact@yumea.fr avec l'objet « AGENT SENSIBLE ».

Sources de référence

• NIST, AI Risk Management Framework.
• CNIL, recommandations sur le développement des systèmes d'IA.
• OWASP, Top 10 for LLM Applications.