Le règlement sur l’IA pour les services financiers

Les services financiers sont l’un des secteurs les plus lourdement touchés par le règlement sur l’IA, et l’un des moins préparés. Banques, assureurs, entreprises d’investissement, établissements de paiement et fintechs utilisent des systèmes d’IA qui tombent nettement dans la classification à haut risque du règlement : évaluation de la solvabilité, établissement d’une note de crédit, tarification d’assurance, traitement des sinistres, lutte contre le blanchiment et profilage du risque client. Ce ne sont pas des cas limites. Ils figurent explicitement à l’annexe III, point 5, b) du règlement sur l’IA comme systèmes d’IA qui déterminent l’accès à des services privés essentiels et à des prestations.

La charge de mise en conformité est lourde. D’ici le 2 décembre 2027 (reporté du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026), chaque système d’IA à haut risque mis sur le marché de l’Union doit satisfaire un ensemble complet d’exigences : systèmes de gestion des risques, programmes de gouvernance des données, documentation technique, mécanismes de contrôle humain, normes d’exactitude et de robustesse et, pour les déployeurs qui sont des établissements financiers, une analyse d’impact sur les droits fondamentaux. Les établissements financiers font aussi face à une difficulté qu’aucun autre secteur ne partage au même degré : le règlement sur l’IA n’opère pas isolément. Il se superpose à un environnement réglementaire déjà dense, DORA, MiFID II, Solvabilité II, DSP2, la directive sur le crédit aux consommateurs, le RGPD, ce qui crée des exigences de conformité qui se recoupent et parfois se contredisent.

Ce guide détaille chaque obligation du règlement sur l’IA pertinente pour les services financiers, explique l’interaction avec la réglementation financière existante, et fournit une feuille de route de mise en conformité actionnable. Si vous n’avez pas encore classé vos systèmes d’IA, commencez par le guide de classification à haut risque puis revenez ici.

L’essentiel, les points clés du règlement sur l’IA pour les services financiers

• L’IA d’évaluation de la solvabilité et de note de crédit est explicitement à haut risque au titre de l’annexe III, point 5, b), la classification la plus lourde de conséquences pour la banque de détail.
• L’IA de tarification d’assurance pour l’assurance-vie et l’assurance maladie entre dans le champ comme système d’IA d’évaluation des risques et de tarification à l’égard des personnes physiques. Les branches dommages et responsabilité civile font face à une classification moins certaine, mais encore plausible.
• La détection de fraude n’est en général pas à haut risque lorsqu’elle sert uniquement à détecter la fraude financière, mais le devient lorsque sa sortie détermine si un client se voit refuser un service financier.
• L’échéance du 2 décembre 2027 s’applique à tous les nouveaux systèmes d’IA à haut risque. Les systèmes déjà en service relèvent d’une disposition transitoire, mais seulement s’ils ne subissent pas de modification substantielle.
• Les établissements financiers sont à la fois déployeurs et parfois fournisseurs de systèmes d’IA. Chaque rôle porte des obligations distinctes. Voir le guide fournisseur / déployeur.
• Le règlement sur l’IA interagit avec DORA, MiFID II, Solvabilité II et le RGPD, ce qui crée des exigences qui se recoupent mais ne sont pas identiques pour la documentation, les essais, la gouvernance et le contrôle humain.
• Les sanctions peuvent aller jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial pour les manquements aux obligations à haut risque, et 35 millions d’euros ou 7 % pour les pratiques interdites. Voir le guide complet des sanctions.
• L’évaluation de la conformité pour l’IA financière est une auto-évaluation dans la plupart des cas, aucun organisme notifié n’est requis, mais elle doit être rigoureuse, documentée et contrôlable. Voir le guide de l’évaluation de la conformité.
• Utilisez l’évaluation Legalithm au titre du règlement sur l’IA pour classer vos systèmes d’IA financiers et identifier les obligations applicables.

Pourquoi les services financiers portent des obligations lourdes au titre du règlement sur l’IA

Les systèmes d’IA financiers touchent les moyens de subsistance des personnes à un niveau fondamental. Un algorithme de note de crédit qui rejette une demande de prêt immobilier détermine si quelqu’un peut acheter un logement. Un modèle de tarification d’assurance qui majore les primes sur la base de prédictions de santé détermine si quelqu’un peut s’offrir une couverture. Un système de lutte contre le blanchiment qui signale un compte pour enquête peut conduire au gel d’avoirs et à la clôture du compte. Les législateurs européens ont identifié ces incidences comme portant un haut risque pour les droits fondamentaux, en particulier le droit à la non-discrimination, le droit à un recours effectif, le droit à la protection sociale et le droit à la dignité humaine.

L’IA financière comme haut risque de l’annexe III

La classification à haut risque du règlement sur l’IA à l’article 6, paragraphe 2 s’applique aux systèmes d’IA relevant des cas d’usage énumérés à l’annexe III. Pour les services financiers, la disposition critique est l’annexe III, point 5, b) :

