Blog · Régulation

    DORA couvre déjà vos systèmes d'IA

    Si une IA aide à accorder un crédit, à détecter une fraude, à filtrer des transactions ou à répondre à des clients, ce n'est plus seulement un sujet de gouvernance des modèles. Au regard de DORA, elle peut aussi être un actif TIC (un composant technologique inscrit à votre registre DORA), une dépendance fournisseur et une source d'incident.

    Un champ de dix-neuf points dispersés représentant les fournisseurs tiers TIC critiques, trois d'entre eux agrandis, avec un point brand au centroïde relié par trois lignes pointillées.
    par Mankinds14 mai 20268 min de lecture
    • DORA
    • AI Act
    • Finance
    • Tiers critiques

    Partez des outils que vos équipes utilisent déjà : un modèle anti-fraude, un assistant AML, un moteur de scoring crédit, un chatbot client, un outil d'analyse documentaire pour l'entrée en relation. Si l'un d'eux exécute une fonction critique ou importante, il relève de DORA. Pas parce que DORA est un règlement sur l'IA, mais parce qu'il porte sur les technologies qui font tourner les services financiers. Une IA en fait partie dès qu'elle pèse sur des décisions, dépend d'un fournisseur cloud, appelle un modèle externe ou peut tomber en panne avec un impact côté clients.

    Cartographier les IA déjà en service

    • Détection de fraude : le modèle peut bloquer à tort des paiements légitimes ou laisser passer des paiements suspects.
    • AML et filtrage des sanctions : l'assistant peut manquer des alertes, générer trop de faux positifs ou ralentir le traitement des dossiers.
    • Scoring crédit et octroi : le modèle peut déterminer qui obtient un crédit, à quel prix et dans quelle limite.
    • Chatbot client : l'outil peut donner une mauvaise réponse, exposer des données ou tomber en panne pendant un pic de sollicitations.
    • Recherche interne et analyse documentaire : le système peut remonter le mauvais document ou dépendre d'un fournisseur qui n'apparaît pas dans le registre.

    Ce ne sont pas des risques IA abstraits. Ce sont des risques d'exploitation. Un modèle peut être indisponible, un fournisseur peut modifier un service, une intégration peut exposer des données, une décision automatisée peut toucher trop de clients avant que quiconque ne s'en aperçoive. C'est pour cela qu'un même système peut relever à la fois du risque modèle, de l'AI Act et de DORA.

    Un fournisseur critique, c'est un fournisseur supervisé directement

    Le 18 novembre 2025, les superviseurs européens ont désigné dix-neuf fournisseurs tiers TIC critiques au titre de DORA. Concrètement, il s'agit de fournisseurs technologiques dont la défaillance pourrait créer un risque pour de nombreux établissements financiers en même temps. Trois noms concernent directement l'IA : Amazon Web Services EMEA, Google Cloud EMEA et Microsoft Ireland Operations.

    Beaucoup de systèmes d'IA financiers tournent sur ces clouds, via Bedrock, Azure OpenAI Service ou Vertex AI. Depuis janvier 2026, ces fournisseurs sont supervisés directement : les autorités peuvent leur demander des informations, enquêter, inspecter et émettre des recommandations. Cela ne fait pas pour autant de tous les usages d'IA des cas à haut risque. Mais cela rend vos dépendances IA bien plus visibles pour les superviseurs.

    DORA s'applique parce que l'IA fait partie du service

    DORA n'a pas besoin de prononcer le mot IA pour s'appliquer à l'IA. Le critère est plus simple : le système soutient-il une fonction métier qui dépend de la technologie ? Si oui, le système, ses flux de données, son hébergeur et ses API externes peuvent tous entrer dans le périmètre DORA.

    Prenez un modèle de scoring crédit. Ce modèle n'est pas qu'un simple fichier. Il dépend de données, d'une application, de contrôles d'accès, d'une supervision, d'un point d'inférence et, le plus souvent, d'un fournisseur cloud ou d'un fournisseur de modèle. Si cette chaîne se rompt et que des clients sont touchés, le sujet ne se limite plus à la qualité de l'IA. Il peut devenir un incident TIC au titre de DORA.

    Trois obligations deviennent très concrètes

    • Inventaire : l'article 8 implique d'inscrire le système d'IA avec son responsable, sa fonction, ses données, ses dépendances modèle et ses fournisseurs.
    • Incidents : l'article 19 implique qu'une défaillance IA peut devenir un incident à déclarer dès lors que son impact est suffisant, quelle que soit la cause technique.
    • Tiers : l'article 28 impose que le registre d'information fasse apparaître le fournisseur cloud, le fournisseur de modèle et toute la chaîne de service dès lors qu'ils soutiennent une fonction critique ou importante.

    C'est souvent là que les registres pèchent. Ils listent l'application, mais pas le service de modèle qui tourne derrière. Ils listent le contrat cloud, mais pas le composant IA utilisé via ce cloud. Ils listent le responsable métier, mais pas le seuil d'incident à partir duquel une défaillance IA devient une déclaration DORA.

    L'AI Act ajoute encore une couche

    Certains systèmes financiers d'IA sont aussi qualifiés à haut risque au titre de l'annexe III de l'AI Act. Le scoring crédit et l'évaluation de solvabilité en sont les exemples les plus clairs. La détection de fraude est exclue de cette catégorie haut risque, mais elle peut très bien rester dans le périmètre de DORA si elle soutient une fonction critique ou importante.

    L'article 9(10) de l'AI Act autorise les établissements à combiner le processus de gestion du risque IA avec les cadres européens déjà applicables. L'ABE a tenu le même discours dans son analyse de novembre 2025. En pratique, le dossier AI Act et le dossier DORA ne doivent pas raconter deux histoires différentes du même système.

    Par où commencer

    • Sélectionnez les systèmes d'IA qui touchent les clients, les transactions, l'entrée en relation, la conformité ou les décisions de risque.
    • Pour chacun, notez la fonction métier, le responsable, les sources de données, le fournisseur de modèle, le fournisseur cloud et le plan de repli.
    • Vérifiez si ce système figure bien dans le registre d'information DORA. S'il n'y est pas, ajoutez-le ou documentez pourquoi il en est exclu.
    • Définissez les seuils de déclenchement d'incident avec des chiffres concrets : clients touchés, transactions touchées, durée d'indisponibilité, impact économique et impact sur les données.
    • Pour les systèmes à haut risque au sens de l'AI Act, assurez-vous que la documentation AI Act et les contrôles DORA renvoient au même responsable, au même périmètre et aux mêmes preuves.

    Pour chaque système d'IA important, le test est concret : où apparaît-il dans le registre, qui porte le risque, de quel fournisseur dépend-il et que se passe-t-il en cas de défaillance ?

    Références

    • Règlement (UE) 2022/2554 (DORA), eur-lex.europa.eu/eli/reg/2022/2554/oj.
    • Règlement d'exécution (UE) 2024/2956 (ITS registre d'information).
    • ESAs, liste des CTPP désignés, 18 novembre 2025, esma.europa.eu.
    • ABE, analyse AI Act, lettre de José Manuel Campa, 21 novembre 2025.
    • Règlement (UE) 2024/1689 (AI Act), article 9(10), annexe III, eur-lex.europa.eu.

    Rendez vos systèmes IA audit-ready, en continu.

    Réservez une démo. Découvrez comment Mankinds transforme l'évaluation continue en preuves lisibles par vos auditeurs.