Guide de la BaFin sur l'IA : piloter les risques TIC dans les entités financières selon DORA

Genèse : du discours à la publication

Nikolas Speer, directeur exécutif de la supervision bancaire, a annoncé le guide le 4 décembre 2025 dans sa keynote « La supervision informatique dans le secteur financier : la première année de DORA », avec cette formule : « Pas un nouveau cahier des charges. Mais une aide. » Le 18 décembre 2025 a suivi le communiqué « Intelligence artificielle : la BaFin publie un guide sur les risques liés aux TIC ». Le document émane de la division CTF 5 de la direction Cyberrisques et technologie dans le secteur financier. La version allemande, « Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen » (état au 18 décembre 2025, 38 pages), est l'original ; la traduction anglaise « Guidance on ICT Risks in the Use of AI at Financial Entities » (version du 23 janvier 2026, 35 pages) a été publiée le 30 janvier 2026.

Nature juridique : non contraignant, mais pas un blanc-seing

Le guide se présente comme une « aide non contraignante », s'appuie notamment sur des échanges avec des entités financières, ne constitue « pas une interprétation contraignante de DORA par la BaFin » et « ne définit aucune attente prudentielle » (chap. I et I.2) ; les mesures de l'étude de cas sont elles aussi expressément données à titre d'exemple. Restent contraignants : DORA, le RTS RMF et le RTS sous-traitance. Le rapport annuel 2025 de la BaFin évoque toutefois des « attentes actualisées », qui auraient été communiquées sous la forme du guide. Aucune obligation n'en découle — mais, en tant que signal de la pratique de supervision, cette formulation mérite d'être prise au sérieux.

Destinataires et limites

Sont visées les entités financières au sens de l'art. 2(2) en liaison avec l'art. 2(1)(a) à (t) DORA, en particulier les établissements CRR et les entreprises d'assurance relevant de Solvabilité II ; le guide s'adresse avant tout aux entités surveillées par la BaFin qui doivent respecter les art. 5 à 15 DORA. Selon le guide, le cadre simplifié de l'art. 16 DORA appelle un examen distinct et n'est pas traité. Sur le fond, il s'agit exclusivement des risques liés aux TIC et de leur traitement au titre de DORA et des RTS complémentaires ; la méthodologie mathématique des modèles, y compris les données, le développement et la validation, reste hors champ (chap. I.1).

Le guide se conçoit comme un « document évolutif » (chap. I.3) ; la version de référence est actuellement celle du 18 décembre 2025 (DE) ou du 23 janvier 2026 (EN). La BaFin y renvoie déjà : dans sa publication « Risiken im Fokus 2026 » du 28 janvier 2026, qui cite notamment comme risques liés à l'IA les dépendances envers des fournisseurs tiers de cloud et de modèles d'IA ainsi que l'empoisonnement des données et des modèles (data et model poisoning), et dans l'entretien du BaFinJournal du 29 juillet 2026 consacré au KI-MIG, la loi allemande sur la surveillance du marché de l'IA et la promotion de l'innovation.

Trois étapes pour construire la notion (chap. I.1)

1. 1
   Art. 3(1) AI ActReprendre la définition légale

   Un système d'IA est un système automatisé conçu pour fonctionner à différents niveaux d'autonomie, qui peut faire preuve d'une capacité d'adaptation après son déploiement et qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu'il reçoit, la manière de générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuels.

2. 2
   C(2025) 5053 final, point 11Interpréter « automatisé »

   Les systèmes d'IA sont développés à l'aide de machines et fonctionnent sur celles-ci. Selon les lignes directrices de la Commission du 29 juillet 2025, la machine comprend du matériel (unités de traitement, mémoire, dispositifs de réseau, interfaces d'entrée et de sortie) et des logiciels (notamment code informatique, systèmes d'exploitation, applications).

3. 3
   Art. 3(2) DORASituer dans DORA

   Les systèmes d'IA constituent ainsi une sous-catégorie des réseaux et systèmes d'information. Il s'agit d'une combinaison d'actifs de TIC et d'infrastructure de TIC dans laquelle est implémenté un modèle mathématique complexe ; le modèle lui-même est un actif de TIC (logiciel).

Ne sont pas examinées les caractéristiques d'autonomie et de capacité d'adaptation au sens du règlement sur l'IA, ni la méthodologie mathématique des modèles, y compris les données utilisées, leur développement et leur validation. Le guide ne se demande donc pas si un modèle calcule bien, mais si le système dans lequel il tourne est sûr et résilient. La nature et la portée d'un système d'IA dépendent du cas d'espèce et doivent notamment correspondre à la finalité métier, à la situation de risque et au contexte.

IA cachée : quand un logiciel devient un système d'IA à l'insu de tous

