SR 11-7 face à l’IA agentique : la gestion du risque de modèle appliquée aux agents IA dans la banque

Depuis plus de dix ans, la gestion du risque de modèle dans les banques américaines est façonnée par un seul document : SR 11-7, la Supervisory Guidance on Model Risk Management de la Réserve fédérale, publiée en avril 2011. L’OCC a publié des orientations identiques sur le fond (Bulletin 2011-12), et la FDIC les a adoptées en 2017. La plupart des banques ont construit autour de ce texte leurs politiques de risque de modèle, leurs inventaires et leurs équipes de validation.

L’IA générative et les agents IA mettent aujourd’hui ce cadre à l’épreuve d’une manière que ses auteurs ne pouvaient anticiper. La bonne nouvelle est que SR 11-7 a été rédigé sous forme de principes et non de règles, et qu’une grande partie reste pertinente. La difficulté est de savoir jusqu’où il peut s’étendre et où il s’arrête.

Ce que SR 11-7 attend des banques

SR 11-7 repose sur trois piliers :

• Un développement, une mise en œuvre et une utilisation rigoureux. Les modèles doivent avoir une finalité claire, une conception solide, des données appropriées et des limites documentées, et être utilisés conformément à leur objet.
• Une validation avec remise en question effective. Les modèles doivent être examinés par des personnes indépendantes du développement, disposant de la compétence et de l’influence nécessaires pour contester hypothèses et résultats.
• Gouvernance, politiques et contrôles. Le conseil d’administration et la direction générale fixent les politiques, définissent les rôles et responsabilités, et tiennent un inventaire des modèles utilisés.

Le texte définit aussi le modèle de manière large, comme une méthode quantitative qui transforme des données d’entrée en estimations, et précise que le risque de modèle provient à la fois d’erreurs dans le modèle et d’une utilisation inappropriée de celui-ci. C’est cette largeur de champ qui le rend pertinent pour l’IA aujourd’hui.

Ce qui constitue un modèle, et comment le classer par niveau de risque

Une grille de score de crédit traditionnelle est facile à identifier comme un modèle. Un agent IA l’est moins. Il combine généralement un grand modèle de langage, un ensemble de prompts et d’instructions, la recherche dans des documents internes, des outils qui appellent d’autres systèmes et des règles métier qui déterminent la suite.

Nous recommandons aux banques de traiter la question par couches plutôt que d’un seul bloc :

• Le modèle de fondation. Le LLM sous-jacent est généralement un composant tiers. Il a sa place dans l’inventaire, même si la banque ne peut pas examiner la manière dont il a été construit.
• L’application configurée. Les prompts, sources documentaires, paramètres et garde-fous qui transforment un modèle généraliste en cas d’usage précis. C’est là que se crée l’essentiel du risque propre à la banque, et c’est là que les validateurs doivent concentrer leur attention.
• Les actions de l’agent. Les outils et habilitations qui permettent à l’application de modifier des données ou de déclencher des processus. Comme nous le verrons plus loin, cette couche exige des contrôles que SR 11-7 n’a pas été conçu pour fournir.

Certaines banques traiteront certains usages de l’IA générative comme des « outils » ou des « non-modèles » plutôt que comme des modèles. Cela peut se justifier pour des usages à faible risque, mais la décision doit être documentée, cohérente et soumise à la même remise en question que toute autre classification. Les exclusions non documentées sont un constat fréquent lors des revues.

Une fois les usages de l’IA identifiés, il faut les classer par niveau de risque. La plupart des banques classent déjà leurs modèles selon leur matérialité, afin que la profondeur de la validation soit proportionnée au risque. La même logique doit s’appliquer à l’IA, mais les critères doivent être actualisés. Un usage de l’IA générative qui rédige des comptes rendus de réunions internes et un autre qui répond aux questions des clients sur les frais peuvent reposer sur le même modèle et présenter des risques très différents.

Parmi les critères de classement utiles pour l’IA et les agents :

• les résultats atteignent-ils les clients ou influencent-ils leur situation ;
• le système peut-il agir ou se limite-t-il à des recommandations ;
• l’impact financier, déontologique et de conformité d’une erreur ;
• le degré de revue humaine avant que l’on se fie aux résultats ;
• la sensibilité des données auxquelles il peut accéder.

Un agent capable de modifier des données dans les systèmes bancaires cœur ou de paiement devrait se situer dans les niveaux les plus élevés presque par définition, quelle que soit la sophistication de son modèle.

Valider des systèmes qui ne donnent jamais deux fois la même réponse

