Checklist de gouvernance des modèles d'IA pour les services financiers

L'intelligence artificielle intervient désormais dans des activités financières telles que l'évaluation du crédit, la détection de la fraude et certaines décisions opérationnelles. Son utilisation peut étendre les capacités, mais elle rend également plus important de savoir quels modèles sont déployés, qui en répond et comment leurs défaillances sont détectées.

Ce checklist aide les responsables du risque, de la conformité, des données et de la technologie à examiner les contrôles tout au long du cycle de vie. C'est un outil d'auto-évaluation, et non une certification ni un conseil juridique. Les références réglementaires et supérieures ont des portées différentes ; chaque entité doit déterminer lesquelles s'appliquent à elle selon son activité, sa localisation et sa supervision.

1. Responsabilités et périmètre

• Existe-t-il une politique de gouvernance de l'IA et des modèles approuvée par le niveau d'autorité correspondant et révisée lorsque les activités ou les risques changent ?
• Les responsables des affaires, du développement, de la validation indépendante, de la gestion des risques, de la conformité et de la technologie sont-ils identifiés ?
• Des voies d'escalade ont-elles été définies pour les résultats inattendus, les incidents, les litiges ou les non-conformités aux contrôles internes ?
• La direction reçoit-elle des informations suffisantes pour superviser les risques pertinents, sans dépendre uniquement d'explications techniques ou de fournisseurs ?
• L'entité a-t-elle déterminé quels cadres et obligations pourraient s'appliquer dans chaque juridiction où elle opère, et qui vérifie cette interprétation ?

La supervision doit être proportionnée au profil et à la complexité de l'entité ainsi qu'à la pertinence de chaque usage. Tous les modèles ne nécessitent pas des contrôles identiques ou la même fréquence de révision.

2. Inventaire et classification des modèles

• Existe-t-il un inventaire à jour incluant les modèles en production, en test et, le cas échéant, les solutions acquises ou intégrées par des tiers ?
• Pour chaque système, sa finalité, son domaine utilisateur, son responsable, ses entrées, ses sorties, ses hypothèses, sa version et son état dans le cycle de vie sont-ils enregistrés ?
• Une définition interne du modèle suffisamment claire a-t-elle été établie pour identifier également les algorithmes ou composants influençant les décisions, même s'ils sont présentés comme des outils ou des services externes ?
• Chaque modèle est-il classifié selon son usage, son exposition, son impact potentiel et sa dépendance envers d'autres systèmes ?
• L'inventaire permet-il d'identifier les modèles sans propriétaire assigné, les doublons, les modèles obsolètes ou déployés sans révision formelle ?

Un inventaire utile n'est pas seulement un catalogue technique : il permet de savoir où chaque modèle est utilisé, quelles décisions il soutient et qui peut intervenir s'il ne fonctionne pas comme prévu.

3. Données, qualité et traçabilité

• L'origine des données est-elle documentée et, lorsque c'est possible, leur parcours depuis l'obtention jusqu'à l'utilisation dans le modèle ?
• La qualité, la pertinence, l'actualité et la représentativité des données sont-elles évaluées par rapport à la finalité déclarée ?
• Les données manquantes, les erreurs, les changements de définitions et les biais potentiels pouvant affecter les résultats sont-ils identifiés ?
• Des contrôles d'accès, de confidentialité, de conservation et d'utilisation conformes aux politiques internes et aux normes pertinentes sont-ils appliqués ?
• Est-il possible de reconstituer quelles données et quelles transformations ont été utilisées dans une version spécifique du modèle ou dans une décision pertinente ?

La révision doit couvrir à la fois les données de développement et celles qui alimentent le système en opération. Une bonne documentation de la provenance et des transformations facilite l'investigation des écarts et l'explication des limites du modèle.

4. Développement, validation et approbation

• Les objectifs, les hypothèses et les limites du modèle sont-ils définis avant son déploiement ?
• Est-il vérifié que la méthode choisie est adaptée à l'usage prévu et que ses résultats sont suffisamment stables dans des conditions raisonnables ?
• La validation examine-t-elle les performances, la sensibilité aux changements de données, les cas extrêmes et les effets indésirables possibles ?
• La révision est-elle indépendante de ceux qui ont développé ou implémenté le modèle, dans la mesure exigée par le cadre interne et le risque ?
• Les constatations, les limites, les mesures correctives et la décision d'approuver, de restreindre ou de ne pas déployer le modèle sont-elles documentées ?
• Les contrôles sont-ils ajustés au risque et à la complexité, au lieu d'appliquer automatiquement une fréquence ou une procédure identique à tous les modèles ?

