Gouvernance de l’IA dans la banque : le modèle opérationnel pour une IA maîtrisée à grande échelle

Executive Summary

1Pourquoi la gouvernance de l’IA dans la banque est différente

L’intelligence artificielle dans la banque n’est plus un sujet futur. Elle entre déjà dans le risque de crédit, la détection de fraude, l’AML, le service client, le développement logiciel, le reporting réglementaire, la cyberdéfense, la résilience opérationnelle et la productivité interne. L’European Banking Authority a indiqué en 2025 que l’adoption de l’IA dans le secteur bancaire et des paiements de l’UE avait largement dépassé le stade de la discussion : 92% des banques de l’UE déploient déjà l’IA, tandis que les 8% restantes pilotent ou discutent des cas d’usage IA. Cela change complètement la question de gouvernance. La gouvernance de l’IA dans la banque ne peut plus être traitée comme un complément éthique, une annexe de validation de modèle ou une politique détenue par une équipe spécialisée. Elle devient une partie du système de management de la banque.

Le point central est le suivant : la gouvernance IA ne vise pas à ralentir l’IA. Elle vise à rendre l’IA scalable dans une institution supervisée.

De nombreuses banques présentent encore la gouvernance IA comme un exercice de conformité. C’est compréhensible, mais stratégiquement trop étroit. En Europe, l’EU AI Act, DORA, le GDPR, les règles d’outsourcing, les attentes en matière de model risk management, les exigences d’internal governance et les priorités de l’ECB Banking Supervision sont tous pertinents. Mais le vrai défi n’est pas de collecter des références réglementaires. Le vrai défi consiste à les traduire en un modèle opérationnel permettant à une banque d’identifier, d’approuver, de déployer, de surveiller et de challenger les systèmes IA à travers le business, la technologie, le risque, la conformité, les données, le cyber, le juridique, l’audit et le conseil.

C’est là que beaucoup de cadres de gouvernance IA échouent. Ils semblent complets sur le papier, mais ne changent pas la manière dont les décisions sont prises.

Une banque peut publier une politique IA. Elle peut créer un comité IA. Elle peut nommer un AI Officer. Elle peut exiger des impact assessments, de la documentation modèle, des contrôles de qualité des données et une supervision humaine. Rien de tout cela n’est faux. Mais si ces éléments ne sont pas reliés aux décisions d’investissement, aux standards d’architecture, au risk appetite, au vendor onboarding, à la change governance, à l’incident management et au reporting au conseil, la banque n’a pas une gouvernance IA. Elle a de la paperasse IA.

La différence est importante parce que la banque n’est pas un environnement technologique ordinaire. Les banques ne traitent pas simplement des données. Elles allouent le crédit, gèrent les dépôts, détectent la criminalité financière, calculent le capital, sécurisent les paiements, traitent des données personnelles sensibles et exploitent une infrastructure économique critique. Lorsque l’IA est intégrée dans ces processus, elle devient une partie de l’environnement de contrôle de l’institution. La question n’est donc pas de savoir si l’IA est innovante. La question est de savoir si elle est gouvernée comme une partie de la banque.

La gouvernance de l’IA dans la banque est différente pour quatre raisons.

1. 1Les conséquences d’un échec sont différentes. Un système IA mal gouverné peut créer des résultats de crédit biaisés, de fausses alertes de fraude, un préjudice client, une détection AML insuffisante, une mauvaise classification du risque, une exposition cyber non contrôlée, des erreurs de reporting réglementaire ou une dépendance excessive à un modèle tiers. Dans une application grand public, un mauvais output IA peut créer un risque de réputation. Dans une banque, il peut affecter les clients, le capital, le conduct, la résilience et la confiance du superviseur.
2. 2L’empilement réglementaire est différent. L’EU AI Act introduit des règles horizontales pour les systèmes IA, y compris des exigences pour l’IA à haut risque. DORA introduit un cadre contraignant pour la résilience opérationnelle numérique dans le secteur financier. Le GDPR reste central dès que des données personnelles, du profilage ou des décisions automatisées sont impliqués. La réglementation bancaire exige déjà une gouvernance interne robuste, une gestion des risques, une supervision de l’outsourcing et un contrôle des modèles. L’IA ne remplace aucun de ces cadres. Elle les croise tous.
3. 3L’environnement opérationnel est différent. La plupart des grandes banques exploitent des paysages technologiques complexes avec des systèmes legacy, une ownership des données fragmentée, plusieurs fournisseurs cloud, du développement externalisé, des plateformes régionales, des exigences réglementaires locales et des fonctions de contrôle qui se chevauchent. La gouvernance IA ne peut donc pas être conçue comme un cadre académique propre. Elle doit fonctionner dans une réalité d’entreprise complexe.
4. 4Le modèle de responsabilité est différent. Dans la banque, personne de crédible ne devrait dire : « Le modèle a décidé. » Le management reste responsable. Le conseil reste responsable de l’oversight. Risk et Compliance restent responsables du challenge. Technology reste responsable de l’implémentation sécurisée et résiliente. Le business reste responsable du cas d’usage et de ses résultats. La gouvernance IA doit rendre cette responsabilité visible avant la mise en production du modèle, pas après un incident.