Le chap. III.2 décrit la difficulté, lors des tests, de détecter si des applications intègrent des modèles d'IA externes, par exemple via des API — un logiciel conçu à l'origine comme application sans IA peut ainsi devenir un système d'IA. Le chap. III.1 ajoute que du code généré par IA peut appeler des fonctions d'IA inconnues de l'utilisateur. Selon l'étude de cas (variante 3), des assistants IA intégrés à des logiciels standard sont parfois appelés à l'insu des utilisateurs ; la conclusion relève qu'ils sont souvent inclus dans les logiciels standard.

Conséquence pour l'inventaire : une politique et des procédures de gestion des actifs informationnels et des actifs de TIC sont obligatoires (art. 8(4) DORA en liaison avec les art. 4 et 5 RTS RMF). Selon le chap. IV.1, il y a lieu d'identifier, de classifier, de documenter et de surveiller en continu également les composants des systèmes d'IA. Qui n'inventorie que les « projets d'IA » passe à côté de l'IA qui entre dans l'entreprise avec la prochaine mise à jour d'un logiciel standard ou par une API.

Note de citation : dans des extraits de texte du PDF allemand, la référence aux lignes directrices de la Commission apparaît sous la forme « Rn. 116 » — il s'agit du point 11 suivi de la note de bas de page 6.

Pourquoi le cycle de vie est le meilleur cadre de référence

Selon le chap. I.2, les risques spécifiques liés aux TIC sont sans rapport avec la place d'un système d'IA dans la chaîne de valeur ; ils découlent de son intégration dans le paysage TIC. C'est pourquoi le guide suit le cycle de vie de l'IA — de l'acquisition des données à l'exploitation courante et à la mise hors service, en passant par le développement du modèle et le déploiement. La sécurité et la résilience du système d'IA devraient être garanties à chaque phase, et les systèmes d'IA sont à prendre en compte dans le cadre de gestion du risque lié aux TIC existant. La figure 1 identifie cinq vecteurs d'attaque : les données et le modèle d'IA (chap. III), les entrées, les sorties et le système de TIC lui-même (chap. IV) ; la cybersécurité et la sécurité des données agissent de manière transversale (chap. V).

Domaines d'utilisation selon le chap. I

Proportionnalité selon l'art. 4 DORA

L'art. 4 DORA impose une application proportionnée de la gestion du risque lié aux TIC, en fonction de la taille, du profil de risque global ainsi que de la nature, de l'ampleur et de la complexité des services et des activités. Le guide transpose ce principe à l'IA : les applications intégrées à des fonctions critiques ou importantes nécessitent des mesures de sécurité et de contrôle plus étendues que, par exemple, des assistants libre-service fondés sur l'IA, entièrement placés sous supervision humaine et non intégrés aux processus décisionnels (chap. I.2). Comme les systèmes de TIC, les systèmes d'IA sont évalués selon leur profil de risque, leur complexité et les fonctions qu'ils soutiennent (chap. II.1). Le guide module expressément selon la criticité aux points suivants :

• Stratégie IA : gagne en importance lorsque l'IA soutient des fonctions critiques ou importantes (chap. II.2).
• Fonctions de contrôle et audit interne : implication lors de l'introduction en fonction de la criticité du système d'IA (chap. II.2).
• Tests : étendue proportionnée à la criticité (art. 16(2) RTS RMF) ; tests adversariaux et tests de résistance « selon la criticité » (chap. III.2).
• Détection : journalisation fondée sur les risques ; seuils et indicateurs de comportement anormal pour les fonctions critiques ou importantes (chap. IV.1).
• Cloud : SLA, stratégie de sortie, tests d'urgence et droits d'audit couvrant toute la chaîne de sous-traitance lorsque des fonctions critiques ou importantes sont soutenues (chap. IV.2).

Stratégie IA et feuille de route technologique

Selon le chap. II.2, les entités financières élaborent « souvent » une stratégie IA alignée sur leur stratégie globale, leur stratégie de risque et, le cas échéant, leur stratégie TIC et leur stratégie de résilience opérationnelle numérique (stratégie DOR), et la font approuver par l'organe de direction — de manière autonome ou intégrée à une stratégie de niveau supérieur. Son poids s'accroît surtout lorsque l'IA soutient des fonctions critiques ou importantes. Elle peut s'appuyer sur une feuille de route technologique qui fixe les ressources, capacités et investissements TIC nécessaires au déploiement de l'IA ; une gestion continue de l'innovation aide à évaluer les nouvelles technologies d'IA. Il est judicieux de couvrir et de documenter dans un même processus toutes les étapes, de la stratégie à la mise hors service en passant par le développement. Selon le guide, il importe de vérifier, avant la mise en œuvre, si les processus concernés sont conçus pour l'IA et s'il existe une sensibilisation au traitement des actifs informationnels.