La validation ne se limite pas à vérifier les métriques initiales. Elle doit fournir des preuves suffisantes pour évaluer si le modèle est adapté à sa finalité et quelles conditions pourraient invalider cette conclusion.

5. Supervision humaine et utilisation des résultats

• Est-il clair quelles décisions le modèle peut soutenir et lesquelles nécessitent une révision ou une autorisation humaine ?
• Les utilisateurs connaissent-ils les limites, les signaux d'alerte et les étapes pour contester ou escalader un résultat ?
• Existe-t-il une voie praticable pour corriger ou réviser les résultats problématiques lorsque le processus et la réglementation applicable l'exigent ?
• Évite-t-on qu'une recommandation automatisée soit traitée comme concluante sans considérer son contexte et sa qualité ?
• Si un modèle est utilisé pour évaluer ou valider un autre, des limites d'utilisation, des contrôles et une révision humaine sont-ils définis pour réduire le risque d'erreurs en chaîne ?

La supervision humaine doit être efficace : les personnes ont besoin d'informations, d'autorité et de temps pour intervenir. La simple présence d'une approbation formelle ne démontre pas à elle seule qu'un contrôle substantiel existe.

6. Documentation, changements et suivi

• Des documents compréhensibles sur la finalité, la conception, les données, les tests, les résultats, les limites et les responsables sont-ils conservés ?
• Chaque changement de données, de code, de configuration ou de fournisseur est-il enregistré et soumis à un processus d'évaluation et d'approbation proportionné ?
• Des indicateurs pour détériorer la performance, les changements de données ou les résultats atypiques existent-ils ?
• Des responsables, des seuils d'alerte et des actions possibles sont-ils définis lorsque le suivi identifie un écart ?
• Est-il révisé périodiquement si le modèle reste adapté à son usage, et sa retrait est-il envisagé s'il ne l'est plus ?
• Les registres permettent-ils de reconstituer les versions, les changements et les décisions de gestion lors d'une révision interne ou externe ?

Le suivi relie la validation initiale au comportement réel. Si l'environnement, les données ou la finalité changent, il peut être nécessaire de réviser les contrôles et l'autorisation d'utilisation.

7. Fournisseurs et dépendances externes

• Les modèles, services et composants de tiers intervenant dans des processus pertinents sont-ils connus ?
• A-t-il été évalué quelles informations le fournisseur reçoit, comment elles sont utilisées et quelle documentation il fournit sur le système ?
• Les canaux pour notifier les incidents, les changements substantiels, les interruptions ou les modifications des conditions de service sont-ils définis ?
• L'entité conserve-t-elle une capacité suffisante pour superviser l'utilisation et gérer la dépendance, même lorsqu'elle ne contrôle pas le développement du modèle ?
• La concentration des fournisseurs et les alternatives disponibles si un service cesse d'être accessible ou change de manière significative ont-elles été prises en considération ?

La sous-traitance externe n'élimine pas le besoin de comprendre comment un système affecte les activités de l'entité. Le degré d'information et de contrôle disponible peut varier selon le fournisseur et le service.

Comment interpréter les cadres de référence

Les sources considérées décrivent des approches différentes : orientations supérieures et de gestion des modèles aux États-Unis, au Canada et au Royaume-Uni, références sur l'IA dans l'Union européenne et propositions de gouvernance à Singapour, en plus des cadres volontaires et des matériaux sectoriels. Par exemple, le NIST AI Risk Management Framework est présenté comme un cadre volontaire ; le guide canadien OSFI E-23 a un périmètre et un calendrier propres ; et la déclaration britannique PRA SS1/23 correspond à son contexte supérieur. Le matériel décrit également un cadre sectoriel du Trésor américain avec 230 objectifs de contrôle, qui ne doit pas être interprété comme une obligation universelle.

Par conséquent, ces références servent à orienter les questions et à comparer les pratiques, et non à remplacer l'analyse des normes applicables à chaque entité. La juridiction, le type d'institution, l'activité et l'usage concret du modèle peuvent modifier le périmètre des obligations.

Résultat de l'auto-évaluation

Pour chaque question, l'entité peut enregistrer les preuves disponibles, le responsable, l'écart détecté et la prochaine révision. Les réponses négatives ou incomplètes aident à prioriser le travail, mais ne déterminent pas à elles seules la conformité juridique ni le niveau global de risque. L'important est que les décisions de contrôle soient traçables, proportionnées à l'usage et révisables lorsque le modèle ou son contexte change.