Un modèle pratique de gouvernance IA devrait donc commencer par un principe simple : chaque cas d’usage IA matériel doit avoir un owner clairement responsable, une finalité documentée, une classification du risque définie, des sources de données approuvées, des contrôles techniques et business, une supervision humaine lorsque nécessaire, des dispositifs de monitoring et un chemin d’escalade clair.

Cela paraît évident. En pratique, c’est difficile.

La difficulté ne vient pas du fait que les banques manquent de fonctions de contrôle. La difficulté vient du fait que l’IA traverse ces fonctions. Data Governance peut détenir la qualité des données. Technology peut détenir les plateformes. Cyber peut détenir les contrôles de sécurité. Risk peut détenir le model risk. Compliance peut détenir l’interprétation réglementaire. Legal peut détenir les sujets contractuels et de responsabilité. Procurement peut détenir l’onboarding des tiers. Audit peut détenir l’assurance indépendante. Le business peut détenir le cas d’usage. Le conseil peut demander des progrès. Sans modèle intégré de gouvernance IA, chaque fonction ne voit qu’une partie du risque.

La gouvernance IA est la discipline qui réunit ces parties.

ai-governance-in-banking-2.jpg16:9 · /insights/img/

2L’EU AI Act : un déclencheur de gouvernance, pas un cadre autonome

L’EU AI Act est souvent discuté comme s’il constituait toute l’histoire de la gouvernance IA. Ce n’est pas le cas. C’est un déclencheur majeur, mais pas le cadre complet.

Pour les banques, l’AI Act est particulièrement pertinent parce que certains cas d’usage de services financiers peuvent entrer dans la catégorie à haut risque. L’exemple le plus évident est l’évaluation de la solvabilité. Selon l’Annexe III de l’AI Act, les systèmes IA utilisés pour évaluer la solvabilité de personnes physiques ou établir leur score de crédit sont classés à haut risque, sauf lorsque le système est utilisé pour détecter la fraude financière. Cette exception est importante parce qu’elle montre que la classification dépend non seulement de la technologie, mais aussi de la finalité et du contexte d’utilisation.

C’est ici que commence la gouvernance pratique.

Une banque ne peut pas simplement demander si un outil est de l’« IA ». Ce n’est que la première question. Elle doit demander ce que fait le système, qui est affecté, s’il soutient ou prend une décision, si la décision produit des effets juridiques ou similaires significatifs, si le cas d’usage est lié à des catégories à haut risque, si des données personnelles sont traitées, si le modèle est développé en interne ou fourni par un tiers, et si le système est utilisé dans un processus bancaire réglementé.

Un modèle utilisé pour la productivité interne peut nécessiter un chemin de gouvernance. Un modèle utilisé pour la segmentation client peut en nécessiter un autre. Un modèle utilisé pour la solvabilité, le recouvrement, la détection de fraude, la priorisation d’alertes AML ou le reporting réglementaire peut exiger un niveau de preuve beaucoup plus élevé. La technologie peut sembler similaire. L’obligation de gouvernance ne l’est pas.

L’AI Act renforce des exigences que les banques sérieuses devraient déjà reconnaître : gestion des risques, gouvernance des données, documentation technique, tenue de registres, transparence, supervision humaine, exactitude, robustesse et cybersécurité. Ce ne sont pas des concepts juridiques abstraits. Ils correspondent directement aux disciplines de contrôle bancaire. La gestion des risques se relie au risk appetite et à l’évaluation des contrôles. La gouvernance des données se relie à la lineage, à la qualité et à l’usage autorisé. La documentation se relie à l’auditabilité. Les enregistrements se relient à la preuve. La supervision humaine se relie à l’accountability. La robustesse et la cybersécurité se relient à la résilience technologique.

C’est pourquoi l’AI Act ne devrait pas être mis en œuvre comme un silo de conformité séparé. Si une banque crée un projet AI Act autonome, déconnecté de la gouvernance technologique, de la gouvernance des données, du model risk management, de DORA, du GDPR et de l’outsourcing oversight, elle créera de la duplication et de la confusion. L’approche la plus stratégique consiste à utiliser l’AI Act comme mécanisme de pression pour renforcer le modèle de gouvernance IA d’entreprise de la banque.

Le travail de mapping de l’EBA sur l’AI Act est pertinent ici, car il a évalué les implications de l’AI Act pour le secteur bancaire et des paiements de l’UE, avec une attention particulière aux systèmes IA à haut risque tels que l’évaluation de solvabilité et le credit scoring. Le message important pour les banques est que l’AI Act readiness ne doit pas être traitée comme un univers parallèle. Elle doit être cartographiée par rapport aux obligations sectorielles existantes et aux attentes de supervision.

En pratique, chaque banque devrait construire un inventaire des cas d’usage IA qui fait plus que lister des outils. Il devrait classifier la finalité, le groupe d’utilisateurs, la population affectée, l’impact décisionnel, la catégorie de données, le type de modèle, la source de développement, la dépendance tierce, la criticité opérationnelle, la pertinence réglementaire et le statut de contrôle. Sans cet inventaire, le senior management ne peut pas savoir où se situe le risque IA. Sans connaître ce risque, il ne peut pas le gouverner.

3Mise à jour Digital Omnibus : le calendrier a changé, pas la responsabilité

