IA et secteur financier : naviguer entre DORA, AI Act et MIF 2
Les équipes conformité des établissements financiers font face à une convergence réglementaire inédite. DORA impose la résilience opérationnelle numérique, l'AI Act catégorise et contraint les systèmes d'IA à haut risque, tandis que MIF 2 encadre le conseil et l'exécution automatisés. Comprendre les zones de chevauchement — et les lacunes — est devenu une priorité pour les banques, sociétés de gestion et leurs prestataires.
Trois textes, un même objet : l'IA dans la chaîne financière
Ces trois réglementations ne visent pas explicitement les mêmes risques, mais elles convergent dès lors qu'un système d'IA intervient dans un processus financier réglementé.
- DORA (Digital Operational Resilience Act, applicable depuis janvier 2025) cible la résilience des systèmes TIC, y compris ceux fournis par des tiers critiques.
- L'AI Act (pleinement applicable en août 2026 pour les systèmes à haut risque) classe certains usages financiers — scoring de crédit, détection de fraude, conseil automatisé — en catégorie à haut risque (Annexe III).
- MIF 2 impose transparence, traçabilité des décisions et gouvernance des algorithmes utilisés dans le conseil en investissement et l'exécution d'ordres.
Un moteur de scoring crédit alimenté par du machine learning est donc simultanément un système TIC critique (DORA), un système d'IA à haut risque (AI Act) et potentiellement un outil de conseil automatisé soumis à MIF 2. La cartographie des obligations doit partir de ce triple regard.
DORA et AI Act : des obligations qui se superposent sans se confondre
Résilience opérationnelle vs gouvernance algorithmique
DORA exige des tests de résilience, une gestion des incidents TIC et un encadrement contractuel des prestataires tiers (dont les fournisseurs de modèles d'IA en cloud). L'AI Act, lui, impose une documentation technique du modèle, une surveillance humaine effective et un système de gestion des risques spécifique au cycle de vie de l'IA.
En pratique, un établissement qui déploie un LLM tiers pour automatiser l'analyse de prospectus doit :
- Intégrer ce fournisseur dans son registre DORA des prestataires TIC critiques ;
- S'assurer que le fournisseur respecte les obligations du provider au sens de l'AI Act (documentation, marquage CE pour les systèmes à haut risque) ;
- Maintenir en interne la capacité de supervision humaine requise par l'AI Act, même si le modèle est hébergé en SaaS.
Le point de friction : la gestion des incidents IA
DORA définit des délais stricts de notification des incidents TIC majeurs (4 heures pour la notification initiale à l'autorité compétente). Or, un incident lié à un biais algorithmique ou à une dérive de modèle n'est pas toujours détecté comme un incident TIC au sens classique. Les équipes doivent aligner leurs procédures de détection des anomalies IA avec les seuils et typologies d'incidents DORA, sous peine de déclaration tardive.
MIF 2 : la couche sectorielle qui précise les attentes
Algorithmes de conseil et exigences d'adéquation
MIF 2 exige que tout conseil en investissement — y compris automatisé — repose sur une évaluation d'adéquation documentée. Lorsque cette évaluation est produite par un algorithme, l'ESMA attend que la société de gestion soit en mesure d'expliquer la logique de recommandation à son client et à son régulateur.
L'AI Act renforce cette exigence : les systèmes à haut risque doivent intégrer des capacités d'explicabilité et générer des journaux d'audit automatiques. MIF 2 et AI Act se rejoignent ici sur le principe de traceability, mais avec des formats et des destinataires différents (client retail pour MIF 2, autorité de surveillance pour l'AI Act).
Surveillance des algorithmes de trading
Les algorithmes d'exécution d'ordres sont soumis aux obligations de contrôle pré- et post-déploiement de MIF 2 (article 17). L'AI Act y ajoute une obligation de surveillance continue et de mise à jour du système de gestion des risques IA. Un établissement ne peut pas se contenter de valider son algorithme à la mise en production : il doit monitorer sa performance et documenter les mises à jour, deux exigences qui se recoupent utilement.
Construire une cartographie des obligations croisées
La première erreur des équipes conformité est de traiter ces trois textes en silos. Voici une approche pragmatique en trois étapes :
- Inventorier les systèmes d'IA par usage métier (crédit, trading, conformité AML, conseil client) et les qualifier simultanément sous DORA (criticité TIC), AI Act (niveau de risque) et MIF 2 (nature de l'activité réglementée).
- Identifier les obligations cumulatives : documentation technique (AI Act) + tests de résilience (DORA) + justification d'adéquation (MIF 2) pour un même système.
- Centraliser la gouvernance : désigner un référent IA transverse capable d'interfacer avec le RSSI (DORA), le DPO (RGPD/AI Act) et le responsable conformité MIF. Un registre IA unique, alimentant les trois reportings réglementaires, réduit les doublons et les angles morts.
Le shadow AI : le risque oublié à l'intersection des trois textes
Les analystes financiers qui utilisent ChatGPT pour rédiger des notes de recherche ou des analystes risque qui automatisent des tableaux de bord via des outils IA non homologués créent un angle mort réglementaire majeur. Ces usages échappent aux contrôles DORA (pas dans le registre TIC), violent potentiellement l'AI Act (déploiement sans évaluation des risques) et exposent à des manquements MIF 2 si la note produite influence une recommandation.
La détection et la gouvernance du shadow AI constituent donc un prérequis à toute conformité croisée sérieuse dans le secteur financier.
Ce que les autorités de supervision attendent concrètement
L'ABE (Autorité Bancaire Européenne) et l'ESMA ont toutes deux publié des orientations anticipant l'AI Act. Elles insistent sur trois points communs :
- La responsabilité non déléguable de l'établissement, même en cas de recours à un modèle tiers ;
- La documentation du cycle de vie des modèles (conception, validation, déploiement, retrait) ;
- La formation des équipes à l'identification des biais et à la supervision humaine effective.
Pour les équipes conformité, cela signifie que la simple vérification contractuelle ne suffit plus : il faut démontrer une maîtrise opérationnelle réelle des systèmes d'IA déployés.
FAQ
Un système de scoring crédit est-il concerné par l'AI Act et DORA simultanément ?
Oui. Il entre dans la catégorie à haut risque de l'AI Act (Annexe III) et constitue un système TIC critique au sens de DORA si sa défaillance peut affecter l'activité de l'établissement. Les deux ensembles d'obligations s'appliquent cumulativement.
Qui est responsable de la conformité AI Act dans une banque utilisant un modèle SaaS tiers ?
L'établissement reste le déployeur au sens de l'AI Act et porte la responsabilité de la supervision humaine, de la gestion des risques et de la documentation d'utilisation, même si le fournisseur est le provider technique du modèle.
MIF 2 oblige-t-elle à expliciter les recommandations produites par IA ?
Oui. L'exigence d'adéquation de MIF 2 impose de pouvoir justifier toute recommandation d'investissement, quelle que soit sa source. L'AI Act renforce cette obligation pour les systèmes à haut risque en exigeant des journaux d'audit et des capacités d'explicabilité.
Comment gérer le shadow AI dans le cadre de DORA ?
Le shadow AI échappe par définition aux registres TIC requis par DORA. Sa détection passe par un audit des accès internet, une politique d'usage de l'IA claire et des outils de gouvernance capables d'identifier les usages non homologués avant tout incident déclarable.
Quand les obligations AI Act à haut risque s'appliquent-elles aux établissements financiers ?
Les systèmes d'IA à haut risque existants (déployés avant août 2026) disposent d'un délai de mise en conformité. Les nouveaux systèmes déployés après l'entrée en vigueur des dispositions pertinentes doivent être conformes dès leur mise sur le marché ou en service.