systèmes d’IA destinés à être utilisés pour évaluer la solvabilité des personnes physiques ou pour établir leur note de crédit, à l’exception des systèmes d’IA utilisés à des fins de détection de fraudes financières

En outre, l’annexe III, point 5, c) vise les systèmes d’IA destinés à être utilisés pour l’évaluation des risques et la tarification en ce qui concerne les personnes physiques en matière d’assurance-vie et d’assurance maladie, ce qui capture la tarification des produits vie et santé, ainsi que, selon les faits, certains outils de gestion de fortune et de conseil en investissement.

La classification ne dépend pas de la sophistication du modèle. Un modèle de régression logistique qui produit une note de crédit est soumis aux mêmes exigences qu’un réseau de neurones profond. Le déclencheur est la fonction, évaluer la solvabilité ou établir une note de crédit, pas la technologie sous-jacente.

L’échéance de décembre 2027

Le calendrier d’application par étapes du règlement sur l’IA signifie que des obligations différentes prennent effet à des dates différentes. Pour les systèmes d’IA à haut risque dans les services financiers :

Les établissements financiers qui n’ont pas encore commencé la planification de mise en conformité sont déjà en retard. L’évaluation de la conformité, la documentation technique, le système de gestion des risques et le programme de gouvernance des données exigés par le règlement sur l’IA ne s’improvisent pas en quelques semaines, ils demandent des mois de travail systématique. Voir le calendrier complet du règlement sur l’IA pour d’autres jalons.

Systèmes d’IA à haut risque en finance : détail

Tous les systèmes d’IA utilisés par une banque ou un assureur ne sont pas à haut risque. La classification est propre à la fonction. Comprendre la frontière est essentiel pour un cadrage exact et pour éviter à la fois la sous-conformité et la sur-conformité.

Évaluation de la solvabilité et établissement d’une note de crédit

Classification : haut risque (annexe III, point 5, b))

C’est la classification à haut risque la plus nette et la plus lourde de conséquences dans les services financiers. Tout système d’IA dont la destination est d’évaluer la solvabilité de personnes physiques ou d’établir leur note de crédit est à haut risque. Le champ est large :

• Modèles traditionnels de note de crédit utilisés par les bureaux de crédit (par exemple des modèles produisant des notes pour les décisions de crédit à la consommation).
• Modèles internes des banques qui évaluent s’il faut accorder un prêt, un prêt immobilier, un découvert ou une carte de crédit.
• Systèmes alternatifs de note de crédit utilisés par les fintechs, des modèles intégrant des données non traditionnelles telles que les paiements de services, l’historique locatif, l’usage du téléphone mobile, des signaux de réseaux sociaux ou le comportement de dépense.
• Modèles d’évaluation de la capacité de remboursement utilisés pour déterminer si un consommateur peut servir une dette.
• Moteurs de préqualification qui déterminent quels consommateurs voient des offres de prêt, parce que le système d’IA évalue effectivement la solvabilité pour décider s’il faut présenter un produit.
• Algorithmes d’ajustement dynamique des plafonds de crédit qui modifient des lignes de crédit existantes sur la base d’une évaluation continue de la solvabilité.

Exemple concret : un prêteur numérique utilise un modèle d’apprentissage automatique intégrant plus de 500 caractéristiques, y compris le type d’appareil, le comportement de navigation, l’heure de la demande et l’historique de transactions, pour produire une note de risque de crédit. Ce modèle est à haut risque, que le prêteur l’appelle « note de crédit », « évaluation du risque » ou « moteur de décision ». La fonction, évaluer la solvabilité, détermine la classification.

Ce que cela signifie en pratique : chaque banque de détail, société de financement à la consommation, émetteur de cartes, prêteur immobilier et fintech de crédit sur le marché de l’Union doit faire en sorte que son IA d’évaluation de la solvabilité satisfasse à l’ensemble des exigences du chapitre III d’ici décembre 2027. Pour les établissements qui utilisent des modèles de notation fournis par un vendeur, le vendeur (en tant que fournisseur) et l’établissement (en tant que déployeur) portent tous deux des obligations de conformité. Voir le guide fournisseur / déployeur pour la répartition de ces responsabilités.

Tarification d’assurance et évaluation des risques (vie et santé)

Classification : haut risque (annexe III, point 5, c))

Les systèmes d’IA utilisés pour l’évaluation des risques et la tarification en matière d’assurance-vie et d’assurance maladie à l’égard des personnes physiques tombent dans la classification à haut risque. La logique est que ces systèmes déterminent l’accès à un service privé essentiel, la protection de la santé et de la vie, et que leurs sorties peuvent avoir une incidence directe et matérielle sur le bien-être financier des personnes et l’accès aux soins.

Sont notamment capturés :

