Nous utilisons des cookies pour la mesure d’audience et la mesure de nos annonces Google Ads. Rien n’est chargé avant votre accord. Politique de cookies

Réglementation & gouvernance

DORA + AI Act : ce que doivent les acteurs CSSF

Mis à jour le Laurent Tousch13 min de lectureDEFREN

DORA + AI Act : ce que doivent les acteurs CSSF

Dernière vérification : 12 septembre 2026.

Deux règlements se superposent à toute initiative d'IA dans un acteur financier luxembourgeois : le règlement sur la résilience opérationnelle numérique (DORA), pleinement applicable depuis le 17 janvier 2025, et l'AI Act. La plupart des entités supervisées par la CSSF et des assureurs régulés par le CAA — y compris ceux qui déploient de l'IA en sinistres, souscription et détection de fraude — les traitent comme deux chantiers de conformité distincts, avec deux budgets et deux calendriers. C'est la manière coûteuse de procéder.

Les dates de l'AI Act ont changé en juillet 2026

Si votre programme est calé sur le 2 août 2026, replanifiez-le. L'omnibus numérique sur l'IA — règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026 — a réécrit les dates d'application :

Obligation AI ActS'applique
Pratiques interdites de l'article 5 ; culture de l'IA de l'article 4Depuis le 2 févr. 2025 (deux nouvelles interdictions au 2 déc. 2026)
Obligations GPAI ; régime de sanctions de l'article 99Depuis le 2 août 2025 (pouvoirs de sanction GPAI de la Commission depuis le 2 août 2026)
Transparence de l'article 50Depuis le 2 août 2026 — marquage lisible par machine des systèmes génératifs préexistants d'ici le 2 déc. 2026
Systèmes autonomes à haut risque de l'annexe III2 déc. 2027 (auparavant 2 août 2026)
IA intégrée aux produits de l'annexe I section A2 août 2028 (auparavant 2 août 2027)

Pour une banque ou un assureur luxembourgeois, cela change le séquencement mais pas la destination. L'obligation vivante aujourd'hui est l'article 50 : votre chatbot client, votre canal vocal, toute communication client générée par IA. Le travail lourd — le modèle de scoring de crédit, le moteur de souscription vie et santé — court vers décembre 2027, et il a besoin de presque tout ce temps.

Ce guide explique où DORA et l'AI Act se recoupent, où ils divergent, et comment séquencer le travail pour payer les contrôles sous-jacents une seule fois.

Pourquoi ces deux règlements appartiennent à la même conversation

DORA et l'AI Act ont été rédigés par des équipes différentes à Bruxelles, pour des raisons différentes. DORA est un règlement de résilience TIC propre au secteur financier : faire tourner la plomberie numérique, contenir les incidents, maîtriser les dépendances aux tiers. L'AI Act est un règlement horizontal de sécurité des produits : classer le risque des systèmes d'IA et encadrer ceux à haut risque par la documentation, les tests et la supervision humaine.

Mais pour une banque, un administrateur de fonds, un assureur ou un PSF luxembourgeois, les deux régimes convergent vers les mêmes artefacts :

  • un inventaire de chaque système d'IA en production ;
  • une classification du risque par système ;
  • une description de chaque fournisseur tiers apportant des composants d'IA ;
  • un plan de réponse aux incidents couvrant les défaillances d'IA ;
  • une piste d'audit des décisions du modèle et des écartements humains ;
  • un processus de surveillance et de notification à l'autorité compétente (CSSF pour DORA, surveillance du marché pour l'AI Act, CNPD lorsque des données personnelles sont en jeu).

Vous pouvez construire ces artefacts deux fois — une fois dans votre registre DORA, une autre dans votre dossier technique AI Act — et voir votre facture de conformité doubler. Ou bâtir un référentiel unique satisfaisant les deux.

Les quatre terrains de recoupement réel

1. Gestion du risque tiers. Sous DORA, tout « prestataire tiers de services TIC » doit être inventorié, lié contractuellement à des standards de résilience précis, et testé en sortie. Chaque fournisseur d'IA externe — votre fournisseur de modèle, votre plateforme d'orchestration, votre environnement d'hébergement — entre dans cette définition. Sous l'AI Act, ces mêmes fournisseurs font partie de votre chaîne fournisseur/déployeur, et vous leur devez une documentation. Construisez un registre fournisseurs unique, étiquetez-le des deux vues réglementaires, et le travail est fait une fois.