Au 29 juin 2026, le Conseil de l’Union européenne a donné son approbation finale à des mesures ciblées de simplification de l’AI Act. Selon la communication du Conseil, l’application des obligations relatives aux systèmes IA à haut risque est déplacée au 2 décembre 2027 pour les systèmes IA autonomes à haut risque et au 2 août 2028 pour les systèmes IA intégrés dans des produits. Je ne peux pas confirmer, sur la base des sources disponibles ici, si le règlement modificatif final a déjà été publié au Journal officiel de l’Union européenne.

Pour les banques, cela modifie la planification de mise en œuvre, mais pas la logique de gouvernance.

Le temps supplémentaire ne devrait pas servir à reporter la gouvernance IA. Il devrait servir à construire l’inventaire, la logique de classification, les contrôles de données, l’approche model risk, la supervision des tiers et le reporting au conseil dont l’IA scalable aura de toute façon besoin. La deadline peut bouger. La responsabilité ne bouge pas.

C’est important parce que l’adoption de l’IA n’attend pas les échéances juridiques. Les banques déploient déjà l’IA dans l’interaction client, la détection de fraude, les processus de crédit, la productivité interne, le développement logiciel et le risk analytics. Si la gouvernance attend la dernière date juridique possible, la banque accumulera pendant des années une exposition IA non classifiée, non documentée et mal contrôlée.

Une banque sérieuse devrait donc utiliser ce calendrier modifié comme un avantage de planification, pas comme une excuse pour retarder. La bonne question n’est pas : « Jusqu’à quand pouvons-nous attendre pour être conformes ? » La bonne question est : « À quel moment pouvons-nous construire un modèle de gouvernance réutilisable qui rend le scaling conforme plus simple ? »

C’est la différence stratégique entre la gestion des deadlines et l’exécution contrôlée.

4DORA : quand la gouvernance de l’IA rencontre la résilience opérationnelle

Les discussions sur la gouvernance IA se concentrent souvent sur la fairness, l’explicabilité et le model risk. Ces sujets comptent. Mais pour les banques, ils ne suffisent pas.

DORA rend la réalité technologique inévitable. Le règlement (UE) 2022/2554 établit un cadre européen pour la résilience opérationnelle numérique du secteur financier, incluant la gestion du risque ICT, le reporting d’incidents, les tests de résilience opérationnelle et le risque ICT lié aux tiers. Cela concerne directement l’IA, car les systèmes IA dépendent de plus en plus de l’infrastructure cloud, des API, des services de modèles, des fournisseurs de données externes, du développement externalisé et des fournisseurs technologiques.

Une banque peut penser qu’elle implémente un chatbot de service client. Du point de vue de la gouvernance, elle introduit peut-être un nouveau flux de données, une nouvelle dépendance fournisseur, un nouveau problème de contrôle d’accès, une nouvelle exigence de monitoring, un nouveau scénario de risque opérationnel et un nouveau chemin d’incident management. Si le chatbot utilise l’IA générative, la banque doit aussi considérer le risque d’hallucination, le prompt injection, la fuite de données confidentielles, le logging insuffisant, la faible explicabilité, le model drift et la dépendance aux mises à jour du fournisseur.

C’est pourquoi la gouvernance IA ne peut pas rester en dehors de la résilience opérationnelle.

Un cadre sérieux de gouvernance IA dans la banque doit poser des questions de type DORA dès le départ. Le système IA soutient-il un service métier important ? Dépend-il d’un fournisseur ICT critique ? Que se passe-t-il si le service modèle devient indisponible ? Que se passe-t-il si les outputs se dégradent ? Que se passe-t-il si le fournisseur modifie le modèle ? Que se passe-t-il si le système produit à grande échelle des outputs nuisibles ou trompeurs ? Que se passe-t-il si des données sensibles sont exposées via prompts, embeddings, logs ou outputs ? Qui le détecte ? Qui décide s’il s’agit d’un incident ICT, d’un incident data, d’un problème modèle, d’un sujet conduct — ou de tout cela à la fois ?

Ces questions déterminent si l’IA est prête pour la production.

DORA modifie également la relation entre innovation IA et risque tiers. De nombreuses capacités IA ne seront pas construites entièrement dans la banque. Elles viendront de fournisseurs cloud, de plateformes IA, de logiciels fournisseurs, de data providers, d’outils analytics et de services modèles spécialisés. Ce n’est pas automatiquement un problème. Mais cela signifie que la gouvernance IA doit être intégrée dans le procurement, l’assessment outsourcing, la classification du risque ICT, les clauses contractuelles, l’exit planning, le service monitoring et l’analyse du risque de concentration.

Une banque qui traite la sélection d’un fournisseur IA comme un achat logiciel normal manque le sujet. La question n’est pas seulement de savoir si l’outil fonctionne. La question est de savoir si la banque peut contrôler, surveiller, expliquer, challenger, sortir et démontrer l’usage de cet outil dans un environnement régulé.

C’est là que la gouvernance devient pratique. Le processus d’approbation IA ne devrait pas commencer après que Procurement a sélectionné le fournisseur. Il devrait commencer avant que la banque ne s’engage sur une architecture, un modèle de partage de données ou une dépendance contractuelle qui deviendra difficile à défaire.

5GDPR et décisions automatisées

La gouvernance IA dans la banque est impossible sans gouvernance de la protection des données.

