Source : Shelby, J. (2026). The AI resilience gap: Bringing artificial intelligence inside the operational resilience perimeter. arXiv

Sommaire : L'intégration structurelle de l'IA au cœur des services financiers critiques impose de dépasser la simple conformité éthique de l'EU AI Act pour se concentrer sur la résilience opérationnelle exigée par DORA, dont les obligations s'appliquent bien avant celles de la réglementation sur l'IA. Les contrôles de continuité classiques sont inadaptés aux défaillances spécifiques de l'IA, telles que la dégradation silencieuse (grey failure), le non-déterminisme et la forte concentration systémique autour de rares fournisseurs de modèles. Pour y remédier, l'AI Resilience Framework (ARF) propose une méthode d'intégration unifiée : cartographier les dépendances aux services importants, piloter une matrice de criticité, instrumenter les tolérances face aux dérives, et garantir des doctrines de repli humain non fictionnelles. Face à ces risques probabilistes, les décideurs et architectes doivent unifier leurs registres de risques et adopter une approche Zero Trust pour assurer la survie de leurs services.

1. Introduction : Le basculement de l'IA vers les services critiques

L'intelligence artificielle (IA) au sein du secteur financier a franchi une étape décisive, passant de simples projets pilotes de marketing ou de productivité administrative à une intégration structurelle au cœur des fonctions critiques. Aujourd'hui, l'IA intervient directement dans les décisions de crédit, la surveillance des transactions, le trading et la gestion des services clients essentiels.

Selon l'enquête menée par la Banque d'Angleterre (BoE) et la Financial Conduct Authority (FCA) en novembre 2024, environ trois quarts des institutions financières utilisent déjà l'IA. Les modèles de fondation, incluant les grands modèles de langage (LLM), représentent désormais un sixième des cas d'usage. L'IA n'est plus une option technologique périphérique, mais une composante structurelle des services financiers dont la disponibilité et l'intégrité sont désormais obligatoires.

2. Distinction entre deux logiques réglementaires : Fiabilité vs Résilience

Une confusion persiste entre la conformité éthique de l'IA et sa résilience opérationnelle. Le tableau ci-dessous distingue la « pile IA de confiance » (orientée vers la sécurité et l'éthique) de la « pile résilience » (orientée vers la continuité du service).

Le problème de la gouvernance en silos

Cette distinction n'est pas seulement théorique ; elle crée une friction organisationnelle majeure. Les obligations de la pile "Trustworthy-AI" sont généralement portées par les fonctions de risque de modèle (Model Risk) et les équipes de Data Science. À l'inverse, les obligations de résilience incombent aux directeurs des opérations (COO) et aux responsables de la résilience opérationnelle. Ce cloisonnement empêche souvent la cartographie des dépendances IA dans les registres de risques critiques, laissant les institutions vulnérables à des défaillances techniques non couvertes par les politiques éthiques.

3. Chronologie des obligations et impératif de convergence

Un décalage temporel structurel existe entre ces deux cadres. Alors que l'EU AI Act impose des obligations graduelles, la résilience opérationnelle est une exigence immédiate et déjà sanctionnable.

• DORA et régimes de résilience : Le règlement DORA s'applique depuis janvier 2025. Parallèlement, le régime britannique de résilience opérationnelle a atteint son régime de croisière en 2025. Ces obligations sont « live ».
• EU AI Act et le "Digital Omnibus" :Bien que l'acte soit entré en vigueur en août 2024, l'accord politique sur le « Digital Omnibus » du 7 mai 2026 a reporté les obligations majeures pour les systèmes à haut risque.
  • Systèmes de l'Annexe III (basés sur l'usage) : Reportés à décembre 2027.
  • Systèmes de l'Annexe I (intégrés aux produits) : Reportés à août 2028.

Pour un gestionnaire de risques, la conclusion est sans appel : les obligations de résilience de l'IA (DORA) mordent bien avant les obligations de conformité (AI Act). La résilience ne peut être traitée comme un sous-produit de l'éthique.

4. Les modes de défaillance spécifiques à l'IA : Au-delà de l'indisponibilité

Les contrôles de résilience classiques, calibrés pour une indisponibilité binaire (up/down), sont inadaptés à la nature probabiliste de l'IA.

