Gouvernance de l'IA bancaire

La gouvernance commence par une décision de direction consignée par écrit. BaFin a publié des orientations sur les risques TIC liés aux systèmes IA en décembre 2025 et demande une stratégie IA aux responsabilités identifiables, issue des stratégies métier et informatique déjà exigées par MaRisk. Ce document évite de devoir reconstituer ensuite qui a approuvé un usage.

La stratégie fixe trois éléments déterminant le reste de l'organisation: les usages permis et exclus, la classe de risque d'un usage et le comité décidant des cas limites. Sans limite définie, chaque cas finit par être décidé dans le projet qui l'a proposé.

Le règlement IA répartit les obligations selon le rôle exercé. Le fournisseur d'un système à haut risque applique un système de gestion de qualité selon l'article 17 du règlement (UE) 2024/1689, couvrant conception, gouvernance des données, tests et suivi après commercialisation. Le déployeur, rôle de la plupart des banques achetant un système, relève de l'article 26: respecter les instructions, confier le contrôle humain à des personnes compétentes et habilitées, conserver les journaux et informer les salariés avant l'usage du système à leur égard.

Une banque ajustant un modèle acheté ou y apposant son nom peut devenir fournisseur du système, assumant alors les obligations plus lourdes. Le rôle est donc évalué par système et consigné dans l'inventaire des IA et modèles, plutôt que supposé une seule fois pour toute l'entreprise.

Depuis le 2 février 2025, fournisseurs et déployeurs doivent prendre des mesures assurant une maîtrise suffisante de l'IA aux personnes exploitant les systèmes pour leur compte, selon l'article 4 du règlement IA. L'obligation concerne toute entreprise utilisant l'IA, quelle que soit la classe de risque, et couvre les prestataires travaillant pour elle comme ses salariés.

Les mesures suffisantes dépendent du rôle de chaque personne concernée. Un chargé de crédit lisant un score doit savoir ce que le modèle ignore; un développeur doit connaître les limites techniques; un dirigeant doit pouvoir contester une proposition. Un module général de formation en ligne, seulement suivi par un taux d'achèvement, résiste rarement aux questions de la supervision.

L'article 14 du règlement IA exige qu'un système à haut risque permette la supervision par des personnes physiques: comprendre ses capacités et limites, rester attentif au risque de confiance excessive, interpréter correctement le résultat, décider de ne pas l'utiliser dans un cas donné et intervenir ou l'arrêter.

Dans une banque, cela devient un rôle nommé avec une procédure documentée. La personne autorisée à arrêter un modèle de scoring en journée figure dans sa fiche, le moyen technique existe et a été testé, et la décision est consignée. Un contrôle réduit à une phrase dans une politique échoue dès qu'un modèle refuse des demandes qu'il devrait approuver.

Deux contrôles commencent avant la mise en service d'un système à haut risque et se poursuivent ensuite. Les tests de biais comparent les résultats entre les groupes protégés par la loi générale sur l'égalité de traitement, et l'article 10 du règlement IA impose d'examiner les biais possibles des données d'entraînement, de validation et de test. La variable indirecte est le piège: sans attribut protégé dans ses variables, un modèle peut en reproduire l'effet via le code postal ou l'intitulé de poste.

La traçabilité répond à l'autre question de l'auditeur: d'où viennent les données d'entraînement, quelles modifications ont-elles subi et la banque peut-elle les utiliser ainsi. Un fournisseur incapable d'identifier les sources empêche le déployeur de répondre, ce qui relève d'une décision d'achat, pas technique. La fiche d'inventaire contient la traçabilité et la date du dernier test de biais.

Un modèle produit une prévision; un agent agit, interroge des données, appelle des outils et lance un processus, parfois sans intervention humaine. La différence de gouvernance concerne l'étendue des effets, donc les banques classent les usages selon l'autonomie permise: assistance, où la personne décide et le système suggère; délégation, où le système prépare une action approuvée par une personne; autonomie, où le système agit sous surveillance humaine.

Chaque niveau comporte des contrôles qui lui sont propres et adaptés. Un agent autonome exige un ensemble borné d'actions autorisées, leur journalisation, une limite infranchissable sans intervention humaine et un moyen d'arrêt testé. Approuver un agent au même niveau qu'un modèle prévisionnel produit des incidents sans responsable identifié.

De nombreux établissements allemands rattachent leurs contrôles au NIST AI Risk Management Framework, NIST AI 100-1, volontaire et organisé en quatre fonctions gouverner, cartographier, mesurer et gérer. Ce cadre NIST n'est pas du droit européen et ne satisfait seul aucune obligation du règlement IA.

Le cadre NIST est une liste de contrôle face au dispositif interne, rédigée indépendamment de tout régulateur et couvrant le cycle de vie plus précisément que le règlement. Le document reliant chaque contrôle à son article du règlement IA et à son exigence MaRisk est celui demandé par l'auditeur. Comme référence allemande, le BSI, qui porte aussi le volet sécurité de AI Safety Institute Germany, publie un catalogue de critères de test pour les systèmes IA financiers.

Le droit allemand de la codétermination atteint l'IA avant le règlement IA. Selon l'article 87(1), numéro 6 du Betriebsverfassungsgesetz, le comité d'entreprise dispose d'un droit de codétermination sur l'introduction et l'usage d'équipements techniques destinés à surveiller le comportement ou la performance des salariés; un système notant les candidatures, classant les ventes ou signalant des communications y est soumis.

Depuis le Betriebsrätemodernisierungsgesetz de 2021, le comité peut aussi consulter un expert pour évaluer l'IA, aux frais de l'employeur. Préparer l'accord avec le comité en parallèle du projet technique détermine la date de mise en service; mener d'abord le projet puis l'accord laisse un système terminé en attente.

Pour les assureurs, cette même question possède son propre texte de supervision. EIOPA a rendu un avis sur la gouvernance et la gestion des risques de l'intelligence artificielle en août 2025, considérant que Solvabilité II et la directive distribution d'assurances couvrent déjà l'IA et demandant une gouvernance proportionnée au risque de chaque usage, avec équité et explicabilité lorsque le système affecte un résultat pour le client.

EIOPA siège à Francfort, donc l'autorité formulant ces attentes et les assureurs qui les appliquent se rencontrent souvent dans la même ville. La page sur l'IA en assurance couvre les usages derrière ces règles.

La gouvernance de l'IA bancaire est la structure interne attribuant la responsabilité d'un système: stratégie IA approuvée par la direction, responsable nommé et classe de risque par système, contrôle humain habilité à l'arrêter, maîtrise de l'IA pour les opérateurs, inventaire complet et procédure remontant les défaillances à la direction. Les obligations viennent du règlement européen sur l'IA et, pour le risque TIC, des orientations de BaFin selon DORA.

L'organe de direction assume la responsabilité globale, comme pour le risque TIC selon DORA, et ne peut la déléguer. La banque nomme ensuite un responsable du modèle ou système en première ligne, répondant de l'usage et des données, la deuxième ligne validant et l'audit interne examinant les deux. La personne exerçant le contrôle humain prévu à l'article 14 est nommée séparément, car arrêter un système et en être responsable sont des missions distinctes.

Aucune loi n'exige un comité de ce nom; les règles exigent un point de décision pouvant approuver ou refuser un usage selon la stratégie IA et conserver ses décisions. Les banques qui en créent réunissent généralement risques, conformité, sécurité informatique, protection des données et métiers, avec mandat de classer le risque d'un usage, décision dont dépendent tous les contrôles ultérieurs.