Obligation et pratique en un coup d'œil

Selon le chap. II.2, il est utile de formuler des exigences générales cohérentes avec la stratégie DOR et avec les politiques et directives en matière de sécurité de l'information. Les règles spécifiques aux prestataires tiers de services TIC et à leurs services devraient idéalement tenir compte d'une évaluation des risques, des indications du prestataire et des mesures propres de réduction des risques. Les exigences générales devraient être rapportées au cas d'usage, en vérifiant si des mesures supplémentaires spécifiques à l'IA sont nécessaires.

Ancrage des compétences : le guide fonde les exigences de compétences sur l'art. 5(4) et l'art. 13(6) DORA, et non sur l'art. 4 du règlement sur l'IA. La règle de maîtrise de l'IA du règlement sur l'IA s'applique en parallèle depuis le 2 février 2025 ; le règlement (UE) 2026/1744 l'a assouplie : au lieu de garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l'IA, il s'agit désormais de prendre des mesures pour soutenir le développement de la maîtrise de l'IA.

L'art. 6(1) DORA exige un cadre de gestion du risque lié aux TIC solide, complet et dûment documenté, faisant partie du système global de gestion des risques. Le guide met cette disposition en exergue dans un encadré de citation et énumère notamment comme composantes du cadre : identification, protection et prévention, détection, réponse et rétablissement, apprentissage et évolution, ainsi que communication (art. 8 à 11, 13 et 14 DORA). Selon lui, l'intégration des systèmes d'IA comprend l'identification des vulnérabilités, par exemple dans l'entraînement des modèles, les pipelines de données ou l'inférence, ainsi que l'évaluation de critères de risque quantitatifs et qualitatifs (chap. II.3).

Ce que le guide déduit pour chaque composante de DORA

Point important pour la délimitation : l'étude de cas considère les hallucinations comme n'étant pas directement pertinentes sous l'angle des TIC (phase 4). Parmi les aspects de la qualité des données, seule l'intégrité est couverte par DORA ; pour les autres, le règlement ne contient aucune disposition (chap. V.2). La surveillance de la dérive des modèles apparaît comme une mesure de traitement à documenter, et non comme un risque lié aux TIC à part entière. Le guide présente les exigences de qualité des données comme un élément typique des structures de gouvernance de l'IA — une qualité élevée des données, surtout pour les données d'entraînement, reste une condition essentielle du recours à l'IA.

Réexamen annuel et rapport

Obligation : le cadre de gestion du risque lié aux TIC doit être réexaminé au moins une fois par an, ainsi qu'après des incidents majeurs liés aux TIC, des instructions des autorités de surveillance ou des constatations issues de tests et d'audits (art. 6(5) DORA). Un rapport sur ce réexamen est à remettre à l'autorité compétente à sa demande ; l'art. 27 RTS RMF impose pour cela un format électronique permettant les recherches. Les contenus obligatoires visés à l'art. 27(2) RTS RMF comprennent notamment une synthèse du profil de risque lié aux TIC actuel et à court terme et du paysage des menaces, la date d'approbation par l'organe de direction, les constatations avec leur niveau de gravité ainsi que les mesures correctives avec échéances et responsables. Le guide ajoute que le rapport peut, si nécessaire, être enrichi d'informations spécifiques aux systèmes d'IA.

Compétences : qui doit savoir quoi

Selon le chap. III.1, les collaborateurs chargés de tâches liées à l'IA sont confrontés au défi d'acquérir des compétences sur le fonctionnement des systèmes d'IA, sur leurs risques et sur les spécificités de l'exploitation dans le cloud et sur site ; plus la tâche est technique, plus les connaissances doivent être spécifiques. Compte tenu de la rapidité des progrès, le guide estime nécessaires des formations régulières et un suivi continu de la dynamique d'évolution. Pour l'organe de direction et le management, il renvoie à l'art. 5(4) et à l'art. 13(6) DORA. Lorsque des métiers construisent leurs propres applications à l'aide d'assistants IA, il cite l'art. 16(9) RTS RMF — cette disposition fonde l'égalité de traitement de l'End-User Computing ; les obligations de compétence elles-mêmes découlent de DORA.

Obligation et pratique dans le processus de développement

Processus d'entraînement : quatre pratiques qui se sont révélées utiles selon le guide

• Les données d'entraînement et de test proviennent de sources fiables.
• Les bibliothèques (open source) et paquets logiciels utilisés pour l'entraînement ne contiennent aucune vulnérabilité connue.
• L'ensemble du processus d'entraînement est documenté et versionné.
• Des analyses de sécurité détectent les manipulations cachées dans le modèle ou dans les données d'entraînement.