• Les modèles de souscription pour l’assurance-vie et l’assurance maladie qui utilisent l’IA pour évaluer le risque et fixer les primes.
• Les systèmes de classification des risques qui rangent les candidats dans des tranches de risque affectant le niveau des primes.
• Les modèles de prédiction des sinistres utilisés pendant la souscription pour estimer la probabilité de sinistre futur et éclairer la tarification.
• Les systèmes d’évaluation du risque santé qui évaluent les profils de santé des candidats à partir de données médicales, de données d’objets connectés ou de données de mode de vie.
• Les algorithmes de tarification dynamique qui ajustent les primes d’assurance maladie ou vie sur la base de données comportementales ou de santé continues.

Assurance de dommages, la zone grise : la classification de l’IA d’assurance dommages est moins tranchée. Les modèles de tarification automobile, habitation et commerciale ne sont pas mentionnés explicitement à l’annexe III, point 5, de la même manière directe que la solvabilité et l’assurance vie/santé. Toutefois, lorsqu’un système d’IA détermine si un consommateur peut accéder à une assurance automobile, obligation légale dans la plupart des États membres, un argument solide existe selon lequel il évalue l’accès à un service essentiel. Les orientations du bureau de l’IA et les pratiques d’exécution des États membres clarifieront cette frontière. Les assureurs prudents devraient conduire une évaluation des risques au titre du règlement sur l’IA sur tous les systèmes d’IA de souscription, pas seulement vie et santé.

Exemple concret : un assureur-vie déploie un modèle d’IA qui ingère des questionnaires de santé des candidats, des dossiers médicaux et des données d’objets connectés pour prédire le risque de mortalité et fixer les primes. Ce modèle est à haut risque au titre du règlement sur l’IA. Il doit satisfaire aux exigences de gouvernance des données, y compris l’examen des données d’entraînement pour des biais liés au sexe, à l’origine ethnique, à l’âge, au handicap et au statut socio-économique, et doit prévoir un contrôle humain effectif des décisions de tarification.

Détection de fraude, l’exception qui compte

Classification : en général PAS à haut risque

L’annexe III, point 5, b) contient une exclusion explicite :

à l’exception des systèmes d’IA utilisés à des fins de détection de fraudes financières

Cela signifie que les systèmes d’IA dont la seule destination est la détection de fraude, surveillance des transactions, identification d’activités suspectes, détection d’anomalies dans les flux de paiement, ne sont pas à haut risque au titre de la classification de l’annexe III du règlement sur l’IA. La rationale est que les systèmes de détection de fraude protègent les consommateurs plutôt que de filtrer leur accès aux services.

Mais l’exception est plus étroite qu’il n’y paraît. Nuances critiques :

1. L’exception ne s’applique qu’à la détection de fraude, pas aux conséquences en aval. Si la sortie d’un système de détection de fraude déclenche une suspension automatique de compte, un blocage de transaction ou un refus de service, le système d’IA qui prend cette décision en aval peut lui-même être à haut risque, parce qu’il détermine désormais l’accès à un service financier essentiel.

2. Les systèmes de lutte contre le blanchiment (LCB) et de financement du terrorisme (FT) occupent une position ambiguë. Ces systèmes ne sont pas uniquement de la détection de fraude, ils évaluent des profils de risque client à des fins de conformité réglementaire. Lorsque l’IA LCB/FT aboutit à des clôtures de comptes, à un désengagement du risque ou à un refus de service, la sortie du système affecte l’accès à des services bancaires essentiels. Les établissements financiers devraient évaluer ces systèmes un par un plutôt que de supposer que l’exemption de détection de fraude s’applique universellement.

3. Les systèmes combinés qui font à la fois de la détection de fraude et de l’évaluation du risque de crédit, architecture fréquente chez les fintechs, ne peuvent pas s’appuyer sur l’exemption de détection de fraude pour la composante risque de crédit. Si le système a une double destination, la classification à haut risque s’applique à la fonction d’évaluation de la solvabilité.

Exemple concret : un établissement de paiement utilise un système d’IA pour signaler en temps réel des transactions potentiellement frauduleuses. La seule sortie du système est une probabilité de fraude envoyée à un analyste humain pour revue. Ce système bénéficie de l’exemption de détection de fraude et n’est pas à haut risque. En revanche, si le même établissement déploie un système qui bloque automatiquement des comptes clients sur la base d’une notation algorithmique du risque, et que les clients bloqués ne peuvent plus accéder à leurs fonds, la fonction de blocage de compte sort de l’exemption.

IA de recrutement dans les établissements financiers

Classification : haut risque (annexe III, point 4)

Les établissements financiers qui utilisent l’IA dans l’embauche, le filtrage de CV, le classement des candidats, la notation d’entretiens, le suivi des performances, les recommandations de promotion, font face aux obligations à haut risque au titre de la classification distincte emploi et recrutement. Cela s’applique que l’établissement soit une banque, un assureur ou une fintech. Pour une analyse détaillée des obligations de l’IA de recrutement, voir le guide de conformité RH et recrutement au titre du règlement sur l’IA.