Au Luxembourg, ce dossier doit également satisfaire la circulaire CSSF 22/806 sur les accords d'externalisation, telle que modifiée par la circulaire CSSF 25/883. La CSSF a réaligné son corpus autour de DORA au cours de 2025 (circulaires 25/880 et 25/882) précisément pour séparer les obligations DORA des autres — établissez de quel côté se situe votre accord avant de construire le dossier, car les exigences diffèrent.

2. Notification d'incidents. DORA impose la notification des incidents TIC majeurs à la CSSF dans des délais stricts. L'AI Act ajoute un devoir de signaler les incidents graves liés à l'IA (dysfonctionnements, résultats biaisés causant un préjudice). Pour une banque luxembourgeoise, les deux signalements couvrent souvent le même événement sous-jacent. Une taxonomie unique de classification des incidents, cartographiée vers les deux régimes, est bien plus propre que deux processus parallèles.

3. Continuité et tests de résilience. DORA impose les tests de pénétration fondés sur la menace (TLPT) et les tests de résilience opérationnelle numérique. L'AI Act impose de tester les systèmes à haut risque pour l'exactitude, la robustesse et la cybersécurité. Les méthodologies se recoupent sérieusement : soumettre un système d'IA à une équipe rouge pour des entrées adverses satisfait une partie des deux régimes — et une bonne part du recoupement NIS2 / AI Act si NIS2 vous concerne également.

4. Supervision humaine et responsabilité. Les deux régimes exigent au bout du compte une personne physique nommément responsable du système. DORA veut un propriétaire TIC au niveau de la direction ; l'article 26 de l'AI Act veut, côté déployeur, une personne dotée de la compétence, de la formation et de l'autorité pour exercer la supervision. Dans une PME ou une entreprise de taille moyenne luxembourgeoise, c'est en général la même personne. Documentez-la comme un rôle unique portant deux casquettes réglementaires.

La consolidation est explicitement permise. L'article 9(10) de l'AI Act autorise à intégrer le système de gestion des risques exigé pour l'IA à haut risque dans les procédures de gestion des risques qu'une entité financière maintient déjà au titre du droit de l'Union sur les services financiers — y compris le cadre de gestion du risque TIC qu'elle exploite sous DORA. Ce n'est pas une interprétation de zone grise : c'est écrit dans le règlement. Les acteurs qui bâtissent un registre des risques IA séparé, de zéro, choisissent de faire le travail deux fois.

Où DORA et l'AI Act divergent

Il est tout aussi important d'être clair sur ce qui ne se recoupe pas, pour éviter les rapprochements forcés :

  • La logique de classification diffère. DORA hiérarchise vos services par criticité. L'AI Act hiérarchise vos systèmes d'IA par cas d'usage. Un « service non critique » au sens de DORA peut parfaitement contenir un « système d'IA à haut risque » au sens du règlement (un outil de tri RH utilisé en interne, par exemple).
  • DORA couvre toutes les TIC, pas seulement l'IA. L'essentiel de votre travail DORA porte sur votre core banking, votre plateforme de négociation, votre système de conservation. L'IA n'en est qu'une tranche.
  • L'AI Act couvre toute l'IA, pas seulement la finance. Un chatbot sur votre site public déclenche les obligations de transparence indépendamment de DORA.
  • Les autorités de notification diffèrent. Les signalements DORA vont à la CSSF (ou au CAA pour les assureurs). Ceux de l'AI Act vont à l'autorité nationale de surveillance du marché — qui, selon le projet de loi n° 8476, serait par défaut la CNPD, la CSSF conservant les systèmes d'IA relevant de son périmètre financier existant et le CAA l'assurance. Le projet était encore en procédure parlementaire au moment de la rédaction ; attendez-vous donc, pour l'instant, à ce que les questions arrivent d'abord par votre relation de supervision habituelle.

Vous préférez trancher cela en une conversation ? Réservez un appel gratuit de 30 minutes — apportez votre cas d'usage et nous le parcourrons ensemble, en langage clair.

La précision de classification, avant toute chose

