L'IA dans la conformité financière : ce qui fonctionne, ce qui échoue et ce que le régulateur demande déjà

L'industrie financière automatise des processus depuis des décennies. Mais il existe une différence fondamentale entre automatiser un processus qui produit le même résultat à chaque fois et utiliser un système qui raisonne, infère et peut se tromper de manière convaincante. Cette différence, c'est l'IA générative. Et son adoption en conformité, en vérification de contrats et en filtrage des sanctions s'accélère bien plus vite que le cadre réglementaire censé la gouverner.

Où en est l'IA dans la conformité aujourd'hui

Les cas d'usage actuels sont clairs et, dans bien des cas, ils fonctionnent bien.

Dans le filtrage des sanctions et l'AML, les grands éditeurs ont intégré des modèles de classification pour réduire les faux positifs dans la mise en correspondance des noms. Les résultats sont réels : le taux d'alertes exploitables a augmenté et le bruit a diminué dans la plupart des déploiements. En revue de contrats, pour des instruments standard tels que les ISDA Master Agreements ou les contrats d'énergie EFET, les modèles de langage sont capables d'identifier les clauses non standard, de détecter les asymétries dans les événements de résiliation anticipée et de signaler les lacunes de juridiction en quelques minutes. Ce qui prenait deux heures à un analyste junior prend aujourd'hui deux minutes. En analyse du risque de contrepartie, le RAG sur les déclarations réglementaires, les rapports de crédit et les bases de données d'exposition sectorielle permet de synthétiser des signaux qu'un analyste humain mettrait des jours à agréger.

Jusqu'ici, tout va bien. Le problème n'est pas que l'IA n'apporte aucune valeur. C'est qu'en apportant de la valeur, elle sème une confiance qui n'est parfois pas justifiée.

Où se situent les risques réels

Le risque le plus immédiat n'est pas l'hallucination flagrante. C'est l'hallucination plausible.

Un modèle peut vous dire qu'une contrepartie ne figure pas sur les listes OFAC en vigueur et se tromper, non parce qu'il invente de toutes pièces, mais parce que sa base de connaissances a une date de coupure, ou parce que l'identifiant que vous avez utilisé ne correspond pas exactement à celui figurant sur la liste. L'analyste qui reçoit cette réponse, dans un flux de travail sous forte pression, la remet rarement en question. La confiance dans le système est le risque.

Le deuxième risque est l'opacité de la décision. La plupart des déploiements d'IA observés en conformité produisent un résultat : risque élevé / moyen / faible, avec un paragraphe de justification. Mais si le régulateur demande dans trois ans pourquoi une transaction avec cette contrepartie a été approuvée, que lui montrez-vous ? Le PDF du rapport ? L'e-mail où l'analyste a dit « le système a dit oui » ? Le MAS à Singapour, l'ESMA en Europe et la future autorité AMLA commencent à poser exactement cette question. Et « nous avons utilisé un outil d'IA » n'est pas une réponse qui satisfait un superviseur.

Le troisième risque est structurel : la séparation des fonctions. Dans de nombreux déploiements actuels, le même système qui analyse le risque génère aussi la recommandation que l'analyste signe. Cela viole le principe fondamental du maker/checker qui existe en conformité bien avant l'IA. L'analyste devient un validateur de ce que dit la machine, et non un évaluateur indépendant. La responsabilité reste en suspens entre l'humain et l'algorithme, et lorsqu'il y a un incident réglementaire, aucun des deux ne l'assume pleinement.

Le quatrième risque est la dérive. Les modèles qui sont réentraînés, qui changent de version, ou dont les fournisseurs ajustent les paramètres de sécurité peuvent produire des résultats radicalement différents pour la même entrée sans que personne dans l'institution ne le détecte jusqu'à ce qu'il y ait un vrai problème.