Le GDPR reste central parce que de nombreux cas d’usage IA bancaires impliquent des données personnelles, du profilage ou des décisions susceptibles d’affecter significativement des personnes. L’article 22 du GDPR donne aux personnes le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, lorsque cette décision produit des effets juridiques ou des effets similaires significatifs, sous réserve d’exceptions et de garanties spécifiques. C’est directement pertinent lorsque l’IA est utilisée dans le crédit, le pricing, le recouvrement, la vulnérabilité client, les contrôles de fraude ou d’autres processus décisionnels affectant les clients.

Mais le GDPR ne concerne pas seulement les décisions automatisées. Il concerne aussi la base légale, la limitation des finalités, la minimisation des données, la transparence, l’exactitude, la limitation de conservation, l’intégrité, la confidentialité et l’accountability. Ces principes ne sont pas des obstacles à la gouvernance IA. Ils en font partie.

L’Opinion 28/2024 de l’EDPB est importante parce qu’elle traite des aspects de protection des données liés aux modèles IA, notamment quand et comment un modèle IA peut être considéré comme anonyme, comment l’intérêt légitime peut être évalué comme base légale en phase de développement et de déploiement, et quelles conséquences peuvent découler d’un traitement illicite en phase de développement. Pour les banques, c’est particulièrement pertinent parce que la data lineage et l’usage licite des données ne sont pas des questions abstraites de privacy. Elles déterminent si la banque peut défendre le cycle de vie du modèle.

L’implication pratique est claire : la gouvernance IA doit relier l’approbation du modèle à l’approbation des données.

Un modèle ne devrait pas être approuvé simplement parce qu’il performe statistiquement. Il faut aussi savoir quelles données ont été utilisées, si la banque a le droit de les utiliser pour la finalité prévue, si des données personnelles sont impliquées, si des caractéristiques sensibles ou protégées sont présentes directement ou indirectement, si des proxies peuvent créer un biais, si la qualité des données est suffisante, si des durées de conservation sont définies et si l’utilisation des outputs est transparente pour les personnes concernées lorsque cela est requis.

C’est particulièrement important pour l’IA générative et les grands modèles de langage. Beaucoup de banques ont commencé par des cas d’usage de productivité interne parce qu’ils semblaient moins risqués. Mais même des outils internes peuvent traiter des informations confidentielles, des données personnelles, des données client, du code, des dossiers d’incidents, du matériel RH, des rapports de risque ou des documents de supervision. Si les employés collent des informations sensibles dans un outil IA sans contrôles appropriés, la banque peut créer des problèmes de privacy, de confidentialité, de propriété intellectuelle, de sécurité et de réglementation avant même qu’un cas d’usage client externe n’existe.

C’est pourquoi les politiques d’usage acceptable ne suffisent pas. Les banques ont besoin de garde-fous techniques, de logging, de contrôles d’accès, de data-loss prevention, de formation, de monitoring et de conséquences claires en cas de mauvaise utilisation. Plus important encore, elles ont besoin d’alternatives approuvées et utilisables. Si l’environnement IA officiel est trop lent, trop restrictif ou trop éloigné de la manière dont les employés travaillent, la shadow AI émergera.

La shadow AI n’est pas une stratégie d’innovation. C’est une défaillance de contrôle.

6Gestion du risque de modèle et IA générative

La gouvernance IA dans la banque doit s’appuyer sur le model risk management, mais elle ne peut pas s’y limiter.

Les banques connaissent déjà la gouvernance des modèles dans le risque de crédit, le risque de marché, le risque de liquidité, les modèles de capital, les stress tests et IFRS 9. Elles connaissent l’importance de la validation, de la documentation, du monitoring, des limitations, du change control et du challenge indépendant. Mais l’IA ajoute de la complexité : comportement non linéaire du modèle, dépendance aux données, interprétabilité réduite, possibilités d’apprentissage continu, dépendance à des fournisseurs externes de modèles et nouvelles formes de risque d’output.

Le follow-up report de l’EBA sur le machine learning pour les modèles IRB est utile parce qu’il montre comment les exigences prudentielles, le GDPR et l’AI Act se croisent lorsque le machine learning est utilisé dans des modèles de risque de crédit. Le guide révisé de la BCE sur les modèles internes clarifie également les attentes de supervision concernant l’usage de techniques de machine learning dans les modèles internes. Ce ne sont pas des documents génériques d’éthique IA. Ce sont des matériaux de supervision spécifiques à la banque qui comptent pour une gouvernance IA sérieuse.

La leçon pratique est que les banques ont besoin d’une approche graduée de gouvernance des modèles. Tous les systèmes IA ne devraient pas passer par le même processus de validation qu’un modèle IRB. Ce serait impraticable. Mais tous les systèmes IA ne peuvent pas non plus être traités comme de simples fonctionnalités logicielles. Le cadre de gouvernance doit classifier les modèles selon la matérialité, le cas d’usage, la pertinence réglementaire, l’impact décisionnel, la complexité, la sensibilité des données, le besoin d’explicabilité, la dépendance opérationnelle et le dommage potentiel.

Un outil interne de résumé à faible risque peut nécessiter un accès contrôlé, des restrictions de données, du logging et un monitoring d’usage acceptable. Un modèle utilisé pour prioriser des alertes AML peut nécessiter une validation plus forte, une explicabilité, une évaluation du biais, un monitoring de performance et un back-testing opérationnel. Un modèle de solvabilité peut nécessiter un chemin de gouvernance beaucoup plus formel parce qu’il peut affecter directement l’accès aux ressources financières et relever d’une catégorie IA à haut risque.

