← Tous les Insights
Actualites du secteur05 nov. 2026Source : OCC

Cadre IA de l’OCC : relier les cas d’usage d’agents aux contrôles de risque existants

Illustration d’une action d’agent bancaire reliée aux responsables de risque existants et aux preuves de contrôle

Les équipes de conformité des banques devraient relier chaque cas d’usage d’agent ayant des effets significatifs aux dispositifs de maîtrise des risques qu’elles appliquent déjà. Le cadre destiné aux examinateurs publié par l’OCC le 4 novembre rend ce travail particulièrement opportun, tout en indiquant explicitement qu’il ne crée aucune nouvelle attente réglementaire et qu’il ne s’agit pas d’un document que les banques sont censées utiliser pour leur autoévaluation. Une réponse pratique consiste à établir une cartographie courte et vérifiable entre l’action métier d’un agent, le responsable du contrôle existant et le dossier d’éléments probants correspondant.

Ce que l’OCC a publié

L’OCC Bulletin 2026-54 présente un cadre destiné aux examinateurs. Le terme Super Intelligence y englobe des technologies auparavant désignées comme de l’IA. L’annonce indique que les examinateurs ne devraient pas traiter l’IA comme une catégorie de risque distincte et que les banques ne devraient pas être tenues de définir une appétence au risque spécifique à l’IA. Reuters rapporte de manière indépendante cette publication et l’attention qu’elle porte aux conséquences plutôt qu’au degré de sophistication du modèle.

Le bulletin exclut toute nouvelle attente prudentielle, toute norme exécutoire et toute exigence prescriptive. Cette précision compte lorsqu’une note interne se transforme en demande de projet. Présenter cela comme un nouveau cadre obligatoire de contrôle de l’IA déformerait la source. La cartographie ci-dessous relève de l’analyse de Maetra pour organiser un travail déjà existant, et non d’une liste de contrôle de l’OCC ou d’une conclusion sur les obligations juridiques d’une banque en particulier.

Commencer par l’action bancaire

Une entrée d’inventaire telle que « assistant fondé sur un modèle de langage » laisse trop peu d’informations au responsable du risque. Décrivez d’abord l’action métier : préparer une analyse interne, rédiger un message client, modifier un dossier ou initier une transaction. Décrivez ensuite la manière dont l’humain et l’agent se partagent la tâche.

Pour un agent hypothétique de service client, indiquez s’il peut seulement proposer une réponse, enregistrer un brouillon, envoyer le message ou modifier le compte du client. Ces autorisations créent des besoins de revue différents, même si chaque version utilise le même modèle. Identifiez la frontière effectivement déployée et la personne habilitée à la modifier. Une capacité inscrite sur une feuille de route doit figurer dans un champ distinct d’une autorisation active aujourd’hui.

Limitez chaque fiche à un périmètre précis pour faciliter son examen. Un même agent qui exécute plusieurs actions dont les effets diffèrent sensiblement peut nécessiter plusieurs enregistrements au niveau de l’action. Une simple étiquette « IA approuvée » appliquée à tout un département peut masquer le flux de travail réellement examiné et l’ajout ultérieur qui n’a jamais été présenté au responsable compétent.

Relier les cas d’usage aux contrôles et à leurs responsables

Maetra recommande une fiche de correspondance concise comportant six champs :

  1. Cas d’usage et action : la finalité métier et l’opération exacte que l’agent est autorisé à exécuter.
  2. Domaine de risque existant : la classification applicable propre à la banque, avec la justification de cette correspondance.
  3. Responsable du contrôle : la personne chargée du contrôle concerné, qu’il s’agisse des accès, des changements, des revues ou de la surveillance.
  4. Limites opérationnelles : les données, systèmes, limites de transaction et points de contrôle humains qui encadrent actuellement l’action.
  5. Référence des éléments probants : la configuration, le test ou le compte rendu de revue qui étaye le périmètre défini.
  6. Motif de réexamen : le changement qui imposerait de réexaminer la preuve.

La valeur réside dans les relations entre ces champs. Un responsable du contrôle d’accès doit pouvoir retrouver la configuration d’autorisation sans demander à l’équipe responsable du modèle de reconstituer une présentation. Un responsable métier doit pouvoir expliquer pourquoi un effet externe donné reste dans les limites du flux de travail approuvé.

Certaines actions touchent plusieurs domaines de risque existants. Désignez un responsable coordinateur et nommez les responsables contributeurs plutôt que de créer des copies concurrentes d’un même contrôle. Consignez explicitement les désaccords. Une correspondance restant à clarifier est une information utile ; une feuille de calcul bien ordonnée qui laisse supposer un accord ne l’est pas autant.

Tester une frontière à l’aide d’un exemple concret

Prenons le cas d’un agent hypothétique qui prépare une instruction de paiement qu’un employé doit examiner. Demandez au responsable technique de montrer, dans un environnement de test approprié, ce qui empêche l’agent de la soumettre lui-même. La preuve peut inclure une configuration de rôle, les autorisations d’intégration pertinentes et un test montrant que la tentative de soumission a été refusée.

Si l’agent peut soumettre dans une certaine limite, consignez cette frontière différente ainsi que le responsable de cette limite. Ne réutilisez pas le test limité au brouillon comme preuve pour le flux de soumission. Un test concluant doit aussi comporter une date et une référence de configuration afin qu’une modification ultérieure des autorisations n’hérite pas silencieusement du résultat antérieur.

Cette approche aide à distinguer trois questions : ce que le système était censé faire, ce qu’il était configuré pour faire et ce que le test a effectivement montré. Lorsque ces réponses divergent, décrivez l’écart avant de formuler de nouvelles conclusions sur les garanties offertes par le système. Le guide de Maetra sur la cartographie des systèmes d’IA vers les obligations de conformité explique plus largement cette démarche.

Garder une réponse proportionnée

La publication récente d’une ressource destinée aux examinateurs ne justifie pas de dupliquer chaque processus de gestion des risques. Commencez par un cas d’usage significatif, identifiez ses responsables existants et repérez les preuves déjà tenues à jour. Ajoutez les références manquantes ou un test ciblé lorsque le dossier actuel ne permet pas de répondre à une question concrète.

Maetra Comply prend en charge la cartographie des référentiels et la gestion de preuves réutilisables ; Discover prend en charge l’inventaire des agents et des capacités, qui permet d’identifier les éléments à cartographier. Aucun des deux n’établit la conformité réglementaire d’une banque ni ne se substitue à sa propre appréciation des exigences applicables. Les équipes qui explorent ce travail peuvent utiliser la couverture des référentiels de Maetra pour planifier un exercice de cartographie délimité.

Sources

Supervision bancaire de l’IACartographie des contrôlesPreuves de conformité