Cadre de gouvernance des agents IA

1. Commencer par des principes de gouvernance

Un modèle de gouvernance doit commencer par un nombre limité de principes cohérents applicables à l’ensemble du portefeuille d’agents. Ils doivent être compris par les responsables produit, les développeurs, les équipes risques, conformité et métiers.

Les principes essentiels sont la traçabilité des responsabilités, le moindre privilège, la proportionnalité des contrôles, la responsabilité humaine, les preuves intégrées dès la conception et la maîtrise des changements.

• Chaque agent dispose d’un propriétaire métier et d’un propriétaire technique identifiés.
• Chaque agent fonctionne dans un objectif et un périmètre d’autorité clairement définis.
• Les accès aux systèmes, données et actions suivent le principe du moindre privilège.
• La supervision humaine est adaptée aux conséquences potentielles d’une erreur.
• Les preuves de test et d’approbation sont conservées et reproductibles.
• Les changements significatifs déclenchent une nouvelle évaluation.

2. Maintenir un inventaire de référence des agents

Une organisation ne peut pas gouverner des agents qu’elle ne peut pas identifier. Un inventaire d’entreprise constitue donc un contrôle fondamental.

Cet inventaire doit aller au-delà d’une simple liste de noms et permettre de comprendre ce que fait l’agent, où il fonctionne, à quels systèmes il accède et qui en est responsable.

• Nom, version et statut du cycle de vie.
• Objectif métier et utilisateurs prévus.
• Propriétaire métier, propriétaire technique et responsable du support.
• Environnement Microsoft, solution et emplacement de déploiement.
• Systèmes connectés, connecteurs, outils et catégories de données.
• Autorisations d’action et pouvoir transactionnel.
• Classification du risque et niveau d’approbation requis.
• Modèle de supervision humaine.
• Preuves de test, statut de certification et date de dernière revue.

3. Classifier le risque avant le déploiement

La classification du risque détermine le niveau de gouvernance requis. Le modèle utilisé n’est pas le seul facteur : il faut considérer ce que l’agent complet peut voir, décider et faire.

Un agent de consultation en lecture seule est fondamentalement différent d’un agent capable d’approuver des transactions, de communiquer à l’extérieur, de modifier des enregistrements ou de déclencher des processus.

Le CAI Score constitue l’approche structurée de ColleagueAI pour classifier le risque des agents d’entreprise. Il prend en compte l’autonomie, l’impact, la sensibilité des données, l’accès aux outils, la réversibilité, la supervision et les exigences de gouvernance.

4. Séparer responsabilité métier et propriété technique

Les équipes techniques peuvent construire et maintenir un agent, mais elles ne doivent pas être seules responsables du résultat métier. La fonction métier qui utilise l’agent doit rester responsable du processus et de ses conséquences.

Un modèle mature distingue donc propriété métier, propriété technique et assurance de gouvernance.

Le modèle de responsabilité doit également définir clairement les droits de décision. Le responsable métier valide l'objectif prévu, les résultats acceptables et les changements importants du processus, tandis que le responsable technique reste chargé de l'intégrité des composants de la solution, de la configuration et des contrôles techniques. Les fonctions de gouvernance, de risque, de sécurité ou de conformité peuvent assurer un contrôle indépendant sans se substituer à la responsabilité métier.

5. Gouverner identité, accès et permissions des outils

Les capacités d’un agent sont largement déterminées par les systèmes et actions auxquels il a accès. Les connecteurs, identités de service, credentials et permissions doivent donc être traités comme des contrôles de premier plan.

Les permissions doivent être limitées à ce qui est nécessaire pour le cas d’usage approuvé.

• Utiliser des identités dédiées lorsque l’architecture le permet.
• Limiter connecteurs et actions aux cas d’usage approuvés.
• Éviter les permissions larges accordées pour simple confort de développement.
• Journaliser les actions privilégiées.
• Utiliser des points d’approbation pour les actions irréversibles ou à fort impact.
• Revalider les permissions après toute modification du workflow ou des intégrations.

6. Intégrer la supervision humaine au workflow