Exigences de conformité pour les systèmes d’IA financiers

Chaque système d’IA à haut risque doit satisfaire aux exigences énoncées au chapitre III, section 2, du règlement sur l’IA. Pour les établissements financiers, ces exigences doivent être comprises dans le contexte des cadres réglementaires existants qui imposent déjà des obligations connexes, mais non identiques.

Système de gestion des risques (article 9)

L’article 9 exige un système de gestion des risques continu et itératif tout au long du cycle de vie du système d’IA. Pour l’IA financière, cela signifie :

• Identification et analyse des risques connus et raisonnablement prévisibles pour la santé, la sécurité et les droits fondamentaux. Pour l’évaluation de la solvabilité, cela inclut le risque de résultats discriminatoires fondés sur des caractéristiques protégées, origine raciale, sexe, âge, handicap, origine ethnique. Pour la tarification d’assurance, cela inclut les risques de discrimination indirecte par variables de substitution.
• Estimation et évaluation des risques découlant de l’usage prévu et de la mauvaise utilisation raisonnablement prévisible. Un modèle de solvabilité conçu pour des décisions de prêt personnel, réaffecté à la souscription immobilière sans revalidation, est un scénario de mauvaise utilisation prévisible.
• Adoption de mesures de gestion des risques, le risque résiduel doit être jugé acceptable, compte tenu de l’état de la technique. Pour l’évaluation de la solvabilité, cela peut exiger de démontrer que le modèle ne produit pas d’écarts statistiquement significatifs entre groupes protégés, ou que tout écart est justifié et proportionné.
• Essais au regard de métriques définies au préalable et de seuils probabilistes adaptés à la destination. Les modèles d’évaluation de la solvabilité doivent être essayés pour l’exactitude prédictive, la stabilité et l’équité entre sous-groupes démographiques.

Les établissements financiers qui opèrent déjà sous les orientations de l’ABE sur les modèles NI, les exigences TRIM de la BCE ou les normes de validation de modèles de Solvabilité II trouveront des recoupements, mais les exigences de gestion des risques du règlement sur l’IA sont plus larges, en particulier autour des droits fondamentaux et des biais. Le règlement sur l’IA exige une évaluation explicite des risques pour la non-discrimination, la vie privée, la dignité et le recours effectif, des dimensions que les cadres existants de gestion du risque de modèle en banque peuvent ne pas traiter de façon systématique.

Gouvernance des données (article 10)

L’article 10 impose des exigences sur les jeux de données d’entraînement, de validation et d’essai. Pour l’IA financière, c’est l’exigence à l’incidence pratique la plus grande :

• Les données d’entraînement doivent être pertinentes, suffisamment représentatives, et aussi exemptes d’erreurs que possible. Pour l’évaluation de la solvabilité, cela signifie que le jeu d’entraînement doit représenter la population à laquelle le modèle sera appliqué, pas seulement la population historiquement acceptée (une source bien connue de biais de sélection dans le crédit).
• L’examen des biais possibles est obligatoire. Les établissements financiers doivent examiner si leurs données d’entraînement reflètent une discrimination historique, par exemple des schémas de prêt qui ont systématiquement défavorisé certains groupes ethniques, les femmes ou les communautés à faibles revenus, et prendre des mesures pour traiter les biais identifiés.
• Les pratiques de gouvernance des données doivent inclure la documentation des sources de données, des méthodes de collecte, des opérations de préparation, des hypothèses et des limites.
• Le traitement de données à caractère personnel doit respecter le RGPD, y compris l’établissement d’une base licite pour le traitement de données sensibles utilisées dans la détection des biais. Voir le guide règlement sur l’IA / RGPD pour l’interaction de ces obligations.

La difficulté pour les établissements financiers est aiguë. L’évaluation de la solvabilité dépend par nature de données historiques, et les données historiques de prêt reflètent des décennies de pratiques discriminatoires. La conformité à l’article 10 exige plus que de documenter les jeux de données, elle exige d’identifier et d’atténuer activement les biais encodés. Voir le guide des essais de biais et d’équité pour des approches concrètes.

Documentation technique (article 11)

L’article 11 et l’annexe IV exigent une documentation technique complète qui couvre :

• Une description générale du système d’IA, de sa destination et du fournisseur.
• Une description détaillée des éléments du système d’IA et de son processus de développement, y compris les spécifications de conception, l’architecture du système, les algorithmes utilisés, les exigences de données et la méthodologie d’entraînement.
• Des informations sur la surveillance, le fonctionnement et le contrôle du système d’IA, y compris les mesures de contrôle humain.
• Une description de l’exactitude, de la robustesse et de la cybersécurité du système, y compris les métriques et les résultats d’essais.
• Une description du système de gestion des risques.
• Une description des changements apportés tout au long du cycle de vie du système.