Les bibliothèques open source — et, à l'extrême, un modèle open source implémenté, entraîné et exploité sur le propre matériel de l'entité — comportent selon le chap. III.1 deux risques supplémentaires : l'injection de code malveillant et des bibliothèques qui ne sont plus maintenues au bout de quelques années, laissant derrière elles des vulnérabilités identifiées mais non corrigées. Le code généré par IA obéit aux mêmes règles que le code écrit par des humains. La difficulté consiste à vérifier s'il appelle des fonctions d'IA inconnues de l'utilisateur ; cela peut notamment être établi par une analyse statique du code (art. 16(3) RTS RMF). Des analyses plus approfondies du code source peuvent apporter une assurance supplémentaire, et une documentation appropriée s'est avérée utile pour les tests ultérieurs.

Ce que le RTS RMF impose

Les entités financières doivent élaborer, documenter et mettre en œuvre des tests. L'étendue des tests doit être proportionnée à la criticité des processus métier et des actifs de TIC concernés et permettre de vérifier si les nouveaux systèmes de TIC — et donc les systèmes d'IA — sont adaptés à leur finalité prévue (art. 16(2) RTS RMF). Avant la mise en production, le code source doit être examiné à l'aide de méthodes statiques et dynamiques afin de détecter des anomalies, y compris par des tests de sécurité des systèmes exposés à Internet (art. 16(3) RTS RMF). Les logiciels propriétaires ainsi que, dans la mesure du possible, le code source fourni par des prestataires tiers de services TIC ou issu de projets open source sont à analyser et à tester avant leur mise en service (art. 16(8) RTS RMF).

Trois défis propres à l'IA (chap. III.2)

Briques de test selon la criticité

Les processus d'exploitation devraient couvrir l'ensemble du cycle de vie — développement, installation, exploitation et désinstallation — et documenter toutes les activités d'exploitation, par exemple les journaux des processus d'inférence des modèles (art. 8 RTS RMF). Les actifs informationnels et les actifs de TIC, y compris les composants d'IA, sont à identifier, classifier, documenter et surveiller en continu (art. 8(4) DORA en liaison avec les art. 4 et 5 RTS RMF ; voir chapitre 2). Le guide qualifie les droits d'accès fondés sur les rôles aux modèles d'IA et aux données d'entraînement d'outil efficace, à vérifier et documenter régulièrement ; l'art. 21 RTS RMF exige le principe du moindre privilège et un réexamen des droits au moins une fois par an, et au moins tous les six mois pour les systèmes soutenant des fonctions critiques ou importantes.

Les briques d'exploitation en un coup d'œil

Le libellé montre ce qui relève de l'obligation et ce qui relève de la pratique : les plans « doivent » être testés au moins une fois par an (art. 11(6)(a) DORA), et l'art. 10 RTS RMF prescrit des analyses de vulnérabilités automatisées au moins hebdomadaires pour les actifs soutenant des fonctions critiques ou importantes. Le guide présente en revanche la surveillance continue, la journalisation exhaustive des décisions de l'IA et des seuils de comportement anormal propres à l'IA comme pertinents, recommandables ou avantageux — l'obligation générale de disposer de mécanismes de détection assortis de seuils d'alerte (art. 10(1) et (2) DORA) n'en est pas affectée. Pour l'exploitation et la maintenance d'un assistant IA (phases 4 et 5), l'étude de cas ajoute une surveillance contextuelle des interactions avec l'IA, des mises à jour automatisées, un plan de réponse aux incidents de sécurité (SIRP) et un tableau de bord de conformité indiquant la version du modèle, les évaluations des risques et les responsabilités. La désinstallation est traitée au chapitre 9.

Les preuves que vous pouvez présenter (VamiSec)

• Inventaire IA avec composants, criticité, propriétaire, origine des données et dates de fin de support des fournisseurs, y compris les dates d'abandon des versions de modèles
• Planification des capacités et rapports de monitoring de l'infrastructure d'IA
• Politique de journalisation avec seuils et preuve du contrôle d'efficacité
• Recertification des droits d'accès aux modèles et aux données d'entraînement
• Procès-verbaux de tests des plans de continuité des activités incluant des scénarios de défaillance de l'IA

Le guide nomme le risque dès le chap. II.1 : la réutilisation incontrôlée ou l'élimination non sécurisée d'applications d'IA met en danger des données sensibles relatives aux modèles ou à l'entreprise. L'étude de cas se fait plus concrète — des données et des modèles historiques peuvent faire l'objet d'une utilisation abusive ou devenir involontairement publics. Elle en conclut que la mise hors service des LLM et des sources de données associées doit être planifiée « comme pour tous les actifs de TIC ». Dès le chap. II.2, le guide suggère de couvrir et de documenter dans un même processus toutes les étapes pertinentes pour l'IA, de la stratégie jusqu'à la mise hors service.

