Obligations DORA des fournisseurs d'IA au service des entités financières

Les obligations DORA des fournisseurs d'IA désignent les exigences réglementaires du règlement (UE) 2022/2554 (Digital Operational Resilience Act) que les entités financières donneuses d'ordre répercutent contractuellement sur leurs fournisseurs d'IA. Quiconque fournit des systèmes d'IA à des banques, des assureurs ou des prestataires de services de paiement est considéré comme prestataire tiers de services TIC et doit respecter des contenus contractuels minimaux, des droits d'audit et d'accès, des contributions à la notification des incidents ainsi que des règles de sortie et de sous-traitance. DORA est applicable depuis le 17 janvier 2025.

• Pas directement, mais avec un effet complet : DORA ne réglemente pas les fournisseurs d'IA de manière directe, mais oblige les entités financières à leur répercuter contractuellement l'ensemble des exigences.
• L'IA relève des TIC : les systèmes d'IA sont des réseaux et systèmes d'information au sens de l'article 3, point 2, de DORA, ce qui déclenche l'ensemble des obligations. La BaFin l'a explicitement précisé dans son guide d'orientation du 18 décembre 2025.
• Le levier, c'est le contrat : sans clauses conformes à DORA (art. 30), les fournisseurs d'IA n'atteignent généralement pas le dernier tour de sélection dans les appels d'offres BFSI en Allemagne et en Autriche.

Pourquoi DORA s'impose aux fournisseurs d'IA

Formellement, DORA s'adresse aux entités financières soumises à surveillance. L'article 2, paragraphe 1, points a) à t), de DORA énumère 20 types d'entités financières, notamment les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d'investissement, les prestataires de services sur crypto-actifs, les entreprises d'assurance et les institutions de retraite professionnelle. Les fournisseurs d'IA ne sont pas réglementés directement, mais sont couverts en tant que prestataires tiers de services TIC. Le mécanisme est indirect, mais efficace : les entités financières sont tenues de répercuter contractuellement les exigences de DORA sur leurs fournisseurs. Quiconque vend à un établissement réglementé un algorithme de détection de fraude, un assistant pour les collaborateurs basé sur le RAG ou un modèle de souscription hérite donc des obligations par le biais du contrat.

Les systèmes d'IA sont des TIC au sens de DORA. Dans son guide d'orientation sur les risques TIC liés à l'utilisation de l'IA dans les entités financières du 18 décembre 2025, la BaFin traite un système d'IA comme un réseau et système d'information au sens de l'article 3, point 2, de DORA. Les obligations découlent de DORA lui-même, pas du guide d'orientation. Selon ses propres termes, celui-ci est une aide non contraignante et non une interprétation obligatoire de DORA par la BaFin, mais il montre comment la BaFin transpose les exigences de DORA aux systèmes d'IA. L'ensemble des obligations de DORA s'applique aux systèmes d'IA :

• Art. 5-15 : gestion du risque lié aux TIC
• Art. 17-23 : gestion, classification et notification des incidents liés aux TIC
• Art. 24-27 : tests de résilience, y compris le Threat-Led Penetration Testing (TLPT)
• Art. 28-30 : gestion du risque lié aux prestataires tiers de services TIC

En Suisse, la Communication FINMA sur la surveillance 08/2024 du 18 décembre 2024 joue un rôle fonctionnellement comparable, sans être entièrement alignée sur la ligne de la BaFin. En Autriche, selon l'état des recherches sur lesquelles s'appuie cet article (mai 2026), il n'existe aucune ligne directrice sectorielle formelle de la FMA sur l'IA ; dans la pratique, les établissements autrichiens s'alignent sur la BaFin et l'EBA.

Les cinq blocs d'obligations en détail

Pour les fournisseurs d'IA, DORA se concrétise surtout dans le régime applicable aux prestataires tiers (art. 28-30) et dans le catalogue de clauses contractuelles de l'article 30. Le tableau suivant traduit les exigences centrales en conséquences concrètes pour les fournisseurs d'IA.

Contenus contractuels minimaux et droits d'audit

Le catalogue de clauses contractuelles de l'article 30 en constitue le cœur pratique. Il exige des droits d'audit obligatoires, des clauses de sortie, des contrôles des sous-traitants ainsi que des accords de niveau de service avec des engagements de résidence des données, de latence et de capacité de calcul. Concrètement, pour les fournisseurs d'IA, l'architecture doit être conçue dès le départ pour que chaque inférence puisse être journalisée de manière inaltérable et auditable. Lors des contrôles prudentiels spéciaux, l'autorité de surveillance attend qu'une personne responsable en interne puisse reproduire la sortie de l'IA et en nommer les facteurs déterminants. En pratique, cela exclut les modèles purement de type boîte noire dans les rôles proches de la décision.

Notification des incidents

Dans le contexte BFSI, les défaillances propres à l'IA sont traitées comme des risques opérationnels et peuvent devoir être notifiées. L'ordre de grandeur montre l'enjeu : rien qu'à la BaFin, 525 incidents majeurs liés aux TIC au total ont été signalés au cours des trois premiers trimestres 2025, dont environ 70 % par des établissements de crédit. Les fournisseurs d'IA sont rarement eux-mêmes soumis à l'obligation de notification, mais doivent garantir contractuellement et techniquement que l'entité financière reçoive à temps les informations nécessaires.

Stratégies de sortie et sous-traitance

