L'Adoption Responsable de l'Intelligence Artificielle dans le Secteur Financier : Cadre d'Analyse, Risques et Pratiques de Gouvernance

Source : Financial Stability Board. (2026). Sound practices for responsible adoption of artificial intelligence.

Sommaire : Le rapport du FSB analyse l'accélération de l'intégration de l'IA (ML, LLM, IA agentique) dans la finance. Si elle optimise les opérations (crédit, assurance, cyberdéfense), elle introduit des risques majeurs : biais, opacité, dérive, cyberattaques et concentration des tiers. L'IA agentique accroît ces périls par son autonomie.
Pour y répondre, le cadre préconise six pratiques : supervision stratégique, modèle à trois lignes de défense, documentation stricte, maintien des compétences, évaluation de la matérialité et sélection rigoureuse des modèles tout au long d'un cycle de vie en sept phases.

1. Synthèse de l'adoption et des cas d'usage de l'IA dans le système financier

L'adoption de l'intelligence artificielle (IA) au sein du système financier mondial connaît une accélération marquée. Historiquement centrées sur des outils décisionnels et des modèles d'apprentissage automatique traditionnels (Machine Learning - ML) basés sur des arbres de décision ou des réseaux de neurones, les institutions financières intègrent désormais des architectures technologiques avancées. La transition s'effectue vers des modèles de langage de grande taille (Large Language Models - LLMs), l'IA générative (GenAI) capable de produire du contenu multimodal (texte, image, code, audio), et plus récemment l'IA agentique (agentic AI). Les systèmes agentiques se distinguent par leur capacité à planifier, raisonner et exécuter de manière autonome des objectifs complexes comportant de multiples étapes au sein de processus de bout en bout.

Cette transformation est tirée par l'augmentation des capacités de calcul (notamment via les infrastructures Cloud), la disponibilité massive de données et l'accessibilité accrue des modèles de fondation, couplées à une volonté d'optimisation opérationnelle, de réduction des coûts et d'amélioration de la gestion des risques.

Le tableau ci-dessous synthétise les cas d'usage majeurs observés par le Conseil de Stabilité Financière (Financial Stability Board - FSB) à travers les différents sous-secteurs financiers, ainsi que leurs bénéfices et métriques opérationnelles mesurés :

2. Typologie des risques et défis d'implémentation pour les institutions financières

L'intégration de l'IA au sein des fonctions critiques expose les institutions financières à des vulnérabilités structurelles et opérationnelles spécifiques.

2.1 Défis de gouvernance, de données et d'explicabilité

• Shadow AI : L'adoption, le développement ou le déploiement d'outils d'IA par des employés à l'insu de l'institution, sans autorisation formelle ni évaluation préalable des risques, prive l'organisation de toute visibilité et de capacité de contrôle sur ses vulnérabilités opérationnelles, légales et réglementaires.
• Biais auto-renforçants : Les modèles d'IA peuvent perpétuer ou amplifier des biais et des inexactitudes contenus dans les données d'entraînement. Ces dérives deviennent auto-renforçantes lorsque les décisions biaisées génèrent de nouvelles données réinjectées dans le système, ancrant l'iniquité ou la distorsion d'évaluation sur le long terme.
• Surajustement (overfitting) et sous-ajustement (underfitting) : Le surajustement survient lorsqu'un modèle offre d'excellentes performances sur les données d'entraînement mais échoue à généraliser sur des données réelles ou inédites. Le sous-ajustement survient lorsque le modèle ne parvient pas à capter la complexité des données. Les deux phénomènes entraînent une dégradation de la performance décisionnelle et augmentent le risque de non-conformité réglementaire.
• Opacité et défis d'explicabilité : L'utilisation d'architectures complexes (réseaux profonds, LLMs) rend difficile, voire impossible, la compréhension précise des étapes menant à un résultat. Cela nuit à la vérification de la solidité conceptuelle, à la distinction entre causalité et corrélation, au contrôle de conformité, ainsi qu'à la capacité d'explication auprès des clients ou des autorités de tutelle.
• Dégradation des performances (hallucinations, data/model drift, requêtes complexes) : La dérive des données (data drift) ou des modèles (model drift) survient lorsque les conditions de marché ou le comportement des utilisateurs s'écartent des données historiques d'apprentissage. Concernant la GenAI, l'apparition d'« hallucinations » (génération de réponses factuellement inexactes mais d'apparence plausible) pose des risques majeurs. En outre, la GenAI présente une vulnérabilité critique lors du traitement de requêtes particulièrement longues ou complexes (lengthy or complex inputs) : elle tend à omettre ou sous-pondérer des informations cruciales au sein de l'intrant, produisant des réponses en apparence fluides et complètes, mais fondamentalement tronquées.

2.2 Menaces cybernétiques et dépendances envers les tiers

1. Attaques directes et émergentes :

• Empoisonnement de données (data poisoning) : Injection de données altérées ou biaisées dans le jeu d'entraînement pour manipuler le comportement futur du modèle.
• Injections de prompts (prompt injections) : Manipulation des instructions d'entrée pour amener le modèle à ignorer ses règles de sécurité ou à divulguer des données confidentielles.
• Contournement des protections (jailbreaking) : Utilisation de techniques d'invite spécifiques pour neutraliser les garde-fous éthiques, légaux ou réglementaires intégrés aux modèles génératifs.
• Évasion (evasion) : Modifications subtiles et quasiment indétectables des données d'entrée visant à tromper un modèle en production (ex. falsification d'images pour contourner un contrôle KYC).
• Extraction de modèle (extraction) : Ingestion massive de requêtes par un tiers malveillant pour rétro-concevoir l'architecture, les paramètres ou reconstituer les données d'entraînement d'un modèle propriétaire.
• Cyberattaques avancées facilitées par des agents IA : Exploitation de la GenAI pour la création de campagnes de phishing hautement crédibles, de deepfakes audios/vidéos, ou l'utilisation d'agents de codage malveillants automatisés. Ces derniers disposent de capacités avancées incluant l'analyse de code source (source code analysis), le test d'applications web, l'analyse binaire (binary analysis), le protocol fuzzing et la rétro-ingénierie des correctifs de sécurité (patch reverse engineering). Ils permettent aux attaquants d'identifier, enchaîner et exploiter des vulnérabilités critiques (notamment zero-day) à une vitesse inédite, réduisant drastiquement la fenêtre de réaction des équipes de défense cyber.