Obligation, pratique, recommandation — clairement distinguées

Un système d'IA laisse derrière lui bien plus qu'une application. Parmi les actifs informationnels et actifs de TIC, le guide compte notamment les jeux de données d'entraînement, les implémentations de modèles, les bibliothèques logicielles, le matériel ainsi que les logiciels développés en interne ou par des tiers (chap. IV.1) ; pour la suppression, l'étude de cas mentionne en outre les interactions historiques avec l'IA. D'après notre pratique, les bases de connaissances RAG, les copies de modèles dans les sauvegardes ainsi que les clés d'API et les comptes de service ont leur place sur la même liste.

Runbook de mise hors service (recommandation VamiSec)

1. 1
   Définir le déclencheur et le périmètre

   Mise hors service, changement de version et changement de fournisseur déclenchent le même processus. Déduire de l'inventaire de l'IA tous les artefacts : versions de modèles, données d'entraînement, bases de connaissances, journaux, interfaces, comptes.

2. 2
   Couper les dépendances

   Désactiver interfaces, comptes de service et clés d'API, bloquer les accès utilisateurs (art. 21 RTS RMF). Désactiver de manière ciblée les versions de modèles obsolètes, plutôt que de simplement les retirer du routage.

3. 3
   Arbitrer entre conservation et suppression

   Les journaux sont soumis aux durées de conservation fixées en application de l'art. 12 RTS RMF, les interactions contenant des données personnelles au RGPD. Résoudre ce conflit de manière documentée avant toute suppression.

4. 4
   Supprimer de manière irréversible

   Supprimer modèles, données et copies — y compris dans les sauvegardes et chez le prestataire ; si possible, par effacement cryptographique via la destruction des clés (art. 7 RTS RMF).

5. 5
   Prouver et clore l'inventaire

   Archiver le journal de suppression et la confirmation du prestataire, passer le statut d'inventaire à « mis hors service », réinjecter les enseignements dans l'évaluation des risques liés aux TIC.

Les mesures de l'étude de cas sont données à titre d'exemple ; seule l'exigence de désinstallation du RTS RMF est contraignante. Pour l'IA dans le cloud, la suppression chez le fournisseur relève selon nous de la planification de sortie (chapitre 10).

La structure reprend celle de la communication prudentielle sur l'externalisation vers des fournisseurs de cloud — l'appréciation commune de la BaFin et de la Deutsche Bundesbank, version révisée du guide de novembre 2018. Certains de ses aspects « peuvent […] également être transposés aux systèmes d'IA » (chap. IV.2). Une différence terminologique subsiste : la communication prudentielle raisonne en externalisations (significatives), DORA en fonctions critiques ou importantes.

Où commence l'obligation

C'est le règlement DORA lui-même qui est contraignant : avant tout accord contractuel portant sur des services TIC, les risques doivent être évalués et les vérifications préalables effectuées (art. 28(4) DORA) ; le contenu minimal prévu à l'art. 30(2) DORA s'applique à tous les contrats. Les clauses contractuelles supplémentaires (art. 30(3)), les stratégies de sortie (art. 28(8)) et le RTS sous-traitance ne s'appliquent qu'aux fonctions critiques ou importantes. Un assistant de rédaction qui ne participe à aucune décision nécessite donc selon nous un dispositif contractuel plus léger qu'un modèle de scoring soutenant une fonction critique ou importante — la classification doit néanmoins être documentée (art. 8(1) DORA).

Trois subtilités de citation

• L'art. 3(6) ITS registre d'informations régit l'identifiant des sous-traitants (LEI ou EUID) ; l'obligation de les recenser figure à l'art. 3(2)(b).
• L'art. 28(8), 3e alinéa, DORA porte sur les tests des plans de sortie ; les tests d'urgence des fonctions critiques ou importantes externalisées relèvent plus précisément de l'art. 11(4) DORA, cité au chap. IV.1 (interprétation VamiSec).
• Pour la restitution des données et leur format, l'art. 30(2)(d) DORA est plus précis ; la BaFin ne le cite pas (interprétation VamiSec).

Point de départ : l'art. 9(2) DORA — les entités financières conçoivent, acquièrent et mettent en œuvre des politiques, procédures, protocoles et outils de sécurité des TIC. Selon le guide, les systèmes d'IA devraient y être dûment pris en compte — avec des mesures relatives à la sécurité des réseaux, à la transmission des données (art. 2(1) RTS RMF) et à la protection contre l'utilisation abusive des données. Pour l'IA, cela signifie qu'au-delà des accès aux modèles, il convient de sécuriser les échanges de données entre données d'entraînement, composants du modèle et utilisateurs finaux.