• Dégradation silencieuse (Grey failure) : Contrairement à une panne franche, le modèle continue de répondre avec une latence normale, mais sa précision se dégrade (drift). L'IA fait de la « grey failure » la norme plutôt que l'exception : le système semble sain pour le monitoring d'uptime alors que ses décisions sont corrompues.
• Adversarial Input et Injection : Les attaques de type « prompt injection » transforment un problème d'intégrité en un risque immédiat pour la sécurité et la disponibilité du service.
• Propagation à l'échelle machine : Lorsqu'un composant IA dispose d'une autonomie de décision, les erreurs se propagent à la vitesse et à l'échelle de la machine, augmentant radicalement le « rayon d'impact » (blast radius) avant toute intervention humaine possible.
• Non-déterminisme : La difficulté de reproduire exactement un incident entrave les processus classiques de gestion d'incidents et de remédiation post-mortem.
• Concentration systémique : La dépendance envers un nombre infime de fournisseurs de modèles de frontière (frontier models) crée une "monoculture" technologique. Une défaillance unique chez un fournisseur peut paralyser simultanément l'ensemble du secteur financier.

5. L'AI Resilience Framework (ARF) : Une méthode d'intégration

L'ARF propose de sortir l'IA de son silo pour l'intégrer dans le périmètre de résilience opérationnelle via cinq étapes structurantes.

Étape 1 : Cartographie des dépendances Identifier chaque composant d'IA et le lier formellement aux Services Commerciaux Importants (SCI) qu'il soutient. Sans cette visibilité, aucun impact tolerance ne peut être appliqué.

Étape 2 : Matrice de Criticité-Substituabilité (CSM) Classer les dépendances pour prioriser l'effort de remédiation :

Étape 3 : Extension des tolérances d'impact (Instrumentation) Les seuils de tolérance doivent intégrer la notion de "correctness". Cela nécessite une instrumentation spécifique : monitoring de la dérive distributionnelle (distributional drift) et validation continue des sorties via des jeux de tests de défi ou des « canary sets ».

Étape 4 : Doctrine de repli (Fallback) Un repli documenté mais non ressourcé est un « fallback fictionnel ». Si l'IA a remplacé un processus manuel dont les compétences ont disparu, le risque est total. Le fallback doit être testé en conditions réelles et doté de ressources humaines capables d'opérer sans l'assistance de l'IA.

Étape 5 : Gestion de la concentration au niveau du fournisseur Évaluer les fournisseurs de modèles comme des tiers critiques (Critical Third Parties - CTP). L'analyse doit porter sur la capacité technique à basculer (failover) vers un autre fournisseur, en utilisant notamment des couches d'abstraction (API agnostiques).

6. Analyse de l'impact opérationnel et préconisations

Scénarios types

1. Assistant client GenAI (Tier 2) : Si le LLM dérive ou devient indisponible, le centre d'appel humain doit absorber la charge. Le risque résilience ici est la tentation de réduire les effectifs humains en dessous du seuil de sécurité opérationnelle.
2. Surveillance des transactions (Tier 1) : Si l'ancien moteur de règles a été déclassé, la dépendance est irreducible. Une dégradation silencieuse du modèle pourrait laisser passer des flux illicites massifs sans qu'aucune alerte de disponibilité ne soit déclenchée.
3. Fournisseur de modèle partagé : L'usage d'un même fournisseur pour plusieurs outils internes crée une concentration de Tier 1 aggregate. Une panne fournisseur devient alors un événement systémique pour l'institution.

Recommandations pour les décideurs

• Pour les CISO et Senior Managers (SM&CR) : Vous devez assumer la responsabilité de la doctrine de repli. L'absence de solution de secours testée pour une IA critique constitue désormais un « accountability gap » majeur.
• Pour les Architectes de sécurité : Appliquez les principes du Zero Trust aux composants IA. Les workloads d'IA doivent disposer de privilèges restreints (scoped), d'identifiants à courte durée de vie et d'un contrôle strict des sorties (constrained egress). Concevez des couches d'abstraction pour découpler les applications des interfaces propriétaires afin de garantir la substituabilité technique.

7. Conclusion : Vers une convergence des registres de risques

La résilience de l'IA n'est pas un défi documentaire, c'est un défi d'architecture. En alignant les exigences de l'EU AI Act avec celles de DORA et du régime CTP, les institutions financières peuvent mettre en œuvre un « Compliance Convergence Framework » (cadre de convergence de la conformité).

Le message final pour les gestionnaires de risques est clair : il faut dédoubler les efforts et unifier les registres. La conformité à l'AI Act gère la « qualité » du modèle, mais seule l'intégration de l'IA dans le périmètre de résilience opérationnelle garantit la survie du service. Dans le contexte du nouveau « UK Cyber Security and Resilience Bill »., la capacité à démontrer une résilience réelle face aux défaillances de l'IA devient le nouveau standard de la supervision financière.