Lignes directrices bancaires américaines sur le risque de modèle — SR 26-2, qui a remplacé SR 11-7 le 17 avril 2026 — preuves relatives au risque de modèle
Cette page est générée à partir de la table d'exigences que le moteur AiSSAY livre pour ce référentiel. Quand le moteur produit un dossier de preuves, chaque ligne ci-dessous reçoit un statut calculé à partir des propres enregistrements de l'opérateur à ce moment-là. Cette page montre la table, pas les résultats de qui que ce soit.
Mise en correspondance à titre informatif, établie par les propres outils de l'opérateur. Ce n'est ni un avis juridique, ni une certification, ni un substitut au conseil d'un avocat. Elle organise les enregistrements de l'opérateur au regard des exigences citées ; la question de savoir si ces enregistrements satisfont aux exigences relève de l'appréciation de l'opérateur, de son conseil juridique et du contrôleur.
SR 26-2 (Federal Reserve, OCC et FDIC, avril 2026) a remplacé SR 11-7 et place pour l'instant les modèles d'IA générative et agentique hors de son champ ; les agences ont annoncé qu'une demande d'informations sur l'IA suivrait. Cette vue met en correspondance les enregistrements d'agents avec les principes de gestion du risque de modèle communs aux deux lettres : suivi, remise en cause effective, documentation et enregistrements destinés à l'audit. Pour les systèmes agentiques, il s'agit d'un alignement volontaire, pas d'une exigence prudentielle.
La table d'exigences
4 lignes : 4 mécanismes
| Exigence | Mécanisme, obligation ou lacune | Type |
|---|---|---|
| Suivi continu de la performance du modèle | constats par exécution ; comparaison de la dérive entre fenêtres temporelles ; registre de calibration là où les résultats sont consignés | mécanisme |
| Remise en cause effective, indépendante du modèle | rapprochement déterministe, sondes de type pot de miel et tests d'enregistrements falsifiés exécutés hors du contrôle du modèle ; arbitrage croisé entre modèles disponible | mécanisme |
| Une documentation suffisante pour des parties qui ne connaissent pas le modèle | compte rendu structuré en 21 champs pour chaque exécution, rendu lisible ; les enregistrements survivent aux changements de fournisseur et de modèle | mécanisme |
| Des enregistrements à l'appui de la validation et de l'audit | scellés, avec accès journalisés, conservés selon le calendrier prévu | mécanisme |
Comment un statut s'obtient
- Étayé
- une vérification déterministe a été exécutée sur vos enregistrements et les décomptes étayent la ligne. Un stockage ne contenant aucun enregistrement pertinent apparaît comme non étayé — une affirmation vraie, pas une validation. Vide ne compte jamais comme conforme.
- Délégué
- le mécanisme est appliqué par un système auquel vous faites déjà confiance — un stockage scellé par votre propre gestionnaire de clés lui délègue le contrôle d'accès, et le dossier indique que le journal qui fait foi est celui de votre gestionnaire de clés, pas le nôtre. Le dossier nomme le point de terminaison par lequel le gestionnaire de clés a été joint. Un point de terminaison AWS autre que celui qu'AWS utilise par défaut pour la région apparaît comme délégué à ce point de terminaison, avec une demande de confirmation qu'il s'agit bien de votre service de gestion des clés. Un seul backend — AWS KMS — a été exécuté sur le service AWS KMS réel ; aucun autre backend ne l'a été.
- Point d'intégration de test
- scellé par un backend de test interne au processus — un bouchon (stub), ou un substitut du client AWS — et le statut précise lequel. Aucun gestionnaire de clés n'applique le contrôle d'accès. Le point d'intégration est construit et testé, et le dossier refuse d'appeler cela une délégation.
- Partiellement étayé
- le mécanisme est construit et certaines de vos exécutions en portent la preuve, mais pas toutes — généralement parce qu'elles ont été scellées avant que le mécanisme n'existe. Le dossier indique combien d'exécutions se trouvent dans chaque groupe, et ne compte jamais celles qui manquent comme validées.
- Organisationnel
- l'exigence est une procédure que seules des personnes peuvent accomplir. Le dossier la désigne comme la vôtre au lieu de déguiser une politique en mécanisme.
- Lacune nommée
- le dossier ne peut pas l'étayer — soit le mécanisme n'est pas construit, soit aucun logiciel ne peut le fournir — et il précise lequel des deux. La lacune est imprimée, parce qu'un examinateur doit la lire ici plutôt que la découvrir.
Aucun statut n'est saisi à la main : chaque statut est recalculé à partir du stockage chaque fois qu'un dossier est produit, le texte des exigences et des mécanismes est rédigé et relu dans le cadre du moteur, et les preuves relatives aux dépendances proviennent de notre analyse de version. Un mécanisme en échec ne peut jamais être lu comme la preuve que le contrôle fonctionne.