2. Dépendances d'infrastructures :

• Concentration des fournisseurs et risque d'IA embarquée (embedded AI) : La dépendance envers un nombre restreint de prestataires tiers pour les infrastructures Cloud, le matériel spécialisé (GPU) ou les modèles de fondation crée un risque d'interruption systémique. Ce risque est accentué par le phénomène d'IA embarquée (embedded AI), où des fournisseurs tiers intègrent des fonctionnalités d'IA dans des logiciels ou services d'entreprise sans les commercialiser explicitement sous cette étiquette. L'institution financière peut ainsi ignorer l'exposition de ses processus à des algorithmes sous-jacents.
• Modifications unilatérales des modèles : Les fournisseurs Cloud/SaaS peuvent procéder à des mises à jour ou des modifications silencieuses des modèles de fondation sans préavis suffisant, altérant imprévisiblement la performance, le comportement ou le niveau de risque résiduel des systèmes de la banque.
• Comportements homogènes et risque de troupeau (herding) : L'utilisation convergente des mêmes modèles de fondation ou jeux de données par de nombreuses institutions financières simultanément peut entraîner des comportements de marché identiques, exacerbant la procyclicité, la volatilité des actifs et les crises de liquidité en période de stress de marché.
• Ambiguïtés contractuelles : Incertitudes quant aux responsabilités juridiques et contractuelles entre l'institution financière et le fournisseur tiers en cas de violation de données, d'erreur algorithmique ou de non-conformité. L'institution financière conserve la responsabilité légale ultime devant le régulateur, indépendamment des défaillances de sa chaîne d'approvisionnement technologique.

2.3 Focus technique : Risques spécifiques liés à l'IA Agentique

Analyse de risque technique : Autonomie des agents IA

L'émergence des systèmes d'IA agentique introduit des vulnérabilités critiques liées à leur niveau d'autonomie exécutive :

• Actions non autorisées ou erronées : Dans la recherche d'optimisation d'un objectif attribué, un agent peut contourner des règles de gestion, interpréter de façon déviante ses instructions ou adopter des « raccourcis » non conformes aux politiques internes ou aux limites de délégation de pouvoir. Ces actions peuvent s'exécuter à grande vitesse à travers des centaines d'étapes intermédiaires indétectables en temps réel par un humain.
• Sous-agents et orchestration : Certains agents principaux possèdent la capacité de créer, déléguer et orchestrer dynamiquement des sous-agents spécialisés. Cette dispersion de l'exécution dilue la chaîne de responsabilité, affaiblit les mécanismes de contrôle et démultiplie le risque d'actions imprévues ou d'inconsistances applicatives.
• Altération de la mémoire et empoisonnement du RAG : Les architectures agentiques s'appuient sur des mécanismes de mémoire à long terme ou de génération augmentée par récupération (Retrieval-Augmented Generation - RAG). L'injection de données malveillantes dans cette base de connaissances (agentic memory poisoning) altère de façon permanente le processus d'apprentissage, de planification et d'action de l'agent.
• Disruption des systèmes connectés : Directement interconnectés aux bases de données, API internes et infrastructures de marché, les agents défaillants ou compromis peuvent générer des appels système aberrants, supprimer du code, entrer en collusion involontaire avec d'autres agents ou causer des pannes en chaîne sur les systèmes environnants.