Cinq mesures éprouvées pour les systèmes d'IA

• Surveillance continue en temps réel des comportements anormaux, p. ex. des schémas de décision inattendus
• Mécanismes de protection contre les entrées adversariales, par exemple des mécanismes de filtrage
• Journalisation des sorties pertinentes et des appels d'API pour des analyses ultérieures
• Mises à jour régulières du système d'IA face aux nouvelles menaces
• Plan d'urgence pour les incidents de sécurité affectant le système d'IA

Point important pour la constitution des preuves : le guide présente ces cinq mesures comme des bonnes pratiques à la suite du renvoi aux art. 24 et 25 DORA — elles ne sont pas fondées sur ces articles. L'obligation porte sur le programme de tests ; la manière de le décliner pour l'IA relève de la pratique. Les cadences contraignantes figurent dans le texte juridique :

Le guide envisage l'IA avant tout comme une cible. Avec l'alerte ESRB/2026/3 du Comité européen du risque systémique (CERS) du 25 juin 2026 et la lettre de la BCE du 7 juillet 2026, l'IA apparaît aussi comme un outil d'attaque : le CERS décrit des modèles de pointe (frontier models) capables de trouver des vulnérabilités et de produire des exploits fonctionnels ; la BCE a invité les établissements importants à soumettre un plan d'action à leur équipe de surveillance prudentielle conjointe (Joint Supervisory Team) d'ici au 31 octobre 2026. À nos yeux, ces deux initiatives visent surtout un domaine que l'art. 10 RTS RMF encadre déjà — la gestion des vulnérabilités et des correctifs, mais à un rythme nettement plus soutenu.

Selon le guide, la classification selon la confidentialité, l'intégrité et la disponibilité constitue la « base la plus importante » d'un traitement et d'un stockage sécurisés : elle détermine comment et où les données peuvent être traitées et stockées — un complément utile, selon le chap. V.2, pour l'exploitation de l'IA dans le cloud. Le guide cite l'art. 5(2)(b) et l'art. 11(2)(k) RTS RMF. À strictement parler, le point (b) fixe des critères pour l'évaluation de la criticité des actifs, et le point (k) des exigences applicables aux actifs exploités par des prestataires tiers de services TIC ; selon notre lecture, l'obligation générale de classification des actifs informationnels et des actifs de TIC figure à l'art. 8(1) DORA.

Bonnes pratiques — adaptables à chaque entité

• Chiffrement et signature des modèles contre les modifications non autorisées
• Exploitation dans des environnements sécurisés, p. ex. des conteneurs
• Modèle zero trust pour l'accès aux services d'IA
• Protection contre les attaques par injection, limitation de débit (rate limiting) contre le déni de service

Pour les assistants LLM, l'étude de cas place la protection dès la source : détection automatisée des données confidentielles, confidentialité différentielle contre les inférences tirées de requêtes multiples, tokenisation des données sensibles avant traitement — et, pour la variante 3, un niveau d'accès aux données réduit, que les utilisateurs ne peuvent pas dépasser de leur propre initiative (étude de cas, phase 1 et variante 3).

Qualité des données : DORA ne couvre que l'intégrité

Selon le guide, la qualité des données recouvre généralement l'exhaustivité, l'exactitude, la validité, la cohérence, l'adéquation ou la représentativité, et l'intégrité. Seule l'intégrité est couverte par DORA ; pour les autres aspects, le règlement ne contient aucune règle. L'exactitude, la fiabilité et la performance de l'IA en dépendent pourtant, surtout pour les données d'entraînement — les exigences de qualité des données relèvent donc typiquement de la gouvernance de l'IA. Dans le même esprit, l'étude de cas range les hallucinations parmi les défis qui ne relèvent pas directement des TIC.

Le chap. V.2 s'appuie exclusivement sur le RTS RMF (art. 5, 6, 7, 11, 14) ; le guide n'y cite aucun article de DORA.