Pour un acteur financier luxembourgeois, on perd plus d'argent par mauvais cadrage que par sous-cadrage. Quatre déterminations décident de la taille du programme :

  • Scoring de crédit de personnes physiques — annexe III point 5(b). Haut risque à partir du 2 décembre 2027. Et une analyse d'impact sur les droits fondamentaux (AIDF) au titre de l'article 27 vous incombe en tant que déployeur, privé ou non : les déployeurs visés aux points 5(b) et 5(c) sont nommés à l'article 27(1) aux côtés des organismes publics.
  • Évaluation et tarification du risque en assurance vie et santé — annexe III point 5(c). Haut risque, AIDF applicable. La tarification auto, dommages et responsabilité civile est hors de cette rubrique. Ne cadrez pas tout le portefeuille.
  • Détection de fraude — expressément exclue de l'annexe III 5(b). Non qualifiée de haut risque à ce titre. Les modèles internes de LBC/FT et d'adéquation des fonds propres relèvent du droit sectoriel, pas de l'annexe III. Le piège est la chaîne hybride où la logique de scoring de crédit et la détection d'anomalies sont architecturalement indissociables — présumez alors l'inclusion.
  • Chatbots et canaux vocaux destinés aux clients — non qualifiés de haut risque, mais pleinement dans le champ de l'article 50, exigible maintenant. C'est le premier contact d'application le plus probable, parce qu'un chatbot non déclaré se voit de l'extérieur de l'entreprise.

Le filtre de l'article 6(3) peut sortir du champ un système pourtant listé lorsqu'il ne présente pas de risque significatif de préjudice — mais jamais lorsqu'il profile des personnes physiques, ce qui exclut la plupart des applications de crédit et de souscription. Lorsque vous vous en prévalez, l'évaluation doit être documentée et enregistrée.

Le séquencement qui vous fait économiser

Étape 1 — Fermez l'article 50 maintenant. Il est en vigueur. Parcourez chaque surface d'IA exposée au client, vérifiez que l'information figure dès la première interaction en FR / DE / EN, et documentez qui a validé la responsabilité éditoriale des communications clients générées par IA. Une demi-journée à une semaine, et cela referme la seule exposition actuellement applicable.