Pour les établissements financiers habitués à la documentation de modèle sous les attentes de supervision (par exemple le guide de la BCE sur les modèles internes, les attentes de la PRA en matière de risque de modèle), une grande partie de cela paraîtra familière. Les exigences de documentation de l’annexe IV sont toutefois plus granulaires dans des domaines précis, en particulier autour de la gouvernance des données, de l’évaluation des biais et de l’incidence sur les droits fondamentaux, que la documentation de modèle typique.

Contrôle humain (article 14)

L’article 14 exige que les systèmes d’IA à haut risque soient conçus pour être effectivement contrôlés par des personnes physiques. Pour l’IA financière :

• Les personnes chargées du contrôle humain doivent pouvoir comprendre correctement les capacités et les limites du système, y compris ses taux d’exactitude, ses taux d’erreur et ses biais connus.
• Elles doivent pouvoir interpréter correctement la sortie du système, compte tenu des caractéristiques du système et des outils d’interprétation disponibles.
• Elles doivent pouvoir décider de ne pas utiliser le système ou d’ignorer, remplacer ou inverser la sortie.
• Pour l’évaluation de la solvabilité, cela signifie que les chargés de prêt doivent avoir la capacité, y compris pratique, de passer outre les décisions de crédit guidées par l’IA, pas seulement un bouton théorique de passage outre qui n’est jamais utilisé. Les autorités de supervision examineront probablement les taux de passage outre comme preuve d’un contrôle humain effectif.

Tension concrète avec l’automatisation : beaucoup d’établissements financiers ont avancé vers le traitement direct (STP) pour les décisions de crédit courantes, acceptation/refus automatisés sans intervention humaine pour les demandes dans certains paramètres. Au titre du règlement sur l’IA, le traitement direct pour des décisions d’IA à haut risque exige une conception soigneuse. Le système doit être configuré pour que le contrôle humain soit disponible pour les cas que le système identifie comme le nécessitant (par exemple décisions proches du seuil, demandes aux caractéristiques inhabituelles), et l’établissement doit démontrer que le mécanisme de contrôle humain est effectif, pas seulement nominal.

Exactitude, robustesse et cybersécurité (article 15)

L’article 15 exige que les systèmes d’IA à haut risque atteignent des niveaux appropriés de :

• Exactitude : le système doit fonctionner de manière cohérente avec sa destination déclarée. Pour l’évaluation de la solvabilité, les métriques d’exactitude doivent être documentées, y compris la performance entre différents sous-groupes démographiques ; l’exactitude agrégée est insuffisante si le modèle performe significativement moins bien pour des populations spécifiques.
• Robustesse : le système doit être résilient aux erreurs, pannes et incohérences, y compris les tentatives adverses. Les modèles d’évaluation de la solvabilité doivent être essayés contre des entrées adverses (par exemple fraude d’identité de synthèse, manipulation de données pour gonfler les notes).
• Cybersécurité : le système doit être protégé contre l’accès non autorisé, la corruption des données et la manipulation du modèle. Cela recoupe directement les exigences DORA (voir plus bas).

Interaction avec la réglementation financière existante

Le règlement sur l’IA ne remplace pas la réglementation financière existante, il s’y ajoute. Les établissements financiers doivent naviguer l’intersection du règlement sur l’IA avec plusieurs cadres réglementaires existants. Dans plusieurs domaines, la réglementation existante impose déjà des exigences qui traitent partiellement les obligations du règlement sur l’IA ; dans d’autres, le règlement sur l’IA crée des exigences réellement nouvelles.

DORA (règlement sur la résilience opérationnelle numérique)

Le règlement sur la résilience opérationnelle numérique (règlement (UE) 2022/2554), pleinement applicable à compter du 17 janvier 2025, exige des entités financières qu’elles établissent des cadres complets de gestion des risques liés aux TIC, conduisent des essais de résilience opérationnelle, gèrent le risque lié aux tiers TIC, et signalent les incidents liés aux TIC.

Recoupement avec le règlement sur l’IA :

• Le cadre DORA de gestion des risques liés aux TIC (articles 5 à 16) couvre des aspects de la gestion des risques des systèmes d’IA, en particulier autour de la résilience opérationnelle, de la gestion des changements et du traitement des incidents.
• Les exigences DORA de gestion du risque lié aux tiers (articles 28 à 44) s’appliquent aux services d’IA externalisés, aux modèles d’évaluation de la solvabilité hébergés dans le nuage, à la détection de fraude fournie par un vendeur, aux composants d’IA de banque en tant que service (BaaS), et traitent partiellement les exigences du règlement sur l’IA pour la gouvernance de la chaîne d’approvisionnement.
• Les essais de résilience opérationnelle DORA (articles 24 à 27) recoupent les exigences d’exactitude, de robustesse et de cybersécurité de l’article 15.