Le model risk management doit aussi évoluer pour l’IA générative. La validation traditionnelle demande si le modèle performe par rapport à des métriques définies sur des données définies. L’IA générative ajoute des questions plus difficiles à réduire à un seul score. Le système hallucine-t-il ? Produit-il des outputs plausibles mais faux ? Fuit-il des informations confidentielles ? Est-il vulnérable au prompt injection ? Génère-t-il des réponses discriminatoires ou trompeuses ? Se comporte-t-il différemment selon les langues ? Se dégrade-t-il lorsque le fournisseur met à jour le modèle ? La banque peut-elle reproduire les outputs ? Peut-elle expliquer pourquoi une réponse a été générée ? Le cas d’usage exige-t-il un comportement déterministe ou un output probabiliste est-il acceptable ?

Ces questions doivent être traitées avant le déploiement, pas après un incident.

La gouvernance IA doit définir ce que signifie « suffisamment bon » pour chaque classe de cas d’usage IA. Si la banque ne peut pas définir des critères d’acceptation, elle ne peut pas gouverner le système. Si elle ne peut pas le gouverner, elle ne devrait pas le scaler.

ai-governance-in-banking-3.jpg16:9 · /insights/img/

7L’inventaire IA : l’outil de gouvernance le plus sous-estimé

L’artefact de gouvernance IA le plus important dans une banque n’est pas la politique. C’est l’inventaire.

Sans inventaire IA, la banque ne connaît pas son exposition. Sans connaissance de l’exposition, elle ne peut pas classifier le risque. Sans classification du risque, elle ne peut pas appliquer de contrôles proportionnés. Sans contrôles proportionnés, elle sur-contrôle les cas d’usage à faible risque ou sous-contrôle les cas matériels.

Un inventaire IA sérieux devrait inclure au minimum les dimensions suivantes : owner du cas d’usage, processus business, entité juridique, juridiction, groupe d’utilisateurs, population affectée, type de modèle, fournisseur, sources de données, implication de données personnelles, impact décisionnel, matérialité, classification AI Act, pertinence GDPR, pertinence DORA, pertinence outsourcing, classification model risk, statut de validation, métriques de monitoring, incidents, limitations, risque résiduel et statut de retrait.

L’inventaire doit également capturer l’IA intégrée dans des produits fournisseurs. C’est facile à manquer. Les banques peuvent ne pas penser qu’elles déploient de l’IA lorsqu’elles achètent un logiciel avec des fonctionnalités IA intégrées. Mais du point de vue de la gouvernance, l’IA intégrée peut quand même affecter des processus, des décisions, des flux de données et des dépendances opérationnelles. L’IA fournisseur n’est pas hors de la responsabilité de la banque simplement parce que le modèle se trouve dans un produit tiers.

L’inventaire devrait aussi distinguer l’expérimentation de la production. Un proof of concept dans une sandbox n’est pas la même chose qu’un outil utilisé par des centaines d’employés ou qu’un modèle affectant les résultats clients. Mais les pilotes ont aussi besoin de gouvernance. Ils ont besoin de limites : données approuvées, environnements approuvés, limites de temps, critères de sortie et règles de passage en production.

Le passage du pilote à la production est l’un des moments les plus risqués de la gouvernance IA. De nombreuses défaillances apparaissent parce qu’un cas d’usage commencé de manière informelle devient opérationnel sans passer par une gate de contrôle appropriée. Une démo devient un workflow. Un workflow devient une dépendance. Une dépendance devient un problème de contrôle.

La gouvernance IA doit rendre cette transition visible.

8Supervision humaine au-delà de la case à cocher

La supervision humaine est l’un des concepts les plus répétés dans la gouvernance IA. C’est aussi l’un des plus mal compris.

Une banque ne devrait pas revendiquer une supervision humaine significative simplement parce qu’une personne se trouve quelque part dans le processus. La supervision humaine doit être conçue. Le reviewer humain doit comprendre la finalité du système IA, les limitations du modèle, le contexte décisionnel, les critères d’escalade et les circonstances dans lesquelles l’output IA doit être challengé ou annulé.

C’est particulièrement important dans la banque, car les employés peuvent faire excessivement confiance aux outputs IA lorsqu’ils paraissent précis, techniques ou confiants. Une recommandation de crédit, un score de fraude, une priorisation AML, un résumé de risque client ou une anomalie de reporting réglementaire peut sembler objective parce qu’elle est générée par un modèle. Mais l’output du modèle n’est pas la vérité. C’est une estimation structurée produite sous des hypothèses, des limitations de données et des choix de conception.

La supervision humaine doit donc être reliée à la formation, au design de processus, aux droits de décision et à l’accountability. Qui peut passer outre le système IA ? Quand faut-il le faire ? Quelle preuve est requise ? Les overrides sont-ils surveillés ? Les patterns d’overrides sont-ils revus ? Le reviewer humain est-il suffisamment indépendant ? Existe-t-il un risque d’automation bias ? Le processus laisse-t-il assez de temps pour une vraie revue, ou l’humain se contente-t-il de tamponner l’output du modèle ?