Ces chiffres proviennent de l'analyse par la BaFin des incidents liés aux TIC notifiés en 2025 au titre de DORA, ainsi que de l'article du BaFinJournal « Vernetzung vervielfacht IT-Risiken » (« L'interconnexion multiplie les risques informatiques ») du 16 juillet 2026, qui présente cette analyse. Ils couvrent l'ensemble des incidents liés aux TIC notifiés ; la BaFin ne publie pas de chiffres propres à l'IA. La part imputable aux tiers n'en reste pas moins instructive : à nos yeux, quiconque consomme un modèle via une API dépend aussi de la situation de son fournisseur en matière d'incidents.

Tout incident lié aux TIC survenant dans un système d'IA n'est pas soumis à notification — mais chacun doit être enregistré (art. 17 DORA). Le caractère majeur d'un incident se détermine selon les critères de classification de l'art. 18 DORA, que le guide lui-même ne cite pas. Les cybermenaces importantes peuvent être notifiées à titre volontaire (art. 19 DORA).

Mesures éprouvées selon le guide

1. 1
   Identifier les menaces propres à l'IA

   Identifier de manière ciblée les menaces propres à l'IA, p. ex. la manipulation des données d'entraînement.

2. 2
   Détecter les incidents d'IA

   Détecter les erreurs de modèle, les pertes de données ou les problèmes de performance de façon à pouvoir agir immédiatement.

3. 3
   Analyser l'impact, évaluer la gravité

   Analyse d'impact, p. ex. en termes de perte de données, et classement par niveau de gravité.

4. 4
   Intégrer à la réponse aux incidents

   Intégrer les incidents issus des systèmes d'IA au dispositif général de réponse aux incidents — avec les rôles, les circuits de communication et les procédures d'escalade que l'art. 17 DORA impose de toute façon.

5. 5
   Analyser les causes, en tirer les leçons

   Analyse approfondie des causes profondes, afin de corriger les faiblesses systémiques des modèles et des processus et d'empêcher durablement que les incidents se répètent.

Pour l'IA dans le cloud, le guide recommande en outre des accords sur la notification des incidents liés aux TIC survenant dans des systèmes d'IA, ainsi que des ressources internes suffisantes et qualifiées pour l'évaluation et la réaction. Pour les assistants IA, l'étude de cas ajoute un plan de réponse aux incidents de sécurité (SIRP) et des cyberattaques simulées qui testent les délais de réaction (phase 5).

Perspective : la proposition « omnibus numérique » de la Commission du 19 novembre 2025 (COM(2025) 837 final) — à ne pas confondre avec le règlement omnibus numérique sur l'IA déjà entré en vigueur, le règlement (UE) 2026/1744 — prévoit notamment d'acheminer les notifications au titre de l'art. 19(1) DORA via un point d'entrée unique (single entry point). Il ne s'agit que d'une proposition ; l'art. 19 DORA dans sa version en vigueur reste déterminant.

Trois variantes d'infrastructure sont examinées (figure 2) : sur site (on-premise), cloud avec application d'IA dans le tenant propre de l'entité, et cloud avec application d'IA hors de ce tenant. Les formes mixtes sont expressément possibles ; l'analyse des risques doit alors être adaptée. L'étude de cas ne traite ni des coûts d'investissement ni des coûts d'exploitation. Il appartient aux entités financières de mettre en œuvre les mesures les mieux adaptées à leur situation de risque spécifique.

Six phases : des risques valables pour chaque variante

Trois variantes, trois profils de risque

L'étude de cas et le chap. VI ne contiennent aucune référence à DORA. Quiconque rattache les mesures de l'étude de cas à des bases juridiques procède à sa propre correspondance — les obligations elles-mêmes découlent de DORA et du RTS RMF.

Règlement sur l'IA et KI-MIG : où banques et assureurs sont concrètement concernés

Sont à haut risque, selon l'annexe III, point 5(b), du règlement sur l'IA, les systèmes destinés à évaluer la solvabilité des personnes physiques ou à établir leur note de crédit — à l'exception de ceux utilisés pour détecter la fraude financière — et, selon le point 5(c), les systèmes destinés à l'évaluation des risques et à la tarification pour les personnes physiques en matière d'assurance vie et d'assurance maladie. En vertu du règlement omnibus numérique sur l'IA (règlement (UE) 2026/1744), les obligations relatives aux systèmes à haut risque (chapitre III, sections 1 à 3, du règlement sur l'IA) s'appliquent à ces systèmes à partir du 2 décembre 2027, au lieu du 2 août 2026 initialement prévu.

En vertu du § 2(3) KI-MIG, la BaFin surveille les systèmes d'IA qui sont en lien direct avec une activité financière réglementée et qui sont mis sur le marché, mis en service ou utilisés par des entités surveillées — selon la BaFin, par exemple les chatbots clients, l'évaluation de la solvabilité et l'évaluation des risques en assurance vie et en assurance maladie. L'IA utilisée dans la gestion des ressources humaines reste du ressort de la Bundesnetzagentur. La BaFin y porte son attention sur les pratiques interdites (art. 5), les obligations de transparence (art. 50) et la maîtrise de l'IA (art. 4 du règlement sur l'IA) ; à partir du 2 décembre 2027 s'y ajoutent les systèmes à haut risque de l'annexe III, point 5(b) et (c). Dans l'entretien consacré au KI-MIG publié par le BaFinJournal le 29 juillet 2026, la BaFin renvoie expressément au guide.

