Guide de la BaFin sur l'IA : ce que les banques et les assureurs devraient mettre en œuvre dès maintenant en matière de risques TIC sous DORA
6 octobre 2026
Ce que la BaFin a publié
Le 18 décembre 2025, la BaFin a publié l'« Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen », son guide sur les risques liés aux TIC dans l'utilisation de l'IA par les entités financières — 38 pages, émanant de la division CTF 5 de la direction Cyberrisques et technologie dans le secteur financier. La version anglaise « Guidance on ICT Risks in the Use of AI at Financial Entities » (version datée du 23 janvier 2026) a suivi le 30 janvier 2026. Le guide se présente expressément comme une aide non contraignante : il ne définit aucune attente prudentielle et ne constitue pas une interprétation contraignante de DORA. Il s'adresse avant tout aux établissements CRR et aux entreprises d'assurance relevant de Solvabilité II qui appliquent la gestion du risque lié aux TIC des art. 5 à 15 DORA ; le cadre simplifié de l'art. 16 DORA n'est pas traité. Il se compose de six chapitres et d'une étude de cas consacrée à l'exploitation d'un assistant IA fondé sur un LLM.
Pourquoi c'est important maintenant
DORA s'applique depuis le 17 janvier 2025 ; les KAIT, VAIT et ZAIT sont depuis lors abrogées, et les BAIT ne s'appliquent plus non plus aux entités soumises à DORA — elles disparaîtront entièrement à l'expiration du 31 décembre 2026. Pour l'informatique de ces entités, la référence est donc DORA — y compris pour l'IA. En parallèle, la BaFin est depuis le 29 juillet 2026, en vertu du KI-MIG (loi allemande sur la surveillance du marché de l'IA et la promotion de l'innovation), l'autorité de surveillance du marché pour les systèmes d'IA directement liés à une activité financière réglementée (§ 2(3) KI-MIG) ; les obligations relatives à l'IA à haut risque de l'annexe III du règlement sur l'IA — par exemple pour l'évaluation de la solvabilité des personnes physiques — s'appliquent, après le report décidé par le règlement (UE) 2026/1744, à partir du 2 décembre 2027. Le guide ne traite pas pour autant des obligations du règlement sur l'IA, mais exclusivement des risques liés aux TIC sous DORA : il montre comment appliquer les exigences existantes de DORA aux systèmes d'IA que, selon la BaFin, les entités financières utilisent déjà tout au long de leur chaîne de valeur.
L'essentiel : un système d'IA relève des TIC — sur tout son cycle de vie
La BaFin reprend la définition du système d'IA de l'art. 3(1) du règlement sur l'IA et classe les systèmes d'IA comme un sous-ensemble des réseaux et systèmes d'information au sens de l'art. 3(2) DORA ; le modèle lui-même est considéré comme un actif de TIC. Il en découle que les systèmes d'IA relèvent du cadre de gestion du risque lié aux TIC existant (art. 6 DORA), de l'inventaire des actifs (art. 8(4) DORA) et — lorsque des tiers les fournissent — de la gestion du risque lié aux prestataires tiers de services TIC (art. 28 DORA). Les risques ne sont pas examinés selon la chaîne de valeur, mais selon le cycle de vie de l'IA, car ils naissent de l'intégration dans le paysage TIC. Le principe directeur est la proportionnalité au sens de l'art. 4 DORA : une IA intervenant dans des fonctions critiques ou importantes appelle davantage de mesures de sécurité et de contrôle qu'un assistant en libre-service entièrement placé sous supervision humaine et non intégré aux processus décisionnels. Une indication pratique du chapitre III : si une application intègre des modèles d'IA externes via une API, elle peut elle-même devenir un système d'IA.
Gouvernance, cadre de gestion du risque, développement et tests
La responsabilité ultime des risques liés aux TIC incombe à l'organe de direction (art. 5(2)(a) DORA) ; ses membres maintiennent activement à jour des connaissances et compétences suffisantes (art. 5(4) DORA), et le personnel reçoit des formations adaptées à ses fonctions (art. 13(6) DORA). La BaFin décrit comme pratique répandue une stratégie IA approuvée par l'organe de direction. Les vulnérabilités propres à l'IA dans l'entraînement, les pipelines de données et l'inférence relèvent de l'identification des risques (art. 8 DORA), et le cadre doit être réexaminé au moins une fois par an (art. 6(5) DORA). Pour le développement et les tests, le guide s'appuie presque entièrement sur le RTS RMF : gestion de projet, spécifications intégrant la protection contre la manipulation, gestion des changements et tests avant la mise en production, d'une ampleur proportionnée à la criticité (art. 15 à 17 RTS RMF). Selon une approche fondée sur les risques, ces exigences s'appliquent aussi aux applications développées par les utilisateurs, l'End-User Computing ou EUC (art. 16(9) RTS RMF) ; pour la BaFin, le code généré par l'IA obéit aux mêmes règles que le code écrit par des humains. En fonction de la criticité, la BaFin cite les tests adversariaux, les tests d'intrusion adversariaux et les tests de résistance comme pratique judicieuse — et les changements non annoncés des modèles obtenus auprès de tiers comme une difficulté particulière pour les tests.
Exploitation, cloud et prestataires tiers
En exploitation, DORA exige une politique et des procédures de gestion des actifs de TIC (art. 8(4) DORA en liaison avec les art. 4 et 5 RTS RMF) ; le guide y inclut expressément les données d'entraînement, les implémentations de modèles, les bibliothèques et le matériel. L'art. 10 RTS RMF impose des analyses automatisées des vulnérabilités et des délais pour les correctifs ; pour les fonctions critiques ou importantes, la BaFin recommande des seuils et des indicateurs de comportement anormal. Comme les systèmes d'IA sont souvent exploités dans le cloud, le chapitre IV.2 transpose à l'IA certains aspects de la communication prudentielle de la BaFin sur l'externalisation vers des fournisseurs de cloud du 1er février 2024 : évaluation des risques et vérifications préalables avant la conclusion du contrat (art. 28(4) DORA) — y compris les changements de modèle effectués par le prestataire —, transparence sur les sous-traitants tels que les fermes de GPU ou les bibliothèques de ML (art. 29 et 30 DORA), SLA de latence et de capacité de calcul, ainsi qu'une stratégie de sortie avec modèles, données d'entraînement et configurations exportables. Pour la mise hors service, la BaFin juge pertinentes des règles prévoyant de supprimer les modèles de manière irréversible et de désactiver les versions obsolètes.
Cybersécurité, sécurité des données et notification des incidents
Les systèmes d'IA relèvent des politiques de sécurité des TIC (art. 9(2) DORA). Sont notamment obligatoires une architecture réseau segmentée selon la criticité (art. 13 RTS RMF) ainsi que le chiffrement et la gestion des clés fondés sur la classification des données (art. 6 et 7 RTS RMF). La BaFin cite en outre comme éprouvés les pare-feu applicatifs web et les passerelles d'API, le zero trust pour l'accès aux services d'IA, la prévention des pertes de données (DLP), la signature des modèles ainsi que la protection contre les attaques par injection et la surcharge. Selon la BaFin, le fondement le plus important d'un traitement sécurisé des données est leur classification selon la confidentialité, l'intégrité et la disponibilité. Les incidents touchant des systèmes d'IA doivent être enregistrés comme incidents liés aux TIC et leurs causes déterminées (art. 17 DORA) ; les incidents majeurs doivent être notifiés (art. 19 DORA). La BaFin recommande en outre de marquer les incidents liés à l'IA comme tels et, après de tels incidents, de mener une analyse détaillée des causes profondes afin de corriger les faiblesses systématiques des modèles et processus d'IA. L'analyse des notifications DORA par la BaFin montre l'importance des tiers en général : environ la moitié des 733 incidents liés aux TIC notifiés en 2025 trouvait son origine dans des problèmes chez des tiers — il n'existe pas de chiffres spécifiques à l'IA.
L'étude de cas : un assistant IA, trois variantes d'infrastructure
L'étude de cas décline un assistant IA fondé sur un LLM, destiné à rédiger textes, e-mails et présentations — en six phases, de la collecte des données à la mise hors service, et en trois variantes : sur site (on-premise), avec un contrôle total mais tous les risques liés au développement, à l'exploitation et à la maintenance ; dans le cloud au sein du tenant propre, avec pour risque principal la dépendance envers l'exploitant du modèle si aucun modèle open source n'est utilisé ; et dans le cloud hors du tenant propre, par exemple un LLM appelé via API ou un assistant IA intégré à un logiciel standard. Dans la troisième variante, des données quittent le tenant et parviennent au fournisseur du modèle — selon l'étude de cas, il convient de s'en prémunir par des mesures contractuelles et techniques, par exemple des restrictions de téléversement, un Governance Shield qui vérifie si les saisies contiennent des contenus confidentiels, ou un niveau d'accès aux données réduit. Important : les mesures de l'étude de cas sont expressément données à titre d'exemple et n'expriment aucune attente prudentielle. Notre recommandation : inventoriez d'abord les fonctions d'IA de vos logiciels standard, comme Microsoft 365 Copilot, car selon l'étude de cas, de tels assistants sont parfois sollicités à l'insu des utilisateurs — le guide lui-même ne cite aucun produit.
Ce que nous avons publié à ce sujet
Notre nouvelle page de connaissances rend les 38 pages opérationnelles et distingue systématiquement l'obligation issue de DORA et des RTS, la pratique selon le guide et la recommandation VamiSec. Le test de périmètre indique le niveau de contrôle adapté à votre système d'IA. Le navigateur du cycle de vie parcourt six phases et deux thèmes transversaux avec risques, ancrages juridiques, questions d'audit et preuves. Le laboratoire des variantes représente les trois variantes d'infrastructure sous forme de flux de données et montre, par un feu tricolore, comment nous classons chaque variante selon la catégorie de données. Le navigateur des références ouvre l'accès aux 97 références selon notre décompte. Avec jusqu'à 31 questions réparties en sept domaines d'action, le diagnostic de résilience IA détermine votre niveau cible selon votre profil, puis présente vos principales lacunes et une feuille de route à 30/90/180 jours. S'y ajoute le livre blanc de 50 pages « KI unter DORA für CISOs » (« L'IA sous DORA pour les CISO », en allemand), avec 30 questions d'audit, une matrice de preuves et une feuille de route sur 12 mois.
Tous les liens
Page de connaissances sur le guide de la BaFin : https://vamisec.com/fr/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken · Diagnostic de résilience IA : https://vamisec.com/fr/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken#ki-check · Demander le livre blanc « KI unter DORA für CISOs » : https://vamisec.com/fr/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken#whitepaper · Page de connaissances DORA : https://vamisec.com/fr/wissen/grc/dora · Communiqué de la BaFin du 18 décembre 2025 : https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2025/meldung_2025_12_18_orientierungshilfe_ikt_risiken.html · Guide (original allemand) : https://www.bafin.de/SharedDocs/Downloads/DE/Anlage/dl_Anlage_orientierungshilfe_IKT_Risiken_bei_KI.html
Vous avez des questions sur la sécurité IT de votre organisation ?
Première consultation gratuite →