Il est facile d’écrire « human in the loop » dans une politique. Il est beaucoup plus difficile de concevoir un processus dans lequel l’humain a réellement la compétence, l’autorité et le temps de challenger la machine.

Pour les cas d’usage bancaires à fort impact, cette différence est décisive.

9Explicabilité : tous les modèles n’exigent pas la même explication

L’explicabilité est un autre domaine où les banques ont besoin de discipline pratique.

Tous les systèmes IA n’exigent pas le même niveau d’explication. Un modèle utilisé pour router des tickets internes ne requiert pas la même explicabilité qu’un modèle soutenant l’évaluation de solvabilité. Un assistant IA génératif qui résume des politiques internes n’exige pas le même standard d’explication qu’un modèle de classification du risque. Mais tout système IA matériel a besoin d’un standard d’explication adapté à son usage.

L’explicabilité devrait être définie selon l’audience et la finalité. Un data scientist peut avoir besoin d’une explication technique. Un validateur modèle peut avoir besoin de drivers de performance, de limitations et d’analyses de sensibilité. Un business user peut avoir besoin de reason codes et de logique décisionnelle. Un client peut avoir besoin d’informations compréhensibles sur la manière dont une décision le concernant a été prise. Un superviseur peut avoir besoin de preuves que la banque comprend, contrôle et surveille le système.

Une seule méthode d’explication ne répondra pas à tous ces besoins.

Pour les banques, l’explicabilité doit être connectée à l’accountability. Si personne ne peut expliquer le modèle suffisamment bien pour le challenger, la banque devrait être prudente avant de le déployer dans des processus décisionnels matériels. Cela ne signifie pas que seuls des modèles simples peuvent être utilisés. Cela signifie que la banque doit pouvoir justifier pourquoi un modèle est approprié pour le cas d’usage, comment ses limitations sont contrôlées, comment ses outputs sont surveillés et comment les parties affectées sont protégées.

Le BIS Financial Stability Institute a identifié la régulation de l’IA dans les services financiers comme un domaine actif de développement prudentiel, incluant model risk, data privacy, explicabilité et risques spécifiques à l’IA générative tels que l’hallucination.

La bonne question n’est pas : « Pouvons-nous expliquer le modèle parfaitement ? » La bonne question est : « Pouvons-nous l’expliquer suffisamment pour la décision qu’il soutient et le risque qu’il crée ? »

10IA tierce et IA intégrée dans les produits fournisseurs

L’IA tierce sera l’un des défis de gouvernance les plus difficiles pour les banques.

De nombreuses banques s’appuieront sur des fournisseurs externes pour les foundation models, l’infrastructure cloud, les plateformes IA, les applications fournisseurs, les services de données, les outils de monitoring et les analytics spécialisés. C’est rationnel. Aucune banque ne devrait supposer qu’elle peut construire toutes les capacités IA en interne. Mais l’usage de tiers ne transfère pas l’accountability hors de la banque.

Le Financial Stability Board a identifié les dépendances envers les tiers, les corrélations de marché, les cyberrisques et les défis de model risk et de gouvernance comme des vulnérabilités liées à l’IA ayant des implications potentielles pour la stabilité financière. C’est très pertinent pour les banques, car l’adoption de l’IA peut concentrer les dépendances sur un petit nombre de fournisseurs technologiques et cloud.

Du point de vue de la gouvernance, l’IA tierce soulève plusieurs questions.

La banque sait-elle si le produit fournisseur contient de l’IA ? Le contrat permet-il à la banque de comprendre le rôle, les limitations et le cycle de mise à jour du modèle ? La banque peut-elle restreindre l’usage des données ? Peut-elle empêcher le fournisseur d’utiliser les données bancaires pour l’entraînement ? Les logs sont-ils disponibles ? La banque peut-elle tester les outputs ? Le fournisseur fournit-il une documentation suffisante ? Que se passe-t-il lorsque le fournisseur modifie le modèle ? Que se passe-t-il si le fournisseur retire le service ? Existe-t-il un plan de sortie ? Y a-t-il des risques de concentration au niveau de la banque ? Plusieurs processus critiques dépendent-ils du même fournisseur ?

Ces questions ne devraient pas être posées uniquement pour les arrangements d’outsourcing critiques. Elles devraient faire partie plus largement de la gouvernance des fournisseurs IA, avec une proportionnalité fondée sur la matérialité.

Les équipes Procurement ont besoin de literacy IA. Les équipes Legal ont besoin de positions contractuelles spécifiques à l’IA. Les équipes Technology ont besoin de standards d’architecture. Les équipes Risk ont besoin d’une classification du risque fournisseur. Les équipes business doivent comprendre qu’acheter de l’IA n’est pas la même chose qu’acheter un logiciel ordinaire.

Le risque fournisseur IA le plus dangereux n’est pas toujours le plus visible. Parfois, c’est la fonctionnalité IA cachée dans une plateforme que la banque utilise déjà. Un fournisseur introduit une nouvelle fonctionnalité IA. Une équipe business l’active. Les données commencent à circuler. Les outputs entrent dans un workflow. Personne ne met à jour l’inventaire. Personne n’évalue le risque. Personne n’informe le conseil.

C’est ainsi que la shadow AI devient un risque institutionnel.

11Valeur business et mécanisme d’arrêt

