DORA et agents IA : ce que l’ACPR attend d’une entité financière
En France, l’ACPR, l’Autorité de contrôle prudentiel et de résolution, supervise les banques et les assureurs, et vérifie donc l’application de DORA, le règlement (UE) 2022/2554, en vigueur pour les entités financières depuis le 17 janvier 2025. Cet article ne prête à l’ACPR aucune position sur les agents IA : il part du texte de DORA et en tire ce qu’un superviseur est en droit d’examiner quand un agent IA soutient une fonction de votre établissement. Sur DORA et agents IA, la question n’est pas de savoir si le règlement s’applique. Il s’applique déjà, sans attendre l’AI Act, le règlement européen sur l’intelligence artificielle. La question est de savoir si votre cadre de gestion du risque TIC, votre registre d’informations, votre processus d’incidents et votre programme de tests savent que l’agent existe. Ce texte s’adresse au responsable de la gouvernance de l’IA, au RSSI et au responsable des risques.
Pourquoi un agent IA est un risque TIC au sens de DORA
DORA ne mentionne pas l’intelligence artificielle. Il n’en a pas besoin : ses définitions couvrent tout logiciel du système d’information d’une entité financière. La première est celle du risque TIC. Le texte anglais dit :
‘ICT risk’ means any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology dependent tool or process, of operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment (Article 3(5))
Une réponse fausse, une action que l’agent n’aurait pas dû prendre, une indisponibilité : chacune de ces circonstances est identifiable à l’avance et peut compromettre un processus ou un service. C’est la définition du risque TIC. L’article 3(7) définit ensuite l’actif TIC comme un actif logiciel ou matériel dans le système d’information de l’entité financière : l’agent en est un. L’article 3(8) définit l’incident lié aux TIC. Le texte anglais dit :
‘ICT-related incident’ means a single event or a series of linked events unplanned by the financial entity that compromises the security of the network and information systems, and have an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity (Article 3(8))
Une panne, une fuite de données par une réponse, un appel d’outil qui modifie un dossier client à tort : chacun de ces événements entre dans cette définition. Enfin, l’éditeur du modèle, l’hébergeur et l’outil d’observabilité fournissent des services TIC. Au sens de l’article 3(19), ce sont des prestataires TIC tiers.
Une fois ces étiquettes posées, le reste du règlement suit. L’article 8 vous demande d’inventorier l’agent, son modèle, ses outils et ses données, de cartographier leurs interdépendances et de tenir cet inventaire à jour. L’article 9(4)(e) exige une gestion des changements documentée : une nouvelle version du modèle, un nouvel outil ou un prompt système réécrit sont des changements d’un système TIC, à enregistrer, tester, évaluer et approuver.
Les fonctions critiques ou importantes
La notion qui décide de l’intensité des obligations est celle de fonction critique ou importante. Le texte anglais dit :
‘critical or important function’ means a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law (Article 3(22))
C’est votre entité qui qualifie la fonction et qui documente cette qualification. Le traitement des sinistres, l’entrée en relation et le KYC, la souscription, les opérations de paiement en sont des exemples typiques. Un agent qui soutient l’une de ces fonctions hérite de sa criticité. Un agent derrière une fonction non critique reste dans le cadre de gestion du risque TIC, avec des attentes plus légères.
La qualification a des conséquences précises. L’article 28(3) impose de distinguer dans le registre d’informations les accords qui soutiennent une fonction critique ou importante, et d’informer l’autorité compétente de tout projet d’accord de ce type et du moment où une fonction devient critique ou importante. L’article 12(6) demande que les objectifs de rétablissement de chaque fonction tiennent compte de sa criticité. L’article 24(6) impose des tests au moins annuels sur tous les systèmes qui soutiennent ces fonctions, et l’article 26(2) y fait porter les tests de pénétration fondés sur la menace, y compris chez les prestataires TIC tiers.
Le registre d’informations et les prestataires derrière l’agent
Un agent IA ne tourne jamais seul : un éditeur de modèle, un hébergeur, souvent un outil d’observabilité. DORA place chacun d’eux dans un même instrument. Le texte anglais dit :
As part of their ICT risk management framework, financial entities shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. ... Financial entities shall make available to the competent authority, upon its request, the full register of information or, as requested, specified sections thereof, along with any information deemed necessary to enable the effective supervision of the financial entity. (Article 28(3))
Pour chaque prestataire derrière l’agent, le registre attend la raison sociale, le code d’identification, le pays, le type de service TIC, la fonction soutenue et sa criticité, la localisation des données et les conditions contractuelles.
Le registre n’est que le point d’arrivée. L’article 28(4) exige, avant tout accord, une diligence sur le prestataire et l’évaluation des risques, dont le risque de concentration : un prestataire difficile à remplacer, une sous-traitance en chaîne, un prestataire établi dans un pays tiers. Si l’éditeur du modèle cesse son service, combien de temps faut-il pour basculer, et l’avez-vous testé ? L’article 28(8) exige une stratégie de sortie pour tout service qui soutient une fonction critique ou importante.
Le contrat doit enfin porter les clauses de l’article 30 : la localisation des données et, pour une fonction critique ou importante, des niveaux de service chiffrés, la participation du prestataire à vos tests de pénétration fondés sur la menace, des droits d’accès, d’inspection et d’audit pour votre entité et pour l’autorité compétente, et une période de transition en cas de sortie.
Incidents et tests de résilience
L’article 17 vous demande un processus qui détecte, gère et notifie les incidents liés aux TIC, les enregistre tous, documente les causes profondes et les classe selon leur priorité, leur gravité et la criticité des services touchés. L’article 18(1) fixe les critères : clients et contreparties touchés, durée, étendue géographique, pertes de données, criticité des services, impact économique. L’article 19 impose de notifier les incidents majeurs à l’autorité compétente par une notification initiale, un rapport intermédiaire et un rapport final, et d’informer les clients dont les intérêts financiers sont touchés. Ce processus ne fonctionne pour un agent que si les seuils de classification le nomment.
Les tests forment le second pilier. L’article 24 exige un programme de tests de résilience opérationnelle numérique intégré au cadre de gestion du risque TIC et confié à des parties indépendantes. L’article 26 ajoute, pour les entités que l’autorité compétente identifie, des tests de pénétration fondés sur la menace au moins tous les trois ans, sur un périmètre validé par l’autorité compétente.
Un agent IA appelle une famille de tests que la plupart des programmes n’incluent pas encore : des tests adverses sur son comportement. Un test, que nous appelons sonde, envoie à l’agent en service un prompt écrit à partir d’une obligation précise et enregistre la réponse et les appels d’outil. Ce n’est pas une mission de red teaming contre votre infrastructure, et cela ne la remplace pas. Il vérifie que l’agent, face à une demande hostile, ne divulgue pas de données et ne sort pas de son périmètre.
Ce qu’un superviseur examine
Nous ne citons aucune position de l’ACPR : le texte de DORA dit lui-même ce qu’une autorité compétente peut demander, et l’ACPR est cette autorité pour les banques et les assureurs. Le texte anglais dit :
They shall provide complete and updated information on ICT risk and on their ICT risk management framework to the competent authorities upon their request. (Article 6(3))
Le reste du règlement précise la liste : le rapport de revue du cadre de gestion du risque TIC (article 6(5)), le registre d’informations, complet ou par sections, et l’information préalable sur tout accord soutenant une fonction critique ou importante (article 28(3)), le périmètre des tests de pénétration fondés sur la menace, que l’autorité valide, puis la synthèse des constats et les plans de remédiation (article 26), des droits d’accès, d’inspection et d’audit chez le prestataire (article 30(3)(e)), et la responsabilité finale de l’organe de direction (article 5).
Pour un agent IA, cela se traduit en six questions. Où l’agent figure-t-il dans l’inventaire des actifs TIC, et avec quel responsable ? Quelle fonction soutient-il et qui a qualifié sa criticité ? Quels prestataires sont derrière lui et que dit le registre pour chacun ? Quels seuils déclenchent la notification d’un incident qui l’implique ? Quand a-t-il été testé, par qui, et qu’a-t-on corrigé ? Quels objectifs de rétablissement lui sont attribués ? Un dossier qui répond par des preuves datées, plutôt que par une politique générique qui ne nomme pas l’agent, est ce qu’un superviseur est en droit d’attendre.
Un dossier unique pour DORA et l’AI Act
L’AI Act regarde le même agent sous un autre angle. Un assistant qui dialogue avec des personnes doit, depuis le 2 août 2026, les informer qu’elles s’adressent à un système d’IA, au titre de l’article 50. Un agent qui soutient l’évaluation de la solvabilité des personnes physiques, ou la tarification en assurance vie et santé, relève de l’annexe III, et les obligations à haut risque s’appliquent à ces systèmes à partir du 2 décembre 2027. Parmi elles, l’article 12 exige l’enregistrement automatique des événements sur toute la durée de vie du système, l’article 14 exige le contrôle humain, avec des personnes capables d’ignorer ou d’annuler la sortie du système et de l’arrêter dans un état sûr, et l’article 73 impose au fournisseur de notifier les incidents graves à l’autorité de surveillance du marché.
Les recoupements sont nets. Le journal qui reconstitue un incident lié aux TIC pour DORA est celui qui assure la traçabilité exigée par l’article 12. Le bouton d’arrêt de l’article 14 est aussi une mesure de confinement au sens de l’article 11(2) de DORA. Un même événement peut déclencher deux notifications, à deux autorités, sur une seule analyse des causes. Deux dossiers séparés produisent deux fois les mêmes preuves, avec le risque qu’elles se contredisent.
Un dossier unique s’organise autour de l’agent. Pour DORA, il porte une liste de contrôle de quinze contrôles en cinq familles, gestion du risque TIC, prestataires TIC, incidents, tests de résilience, continuité, évaluée sur votre déclaration et vos preuves, plus des tests comportementaux tirés du texte de DORA, et un export des lignes du registre d’informations pour chaque prestataire derrière l’agent. Pour l’AI Act, il porte les tests adverses écrits à partir des articles applicables, avec le prompt, les appels d’outil, la réponse et le verdict, confirmés par un relecteur, la personne qui valide. Ce sont des évaluations indicatives, sous réserve d’une revue humaine. Vidimus n’est ni un organisme notifié ni un organisme d’évaluation de la conformité, aucune norme harmonisée n’a encore été citée au Journal officiel, et rien dans ce dossier ne constitue un conseil juridique.
Vidimus construit ce dossier pour un agent à la fois : les tests sont exécutés contre l’agent en service, les appels d’outil enregistrés, chaque réponse notée par un modèle de notation distinct, un relecteur confirme, puis un dossier de preuves versionné et signé est émis. Un pilote prend environ deux semaines pour un agent. Pour voir comment l’évaluation DORA se déroule, consultez la page solution DORA.