Étape 2 — Construisez l'inventaire unifié. Chaque système d'IA de la maison, du modèle de détection de fraude en production jusqu'à l'abonnement ChatGPT de l'équipe marketing. Pour chacun : propriétaire métier, fournisseur, données d'entrée, impact décisionnel, rôle fournisseur ou déployeur, et classe AI Act (interdit / haut risque / filtré par l'article 6(3) / limité / minimal). Cet inventaire unique alimente votre registre TIC DORA, votre dossier d'externalisation 22/806 et vos enregistrements AI Act.

Étape 3 — Classez et priorisez face à décembre 2027. Les systèmes à haut risque sont la contrainte. Pour chacun, vous devez un processus de gestion des risques (intégré à votre cadre DORA au titre de l'article 9(10)), une gouvernance des données, une documentation technique conforme à l'annexe IV, une journalisation, la transparence, une conception de la supervision humaine, des tests d'exactitude et de robustesse, une surveillance après commercialisation et — pour les déployeurs 5(b) et 5(c) — une AIDF. Cela représente douze à dix-huit mois de travail réel par système complexe, pas une liste à cocher.

Étape 4 — Modélisez une fois, réutilisez partout. Un seul jeu de modèles — évaluation des risques, fiche de modèle, AIPD, manuel d'incident, procédure de surveillance, questionnaire de diligence fournisseur — satisfaisant simultanément DORA, l'AI Act, la circulaire 22/806 et le RGPD. La plupart des acteurs luxembourgeois que nous accompagnons finissent avec une douzaine de documents réutilisables couvrant 80 % des obligations récurrentes.

Étape 5 — Opérationnalisez la surveillance. La conformité devient une discipline d'exploitation continue, pas un projet : revue trimestrielle de la performance des modèles, cycle annuel de tests DORA, réévaluation continue des fournisseurs, et un reporting du taux d'écartement qui prouve que votre supervision humaine est réelle et non décorative.

Pour approfondir le versant AI Act, voir notre guide de ce qui s'applique réellement aujourd'hui.

Ce que la CSSF a réellement dit sur l'IA

Il n'existe pas de circulaire CSSF dédiée à l'intelligence artificielle. Les attentes prudentielles passent par deux revues thématiques conjointes CSSF / BCL sur l'usage de l'IA dans le secteur financier luxembourgeois : la première publiée en mai 2023, couvrant les établissements de crédit, les établissements de monnaie électronique et les établissements de paiement ; la seconde en mai 2025, nettement plus large, ajoutant les entreprises d'investissement et les gestionnaires de fonds d'investissement alternatifs agréés — soit une participation plus que triplée.

Le message constant des deux éditions : gouvernance, supervision humaine et explicabilité doivent être démontrables pour toute solution d'IA sur laquelle s'appuie une entité supervisée. C'est le même triptyque que codifie l'AI Act, ce qui tombe bien — les preuves construites pour l'un servent l'autre. Lisez les deux rapports ; c'est ce qui ressemble le plus à un corpus CSSF sur l'IA, et ils vous disent ce que votre superviseur demande déjà à vos pairs.

Trois modes d'échec à éviter

Nous voyons les mêmes trois erreurs revenir chez les acteurs financiers luxembourgeois :

Considérer DORA comme « fait » parce que l'échéance de janvier 2025 est passée. DORA est un régime d'exploitation continue, pas une certification ponctuelle. Vos déploiements d'IA depuis janvier 2025 devraient déjà figurer dans votre registre TIC DORA ; si ce n'est pas le cas, corrigez-le avant d'empiler le travail AI Act par-dessus.

Confier le travail AI Act au seul service juridique. L'AI Act est un règlement autant technique que juridique. Des juristes ne peuvent pas rédiger un dossier technique sérieux sans apport d'ingénierie. Un groupe de travail conjoint juridique + ingénierie + risque est la seule structure qui livre des systèmes conformes dans les délais.

Sous-estimer le périmètre des tiers. Chaque fournisseur d'IA de votre pile déclenche des avenants contractuels DORA, une documentation d'externalisation 22/806 et des preuves de chaîne d'approvisionnement AI Act. Avec cinq fournisseurs d'IA ou plus, prévoyez 4 à 8 semaines pour la seule remédiation contractuelle.

Lire le report comme une dispense. C'est le mode d'échec nouveau, et il coûtera à plusieurs acteurs luxembourgeois leur date de décembre 2027. Les obligations haut risque ont bougé de seize mois ; un premier dossier haut risque en prend douze à dix-huit. Le report vous a acheté le temps que le travail exige, pas du temps libre.


Situez votre empreinte IA réelle — face aux vraies dates

L'évaluation de préparation à l'AI Act de 20 More, calibrée pour les entités supervisées par la CSSF et les assureurs régulés par le CAA. Dix jours ouvrés, périmètre fixe :

  1. L'inventaire IA unifié — chaque système et chaque fonction d'IA de la maison, structuré pour que les mêmes lignes servent votre registre TIC DORA, votre dossier d'externalisation 22/806 et vos enregistrements AI Act. Un référentiel, trois vues réglementaires.
  2. La détermination de classification — fournisseur ou déployeur par système ; annexe III 5(b) / 5(c) dans le champ ou hors champ ; modèles de détection de fraude et de LBC/FT correctement exclus ; filtre de l'article 6(3) évalué et documenté le cas échéant ; AIDF de l'article 27 signalée lorsqu'elle vous incombe.
  3. Le rapport d'écart article 50 — les informations légalement dues aujourd'hui sur vos canaux clients, rattachées aux parcours de chatbot, aux scripts vocaux et aux communications clients qui en sont dépourvus.
  4. Un plan chiffré jusqu'au 2 décembre 2027 — rapporté à votre dispositif de contrôle DORA existant, montrant explicitement quelles obligations AI Act vous pouvez satisfaire par l'intégration de l'article 9(10) et lesquelles exigent un travail neuf, dans une note d'une page pour votre comité des risques.

Nous déployons également des systèmes d'IA pour des acteurs financiers luxembourgeois sur une infrastructure hébergée dans l'UE, avec la documentation DORA, AI Act et RGPD produite en parallèle de la construction, et non ajoutée après coup.

→ Voir le service de préparation à l'AI Act, ou réserver une consultation gratuite de 30 minutes. Nous ferons un appel d'inventaire rapide et vous dirons honnêtement si vous êtes dans les temps ou en retard — sans théâtre commercial.

À lire également :