La gouvernance IA ne devrait pas être conçue uniquement autour du risque. Ce serait incomplet.

Les banques ont besoin d’IA parce qu’elles ont besoin d’une meilleure productivité, d’une meilleure expérience client, d’une détection de fraude plus forte, d’un développement logiciel plus rapide, d’une meilleure analyse des risques, de contrôles plus efficaces et d’une meilleure utilisation des données. Un modèle de gouvernance qui ne fait que bloquer l’IA échouera. Il poussera l’innovation dans des canaux informels ou rendra la banque stratégiquement plus lente.

Le bon modèle de gouvernance doit relier contrôle du risque et création de valeur.

Chaque cas d’usage IA matériel devrait avoir un business case. Quel problème résout-il ? Quel processus améliore-t-il ? Quel coût réduit-il ? Quel risque atténue-t-il ? Quel résultat client améliore-t-il ? Quelle faiblesse de contrôle adresse-t-il ? Quelle métrique prouvera que le cas d’usage fonctionne ?

Sans cette discipline, l’IA devient du théâtre.

Les banques sont particulièrement vulnérables à l’AI theatre parce que la pression exécutive est élevée. Chaque institution veut montrer qu’elle est active en IA. Chaque fonction veut un cas d’usage. Chaque fournisseur revendique une capacité IA. Chaque présentation stratégique inclut une slide sur l’IA générative. Mais l’activité n’est pas la transformation.

Une banque avec cinquante pilotes et aucun modèle de contrôle scalable n’est pas en avance. Elle est exposée.

Une banque avec moins de cas d’usage, mais une plateforme claire, des pipelines de données gouvernés, des chemins d’approbation réutilisables, des bénéfices mesurables et un déploiement en production contrôlé peut être dans une position beaucoup plus forte. L’objectif n’est pas de maximiser le nombre d’expériences IA. L’objectif est d’opérationnaliser l’IA là où elle crée de la valeur et peut être contrôlée.

C’est pourquoi la gouvernance IA devrait inclure un mécanisme d’arrêt. Tous les cas d’usage IA ne devraient pas survivre. Si un cas d’usage ne crée pas de valeur mesurable, ne peut pas être contrôlé, duplique des capacités existantes, augmente la complexité ou crée un risque disproportionné, il devrait être arrêté. La gouvernance mature ne concerne pas seulement l’approbation. Elle concerne aussi la terminaison.

ai-governance-in-banking-4.jpg16:9 · /insights/img/

12La gouvernance IA comme capacité d’entreprise

Les banques qui réussiront à scaler l’IA traiteront la gouvernance IA comme une capacité d’entreprise.

Cela signifie que la banque dispose d’une taxonomie IA commune. Elle sait ce qui compte comme IA, ce qui compte comme IA générative, ce qui compte comme modèle, ce qui compte comme high impact, ce qui compte comme usage en production et ce qui compte comme usage interdit ou restreint.

Cela signifie que la banque dispose d’un inventaire contrôlé. Pas dix feuilles de calcul. Pas des registres dispersés entre Risk, Technology, Data et Compliance. Une vue fiable de l’adoption IA et du risque.

Cela signifie que la banque dispose de chemins d’approbation fondés sur le risque. Les outils de productivité à faible risque suivent un processus proportionné. Les systèmes décisionnels à fort impact font l’objet d’une revue plus approfondie. L’IA tierce est évaluée avant adoption. Les changements matériels déclenchent une réapprobation.

Cela signifie que la banque dispose d’une AI Control Library. Les contrôles de données, contrôles d’accès, logs, monitoring, bias testing, explicabilité, tests cyber, contrôles fournisseurs, triggers d’incident et supervision humaine ne sont pas réinventés pour chaque cas d’usage.

Cela signifie que la banque dispose d’une literacy IA à plusieurs niveaux. Les membres du conseil doivent comprendre assez pour challenger le management. Les senior executives doivent comprendre assez pour assumer les décisions. Les fonctions de contrôle doivent comprendre assez pour évaluer le risque. Les employés doivent comprendre assez pour utiliser les outils de manière sûre.

Cela signifie que la banque dispose de métriques. La gouvernance IA sans métriques devient narrative. La banque devrait suivre les cas d’usage IA par statut, classe de risque, business line, entité juridique, fournisseur, maturité des contrôles, issues, incidents, valeur délivrée et constats d’audit.

Cela signifie que la banque dispose d’une assurance. L’audit interne ne devrait pas attendre que l’IA ait déjà été scalée de manière informelle. Il devrait tester le cadre de gouvernance, l’exhaustivité de l’inventaire, le design des contrôles, les preuves d’approbation, le monitoring et la remédiation des issues.

Cela signifie que la banque dispose d’un rythme de management. La gouvernance IA devrait être revue régulièrement dans le forum exécutif approprié, escaladée au conseil lorsque c’est matériel, et reliée à la stratégie, aux investissements technologiques et au risk appetite.

Les cadres externes peuvent soutenir ce travail. ISO/IEC 42001:2023 spécifie des exigences et des lignes directrices pour établir, mettre en œuvre, maintenir et améliorer continuellement un système de management de l’IA. Le NIST AI Risk Management Framework et le Generative AI Profile fournissent une référence structurée pour la gestion du risque IA, y compris les risques de l’IA générative.

