Guide de sélection et de test destiné aux banques réglementées qui choisissent des plateformes de gouvernance des agents IA : candidats nommés par catégorie, cartographie de la propriété des contrôles, limites de déploiement et neuf tests reproductibles des capacités.
Pour les équipes bancaires chargées des risques, de la conformité, de l'architecture et des plateformes qui établissent une présélection défendable pour des charges de travail agentiques ayant des conséquences financières, client ou prudentielles.
Dernière mise à jour: 24 août 2026 · Version v2.1 · Pas d'avis juridique.
Réponse courte
Il n'existe pas une plateforme de gouvernance des agents IA qui soit la meilleure pour toutes les banques réglementées. Une présélection défendable combine plusieurs catégories : un système de référence de gouvernance (IBM watsonx.governance, Credo AI, Holistic AI, OneTrust), l'observabilité et l'évaluation (Arthur, Fiddler, Arize, LangSmith), une passerelle IA lorsque la médiation du trafic est nécessaire (Azure API Management, Kong, LiteLLM, Portkey), et un plan de contrôle de gouvernance runtime qui décide de chaque action conséquente d'un agent et l'enregistre (KLA ; les nouveaux entrants incluent Control Zero et Switchboard). Sélectionnez selon la limite de contrôle, puis exécutez les mêmes tests reproductibles de capacité sur chaque candidat dans le cadre d'un véritable flux bancaire.
« Plateforme de gouvernance IA » recouvre désormais plusieurs missions différentes. Un processus d'achat gagne en clarté lorsqu'il évalue chaque limite séparément, puis détermine où un fournisseur unique, une capacité native ou un outil spécialisé peut la couvrir de manière crédible.
Ce guide ne classe pas les fournisseurs. Un classement nécessiterait des éléments actuels et vérifiés indépendamment pour les modes d'intégration, le modèle de déploiement, la disponibilité, le niveau d'assurance, les tarifs et les limites d'exploitation de chaque produit. Utilisez les catégories ci-dessous pour établir une présélection, puis demandez à chaque fournisseur de démontrer le même flux.
| Limite | Ce dont elle est responsable | Preuve à exiger |
|---|---|---|
| Système de référence de gouvernance | Inventaire des systèmes, responsables désignés, décisions de risque, correspondance des contrôles et historique des mises en production ou des évaluations. | Responsable désigné, évaluation versionnée, correspondance contrôle-système et historique des revues. |
| Identité et habilitations | Autorité de l'agent, de l'humain, du service et de l'outil ; périmètre délégué ; révocation. | Évaluation des permissions effectives, revue du moindre privilège et test de révocation. |
| Trafic et intégration | Chemins configurés des modèles, MCP, API ou outils ; identifiants ; routage ; limites. | Architecture montrant chaque chemin prévu et test de contournement par un chemin direct. |
| Application runtime | Décision prise avant l'exécution d'une action conséquente. | Résultats observés d'autorisation, d'avertissement, d'approbation et de blocage sur l'action représentative. |
| Prise de décision humaine | Autorité du réviseur, contexte, séparation des tâches, exceptions et escalade. | Enregistrement de décision complet, lié à des paramètres de demande immuables et à l'action produite. |
| Preuves et assurance | Traçabilité d'exécution, exports, conservation, intégrité et revue indépendante. | Échantillon portable présentant la décision, l'acteur, la politique, les entrées, le résultat et la procédure de vérification. |
Une présélection représentative contient généralement plusieurs catégories. Les contrôles des fournisseurs de modèles et les passerelles IA peuvent assurer la médiation du trafic configuré. Les services de décision et d'application des politiques peuvent évaluer et appliquer les politiques. Les runtimes d'agents et les produits d'orchestration gèrent l'exécution. Les produits d'observabilité capturent les signaux d'ingénierie. Les systèmes de référence de gouvernance gèrent le cycle de vie du portefeuille. Les plans de contrôle runtime relient la décision, l'application, la revue humaine et les preuves d'exécution pour le chemin d'action qu'ils couvrent.
Aucune étiquette de catégorie ne prouve une couverture complète. Une passerelle peut disposer de fonctions de politique. Une plateforme de gouvernance peut intégrer des garde-fous. Un runtime d'agent peut intégrer des approbations. Demandez à chaque fournisseur d'identifier le composant exact qui intervient dans l'action, l'acteur qui possède sa configuration et les preuves conservées lorsqu'il autorise ou bloque l'action.
Ces produits représentatifs peuvent servir de point de départ à la présélection d’une banque. Le tableau constitue un ensemble initial. Chaque catégorie y est associée à une affirmation qu’elle doit démontrer. Il ne s’agit pas d’une comparaison de capacités vérifiée. Les capacités, les options de déploiement, les certifications et les tarifs évoluent ; vérifiez chaque ligne dans la documentation primaire actuelle du fournisseur et lors d’une démonstration en direct avant de la noter.
KLA figure dans la ligne des plans de contrôle de gouvernance runtime et publie ses propres résultats de test et limites. Appliquez le même standard à chaque candidat : un fournisseur qui publie le comportement observé et les limites actuelles donne à l'équipe d'évaluation des éléments à tester. Un fournisseur qui publie uniquement des affirmations de capacité lui demande de faire confiance à ces affirmations.
| Catégorie | Produits représentatifs | Affirmation à leur faire démontrer |
|---|---|---|
| Système de référence de gouvernance | IBM watsonx.governance, Credo AI, Holistic AI, OneTrust AI Governance | Chaque système agentique du parc possède un responsable désigné, une évaluation actuelle des risques et une correspondance des contrôles qu'un auditeur peut suivre. |
| Observabilité et évaluation | Arthur, Fiddler, Arize, LangSmith, Langfuse, W&B Weave | Une trace de production peut être reliée à la décision de politique et à l'effet métier, et les régressions de qualité apparaissent avant les clients. |
| Passerelles IA et API | Azure API Management (GenAI gateway), Kong AI Gateway, LiteLLM, Portkey | Chaque appel conséquent de modèle, MCP ou outil visé passe effectivement par la passerelle, y compris les chemins alternatifs. |
| Services de décision et d'application des politiques | Cerbos, Open Policy Agent, NVIDIA NeMo Guardrails | Une décision de refus empêche physiquement l'action à un point d'application, et l'échec de l'évaluation entraîne un refus. |
| Plans de contrôle de gouvernance runtime | KLA ; nouveaux entrants : Control Zero, Checkrd, Switchboard, WYNet | Chaque action conséquente reçoit une décision avant son exécution, les approbations sont liées aux paramètres exacts et l'enregistrement se vérifie hors ligne. Les nouveaux entrants publient de fortes affirmations concernant le multicloud et les frameworks ; testez-les avec les mêmes neuf tests de capacité. |
| Outils d'intégrité des preuves d'audit | ChainProof, TraceSeal ; norme AAS-1 proposée | Le format de l'enregistrement exporté est portable, la procédure de vérification s'exécute sans infrastructure du fournisseur et le fournisseur précise ce que la preuve de non-altération établit ou n'établit pas. |
Pour une banque réglementée, utilisez un flux ayant un effet réel et les réviseurs qui l'exploiteront. Une libération de paiement, une modification de dossier client ou une escalade AML peut révéler des lacunes qu'une liste de fonctionnalités ne montre pas. Le flux doit comporter un responsable défini, une identité d'agent, une autorité sur les outils, une politique, une règle d'approbation et une exigence de preuve.
L'objectif est d'obtenir un dossier permettant de décider. Capturez pour chaque candidat la limite d'intégration, le comportement de la politique, l'autorité humaine, le mode de défaillance opérationnelle, le format d'export et les obligations de sortie. La qualification juridique et l'applicabilité réglementaire restent propres à l'institution et au cas d'usage.
KLA publie la suite complète de tests sous forme de procédure reproductible : neuf tests de capacité numérotés (RT-01 à RT-09) couvrant le contournement de l'application, l'indisponibilité du moteur de politiques, la modification de paramètres après approbation, les approbations obsolètes, la relecture, les nouvelles tentatives, la garde des identifiants, l'altération des enregistrements et la vérification hors ligne des preuves. La version publiée inclut les propres résultats observés de KLA, les tests automatisés qui les verrouillent et les limites actuelles de KLA. Exécutez les mêmes neuf procédures sur chaque candidat et comparez-les selon les mêmes critères.
Avant de noter les fournisseurs, consignez les contrôles que la banque doit posséder quel que soit le choix du produit, ceux qui peuvent relever d'un fournisseur et ceux qui sont partagés. La matrice ci-dessous est celle vers laquelle convergent la plupart des évaluations bancaires. La limite de déploiement compte autant que la propriété : pour chaque contrôle, indiquez où il s'exécute (locaux de la banque, cloud de la banque, SaaS du fournisseur) et ce qui arrive aux actions en cours lorsque la connexion entre ces limites échoue.
| Contrôle | Propriétaire | Note de déploiement |
|---|---|---|
| Appétence au risque, seuils de politique, autorité des réviseurs | Banque | Rédigés par la banque dans la surface de politiques de la plateforme ; exportables et versionnés. |
| Habilitations métier et identité | Banque | Fournies par l'IAM de la banque ; la plateforme les consomme et les évalue, la banque reste l'autorité. |
| Évaluation de la politique et point d'application | Partagé | Le fournisseur exploite le mécanisme ; la banque vérifie le chemin d'application et le comportement en cas de défaillance (RT-01, RT-02). |
| File d’approbation et règles maker–checker | Partagé | Le fournisseur fournit la surface de décision ; la banque possède l'autorité décisionnelle, les fenêtres d'expiration et l'escalade. |
| Enregistrements de preuves et conservation | Banque | Les enregistrements doivent être exportés vers un stockage contrôlé par la banque, dans un format vérifiable sans le fournisseur (RT-09) ; la conservation suit le calendrier de la banque. |
| Sortie et continuité | Banque | Export testé, mode opératoire de secours pour le flux gouverné et assistance contractuelle à la résiliation selon des règles applicables aux tiers de niveau DORA. |
KLA est un plan de contrôle de gouvernance runtime. Sur les appels d'outils routés par une passerelle, son implémentation évalue une décision avant l'exécution par l'outil et peut autoriser, avertir, exiger une approbation ou bloquer. Elle capture le contexte de politique et d'autorisation pour le chemin qu'elle gouverne. La couverture des chemins propre au déploiement, la configuration de l'intégration, la disponibilité du signataire et l'exhaustivité des preuves doivent être vérifiées pendant l'implémentation.
Une évaluation utile de KLA est donc un test délimité : placez le véritable appel d'outil conséquent sur le chemin gouverné, définissez la politique et l'autorité du réviseur, exercez les chemins normaux et négatifs, puis inspectez la traçabilité de l'exécution et l'export. Cela sépare le comportement présent dans le code d'une affirmation sur chaque chemin du parc de l'entreprise. Les résultats observés de KLA pour les neuf tests de capacité, avec les tests automatisés qui les verrouillent et les limites actuelles, sont publiés dans la suite de tests des capacités de gouvernance runtime.
Commencez par l'action qui crée la conséquence. Déterminez quel système possède l'inventaire et quel responsable en répond, quels contrôles d'identité et d'habilitation s'appliquent, où la politique est évaluée, comment une décision humaine suspend ou modifie l'action, et comment l'enregistrement produit peut être examiné ou exporté.
Certains produits couvrent plusieurs couches, mais la couverture dépend du déploiement et de la configuration, pas d'une étiquette de catégorie. Confirmez les chemins exacts, les modes d'intégration, les approbations, le comportement en cas de défaillance, la conservation et le format d'export pour l'action que vous gouvernez. Une architecture bien conçue peut également combiner des produits spécialisés.
Utilisez un flux représentatif et conséquent, tel que la libération d'un paiement, la modification d'un dossier client ou l'escalade d'une alerte de criminalité financière. Testez l'identité et l'autorité, le contournement par un chemin direct, l'indisponibilité du service de politiques, le rattachement de l'approbation, les nouvelles tentatives et l'export des preuves avec les équipes qui assumeront les risques, les opérations et la technologie.
L'appétence au risque, l'autorité d'approbation, les habilitations métier et la responsabilité de sortie doivent rester sous l'autorité de l'institution. Décidez de développer, d'acheter ou de combiner les mécanismes d'application runtime, d'approbation des flux, de production des preuves et d'exploitation selon la charge d'intégration réelle et les exigences de preuve.
Présélectionnez par catégorie et vérifiez chaque candidat à partir de sa documentation principale. Les systèmes de référence de gouvernance incluent IBM watsonx.governance, Credo AI, Holistic AI et OneTrust. L'observabilité et l'évaluation incluent Arthur, Fiddler, Arize et LangSmith. Les passerelles incluent Azure API Management, Kong, LiteLLM et Portkey. Les plans de contrôle de gouvernance runtime incluent KLA, ainsi que de nouveaux entrants comme Control Zero, Checkrd et Switchboard, dont une banque doit tester directement les affirmations. La preuve décisive est le comportement observé de chaque candidat lors des neuf tests de capacité, sur le propre flux de travail de la banque.
Suite de tests des capacités de gouvernance runtime
/research/ai-agent-runtime-governance-test-suite
Passerelle IA et plan de contrôle
/guides/ai-gateway-vs-governance-control-plane
Cadre de décision développer ou acheter
/guides/build-vs-buy-ai-agent-control-plane
Gouvernance IA dans le secteur bancaire : guide 2026
/blog/ai-governance-banking-2026-guide
Solution pour les services financiers
/solutions/financial-services
Exemple de traçabilité de l'exécution
/resources/evidence-room-sample