Là où ils divergent : DORA est centré sur la résilience opérationnelle, faire en sorte que les établissements financiers puissent encaisser et se remettre des perturbations TIC. Il ne traite pas les droits fondamentaux, les biais, la discrimination, la transparence vis-à-vis des personnes concernées, ni les exigences spécifiques de gouvernance des données de l’article 10. Un système d’IA peut être pleinement conforme à DORA et encore manquer le règlement sur l’IA.

MiFID II

La directive concernant les marchés d’instruments financiers II (directive 2014/65/UE) encadre les services et activités d’investissement. Lorsque l’IA est utilisée pour le conseil en investissement, la gestion de portefeuille, les évaluations d’adéquation ou la négociation algorithmique :

• Les exigences d’évaluation de l’adéquation de MiFID II (article 25) exigent déjà des entreprises qu’elles fassent en sorte que les recommandations d’investissement soient adaptées au client. Les plateformes de conseil automatisé fondées sur l’IA doivent satisfaire à la fois aux exigences d’adéquation de MiFID II et aux exigences de transparence et de contrôle humain du règlement sur l’IA.
• Les obligations de négociation algorithmique au titre de MiFID II (article 17) exigent des contrôles de risque, des essais et de la documentation pour les algorithmes de négociation. Cela recoupe la gestion des risques et l’exactitude du règlement sur l’IA, mais le règlement sur l’IA exige en plus une évaluation de l’incidence sur les droits fondamentaux et des biais, des concepts que MiFID II ne traite pas.
• Les obligations de meilleure exécution de MiFID II exigent des entreprises qu’elles prennent des mesures suffisantes pour obtenir le meilleur résultat possible pour les clients. Lorsque l’IA est utilisée pour déterminer les lieux ou les stratégies d’exécution, les exigences de transparence du règlement sur l’IA peuvent imposer des obligations d’information supplémentaires.

Solvabilité II

La directive Solvabilité II (directive 2009/138/CE) encadre les entreprises d’assurance et de réassurance. Sa pertinence pour la conformité de l’IA :

• Les exigences d’évaluation interne des risques et de la solvabilité (ORSA) de Solvabilité II demandent déjà aux assureurs de comprendre et de documenter les risques découlant de leurs modèles internes, y compris les modèles de tarification.
• Les exigences de fonction actuarielle (article 48) imposent des obligations de gouvernance et de validation sur les modèles de tarification et de provisionnement qui recoupent partiellement la documentation technique et la gestion des risques du règlement sur l’IA.
• Les exigences de système de gouvernance de Solvabilité II (articles 41 à 49), y compris les exigences d’honorabilité et de compétence, la gestion des risques et les contrôles internes, fournissent une base pour la gouvernance de l’IA, mais ne traitent pas les essais de biais, l’analyse d’impact sur les droits fondamentaux, ni les exigences spécifiques de contrôle humain de l’article 14.

RGPD

Le règlement général sur la protection des données recoupe le plus significativement le règlement sur l’IA pour les services financiers. Voir la comparaison détaillée règlement sur l’IA / RGPD. Intersections clés :

• Décision individuelle automatisée (article 22 du RGPD) : l’évaluation de la solvabilité est l’exemple canonique de décision automatisée produisant des effets juridiques ou affectant de manière similaire de façon significative. L’article 22 du RGPD exige déjà des informations utiles concernant la logique sous-jacente, le droit à une intervention humaine et le droit de contester. Le contrôle humain et la transparence du règlement sur l’IA étendent ces obligations.
• Analyse d’impact relative à la protection des données (AIPD) : une AIPD au titre de l’article 35 du RGPD est vraisemblablement requise pour la plupart des systèmes d’IA financiers à haut risque. L’analyse d’impact sur les droits fondamentaux (FRIA) du règlement sur l’IA est une obligation distincte pour certains déployeurs, y compris les établissements financiers, mais peut être coordonnée avec l’AIPD.
• Base licite pour les essais de biais : examiner les données d’entraînement pour des biais exige de traiter des données sur des caractéristiques protégées (origine raciale, origine ethnique, état de santé, sexe). Au titre du RGPD, cela exige une base licite, typiquement l’article 9, paragraphe 2, g) (intérêt public important) mis en œuvre par le droit de l’État membre. C’est une tension non résolue que le Comité européen de la protection des données et le bureau de l’IA sont attendus pour traiter dans des orientations.
• Droit à l’explication : le RGPD fournit un droit à des informations utiles sur les décisions automatisées. Le règlement sur l’IA exige que les déployeurs informent les personnes concernées qu’elles font l’objet d’un système d’IA à haut risque (article 26, paragraphe 11). Ces obligations sont complémentaires mais ont des champs et des déclencheurs différents.

Obligations comparées entre cadres

Évaluation de la conformité pour l’IA financière

