Gouvernance et risque chez les agents IA : que contrôler avant de donner de l'autonomie

Un agent IA d'entreprise n'est plus une simple interface lorsqu'il peut interroger des données, appeler des API, créer des enregistrements, envoyer des messages, modifier des états ou exécuter des actions. A ce moment-là, il ne suffit plus de se demander s’il « réagit bien ». Vous devez concevoir ce qu’elle peut faire, avec quelles ressources, dans quelles conditions et comment l’organisation se rétablit lorsqu’elle commet une erreur.

La gouvernance n’est pas une couche bureaucratique ajoutée ultérieurement. Cela fait partie de l'architecture. Le cadre AI RMF du NIST est conçu précisément pour aider les organisations à gérer les risques du système d'IA pendant la conception, le développement, l'utilisation et l'évaluation, et son profil pour l'IA générative étend cette approche à des risques spécifiques du système génératif.

1. Modéliser le risque par action, et non par « niveau de renseignement »

Le risque d'un agent ne dépend pas uniquement du modèle utilisé. Cela dépend des actions disponibles et des conséquences d'une erreur. Un modèle médiocre avec autorisation de suppression de données peut être plus dangereux qu'un excellent modèle limité à la synthèse de documents.

Pour chaque capacité, évaluez au moins quatre dimensions : impacto, reversibilidad, sensibilité des données y frecuencia. L’envoi d’un brouillon interne est différent de l’envoi d’une offre à un client. Consulter un fichier est différent de le modifier. Préparer un paiement est différent de son exécution.

2. Définir l'autonomie par étapes

Il n’existe pas de décision unique « autonome ou non autonome ». Vous pouvez concevoir des niveaux.

1. Aide : l'agent propose, une personne exécute.
2. Exécution avec approbation : L'agent prépare l'action et attend la confirmation humaine.
3. Exécution limitée : peut agir automatiquement selon des règles et des seuils définis.
4. Autonomie encadrée : gère un flux entier, mais enregistre les actions, applique des limites et fait remonter les exceptions.

Le niveau doit dépendre du risque et non de la volonté d’automatisation. Une action réversible, fréquente et bien définie peut bénéficier de plus d’autonomie. Une décision irréversiblement coûteuse devrait faire l’objet d’un examen humain même si le modèle est très bon.

3. Appliquer le moindre privilège

L'agent doit disposer uniquement des autorisations nécessaires à sa tâche. N'utilisez pas d'informations d'identification d'administrateur global car « c'est plus facile ». Créez des comptes ou des étendues de service distincts lorsque la plateforme le permet.

Si un agent a uniquement besoin de lire le calendrier, il ne devrait pas pouvoir supprimer les événements. Si vous devez créer des brouillons, vous n’avez pas besoin d’autorisation pour les envoyer. Si vous interrogez une base de données, vous séparez la lecture de l'écriture. Si vous devez écrire, limitez les tables, les opérations ou les points de terminaison.

Séparer les secrets par fonction

Ne mélangez pas toutes les informations d’identification dans un seul contexte accessible. Un agent n’a pas besoin de connaître le secret utilisé par un autre service. Gérez les secrets en dehors de l'invite et transmettez-les uniquement au connecteur qui en a besoin.

La meilleure façon d’atténuer une action dangereuse est de ne pas demander au modèle de « faire attention ». Le fait est que l'architecture ne permet pas de l'exécuter en dehors des règles.

4. Concevoir une véritable supervision humaine

« L'humain dans la boucle » ne signifie pas afficher un écran avec un bouton d'approbation. La personne a besoin de suffisamment de contexte pour détecter une erreur.

Une approbation doit montrer quelle action est proposée, sur quel objet, quelles données la justifient, quelles conséquences elle a et quels champs ont été générés ou déduits par l’IA. Si l’examinateur doit tout réexaminer à partir de zéro, les économies supposées disparaissent.

Évitez l’automatisation de l’approbation

Si une personne approuve des centaines de propositions identiques sans les lire, le contrôle n'existe que formellement. Lorsque le volume rend impossible l'examen de chaque cas, repensez le contrôle : examen par échantillons, seuils, règles déterministes ou séparation des cas à risque.

5. Évaluez le système avec des tâches réelles

Une démo ne valide pas un agent. Construisez un ensemble de cas représentatifs et de cas difficiles : données incomplètes, contradictions, contributions contradictoires, demandes hors de portée et erreurs d'outils.

Définir les métriques liées au résultat : précision de l'extraction, taux d'escalade correct, fausses actions, omissions, temps de résolution, coût par cas et erreurs critiques. Pour les tâches génératives, l’évaluation humaine est toujours nécessaire dans les dimensions où il n’existe pas de métrique déterministe suffisante.

Tests avant et après chaque changement

Changer de modèle, d'invite, d'outil ou de version peut modifier le comportement. Maintenez un ensemble de régression. Si une mise à jour améliore la moyenne mais brise un cas critique, vous devez la détecter avant la production.

6. Protège l'agent des instructions non fiables