La validation traditionnelle repose sur la reproduction des résultats, le test des hypothèses et la comparaison avec des approches alternatives. Les grands modèles de langage sont non déterministes : une même entrée peut produire des sorties différentes, et leur comportement peut changer lorsqu’un fournisseur met à jour le modèle. La validation doit s’adapter sans renoncer à la remise en question effective.

En pratique, cela suppose de combiner plusieurs techniques :

• Jeux de tests par cas d’usage. Des ensembles d’entrées réalistes, sélectionnés avec leurs résultats attendus, exécutés de manière répétée pour mesurer l’exactitude et la cohérence sur de nombreuses exécutions plutôt que sur une seule.
• Points de comparaison. Une comparaison avec une référence, comme le processus manuel existant ou une approche plus simple fondée sur des règles, afin que la banque puisse juger si l’IA est adaptée à l’usage prévu.
• Red teaming. Des tentatives délibérées de mettre le système en échec, notamment par injection de prompts, tentatives d’extraction de données confidentielles et entrées conçues pour provoquer des résultats biaisés ou préjudiciables.
• Surveillance continue. Le comportement pouvant dériver, la validation ne peut pas être un exercice ponctuel. La surveillance en production de la qualité des résultats, des taux de correction, des réclamations et des incidents fait partie des éléments probants de la validation.

Les validateurs auront aussi besoin de nouvelles compétences. Une remise en question effective exige des personnes qui comprennent comment ces systèmes échouent, et pas seulement la théorie statistique des modèles.

Modèles tiers et risque fournisseur

SR 11-7 attend déjà des banques qu’elles gèrent les modèles de fournisseurs, même lorsque ceux-ci ne communiquent pas tous les détails de conception et de données. Ce principe devient central, car l’essentiel de l’IA générative dans les banques repose sur des modèles que la banque n’a pas construits et ne peut pas examiner entièrement.

Les banques devraient relier la gestion du risque de modèle à la gestion du risque lié aux tiers, afin de comprendre, pour chaque fournisseur d’IA :

• quelle documentation et quels éléments de test le fournisseur met à disposition ;
• comment et quand le fournisseur modifie ou retire des modèles, et comment la banque en est informée ;
• où les données sont traitées et si elles servent à entraîner les modèles du fournisseur ;
• de quels droits contractuels la banque dispose pour auditer, tester et se désengager.

Lorsque la transparence du fournisseur est limitée, les tests et la surveillance menés par la banque sur l’application configurée doivent porter une plus grande part de la charge.

La lacune : SR 11-7 valide des modèles, pas des actions

C’est le point le plus important pour les banques qui déploient des agents. SR 11-7 porte sur la solidité des résultats d’un modèle et sur leur utilisation appropriée. Il n’indique pas à une banque comment contrôler un système qui agit de lui-même : ce qu’il est autorisé à modifier, qui approuve ces modifications et comment les annuler.

Un modèle bien validé peut tout de même causer des dommages si l’agent qui l’entoure dispose d’habilitations excessives ou d’aucune étape d’approbation. Combler cette lacune suppose de mobiliser des contrôles issus du risque opérationnel et des contrôles généraux informatiques :

• Identités et accès. Chaque agent dispose de sa propre identité, avec des habilitations au moindre privilège, intégrée aux revues d’accès.
• Approbations. Des seuils d’approbation humaine fixés selon le risque de chaque action, et non appliqués uniformément.
• Gestion des changements. Les modifications des prompts, des outils et des versions de modèles suivent des processus de mise en production contrôlés, comme les modifications de code.
• Journalisation et pistes d’audit. Chaque action est attribuable, reconstituable et reliée à la donnée qu’elle a modifiée.
• Réponse aux incidents. Un moyen éprouvé de suspendre un agent et d’annuler ses actions.

La réponse pragmatique n’est pas d’étirer SR 11-7 pour tout couvrir, mais de définir clairement quelle fonction est responsable de quel contrôle, afin que le risque de modèle, le risque opérationnel, le risque technologique et les métiers connaissent chacun leur rôle.

Les attentes des superviseurs évoluent

Les superviseurs ont clairement indiqué que les attentes existantes en matière de risque de modèle, de risque lié aux tiers et de résilience opérationnelle s’appliquent à l’IA, et ces attentes continuent d’évoluer. Les banques qui étendent leurs cadres actuels avec discernement, documentent leur raisonnement et comblent l’écart entre validation des modèles et contrôle des actions seront en bonne position, quelle que soit la suite.

Cet article est fourni à titre d’information générale et ne constitue pas un conseil juridique ou réglementaire.