IA de frontière : ce que les AES attendent des banques au titre de DORA

Mise à jour – 8 novembre 2026. Parallèlement à la déclaration des AES, la BCE a écrit le 7 juillet 2026 aux dirigeants des établissements importants au sujet des cybermenaces liées à l’IA, en leur demandant de remettre un plan d’action à leur équipe de surveillance prudentielle conjointe (JST) avant le 31 octobre 2026. Cette échéance est désormais passée : la BCE va conduire une analyse transversale des plans reçus et en partager les conclusions, et elle a reporté son questionnaire annuel sur le risque informatique à février 2027. Les établissements moins importants n’étaient pas concernés, mais doivent s’attendre aux mêmes questions de la part de leurs superviseurs nationaux.

Le 31 juillet 2026, les trois autorités européennes de supervision (ABE, AEMF, AEAPP) ont publié une déclaration commune sur les risques TIC liés aux modèles d’IA de frontière. Elle ne crée aucune obligation nouvelle. Elle indique en revanche comment les autorités liront, dans leurs contrôles, les exigences déjà applicables de DORA, et cela suffit à modifier vos priorités de résilience.

Une déclaration de convergence, pas un nouveau texte

Le document (JC 2026 25) s’appuie sur DORA et sur le règlement sur l’IA. Il rappelle que des modèles très performants peuvent accélérer la découverte de vulnérabilités, viser des infrastructures partagées et exploiter les points de défaillance uniques. Il cite l’avertissement du CERS sur l’impact potentiel d’un usage malveillant de ces modèles sur le système financier, ainsi que le plan d’action de la Commission sur la cybersécurité et l’IA de juillet 2026.

La BCE y est citée pour un point précis : les établissements importants doivent traiter sans délai les constats de supervision ouverts sur les domaines TIC prioritaires. La déclaration ne fixe aucune échéance propre. Elle indique en revanche que les risques liés à l’IA seront intégrés aux méthodes de contrôle du plan de supervision 2027.

Quatorze actions en trois volets

L’annexe organise quatorze actions de réduction du risque, chacune avec des exemples allant d’un niveau de maturité de base à un niveau avancé.

Volet	Nombre d’actions	Exemples de mesures attendues
Prévention	7	Inventaire à jour des actifs, y compris composants IA/ML ; sécurité dès la conception ; correctifs automatisés sur les systèmes à risque ; réduction de la surface d’attaque
Détection	4	Analyse continue des vulnérabilités ; journalisation et surveillance comportementale ; fréquence accrue des tests ; SOC renforcé par l’IA
Gestion	3	Plans d’incident et de continuité pour défaillances multi-systèmes ; tests de résilience simulant des menaces assistées par l’IA ; suivi des dépendances

Ce que cela implique pour la gouvernance

La déclaration demande aux autorités de vérifier que l’organe de direction s’engage réellement : responsabilités claires, plans de réponse rapides, investissements suffisants en cyber-résilience et appétence au risque mise à jour avec des indicateurs propres à l’IA. Elle fait évoluer la supervision par l’organe de direction d’un rythme périodique vers une décision plus continue, appuyée par un suivi automatisé et des règles d’escalade.

Le principe de proportionnalité reste applicable : les mesures se calibrent selon la taille, le profil de risque et la complexité des activités.

Le risque de tiers au premier plan

Les autorités insistent sur la chaîne d’approvisionnement : évaluer et faire respecter les standards de cybersécurité chez les prestataires de services, les fournisseurs de matériel et de logiciels, y compris les communautés open source. Pour une banque, cela relie directement ce sujet au registre d’information DORA et à l’analyse de concentration.

Comment l’articuler avec DORA et le règlement sur l’IA

Les autorités rattachent le sujet à quatre piliers de DORA déjà applicables : le cadre de gestion du risque TIC, les tests, la gestion des incidents et de la reprise, et le risque lié aux prestataires TIC. Le règlement sur l’IA complète l’ensemble : il impose des obligations de transparence et de cybersécurité aux fournisseurs de modèles à usage général présentant un risque systémique. Concrètement, votre revue de conformité DORA devient le point d’entrée naturel : plutôt que de créer un chantier parallèle « IA », intégrez ces quatorze actions dans les plans existants de test, de continuité et de suivi des prestataires. Vérifiez aussi que le suivi des correctifs et des accès privilégiés, souvent déjà couvert, résiste à un rythme d’exploitation plus rapide.

Ce que ça change pour vous

Étendez votre inventaire d’actifs aux composants d’IA. Modèles, API, jeux de données et outils d’IA de vos fournisseurs doivent figurer dans la cartographie qui alimente votre registre DORA.
Ajoutez des scénarios assistés par l’IA à vos tests de résilience. Faites évoluer vos exercices pour tester des défaillances simultanées de plusieurs systèmes et des vulnérabilités découvertes plus vite.
Faites valider par l’organe de direction des indicateurs d’appétence au risque liés à l’IA. Fixez des seuils de tolérance et un circuit d’escalade documentés, et soldez vos constats de supervision ouverts.

Helios Advisory conçoit des parcours de formation pour les professionnels de la banque et de l’assurance : consultez nos formations pour préparer vos équipes à ces exigences.

Sources

ABE / AES, Page « Operational resilience » et déclaration JC 2026 25 sur les modèles d’IA de frontière, 31 juillet 2026.
ABE / AES, Déclaration JC 2026 25 (PDF), 31 juillet 2026.
Union européenne, Règlement (UE) 2022/2554 (DORA), EUR-Lex.