Supervision européenne : même direction, accents propres

• AEAPP (EIOPA), avis du 6 août 2025 (EIOPA-BoS-25-360) : explique aux autorités nationales de surveillance, selon une approche fondée sur les risques et proportionnée, comment appliquer la DDA, Solvabilité II et DORA à l'IA chez les assureurs — sans nouvelles exigences ; l'IA interdite et à haut risque au sens du règlement sur l'IA en est exclue.
• ABE (EBA), fiche d'information du 21 novembre 2025 : mise en regard des exigences du règlement sur l'IA relatives aux systèmes à haut risque (en particulier l'évaluation de la solvabilité) avec CRD/CRR, DORA et le reste du droit prudentiel bancaire : aucune contradiction significative ; l'ABE n'estime pas nécessaire d'adopter de nouvelles orientations.
• AEMF (ESMA), déclaration publique du 30 mai 2024 : l'IA utilisée dans les services d'investissement fournis aux clients de détail doit satisfaire aux obligations de MiFID II ; la responsabilité reste du ressort de l'organe de direction.
• ABE, AEAPP et AEMF, déclaration JC 2026 25 du 31 juillet 2026 : DORA et le règlement sur l'IA constituent une base solide face aux risques liés aux TIC découlant des modèles d'IA de pointe (frontier AI) ; la prévention passe notamment par un inventaire complet des actifs, composants d'IA/ML compris.

L'exigence d'explicabilité des modèles d'IA n'est pas une nouveauté de la 9e révision des MaRisk ; elle figurait déjà, avec un contenu identique, à l'AT 4.3.5 de la 7e révision (circulaire 05/2023 (BA)).

1. 1
   Phase 0 · mois 1Clarifier le mandat et le régime applicable

   L'organe de direction confirme sa responsabilité ultime (art. 5(2)(a) DORA) et alloue un budget ; vérifier si ce sont les art. 5 à 15 ou le cadre simplifié de l'art. 16 DORA qui s'appliquent ; désigner, pour chaque fonction, les responsables des résultats produits par l'IA.

2. 2
   Phase 1 · mois 1–3Établir la transparence

   Constituer un inventaire de l'IA — y compris l'IA consommée via API et intégrée aux logiciels standard (art. 8(4) DORA en liaison avec les art. 4 et 5 RTS RMF) ; consigner pour chaque système la criticité, la variante d'infrastructure, les classes de données et le propriétaire.

3. 3
   Phase 2 · mois 3–6Adapter le cadre

   Stratégie IA ou volet IA de la stratégie de résilience opérationnelle numérique ; ancrer l'IA dans le cadre de gestion du risque lié aux TIC, dans les politiques de sécurité (art. 9(2) DORA), dans la politique de gestion des incidents (art. 22 RTS RMF) et dans les contrats avec les prestataires tiers (art. 28 à 30 DORA).

4. 4
   Phase 3 · mois 6–9Durcir et tester

   Tests avant mise en production, d'une ampleur proportionnée à la criticité (art. 16(2) RTS RMF), complétés par des tests adversariaux pour l'IA soutenant des fonctions critiques ou importantes ; seuils de comportement anormal de l'IA dans les fonctions critiques ou importantes (art. 10(1), 2e alinéa, en liaison avec l'art. 10(2) DORA) ; Governance Shield pour la variante 3 ; tester les plans de continuité des activités (art. 11(6)(a) DORA, art. 25 RTS RMF).

5. 5
   Phase 4 · mois 9–12Démontrer l'efficacité

   Réexamen annuel du cadre de gestion du risque lié aux TIC (art. 6(5) DORA), avec un volet IA dans le rapport prévu à l'art. 27 RTS RMF ; intégrer les enseignements tirés (art. 13(3) DORA) ; tester les plans de sortie (art. 28(8) DORA) ; documenter les formations (art. 5(4), art. 13(6) DORA).

Des indicateurs que la direction comprend

La proportionnalité vaut aussi pour la feuille de route : un assistant en libre-service fondé sur l'IA, entièrement placé sous supervision humaine et non intégré aux processus décisionnels, ne requiert pas la même profondeur de contrôle qu'une IA soutenant une fonction critique ou importante (art. 4 DORA, chap. I.2). Commencer par l'inventaire permet d'échelonner cette profondeur de manière motivée — et de documenter cette motivation.

Le guide est une aide non contraignante et ne constitue pas une interprétation contraignante de DORA par la BaFin. Seuls DORA, le RTS RMF et le RTS sous-traitance sont contraignants. La feuille de route est une recommandation VamiSec et ne constitue pas un conseil juridique.