La supervision humaine ne doit pas être une simple affirmation selon laquelle un humain reste responsable. Il faut identifier précisément où les personnes examinent, approuvent, interviennent ou arrêtent l’agent.

Le modèle approprié dépend du risque. Certains agents peuvent être autonomes dans des tâches faiblement risquées et strictement encadrées, tandis que d’autres nécessitent une approbation avant toute action importante.

Le contrôle doit préciser le moment de l'intervention, la personne qui effectue la revue, les informations dont elle dispose et les actions qu'elle est autorisée à entreprendre. Une étape d'approbation purement formelle n'est pas suffisante si la personne ne peut pas comprendre ou arrêter le résultat proposé. La supervision humaine doit donc être testée comme un véritable contrôle opérationnel.

7. Tester l’agent comme un système complet

L’assurance d’un agent exige de tester l’ensemble du workflow. La qualité du prompt compte, mais aussi les permissions, appels d’outils, comportements en erreur, traitement des données, logique d’escalade, qualité des résultats et gestion des entrées inattendues.

Un package de production doit conserver les preuves de ce qui a été testé, du comportement attendu, des limites connues et de la version validée.

• Tests fonctionnels et par scénarios.
• Tests des permissions et connecteurs.
• Chemins d’erreur et d’exception.
• Parcours d’approbation et d’escalade.
• Traitement des données sensibles.
• Critères de qualité des résultats.
• Journalisation et génération de preuves.
• Tests de régression après changements significatifs.

8. Faire du déploiement une transmission contrôlée

Un agent packagé doit avoir une frontière de déploiement claire. Le fournisseur peut fournir une solution testée, de la documentation, des guides de configuration, des preuves de gouvernance et des instructions de déploiement, mais le client contrôle son propre tenant et son environnement d’exploitation.

Pour les produits ColleagueAI, le déploiement et le runtime restent dans l’environnement Microsoft du client. La configuration spécifique au tenant, les intégrations, le déploiement et l’exploitation sont réalisés par le client ou un partenaire d’implémentation approuvé.

Un transfert contrôlé doit également documenter les prérequis, les variables d'environnement, les références de connexion, les rôles requis, les limites connues et les étapes de validation après import. Le client ou son partenaire d'implémentation peut ainsi reproduire la configuration testée sans dépendre de connaissances non documentées du développeur initial. La version déployée doit rester traçable jusqu'au package et aux preuves approuvés.

9. Surveiller le risque opérationnel et les changements

L’approbation initiale ne met pas fin à la gouvernance. Le comportement d’un agent peut évoluer lorsque les prompts, modèles, outils, permissions, sources de connaissances ou systèmes connectés changent.

La gouvernance continue doit donc suivre les changements significatifs, exceptions, incidents, usages, overrides d’approbation et preuves que la configuration déployée reste conforme au design approuvé.

Le suivi doit être associé à des déclencheurs explicites de nouvelle revue. Il peut s'agir d'un nouveau connecteur, de permissions élargies, d'un modèle différent, d'une nouvelle source de connaissances, d'une hausse des dérogations, d'exceptions répétées ou d'un changement du processus métier. Ces signaux doivent déterminer quand une investigation, une correction, une recertification ou une nouvelle décision de gouvernance est nécessaire.

10. Gouverner le retrait aussi sérieusement que le lancement

Les agents inutilisés ou remplacés ne doivent pas conserver indéfiniment des accès inactifs. Leur retrait doit supprimer les permissions, désactiver les intégrations, archiver les preuves et mettre à jour l’inventaire.

Un processus de retrait propre réduit la surface d’attaque et évite l’accumulation de capacités IA sans propriétaire.

Le retrait d'un agent doit également fermer ses dépendances opérationnelles et de gouvernance. Les responsables doivent confirmer que les flux planifiés sont désactivés, que les identifiants de service sont révoqués lorsque nécessaire, que les intégrations en aval ne dépendent plus de l'agent et que les preuves sont conservées conformément aux règles applicables. L'inventaire doit enregistrer la date de retrait et le statut final.

Questions fréquentes