Conformité DORA, NIS2 et AI Act en un seul chantier, analyse

Une banque qui déploie de l’IA en Europe peut désormais tenir trois réunions de conformité sur le même système avant le déjeuner. Une équipe appelle cela la résilience opérationnelle. Une autre appelle cela la cybersécurité. Une troisième appelle cela la gouvernance de l’IA. Le modèle, malheureusement, ne se soucie pas du registre dans lequel on le place. Marco Eggerling, Field CISO chez UiPath, avance un argument plus pratique : traiter DORA, NIS2 et le règlement européen sur l’IA comme une seule mission de gouvernance. Dans des réponses écrites rapportées par The Fintech Times, il affirme que la question commune est de savoir si une institution peut prouver qu’elle contrôle un système qu’elle ne comprend pas entièrement de bout en bout. Ce n’est pas une question philosophique. C’est un problème d’achats, de journalisation, de réponse aux incidents et de reporting au conseil d’administration, portant trois badges différents.

Le chevauchement est précisément

le sujet, selon The Fintech Times et Digital Chiefs The Fintech Times présente le problème clairement : les banques qui déploient de l’IA en Europe opèrent sous DORA, la directive de cybersécurité NIS2 et le règlement européen sur l’IA en même temps. Le média note aussi le réflexe institutionnel bien connu qui consiste à attribuer à chaque régime son propre programme, son responsable et son registre. Eggerling soutient que c’est là que les difficultés commencent, car les cadres convergent vers la preuve de résilience et de contrôle plutôt que vers des esthétiques administratives séparées. Traduction : si votre système d’IA tombe en panne, fuit, dérive ou se comporte mal en production, le superviseur ne sera pas impressionné par le fait que l’incident ait été joliment dupliqué dans trois feuilles de calcul. Digital Chiefs place cette convergence sur un calendrier, en indiquant que DORA est en vigueur depuis janvier 2025, que les obligations à haut risque du règlement européen sur l’IA commencent en août 2026 et que l’application de NIS2 débute en octobre 2026. Les échéances exactes comptent moins que la réalité opérationnelle qu’elles créent. Les institutions financières n’ont pas droit à trois saisons de mise en œuvre bien séparées. Elles reçoivent des obligations qui se chevauchent et qui s’appliquent aux mêmes systèmes, fournisseurs et décideurs.

Une seule carte des contrôles vaut mieux que trois registres, selon

The Fintech Times The Fintech Times rapporte qu’Eggerling voit la gouvernance comme quelque chose qui dépasse le simple fait de cocher des cases une fois qu’un modèle est en production. Cette formule est utile. Les services juridiques peuvent conserver des citations séparées, mais les équipes d’ingénierie et de gestion des risques ont besoin d’une seule carte des systèmes, des dépendances, du comportement des modèles, des droits d’accès, des journaux d’audit, des chemins de gestion des incidents et des responsabilités des fournisseurs. Sinon, la même panne ou défaillance de modèle est examinée trois fois, généralement par des personnes qui posent des questions presque identiques dans des polices légèrement différentes. La version pratique ne consiste pas à fusionner les lois en une super-réglementation imaginaire. DORA parle toujours de résilience opérationnelle numérique, NIS2 d’obligations de cybersécurité et le règlement européen sur l’IA de gouvernance de l’IA. L’idée est de produire une fois des preuves communes et de les rattacher à chaque obligation pertinente. Pour un flux de travail d’IA en production, cela signifie une seule entrée d’inventaire, une seule lignée d’évaluation des risques, un seul dossier fournisseur, un seul plan de surveillance et une seule trace d’incident pouvant répondre à plusieurs régulateurs sans improvisation.

Le conseil d’administration est aussi concerné, selon

The Fintech Times et Digital Chiefs The Fintech Times indique qu’Eggerling se préparerait dès maintenant à ce que la culture IA au niveau du conseil d’administration devienne une attente de supervision. C’est la partie que beaucoup d’organisations classent sous « formation » et oublient jusqu’à la présentation annuelle. Un conseil d’administration n’a pas besoin d’affiner un modèle, mais il doit comprendre ce que fait le système, où il se situe dans les opérations critiques et à quoi ressemblerait une défaillance. Si la seule personne capable d’expliquer l’environnement de contrôle de l’IA est l’architecte solution du fournisseur, ce n’est pas de la gouvernance. C’est de l’externalisation avec du papier à en-tête plus élégant. Digital Chiefs ajoute une dimension plus ferme, en affirmant que NIS2 et DORA tiennent les dirigeants et les membres du conseil d’administration personnellement responsables des défaillances de cybersécurité en cas de négligence grave. Cela ne signifie pas que chaque mauvaise alerte devient une crise du conseil. Cela signifie que les administrateurs devraient demander des preuves qu’ils peuvent comprendre avant l’incident, et non après que les juristes ont commencé à utiliser le mot posture dans chaque phrase. Dans cette lecture, la culture IA du conseil d’administration n’est pas un certificat de webinaire. C’est la capacité de demander si l’empilement de contrôles correspond au risque opérationnel.

Ce que les bâtisseurs devraient changer dès maintenant, selon

The Fintech Times Pour les bâtisseurs, la réponse ennuyeuse est la bonne : faire de la conformité une exigence d’architecture. The Fintech Times rapporte qu’Eggerling se concentre sur ce à quoi ressemble le contrôle une fois qu’un modèle est en production, c’est-à-dire là où de nombreux programmes de gouvernance de l’IA cessent d’être de simples diapositives et commencent à toucher aux journaux, aux alertes et aux contrats. Si une banque utilise l’automatisation ou l’IA dans un flux de travail réglementé, l’équipe produit devrait savoir quelles preuves sont générées automatiquement et lesquelles dépendent encore du fait que quelqu’un se souvienne de mettre à jour un registre un vendredi. La liste de vérification utile est assez courte pour survivre au contact avec l’ingénierie. Identifiez le système d’IA et sa fonction métier. Cartographiez ses dépendances opérationnelles, ses contrôles de cybersécurité, ses contrôles de gouvernance des modèles et les responsabilités des tiers. Décidez quelles preuves peuvent soutenir ensemble les obligations de DORA, de NIS2 et du règlement sur l’IA. Puis testez le chemin de gestion des incidents, car le premier véritable audit arrive souvent déguisé en panne. La leçon contre-intuitive du Field CISO d’UiPath n’est pas que l’Europe a rendu la conformité simple. Ce n’est pas le cas. La leçon est que les règles qui se chevauchent punissent davantage les opérations en silos qu’une cartographie soigneuse. Pour les lecteurs qui construisent ou achètent de l’IA dans des secteurs réglementés, la prochaine question utile n’est pas de savoir quelle loi possède le problème. C’est de savoir si votre trace de preuves peut survivre au fait qu’on lui pose la même question de trois manières différentes.