Mais une banque ne devrait pas confondre alignement avec un framework et readiness réglementaire. ISO et NIST peuvent soutenir le système de management, mais ils ne remplacent pas l’EU AI Act, DORA, le GDPR, les attentes de l’EBA, la supervision de la BCE, les obligations d’internal governance ou les exigences réglementaires locales.

La meilleure approche consiste à utiliser les cadres externes comme échafaudage, pas comme le bâtiment lui-même.

13Ce que les conseils devraient demander maintenant

Les conseils et senior executives ne devraient pas attendre un cadre de gouvernance IA parfait pour poser de meilleures questions. Ils peuvent commencer maintenant.

• Ils devraient demander : avons-nous un inventaire IA complet, y compris l’IA tierce et l’IA intégrée?
• Ils devraient demander : quels cas d’usage IA pourraient affecter matériellement les clients, les employés, les décisions de risque, les contrôles de criminalité financière, le reporting réglementaire, le capital ou la résilience opérationnelle?
• Ils devraient demander : quels systèmes IA pourraient relever des catégories à haut risque de l’EU AI Act, et quelles preuves soutiennent cette classification?
• Ils devraient demander : comment la gouvernance IA se connecte-t-elle à DORA, au GDPR, à l’outsourcing, au model risk management et à l’internal governance?
• Ils devraient demander : qui est responsable end to end de chaque système IA matériel?
• Ils devraient demander : le management peut-il démontrer la qualité des données, l’usage licite des données, la performance du modèle, la supervision humaine, le monitoring et la gestion des issues?
• Ils devraient demander : quelles dépendances IA tierces émergent, et où un risque de concentration pourrait-il apparaître?
• Ils devraient demander : où l’IA générative est-elle déjà utilisée par les employés, et comment la shadow AI est-elle prévenue?
• Ils devraient demander : quelle valeur mesurable l’IA a-t-elle délivrée, et quels cas d’usage devraient être arrêtés?
• Ils devraient demander : quand l’audit interne examinera-t-il le cadre de gouvernance IA?

Ces questions ne visent pas à ralentir l’IA. Elles visent à rendre l’IA réelle.

14Conclusion

La gouvernance de l’IA dans la banque est souvent mal comprise. Elle est traitée comme un fardeau réglementaire, une checklist de conformité ou une couche de contrôle défensive. Cette vision est trop limitée.

Dans une banque européenne, la gouvernance IA est le mécanisme qui permet à l’IA de scaler sans affaiblir l’accountability, la résilience, la protection des données, le contrôle des modèles ou la confiance du superviseur.

Les institutions qui échoueront ne seront pas nécessairement celles qui avancent lentement. Certaines avanceront vite, mais sans contrôle. D’autres construiront des documents de gouvernance complexes qui ne changent pas la prise de décision. Les deux approches finiront par bloquer.

Les institutions qui réussiront feront quelque chose de plus difficile. Elles connecteront la stratégie IA au modèle opérationnel de la banque. Elles sauront où l’IA est utilisée. Elles classifieront les risques de manière cohérente. Elles gouverneront données et modèles ensemble. Elles contrôleront les dépendances tierces. Elles rendront la supervision humaine significative. Elles fourniront au conseil des preuves, pas des slogans. Elles arrêteront les cas d’usage faibles et scaleront les cas forts.

C’est la différence entre expérimentation IA et transformation IA.

Une banque peut acheter des outils IA. Elle peut acheter des plateformes cloud. Elle peut acheter l’accès à des modèles. Elle peut acheter du consulting. Mais elle ne peut pas acheter l’accountability. Elle ne peut pas outsourcer le jugement. Elle ne peut pas déléguer la confiance.

La gouvernance IA dans la banque n’est donc pas le côté administratif de l’IA. C’est la discipline de leadership qui détermine si l’IA devient une capacité d’entreprise contrôlée ou une couche supplémentaire de complexité non maîtrisée.

La prochaine ligne de séparation compétitive dans la banque européenne ne sera pas entre les banques qui utilisent l’IA et celles qui ne l’utilisent pas. Presque toutes les institutions sérieuses l’utiliseront. La ligne passera entre les banques capables de gouverner l’IA à grande échelle et celles qui resteront coincées entre innovation theatre et inconfort prudentiel.

C’est dans la gouvernance IA que cette ligne deviendra visible.

15Sources

La base factuelle et réglementaire de cet article comprend : l’EU AI Act et sa logique de classification à haut risque, y compris l’Annexe III ; la communication du Conseil du 29 juin 2026 sur la simplification de l’AI Act et les calendriers ajustés pour les systèmes à haut risque ; DORA et son cadre de risque ICT et de risque tiers ; le GDPR, y compris les décisions automatisées au titre de l’article 22 ; l’Opinion 28/2024 de l’EDPB sur les modèles IA et les données personnelles ; les matériaux de l’EBA sur l’adoption de l’IA et les implications de l’AI Act pour la banque et les paiements ; les matériaux de la BCE sur les modèles internes et le machine learning ; les matériaux du FSB sur les vulnérabilités liées à l’IA pour la stabilité financière ; les travaux BIS/FSI sur la régulation de l’IA dans les services financiers ; ISO/IEC 42001:2023 ; ainsi que le NIST AI Risk Management Framework et le Generative AI Profile.