Le cinquième, celui dont on parle le moins : la dépendance au fournisseur. Si votre processus de conformité dépend d'un modèle dont vous ne contrôlez pas la logique interne, vous avez un risque de continuité opérationnelle qu'aucun BCP traditionnel ne prévoit.

Ce qu'il faut construire

La bonne nouvelle, c'est que ces risques sont gouvernables. La mauvaise, c'est qu'ils exigent un travail d'architecture, et pas seulement de prompting.

La première chose est la piste d'audit de l'inférence. Non pas le journal indiquant que « l'IA a été utilisée », mais l'enregistrement infalsifiable et à ajout seul du prompt exact qui a été exécuté, avec quel modèle, dans quelle version, avec quels paramètres et quel a été le résultat littéral. Scellé par un hash cryptographique et un horodatage RFC 3161. C'est ce que vous pouvez montrer à un superviseur trois ans plus tard. L'IMDA Model AI Governance Framework for Agentic AI de Singapour l'exige déjà explicitement. L'EU AI Act l'implique pour les systèmes à haut risque dans les services financiers. Ce n'est qu'une question de temps avant qu'il ne devienne une norme réglementaire mondiale.

La deuxième est la vérification adversariale. Un seul modèle ne devrait pas être l'arbitre d'une décision de conformité. La pratique qui se consolide dans les déploiements les plus matures est le consensus multi-modèles : vous exécutez la même analyse sur trois modèles différents, de fournisseurs différents, et vous ne faites confiance au résultat que lorsqu'ils convergent. Lorsqu'ils divergent, le cas passe en revue humaine. Cela n'élimine pas l'erreur, mais la rend détectable avant qu'elle ne devienne un incident.

La troisième est de séparer l'analyse de la validation. Le maker est le système, ou l'analyste assisté par le système. Le checker est un humain différent qui examine avec accès à la piste complète, et non seulement au résultat. C'est ce qui transforme l'IA d'un substitut au jugement humain en un amplificateur du jugement humain. La différence n'est pas sémantique. Elle a des implications directes sur la manière dont le régulateur attribue la responsabilité lorsque quelque chose échoue.

La quatrième est la granularité du contrôle juridictionnel. Les exigences du MAS Notice 626, d'EMIR, de REMIT et d'AMLA ne sont pas identiques. La capacité de fixer, par juridiction, quels modèles sont autorisés, quelles sources sont utilisées et quel niveau de confiance minimal requiert la validation humaine est ce qui rend un déploiement évolutif sans transformer chaque marché en un fork de code indépendant.

Le principe qui ne devrait pas être négociable

Il existe une formulation qui résume la posture correcte face à l'IA en conformité : l'objectif n'est pas d'éliminer l'erreur. C'est de rendre l'erreur détectable et auditable.

L'IA ne sera pas infaillible. Aucun système humain ne l'est non plus. La question pertinente n'est pas de savoir si l'IA peut se tromper. À l'évidence, elle le peut. La question est : lorsqu'elle se trompe, quelqu'un peut-il le détecter, comprendre pourquoi cela s'est produit et le corriger sans que le régulateur ne l'apprenne dans la pire circonstance possible ?

Si la réponse est oui, vous disposez d'un système de conformité appuyé sur l'IA qui est véritablement plus robuste que le processus manuel qu'il remplace. Si la réponse est non, vous disposez d'un nouveau risque déguisé en efficacité opérationnelle.

Le travail qui reste à accomplir dans l'industrie est majoritairement celui-là : passer de « nous avons de l'IA en conformité » à « nous avons de l'IA en conformité dont nous pouvons démontrer, au régulateur et à nous-mêmes, qu'elle fonctionne comme nous avons dit qu'elle fonctionnait ». La différence entre ces deux affirmations est la différence entre une adoption responsable et une exposition réglementaire latente.

C'est ce que le régulateur commence à demander. Et l'industrie a tout intérêt à avoir les réponses prêtes avant que la question n'arrive sous la forme d'une amende.