Les systèmes d’IA à haut risque dans les services financiers sont soumis à une évaluation de la conformité au titre de l’article 43. Pour l’IA financière qui n’est pas un composant de sécurité d’un produit couvert par la législation de l’annexe I, l’évaluation de la conformité est fondée sur le contrôle interne, ce qui signifie que le fournisseur (typiquement le vendeur ou, pour les systèmes développés en interne, l’établissement financier lui-même) conduit l’évaluation sans faire intervenir un organisme notifié.

C’est à la fois un avantage et une responsabilité :

• Aucun auditeur externe n’est requis. Les établissements financiers qui développent des systèmes d’IA en interne ou les achètent à des vendeurs peuvent conduire les évaluations de la conformité en interne, selon la procédure énoncée à l’annexe VI.
• L’évaluation doit être rigoureuse et documentée. L’auto-évaluation ne signifie pas une conformité légère. Le fournisseur doit vérifier la conformité à chaque exigence applicable, gestion des risques, gouvernance des données, documentation technique, contrôle humain, exactitude, robustesse, et établir une déclaration UE de conformité au titre de l’article 47.
• La documentation doit résister au regard réglementaire. Les autorités nationales de surveillance du marché peuvent demander la documentation technique complète et auditer l’évaluation de la conformité. Les établissements financiers soumis à une supervision prudentielle (par la BCE, les autorités nationales compétentes ou les autorités nationales de supervision) peuvent aussi faire l’objet de questions sur la conformité au règlement sur l’IA par les canaux de supervision.
• Le marquage CE est requis pour les systèmes d’IA à haut risque mis sur le marché après l’échéance de conformité. Le marquage CE signifie que le système est conforme aux exigences du règlement sur l’IA.

Pour un parcours complet du processus d’évaluation de la conformité, voir le guide de l’évaluation de la conformité.

Cas particulier, IA financière utilisant l’identification biométrique : si un établissement financier utilise l’identification biométrique à distance en temps réel (par exemple la reconnaissance faciale pour l’entrée en relation client), l’évaluation de la conformité exige l’intervention d’un organisme notifié au titre de l’annexe VII. C’est le seul scénario dans les services financiers où l’évaluation de la conformité par un tiers est imposée.

Sanctions et exécution

Le règlement sur l’IA établit un régime de sanctions par paliers qui s’applique aux établissements financiers en tant que fournisseurs et déployeurs de systèmes d’IA :

Pour les grands établissements financiers, le calcul fondé sur le chiffre d’affaires produit des montants dramatiquement plus élevés. Une banque mondiale avec 50 milliards d’euros de revenus fait face à une sanction théorique maximale de 3,5 milliards d’euros (7 % pour les pratiques interdites) ou 1,5 milliard d’euros (3 % pour la non-conformité à haut risque).

Architecture d’exécution : le règlement sur l’IA est exécuté au niveau national par les autorités de surveillance du marché désignées par chaque État membre. Pour les services financiers, les États membres peuvent désigner les autorités de supervision financière existantes (banques centrales, autorités de conduite financière) comme autorité compétente pour l’exécution du règlement sur l’IA dans le secteur financier. Cela signifie que le même organe de supervision qui conduit les inspections prudentielles peut aussi exécuter la conformité au règlement sur l’IA, en intégrant la gouvernance de l’IA dans le cadre plus large de supervision.

Interaction avec les sanctions de la réglementation financière : les sanctions du règlement sur l’IA s’ajoutent aux sanctions disponibles au titre d’autres cadres réglementaires. Un modèle d’évaluation de la solvabilité qui viole à la fois le règlement sur l’IA (en omettant les essais de biais) et le RGPD (en n’ayant pas de base licite pour le traitement de données sensibles) peut attirer des sanctions au titre des deux règlements. Il n’y a pas de protection contre le cumul entre ces cadres.

Pour le régime complet des sanctions, voir le guide des sanctions et amendes.

Feuille de route de mise en œuvre pour les établissements financiers

La conformité ne s’obtient pas en un seul cycle. Le calendrier suivant reflète des horizons de planification réalistes pour des établissements financiers de tailles diverses.

Questions fréquentes

L’évaluation de la solvabilité est-elle toujours à haut risque au titre du règlement sur l’IA ?

Oui, avec une réserve. Tout système d’IA destiné à évaluer la solvabilité de personnes physiques ou à établir leur note de crédit est à haut risque au titre de l’annexe III, point 5, b). Cela s’applique indépendamment de la complexité du modèle, des données d’entrée, ou du fait que le système prenne la décision de crédit finale ou se borne à une recommandation. La seule exception est l’IA utilisée uniquement à des fins de détection de fraudes financières. Si un modèle d’évaluation de la solvabilité a une composante de détection de fraude, la fonction de solvabilité reste à haut risque ; l’exemption de détection de fraude ne peut pas servir à protéger l’ensemble du système.

Le règlement sur l’IA s’applique-t-il aux systèmes d’IA que nous achetons à des vendeurs ?