Pour les services TIC qui soutiennent des fonctions critiques ou importantes, les plans de sortie doivent être testés de manière adéquate et réexaminés régulièrement conformément à l'article 28, paragraphe 8, de DORA ; combiné à la désignation des CTPP, cela impose de fait des stratégies multicloud. Pour les fournisseurs d'IA, il s'agit de démontrer la portabilité des données, des processus de transfert documentés et la réversibilité. En matière de sous-traitance, toute la chaîne doit être divulguée et contrôlable, ce qui compte particulièrement lorsqu'un fournisseur d'IA achète lui-même à des tiers de l'inférence de modèles de fondation, des bases de données vectorielles ou de la capacité GPU.

Risque de concentration et les 19 CTPP

Le 18 novembre 2025, les autorités européennes de surveillance ou AES (EBA, EIOPA, ESMA) ont désigné pour la première fois 19 prestataires tiers critiques de services TIC (CTPP), dont AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix et Bloomberg (liste des AES). Ces 19 prestataires sont soumis à une surveillance directe de l'UE à partir de 2026. Pour chaque CTPP, la surveillance est assurée par un superviseur principal (Lead Overseer), c'est-à-dire l'EBA, l'EIOPA ou l'ESMA. L'Oversight Forum prévu à l'article 32 de DORA prépare des positions communes et évalue les résultats, mais ne contrôle pas lui-même les prestataires. Les recommandations du Lead Overseer ne sont pas contraignantes. Le CTPP doit toutefois indiquer dans un délai de 60 jours civils s'il les suit, ou expliquer pourquoi il ne le fait pas (article 42 de DORA). Pour les fournisseurs d'IA dont les charges de travail tournent chez l'un de ces prestataires, cela signifie une attention accrue et un risque de concentration renforcé côté donneur d'ordre. En 2025, le BSI a par ailleurs publié un catalogue de critères d'évaluation pour les systèmes d'IA dans le secteur financier (Test Criteria Catalogue for AI Systems in Finance). Il évalue les systèmes d'IA notamment selon la robustesse, l'équité, la transparence, la qualité des données et la sécurité informatique, et peut servir de grille pour l'évaluation des fournisseurs.

Pour bien situer le sujet : les orientations de l'EBA relatives à l'externalisation (EBA/GL/2019/02) et les orientations de l'ESMA sur l'externalisation (ESMA50-164-4285) restent applicables, mais ont été substantiellement modifiées par les articles 28 à 30 de DORA. DORA n'est donc pas le seul régime applicable aux prestataires tiers, mais c'est le régime de référence.

Cas pratique : un agent de connaissances IA dans l'appel d'offres d'une banque de taille moyenne

Un fournisseur d'IA propose à un établissement allemand de taille moyenne (total de bilan dans le bas de la fourchette des dizaines de milliards) un assistant pour les collaborateurs basé sur le RAG, destiné à la recherche interne. Dans la procédure d'attribution, ce n'est pas le modèle qui échoue, mais le contrat. Points de blocage typiques et leur résolution :

```text
Étape RFP (imposée par DORA) Statut startup Exigé (art. 30 / 28)
_________________________________ _______________ __________________________________
Droits d'audit/d'accès BaFin manquant garantir par contrat
Journal d'inférence inaltérable partiel prompt + source + version modèle
Clause de sortie + export données manquant testable régulièrement, réversible
Transparence sous-traitants floue divulguer chaîne + droit contrôle
Résidence données (UE/souveraine) hyperscaler US option cloud UE/souverain
AIC4 / ISO 42001 / 27001 / SOC 2 ISO 27001 seule fournir les attestations
```

Ce n'est qu'après avoir garanti contractuellement la résidence des données dans l'UE, une journalisation complète des inférences et un processus de sortie ordonné que le fournisseur atteint le dernier tour. En 2026, les fournisseurs d'IA sans BSI AIC4, ISO 42001, SOC 2 ou ISO 27001 n'atteignent généralement pas la sélection finale dans les appels d'offres BFSI de la région DACH (Allemagne, Autriche, Suisse). Les clouds souverains (par exemple STACKIT, Open Telekom Cloud, IONOS Sovereign Cloud en Allemagne ; Swisscom, Exoscale, Infomaniak en Suisse) ou les solutions sur site mutualisées ont la préférence.

Remarque : cet article sert d'orientation professionnelle et ne constitue pas un conseil juridique. La situation concrète des obligations DORA, les références d'articles et les délais doivent être vérifiés au cas par cas avec des fonctions juridiques et de conformité qualifiées ; les sources réglementaires évoluent en 2025/2026.

Pour les agences et les prestataires B2B

Quiconque développe des produits d'IA ou des contenus pour le secteur financier devrait intégrer la conformité DORA dès le départ comme une condition d'architecture et de go-to-market, et non la traiter à la fin comme une question juridique. D'expérience, la couche de conformité représente 30 à 50 % de l'effort de mise en œuvre dans les secteurs réglementés de la région DACH, davantage que dans les secteurs horizontaux. Pour les agences marketing et tech, c'est un double signal : d'abord, les décideurs des banques et des assurances recherchent des contenus qui expliquent de façon précise et fiable les exigences de DORA pour les fournisseurs d'IA. Ensuite, ce qui fait gagner ou perdre un appel d'offres, c'est une capacité d'audit démontrable, la résidence des données et un chemin de sortie testable. Blck Alpaca t'aide à concevoir et à communiquer des projets d'IA pour des donneurs d'ordre réglementés de manière à franchir les étapes d'achat du secteur financier.