RSSI en secteur financier : les 5 risques IA qui rendent votre dispositif sécurité inopérant
L’intelligence artificielle est désormais déployée dans la quasi-totalité des établissements financiers. Scoring crédit, détection des fraude, tarification en assurance, productivité des équipes ; les usages IA se sont multipliés à une vitesse fulgurante mais les dispositifs de cybersécurité n’ont pas suivie. Dans les environnements dans lesquels nous intervenons, nous rencontrons régulièrement des systèmes IA en production sans monitoring comportemental, sans traçabilité des décisions et sans réelle gouvernance des accès. DORA est en vigueur depuis janvier 2025. L’AI Act impose ses premières obligations. Et les RSSI se retrouvent face à cinq angles morts que leurs outils actuels, conçus avant l’avènement des agents IA et des LLM, ne couvrent tout simplement pas.
Votre dispositif sécurité couvre-t-il vos systèmes IA ?
Évaluez votre exposition en 2 semaines.
Pourquoi l’IA est l’angle mort de votre stratégie cyber ?
Ce que DORA, l’AI Act et NIS2 changent concrètement pour vous
Les pressions réglementaire européennes sont renforcées fortement avec trois textes s’appliquent simultanément aux acteurs financiers français, avec des obligations directement liées à l’IA :
- DORA (Digital Operational Resilience Act) en vigueur depuis le 17 janvier 2025, impose que les systèmes d’information critiques, y compris les modèles IA en production, soient résilients, auditables et sous supervision humaine. Il impose également des tests de résilience opérationnelle et le reporting des incidents majeurs.
- L’AI Act classe les systèmes d’évaluation de solvabilité (banque) et de tarification des risques en assurance-vie et santé comme systèmes IA à haut risque, avec des obligations d’auditabilité, de traçabilité, de contrôle humain et de registre documenté. L’ACPR sera l’autorité de surveillance compétente en France.
- NIS2 élargit les obligations de cybersécurité aux banques et aux assurances pour l’ensemble de leurs systèmes d’information cloud. Le niveau de sécurité High recommandé par l’EUCS pour les données financières sensibles est rarement atteint dans les configurations actuelles.
Le problème est que vos outils sécurité n’ont pas été conçus pour l’IA
Les dispositifs de sécurité dans les environnements financiers (SAST, DAST, SIEM, EDR) ont été conçus pour des architectures applicatives classiques. Ils ne prennent pas en compte les spécificités des modèles d’apprentissage automatique, des agents IA autonomes, des bases vectorielles RAG ou des pipelines de fine-tuning. Ce n’est pas un défaut de configuration : c’est une inadéquation structurelle entre vos outils et les nouvelles architectures IA.
-> En savoir plus sur ce sujet : Agent IA d’entreprise : de l’architecture aux agents, une approche industrielle et souveraine
Les équipes sécurité se retrouvent avec des angles morts qu’elles ne voient même pas, sur des périmètres qu’elles ne maîtrisent pas et face à de nouvelles obligations réglementaires à intégrer dans des délais très courts. Et c’est exactement face à cette situation que nous nous retrouvons dans les SI financiers sur lesquels nous intervenons chez Harington.
Risque n°1 : Vos modèles IA violent DORA sans que personne ne le sache
Ce que DORA exige de vos systèmes IA
DORA ne se limite pas à la gestion des prestataires IT ou aux plans de continuité d’activité. Le règlement exige que les systèmes d’information critiques, et les modèles IA qui y sont intégrés, respectent trois critères fondamentaux : la résilience opérationnelle (capacité à résister et se remettre d’incidents), l’auditabilité (traçabilité des décisions et des comportements) et la supervision humaine (contrôle humain effectif sur les outputs du système).
Ces exigences s’appliquent donc aux modèles IA déployés en production dans les processus métier critiques : scoring de crédit, moteurs de recommandation, outils de détection de fraude, assistants IA opérationnels. Et le fait qu’un modèle ait été déployé par une équipe métier, et non par la DSI, ne l’exonère pas des obligations DORA alors que souvent la DSI n’a pas été intégrée comme elle l’aurait du dans ce type de projets.
Chiffres clés
+51%
d’incidents liés à des exfiltrations de données en France
ANSSI 2025
46%
des incidents cyber européens dans la finance ciblent les banques
ENISA 2024
64%
des grandes entreprises ont une politique sécurité dédiée à l’IA
Wavestone 2025
Majorité
des ETI financières sans registre documenté de leurs systèmes IA haut risque
Harington Cyber
Les 3 critères que la plupart des environnements ne respectent pas
Dans les entreprises financières chez qui nous intervenons en cybersécurité, nous constatons quasi systématiquement que les modèles IA en production ne répondent pas aux trois critères DORA, ou du moins partiellement.
- Pas de monitoring comportemental continu : Aucun système ne surveille la dérive des modèles, les anomalies de comportement ou les changements de distribution des données en entrée.
- Pas de traçabilité des décisions : Les outputs des modèles ne sont pas logués de manière exploitable. Impossible de reconstituer pourquoi un modèle a pris telle décision à telle heure sur tel dossier.
- Pas de contrôle humain structuré : Les décisions IA ne font l’objet d’aucun dispositif de supervision humaine formalisé (human-in-the-loop) en violation directe des exigences DORA et AI Act.
C’est tout simplement par ce que ces modèles ont été déployés avant que DORA n’entre en vigueur, sans que les équipes sécurité aient été associées projet. Il est donc nécessaire de rectifier au plus vite cette situation … avant que les auditeurs ACPR se présentent.
Risque n°2 : Vos systèmes de scoring et de tarification sont en infraction avec l’AI Act
Ce que l’ACPR va contrôler en premier
L’AI Act désigne explicitement deux catégories de systèmes IA comme à haut risque dans le secteur financier : les algorithmes d’évaluation de la solvabilité et de notation de crédit pour les personnes physiques (banque) et les systèmes d’évaluation des risques et de tarification en assurance-vie et santé. L’ACPR sera l’autorité de surveillance compétente en France pour vérifier la conformité de ces systèmes.
Les premières vérifications de l’ACPR porteront sur des éléments très précis : l’existence d’un registre documenté des systèmes IA haut risque, la qualité et la traçabilité des données d’entraînement, les mécanismes de supervision humaine, et la documentation technique tenue à jour. Ce sont des éléments que la majorité des ETI financières n’ont pas encore produits.
Vos obligation sur les IA à haut risque
En tant qu’opérateur et non fournisseurs d’algorithmes IA, les établissements financiers ont des obligations spécifiques au sens de l’AI Act :
- Informer les personnes physiques lorsqu’elles font l’objet d’une décision d’un système IA haut risque
- Effectuer une analyse d’impact sur les droits fondamentaux avant toute mise en production
- Assurer la supervision humaine effective du système conformément au mode d’emploi du fournisseur
- Tenir un registre des logs d’utilisation automatiquement générés par le système
- Signaler tout incident grave ou dysfonctionnement sérieux à l’ACPR
Sanctions AI Act
L’ACPR dispose des mêmes pouvoirs de sanction que pour la réglementation prudentielle.
Risque n°3 : Du code IA non audité part en production à chaque sprint
Pourquoi les SAST/DAST classiques ne voient pas le code IA
Vos développeurs utilisent des assistants IA pour coder (Copilot, Cursor, Claude, Gemini) et la productivité gagnée est réelle. Le problème, c’est le code généré par ces assistants contient des vulnérabilités spécifiques que les outils d’analyse statique (SAST) et d’analyse dynamique (DAST) classiques ne détectent pas. Certains de ces générateurs de codes IA proposent des fonctionnalités d’examen de sécurité automatisé pour vous aider à identifier et corriger les vulnérabilités dans votre code mais les développeurs n’ont pas encore ce réflexe (lire annonce de Claude en mars 2026).
Ces outils ont été construits pour analyser du code écrit manuellement selon des modèles de vulnérabilités connus et catalogués. Le code généré par IA présente des patterns différents avec des injections de prompts, des dépendances non vérifiées, des hallucinations de bibliothèques inexistantes, des accès non sécurisés à des APIs ; que les règles SAST/DAST actuelles ne couvrent pas. Dans les faits, à chaque sprint, du code non audité part en production dans vos environnements financiers.
La supply chain des agents IA : un risque invisible
Au-delà du code, la chaîne de dépendances applicatives des agents IA représente une surface d’attaque que peu d’organisations maîtrisent. Un agent IA qui orchestre plusieurs outils, appelle des APIs externes et consomme des modèles tiers génère un périmètre étendu que l’on appelle l’AI Supply Chain Security. Dans le secteur financier, où les systèmes sont interconnectés et où les données traitées sont sensibles, cartographier et sécuriser cette chaîne est indispensable.
L’ANSSI a publié le 13 avril 2026 le bulletin CERTFR-2026-ACT-016, dédié aux risques des agents IA autonomes sur les postes de travail. Adressé directement aux DSI et RSSI, il prescrit la cartographie de tous les agents déployés, le principe de moindre privilège sur leurs accès, et une validation humaine obligatoire pour toute action à effet de bord.
Source : CERT-FR — CERTFR-2026-ACT-016
Risque n°4 : Vos agents IA ont des accès directs à vos SI sans aucune gouvernance
Le protocole MCP, une porte d’entrée non surveillée
Le Model Context Protocol (MCP), le standard ouvert publié par Anthropic et largement adopté, permet aux agents IA de se connecter à des outils, des bases de données et des systèmes externes pour exécuter des actions. Dans les environnements financiers, cela signifie qu’un agent IA peut avoir accès à vos données clients, vos systèmes de gestion de risques, des outils comptables ou des plateformes de trading ; sans que cet accès soit gouverné comme un accès humain classique.
Ces connexions créent des identités machines, c’est à dire des identifiants techniques que les agents utilisent pour s’authentifier auprès des systèmes. Dans la quasi-totalité des environnements dans lesquels nos consultants cyber interviennent, ces identités machines ne sont pas gouvernées. Pas de principe de moindre privilège, pas de revue périodique des accès ni d’audit des actions effectuées; le risque est considérable.
Identités machines, périmètres d’exécution : qui contrôle ?
La question de la gouvernance est rarement adressée : Qui dans votre organisation est responsable des identités machines des agents IA ? Qui définit ce qu’un agent IA peut faire et ce qu’il ne peut pas faire ? Qui audite les communications entre agents ou encore les appels qu’ils se font les uns aux autres dans une architecture multi-agents ?
Or DORA exige la maîtrise du périmètre IT et la traçabilité des accès aux systèmes critiques, l’absence de gouvernance des agents IA est une non-conformité directe. Et dans un contexte où menace est exponentielle, c’est aussi un vecteur d’attaque privilégié. Un agent compromis avec des accès élargis peut exfiltrer des données ou exécuter des actions malveillantes sans déclencher les alertes classiques.
Expert Harington
Brice Leffe
Cybersécurité Practice Manager
Pouvez-vous lister aujourd’hui tous les LLM tiers qui traitent des données financières ou clients de votre établissement ? Connaissez-vous leurs conditions de traitement, leur localisation de stockage, leur politique de rétention des données ? Dans la majorité des cas, la réponse est non.
Risques N°5 : Vos données financières alimentent des LLM tiers sans vérification de souveraineté
RAG, fine-tuning, agents : trois flux de données non contrôlés
Trois des architectures IA les plus courantes dans le secteur financier créent des flux de données vers des modèles tiers qui n’ont jamais été vérifiés sous l’angle de la souveraineté et de la protection des données :
- Le RAG (Retrieval-Augmented Generation) : Vos bases documentaires, vos données clients, vos procédures internes sont indexées dans des bases vectorielles et requêtées en temps réel par des LLM. La criticité de ces données est rarement évaluée avant leur indexation.
- Le fine-tuning : Certaines équipes entraînent des modèles sur des données métier et ces datasets contiennent souvent des informations financières sensibles dont le traitement par un prestataire tiers n’a pas été encadré contractuellement.
- Les agents connectés : Les agents IA qui orchestrent des tâches envoient des données en contexte à des LLM tiers pour chaque requête. Ces données transitent via des APIs dont les conditions de traitement et de stockage ne sont pas toujours vérifiées.
+51 % d’exfiltrations en France : le signal d’alarme de l’ANSSI
L’ANSSI recense +51 % d’incidents liés à des exfiltrations de données en France en 2025 (Source 11 mars 2026 Panorama de la Cybermenace). Une partie de ces incidents implique des données ayant transité via des services IA tiers. Alors que le RGPD impose de connaître précisément où sont traitées les données personnelles et que d’AI Act exige la traçabilité des données d’entraînement, ne pas maîtriser ses flux IA est un risque juridique et opérationnel considérable.
Comment sécuriser vos systèmes IA : l’approche AI Security en 4 piliers
Pour sécuriser ces risques majeurs, Harington a structuré une offre AI Security spécifiquement conçue pour les environnements financiers. Notre approche couvre les angles morts que les outils de sécurité classiques ne voient pas, avec une méthode en 4 piliers complémentaires.
AI Code Security, MCP Security, AI Quality & Governance et IA Data Access
- AI Code Security : Sécurisation du code source généré par IA et de la chaîne de dépendances applicatives des agents. SAST/DAST spécifique IA, audit de la supply chain des agents, détection des vulnérabilités propres au code IA.
- MCP Security : Sécurisation des protocoles de communication des agents IA, définition et contrôle des périmètres d’exécution, gouvernance des identités machines. Contrôle des communications inter-agents et des flux vers les systèmes tiers.
- AI Quality & Governance : Monitoring comportemental continu des modèles en production, QA avancée IA, dispositifs human-in-the-loop, observabilité et traçabilité des décisions. Répond directement aux obligations DORA et AI Act.
- IA Data Access : Sécurisation des accès aux données par les systèmes IA et les utilisateurs humains, contrôle des bases vectorielles RAG, chiffrement, souveraineté des données de fine-tuning. Aligné avec les exigences RGPD et AI Act.
Votre audit de maturité AI Security avec livrable en 2 semaines
Nous vous proposons un audit de maturité AI Security ciblé. En deux semaines, nous produisons un tableau de bord de maturité avec les gaps identifiés et les priorités chiffrées, une matrice RACI pour aligner les responsabilités entre DSI, RSSI, DPO et métiers et une feuille de route priorisée avec les chantiers à lancer en urgence.
HARINGTON
Audit de maturité AI Security
Identifiez vos gaps, priorisez vos chantiers, sécurisez vos systèmes IA.
Vos questions sur la sécurité IA en secteur financier
Qu’est-ce qu’un système IA à haut risque selon l’AI Act pour le secteur financier ?
L’AI Act définit deux catégories de systèmes IA à haut risque dans le secteur financier : les algorithmes d’évaluation de la solvabilité et de notation de crédit pour les personnes physiques (banque) et les systèmes d’évaluation des risques et de tarification en assurance-vie et santé. Ces systèmes sont soumis à des obligations strictes de traçabilité, d’auditabilité, de supervision humaine et de documentation technique. L’ACPR sera l’autorité compétente pour contrôler leur conformité en France.
DORA s’applique-t-il aux modèles IA déployés en interne par les équipes métier ?
Oui. DORA s’applique à l’ensemble des systèmes d’information critiques d’une entité financière, quelle que soit la manière dont ils ont été déployés. Un modèle IA déployé par une équipe métier sans validation de la DSI ou du RSSI reste soumis aux obligations DORA dès lors qu’il s’intègre dans des processus opérationnels critiques. Le fait que ce modèle n’ait pas suivi un processus de validation formel ne l’exonère pas des exigences de résilience, d’auditabilité et de supervision humaine.
Les SAST et DAST suffisent-ils pour auditer le code généré par IA ?
Non. Les outils SAST et DAST classiques ont été conçus pour détecter des vulnérabilités dans du code écrit manuellement, selon des modèles connus et catalogués. Le code généré par des assistants IA présente des spécificités que ces outils ne détectent pas : injections de prompts, hallucinations de bibliothèques, dépendances non vérifiées, accès non sécurisés. Un audit de code IA nécessite des outils et des méthodologies conçus pour analyser le code généré par intelligence artificielle.
En savoir plus
L’IA s’est déployée dans les établissements financiers à une vitesse que les dispositifs de cybersécurité n’ont pas suivie. DORA est en vigueur, l’AI Act impose ses premières obligations. Voici les 5 angles morts que vos outils actuels ne couvrent pas.
Harington entre au FT1000 2026 du Financial Times et de Statista, à la 766e place des entreprises européennes à plus forte croissance.
Comment choisir un centre de services nearshore en 2026 ? Critères de décision, tarifs, gouvernance, SLA et modèle de delivery pour les DSI.