Oui. Les établissements financiers qui utilisent des systèmes d’IA fournis par des vendeurs (plateformes d’évaluation de la solvabilité, solutions LCB, outils de tarification d’assurance) sont déployeurs au titre du règlement sur l’IA et portent leurs propres obligations de conformité, y compris le contrôle humain, l’information des personnes concernées, la conduite de la FRIA (le cas échéant), et le fait que le système soit utilisé conformément à sa notice d’utilisation. La conformité du vendeur en tant que fournisseur ne décharge pas les devoirs indépendants du déployeur. Voir le guide des obligations fournisseur / déployeur.

Comment le règlement sur l’IA interagit-il avec les attentes existantes de l’ABE et de la BCE en matière de gestion du risque de modèle ?

Les exigences du règlement sur l’IA recoupent partiellement les attentes de supervision existantes pour la gestion du risque de modèle (MRM), la validation de modèles et les modèles internes. La gestion des risques (article 9), la documentation technique (article 11), les essais d’exactitude (article 15) et le contrôle humain (article 14) ont tous des correspondants dans la supervision prudentielle. Le règlement sur l’IA introduit toutefois des exigences qui vont au-delà du MRM traditionnel, concrètement les essais de biais obligatoires au titre de l’article 10, l’analyse d’impact sur les droits fondamentaux, la transparence vis-à-vis des personnes concernées, et le processus formel d’évaluation de la conformité. Les établissements financiers devraient étendre leurs cadres MRM existants plutôt que de construire des structures parallèles.

Les systèmes d’IA de lutte contre le blanchiment (LCB) sont-ils à haut risque ?

La réponse dépend de la fonction et de l’incidence. Les systèmes d’IA utilisés uniquement pour la détection de fraude bénéficient de l’exemption explicite de l’annexe III, point 5, b). Les systèmes LCB dépassent toutefois souvent la détection, ils produisent des notes de risque client, déclenchent un devoir de vigilance renforcé, conduisent à des restrictions de compte, et éclairent des décisions de retirer un client. Lorsque la sortie d’un système LCB influe matériellement sur une décision de refuser, restreindre ou mettre fin à l’accès d’un client aux services bancaires, le système peut relever du haut risque au titre de l’annexe III, point 5, comme système d’IA qui influe sur l’accès à des services privés essentiels. Les établissements financiers devraient conduire une analyse fonction par fonction plutôt que de supposer une exemption générale.

Que se passe-t-il si notre système d’IA est déjà en production avant décembre 2027 ?

Le règlement sur l’IA contient une disposition transitoire pour les systèmes d’IA déjà mis sur le marché ou mis en service avant le début d’application des obligations à haut risque. Le Digital Omnibus (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) a reporté ce début d’application du 2 août 2026 au 2 décembre 2027. Ces systèmes n’ont pas à être conformes immédiatement, pourvu qu’ils ne subissent pas de modification substantielle de leur destination, de leur fonctionnalité ou de leur conception. Si le système reste inchangé, la conformité est requise d’ici le 2 décembre 2027. Toute modification substantielle, toutefois, un réentraînement majeur du modèle, un changement de population cible, l’incorporation de nouvelles sources de données, remet l’horloge à zéro et déclenche des exigences de conformité immédiates. Les établissements financiers devraient évaluer l’historique des modifications et le plan de développement de chaque système pour déterminer quelle échéance s’applique.

Avons-nous besoin d’une analyse d’impact sur les droits fondamentaux ?

Au titre de l’article 27, les déployeurs de systèmes d’IA à haut risque visés à l’article 6, paragraphe 2, qui sont des organismes de droit public, des entités privées fournissant des services publics, ainsi que les déployeurs de systèmes d’IA à haut risque visés à l’annexe III, points 5, b) et c), doivent effectuer une analyse d’impact sur les droits fondamentaux avant le déploiement. Les établissements de crédit et les assureurs qui déploient de l’IA à haut risque dans le crédit et la tarification d’assurance vie/santé tombent dans ce champ. La FRIA est un document distinct de l’AIPD RGPD, les deux peuvent toutefois être conduites en parallèle et partager l’analyse factuelle. Voir le guide FRIA pour la méthodologie complète.

Prochaines étapes

Les établissements financiers ont une fenêtre étroite mais praticable pour atteindre la conformité au règlement sur l’IA avant l’échéance de décembre 2027. L’essentiel est de commencer maintenant, d’utiliser les cadres réglementaires existants là où ils se recoupent, et d’identifier tôt les obligations réellement nouvelles que le règlement sur l’IA introduit.

Commencez par la classification. Utilisez l’outil d’évaluation Legalithm au titre du règlement sur l’IA pour classer vos systèmes d’IA, identifier lesquels sont à haut risque, et générer un rapport d’obligations adapté. Travaillez ensuite la liste de contrôle 2026 du règlement sur l’IA pour fermer les écarts de façon systématique.

Pour une vue plus large du paysage réglementaire et de sa comparaison entre juridictions, voir la comparaison mondiale de la régulation de l’IA.