3. Pratiques de gouvernance organisationnelle de l'IA (Pratiques 1 à 4)

Les quatre premières pratiques recommandées par le FSB définissent les exigences d'une gouvernance transversale de l'IA à l'échelle de l'entreprise.

3.1 Orientations stratégiques et appétence au risque (Pratique 1)

Le conseil d'administration et la direction générale doivent fixer la stratégie d'adoption de l'IA en garantissant son alignement strict avec le modèle d'affaires, la stratégie globale et l'appétence au risque de l'institution.

• Supervision stratégique : Les dirigeants évaluent en continu le solde entre les bénéfices attendus (efficacité, nouveaux services, amélioration de la gestion des risques) et les risques induits par l'IA.
• Caps d'appétence au risque et seuils de tolérance : Le conseil d'administration établit des caps d'appétence au risque et des seuils de tolérance clairs et explicites. Ceux-ci incluent des interdictions strictes pour certains cas d'usage (ex. décisions d'octroi de crédit ou d'exécution de transactions 100 % automatisées sans contrôle humain lorsque le risque évalué dépasse la tolérance définies par la banque).
• Allocation de ressources et évaluation continue : La direction s'assure que l'organisation dispose de la maturité technologique, des compétences d'experts et des infrastructures adaptées. Elle reçoit régulièrement des rapports de gestion (Management Information - MI) incluant des métriques de performance, de conformité et de suivi des incidents pour ajuster la stratégie si nécessaire.

3.2 Responsabilité, rôles et modèle opérationnel (Pratique 2)

Les institutions financières doivent appliquer le modèle des trois lignes de défense à l'IA et structurer des comités de gouvernance adaptés :

• Première ligne (Métiers et Opérations) : Conçoit, déploie et exploite les cas d'usage d'IA. Elle est responsable de l'évaluation initiale des risques, de la matérialité et du contrôle operational quotidien. Des cadres exécutifs sont nommés responsables individuels des cas d'usage à fort risque ou haute matérialité.
• Deuxième ligne (Gestion des Risques et Conformité) : Maintient une vision transversale des risques liés à l'IA. Elle valide et conteste de manière indépendante les modèles, vérifie la qualité des données, la conformité réglementaire, l'explicabilité, la gestion des dérives et les risques cyber/TIC.
• Troisième ligne (Audit Interne) : Fournit une assurance indépendante au conseil d'administration sur l'efficacité globale du cadre de gouvernance et de contrôle de l'IA.
• Découplage fonctionnel des contrôles : Lorsqu'un système d'IA est utilisé pour surveiller ou évaluer la performance ou les risques d'un autre modèle d'IA, le système de surveillance doit faire l'objet d'un découplage fonctionnel et technique strict afin de garantir l'indépendance absolue de la supervision par rapport au système contrôlé.

Étude de cas : Intégration de la gouvernance IA par une banque d'importance systémique (G-SIB)

Une banque globale d'importance systémique (G-SIB) active sur les marchés de capitaux a fait le choix d'intégrer la gouvernance de l'IA au sein de ses cadres de risques d'entreprise existants (risques de modèle, technologiques, opérationnels et de conformité) plutôt que de créer une structure isolée.

Pour assurer une visibilité à l'échelle du groupe, la banque a instauré un comité dédié à la gouvernance de l'IA, présidé par un membre de la direction générale. Ce comité définit les exigences de contrôle, surveille les risques émergents et établit un canal direct d'escalade vers le comité de risque du conseil d'administration. Chaque unité d'affaires dispose d'un comité local d'IA et d'un responsable (AI Governance Lead) chargé de la mise en œuvre opérationnelle et de la représentation auprès du comité central. Les contrôles sont calibrés de manière proportionnelle à la matérialité de chaque application (ex. exigences renforcées sur les modèles orientés clients ou s'appuyant sur l'IA agentique).

3.3 Cadre de gestion du risque et exigences de documentation (Pratique 3)

L'institution financière doit intégrer les risques d'IA dans ses politiques d'entreprise et tenir un inventaire centralisé exhaustif des cas d'usage d'IA.