Lorsqu'un agent lit des e-mails, des pages Web, des documents ou des messages, ce contenu doit être traité comme des données et non comme des instructions autorisées. Un document peut contenir du texte qui tente de manipuler le comportement de l'agent.

Séparez clairement les instructions système, les politiques et le contenu externe. Limite les outils qui peuvent être invoqués à partir d’entrées non fiables et nécessite une confirmation pour les actions sensibles.

7. Concevoir des pannes sûres

Les systèmes échouent : les API ne répondent pas, les informations d'identification expirent, les données arrivent incomplètes et les modèles renvoient des formats non valides. La question importante est de savoir ce qui se passera ensuite.

Pour les actions à fort impact, une défaillance devrait fermer le flux en toute sécurité plutôt que d’improviser. S’il manque une information obligatoire, ne l’inventez pas. Si une API renvoie un état ambigu après l'exécution d'une action, effectuez la réconciliation avant de réessayer. S'il existe un risque de duplication d'une publication, d'un paiement ou d'une commande, l'idempotence s'applique.

Classer les erreurs

• Transitoires : délai d'attente, délai, temps d'arrêt du fournisseur. Ils peuvent prendre en charge les nouvelles tentatives contrôlées.
• Données : champs manquants, formats invalides. Ils nécessitent une correction ou une mise à l’échelle.
• À propos de la politique : action en dehors des autorisations ou du seuil. Il faut les bloquer.
• Ambigu : Nous ne savons pas si l'action a été exécutée. Ils nécessitent une conciliation avant de répéter.

8. Observabilité : savoir ce que vous avez fait et pourquoi

Enregistre suffisamment d'événements pour reconstruire une décision : identifiant de cas, version du flux, modèle si pertinent, outils invoqués, paramètres non sensibles, résultat, erreurs et approbations. Ne conservez pas de secrets ou de données inutiles dans les journaux.

L’observabilité sert au fonctionnement et à l’amélioration. Si le taux d’exception augmente, il faut savoir à quel stade. Si la qualité change après une mise à jour, vous devez pouvoir comparer les versions.

9. Dépendance aux fournisseurs et continuité

Un système d'IA dépend généralement de plusieurs services. Documentez ce qui se passe si un fournisseur modifie le prix, le modèle, les limites ou la disponibilité. Cela ne signifie pas créer des substituts à tout ; Cela signifie connaître les dépendances critiques et concevoir des chemins de dégradation si nécessaire.

Il préserve les formats internes stables, fait abstraction des intégrations importantes et empêche la logique métier de dépendre inutilement d'une fonctionnalité propriétaire difficile à remplacer.

10. Données et confidentialité

Minimise les données envoyées au modèle. Si une tâche peut être résolue avec des champs partiels, n'envoyez pas le fichier complet. Examine les contrats, les régions de traitement, la rétention et les contrôles des fournisseurs en fonction de la sensibilité et des obligations applicables.

La gouvernance technique ne remplace pas les conseils juridiques. Lorsqu’il existe des données personnelles, des secteurs réglementés ou des décisions ayant des effets pertinents, cela intègre un contrôle juridique et de conformité spécifique.

11. Utilisez des cadres de référence sans les transformer en listes de contrôle vides

El Cadre de gestion des risques liés à l'IA du NIST propose une approche structurée pour gérer les risques et la confiance dans les systèmes d’IA. Son profil d'IA générative ajoute des considérations spécifiques aux systèmes génératifs. Ces cadres sont utiles comme référence, mais doivent être traduits en contrôles concrets du processus réel.

La question n’est pas « est-ce que nous respectons un cadre ? Il s’agit de « quel risque existe dans ce cas, à qui appartient ce risque, quel contrôle le réduit et comment savons-nous que le contrôle fonctionne ? »

12. Check-list avant de donner de l'autonomie à un agent

1. Répertorie tous les outils et actions disponibles.
2. Classez chaque action par impact et réversibilité.
3. Réduisez les autorisations au minimum nécessaire.
4. Définit les actions qui nécessitent une approbation.
5. Concevez le traitement des entrées non fiables.
6. Créez un ensemble d’évaluation avec des cas réels et contradictoires.
7. Définir les limites de dépenses, de volume et de fréquence.
8. Implémente l'idempotence pour les actions répétables.
9. Classez les erreurs et réessayez les stratégies.
10. Concevez des journaux sans secrets.
11. Définit l’escalade humaine et la responsabilité opérationnelle.
12. Test de reprise en cas de panne fournisseur.
13. Documente comment désactiver rapidement l'agent.

Conclusion

Une autonomie utile ne consiste pas à donner plus d’outils à un agent. Cela consiste à vous permettre d'agir dans un périmètre défini : autorisations minimales, données suffisantes, limites claires, observabilité, évaluation et sortie sûre lorsque vous ne savez pas quoi faire.

Plus l’impact potentiel d’une action est grand, moins la confiance devrait dépendre du « bon comportement » du modèle et davantage des contrôles déterministes autour du modèle.

En comment nous travaillons Nous expliquons comment ProjectCore conçoit les processus, les contrôles et l'architecture avant d'augmenter l'autonomie d'un système.