Pour chaque application d'IA, la documentation tenue à jour tout au long du cycle de vie doit obligatoirement inclure :

1. La description détaillée du cas d'usage, des modèles sous-jacents et la justification de l'architecture retenue.
2. Les applications approuvées, les usages prévus et les utilisations formellement interdites.
3. La modalité de développement (développement interne, recours à l'open-source/open-weight, ou acquisition auprès d'un tiers).
4. L'évaluation formelle de la matérialité, du niveau de risque et les mesures de mitigation associées.
5. Les lignes de métier, régions, produits, catégories de clients ou acteurs de marché impactés.
6. Les hypothèses clés de fonctionnement et les limitations identifiées de l'outil.
7. Les sources de données utilisées pour l'entraînement (si interne) et pour l'inférence.
8. L'imputation explicite de la responsabilité (nom du propriétaire du cas d'usage et rôles d'encadrement).
9. L'ensemble des dépendances (autres modèles, systèmes TIC, API, sources de données critiques, fournisseurs Cloud, mécanismes de secours).
10. L'étape actuelle dans le cycle de vie de l'IA et son statut opérationnel.
11. Les résultats des tests de validation, du suivi de performance continu et des audits.
12. Les détails relatifs à la revue indépendante et les informations contractuelles pertinentes issues des fournisseurs tiers.

Exigences complémentaires pour la GenAI et l'IA Agentique :

• Traçabilité GenAI : Obligation d'intégrer la gestion de version des prompts (prompt versioning) pour permettre le retour à des configurations antérieures (rollback), le suivi des paramètres de modèles, ainsi que la journalisation des chaînes de pensée (chain-of-thought logging) pour expliciter la génération des résultats.
• Visibilité et Identifiants Uniques (Unique ID) : Attribution obligatoire d'un identifiant unique individuel à chaque agent IA. Cet identifiant permet de distinguer l'agent des utilisateurs humains et des autres systèmes TIC, et de tracer les personnes ayant configuré, déployé et supervisé l'agent.
• Traçabilité des actions : Enregistrement continu de la chaîne d'action de l'agent (déclencheurs, outils et données accédés, étapes de raisonnement intermédiaires, escalades humaines et vérification du respect des autorisations).
• Certification des agents IA réutilisables : Dans les organisations à forte maturité adoptant des architectures modulaires, la gouvernance procède à une « certification » formelle des agents réutilisables à l'échelle de l'agent lui-même (définissant son périmètre d'action certifié et ses limites d'utilisation) avant son intégration dans des cas d'usage métiers spécifiques.

3.4 Adaptabilité organisationnelle et veille externe (Pratique 4)

L'institution financière doit continuellement ajuster ses capacités et compétences à l'évolution des technologies d'IA.

• Prévention du deskilling et maintien de la compétence humaine : Le déploiement de l'IA ne doit pas entraîner une perte de qualification (deskilling) ni l'atrophie du jugement critique des équipes métiers. Les collaborateurs doivent conserver la capacité d'intervenir, de contester les résultats générés et de reprendre le contrôle manuel en cas de défaillance, de dégradation ou de dysfonctionnement des outils d'IA.
• Programmes de formation ciblés : Mise en place de formations fondamentales à l'échelle globale (sensibilisation aux biais d'automatisation, à la sur-confiance et aux erreurs) et de modules spécialisés par rôle (pour les développeurs, validesurs, auditeurs et membres du conseil d'administration).
• Veille externe et plateformes collaboratives :Participation active aux consortia sectoriels et plateformes de collaboration public-privé pour partager les retours d'expérience sur les risques et vulnérabilités. Le FSB met en avant des initiatives telles que :
  • Project MindForge (convoqué par l'Autorité Monétaire de Singapour - MAS) : Élaboration de guides de gestion des risques liés à la GenAI et de boîtes à outils opérationnelles (AI Risk Management Toolkit).
  • Le Consortium IA Banque d'Angleterre (BoE) / FCA : Groupe de réflexion pour identifier les cas d'usage et encadrer l'adoption sécurisée dans les services financiers.
  • Bac à sable réglementaire GenAI de la HKMA (Hong Kong) : Mise à disposition d'infrastructures de calcul (GPU) et d'orientations de supervision pour tester des modèles en environnement contrôlé.

4. Gestion du cycle de vie de l'IA, évaluation de la matérialité et sélection (Pratiques 5 et 6)

4.1 Les 7 étapes du cycle de vie de l'IA

La gestion prudentielle de l'IA s'articule autour d'un cycle de vie structuré en sept phases successives :

1. Inception : Identification des besoins métiers, clarification des objectifs, faisabilité technique et évaluation initiale de la matérialité et des risques.
2. Design et développement : Définition de l'architecture système, gouvernance des données, sélection du modèle, intégration des principes de security-by-design, entraînement ou affinement (fine-tuning) le cas échéant.
3. Vérification et validation : Réalisation de tests poussés (y compris tests d'attaque/adversariaux) pour confirmer que le modèle répond aux exigences (vérification) et fonctionne correctement en conditions réelles (validation).
4. Déploiement : Mise en production dans l'environnement opérationnel, configuration des accès, de la surveillance et mise en place des protocoles de supervision humaine.
5. Exploitation et surveillance : Exécution continue du modèle, journalisation (logging) des activités, contrôle quotidien des performances, de la sécurité et détection des dérives (data/model drift).
6. Réévaluation : Revues périodiques pour vérifier si le cas d'usage répond toujours à ses objectifs face à l'évolution de son environnement, déclenchant si besoin un ré-entraînement ou une mise à jour.
7. Retraite / Mise hors service : Désactivation sécurisée du modèle ou du système, gestion de la conservation ou purge des données, et clôture définitives des droits d'accès.

4.2 Évaluation systématique de la matérialité et des risques (Pratique 5)

Les notions de matérialité et de risque sont complémentaires mais distinctes :

• Matérialité : Mesure l'importance stratégique, financière ou opérationnelle du cas d'usage pour la viabilité de l'institution, la continuité de ses opérations critiques ou le respect de ses obligations réglementaires et légales.
• Critères d'évaluation de la matérialité :
  • Importance : Impact financier direct, rôle dans la prise de décision stratégique ou soutien à des fonctions critiques.
  • Tolérance aux disruptions : Seuils d'interruption admissibles fixés par l'établissement ou les autorités de tutelle.
  • Nature des données : Sensibilité, volume et degré de confidentialité des données traitées (données personnelles, secrets d'affaires).
  • Substitutabilité : Capacité à remplacer rapidement le modèle ou le fournisseur défaillant par une solution équivalente sans impact majeur.
• Analyse comparative des risques :
  • Risque Inhérent : Niveau de risque brut présent avant l'application de tout contrôle ou mesure de mitigation (lié à la complexité de l'algorithme, son autonomie ou sa criticité).
  • Risque Résiduel : Niveau de risque subsistant une fois l'ensemble des garde-fous, contrôles organisationnels et atténuations techniques mis en œuvre.

Un cas d'usage peut présenter une faible matérialité opérationnelle initiale mais porter un risque inhérent très élevé (ex. un agent IA autonome opérant dans un environnement de test mais disposant d'accès mal configurés aux systèmes centraux).

• Effet multiplicatif des risques d'accès pour l'IA Agentique : Les risques associés aux autorisations accordées à un agent IA ne s'additionnent pas, ils se multiplient (effet multiplicatif). L'attribution combinée d'accès aux bases de données et de capacités d'exécution d'outils externes (tool-calling capabilities) ou d'orchestration dynamique d'API permet à l'agent de combiner des droits isolés pour créer des chemins d'action imprévus. L'extension des droits d'un agent doit donc être évaluée de manière globale en analysant le cumul des accès existants et nouveaux, et non de façon isolée.

4.3 Processus de sélection et arbitrage technique (Pratique 6)

Lors de la phase de sélection d'une solution d'IA, les institutions financières procèdent à un arbitrage stratégique et technique motivé par leurs objectifs métiers, leur capacité opérationnelle et leur profil de risque :

• Développement interne (In-house) : Offre un contrôle maximal sur l'architecture, le processus d'entraînement, la gouvernance des données et l'explicabilité. Exige des compétences techniques très élevées et une infrastructure technologique robuste.
• Acquisition auprès de tiers (Third-party AI providers) : Permet un déploiement rapide et l'accès à des technologies de pointe, mais introduit des risques de transparence (modèles "boîte noire"), de dépendance envers les fournisseurs Cloud et d'incertitudes contractuelles.
• Modèles Open-Source / Open-Weight : Offrent une grande flexibilité de personnalisation et une transparence sur l'architecture du modèle. Néanmoins, ils transfèrent la responsabilité de la sécurité, de la validation, du filtrage des données et de la maintenance continue entièrement sur l'institution financière.

Le choix final de l'architecture (modèles ML traditionnels, LLM, architectures agentiques ou approches hybrides) doit résulter d'une adéquation stricte entre la complexité de la technologie retenue, la capacité de l'institution à en maîtriser les risques, et le niveau de risque résiduel toléré par l'organisation.