L’adoption des assistants IA internes s’accélère dans les banques et les assurances. Copilotes bureautiques, assistants documentaires, outils de synthèse d’incidents, moteurs de recherche augmentés ou agents métiers connectés à des bases internes : ces solutions deviennent progressivement des composants du poste de travail et des processus opérationnels.
Le sujet n’est donc plus uniquement l’usage de l’IA générative dans les métiers ou en cybersécurité. Il porte désormais sur la sécurisation des IA elles-mêmes, en particulier lorsqu’elles accèdent à des données internes, à des référentiels documentaires ou à des outils métiers.
Les travaux de l’OWASP Top 10 for LLM Applications 2025 formalisent plusieurs risques désormais centraux pour les applications fondées sur des modèles de langage : prompt injection, divulgation d’informations sensibles, vulnérabilités de supply chain, empoisonnement de données, mauvaise gestion des sorties, excès d’autonomie ou faiblesses liées aux embeddings et aux bases vectorielles.
Le NIST AI Risk Management Framework rappelle de son côté que la maîtrise des risques IA repose sur une gouvernance continue, couvrant la cartographie des usages, la mesure des risques, leur gestion et l’organisation des responsabilités.
Une nouvelle surface d’attaque liée au langage, au contexte et aux connecteurs
Un assistant IA interne ne se comporte pas comme une application classique. Il interprète des instructions en langage naturel, manipule du contexte et produit une réponse probabiliste. Cette architecture introduit des risques spécifiques.
La prompt injection est l’un des plus connus. OWASP la définit comme une manipulation des réponses du modèle par des entrées conçues pour modifier son comportement, contourner ses instructions ou l’amener à produire une sortie non prévue.
Dans un contexte financier, le risque ne se limite pas à un utilisateur qui saisit volontairement une instruction malveillante. Une injection peut aussi provenir d’un document indexé, d’un ticket, d’un email, d’un compte rendu ou d’un contenu externe intégré dans une base documentaire. C’est un point important pour les architectures RAG.
RAG : efficacité opérationnelle, mais risque de confusion entre données et instructions
Les architectures de type Retrieval-Augmented Generation permettent à un assistant IA de rechercher des informations dans des sources internes avant de générer une réponse. Cette approche est utile pour exploiter une documentation métier, des procédures, des référentiels de conformité ou des bases de connaissances IT.
Mais elle crée également une difficulté structurelle : le modèle reçoit des contenus qui peuvent être interprétés à la fois comme des données et comme des instructions. Un document malveillant ou insuffisamment contrôlé peut contenir des consignes visant à influencer la réponse du modèle.
Dans le secteur bancaire et assurantiel, ce risque peut concerner des cas d’usage concrets : assistant de conformité, moteur de recherche documentaire, aide à l’analyse d’incident, assistant support interne, outil d’aide à la relation client ou copilote de gestion des sinistres.
La question n’est donc pas uniquement de savoir si le modèle est robuste. Il faut aussi sécuriser les sources, les connecteurs, les droits d’accès et les règles d’assemblage du contexte transmis au modèle.
Divulgation d’informations sensibles : un risque d’architecture plus que de modèle
OWASP classe la divulgation d’informations sensibles parmi les principaux risques des applications LLM. Ce risque peut provenir d’une mauvaise séparation des données, d’une journalisation excessive, d’un paramétrage insuffisant des sorties ou d’un usage de données sensibles dans les prompts ou les contextes.
Dans un environnement financier, les données concernées peuvent être multiples : données clients, informations patrimoniales, données de santé en assurance, données de paiement, informations internes de sécurité, comptes rendus de crise, procédures de contrôle ou documents juridiques.
L’expression “IA interne” ne suffit pas à éliminer ce risque. Une solution peut être interne au sens de l’hébergement ou de la contractualisation, tout en étant mal segmentée, mal journalisée ou trop largement connectée. Le risque de fuite doit donc être compris comme un risque de mauvaise exposition interne, de sur-permissionnement ou de réutilisation non maîtrisée des données, et non uniquement comme une fuite vers un fournisseur externe.
Shadow AI : usages non gouvernés et contournement des contrôles
Le shadow AI désigne les usages d’outils IA non recensés, non validés ou non intégrés dans la gouvernance de sécurité de l’organisation. Il peut s’agir d’un outil SaaS utilisé par une équipe, d’un plugin ajouté à un poste de travail, d’un assistant connecté à une base documentaire ou d’un prototype métier déployé sans revue sécurité formelle.
Pour les banques et assurances, ce risque est particulièrement sensible car les usages non gouvernés peuvent contourner plusieurs dispositifs existants : classification des données, DLP, journalisation, gestion des accès, revue des fournisseurs, analyse juridique ou validation conformité.
Le shadow AI n’est pas nécessairement un comportement malveillant. Il traduit souvent un besoin métier réel, associé à des délais de mise à disposition trop longs ou à une absence d’offre interne adaptée. La réponse doit donc combiner contrôle, pédagogie et mise à disposition d’alternatives maîtrisées.
Contrôle des accès : le principe clé reste le moindre privilège
Un assistant IA ne doit pas devenir un raccourci permettant d’accéder à des informations qu’un utilisateur ne pourrait pas consulter par les canaux habituels.
Le contrôle d’accès doit donc s’appliquer au moment de la récupération documentaire, pas seulement au niveau de l’interface de chat. Concrètement, un moteur RAG doit filtrer les documents récupérés selon les droits effectifs de l’utilisateur : métier, entité, niveau d’habilitation, confidentialité, localisation ou besoin d’en connaître.
Les difficultés apparaissent souvent lorsque les connecteurs sont configurés avec des comptes techniques trop larges, ou lorsque les bases documentaires internes contiennent des droits hérités mal maîtrisés. Dans ces cas, l’assistant IA peut révéler indirectement des informations qui étaient déjà trop largement accessibles, mais peu visibles auparavant.
Bases vectorielles et embeddings : un point de contrôle à ne pas négliger
Les bases vectorielles utilisées dans les architectures RAG peuvent contenir des représentations de documents internes. Elles ne doivent pas être considérées comme neutres ou sans sensibilité.
OWASP inclut les faiblesses liées aux embeddings et aux vecteurs parmi les risques des applications LLM 2025, car ces composants peuvent introduire des problèmes de fuite, d’empoisonnement ou de récupération de contenus non souhaités.
Dans un environnement financier, les équipes doivent donc définir des règles sur l’indexation des documents, la suppression des contenus obsolètes, la séparation des collections vectorielles, la traçabilité des sources utilisées et la gestion des droits appliqués aux résultats récupérés.
Journalisation et auditabilité : condition de maîtrise en environnement réglementé
La journalisation des assistants IA internes doit permettre de répondre à plusieurs questions : qui a interrogé l’assistant, quelles sources ont été mobilisées, quelle réponse a été fournie, quelles actions ont été déclenchées et quels contrôles ont été appliqués.
Cette traçabilité est essentielle pour l’investigation, l’audit interne, la conformité et la gestion des incidents. Elle doit toutefois être conçue avec prudence, car les logs eux-mêmes peuvent contenir des données sensibles. Il faut donc définir une politique claire de conservation, d’accès, de masquage et de protection des journaux.
Dans une logique proche des exigences de résilience opérationnelle numérique, la capacité à expliquer l’usage d’un assistant IA devient un élément de gouvernance, et pas uniquement un sujet technique.
Supply chain des composants IA
Les applications IA internes dépendent souvent d’un écosystème complexe : modèles, frameworks d’orchestration, bibliothèques, connecteurs, bases vectorielles, services d’hébergement, outils de monitoring et API tierces.
OWASP classe les vulnérabilités de supply chain parmi les risques majeurs pour les applications LLM. Les composants, datasets, plugins ou services compromis peuvent affecter l’intégrité du système et provoquer des fuites ou des comportements non souhaités.
Pour les établissements financiers, cela implique une gouvernance comparable à celle de la supply chain logicielle classique : inventaire, qualification des composants, suivi des versions, contrôle des dépendances, revue des fournisseurs et tests de sécurité avant déploiement.
Contrôles “by design” à intégrer
La sécurisation des assistants IA internes doit être intégrée dès la conception. Les contrôles les plus structurants sont les suivants : séparation entre données et instructions, filtrage des contenus indexés, contrôle des droits au moment de la récupération RAG, limitation du contexte transmis au modèle, validation des sorties sensibles, journalisation exploitable, cloisonnement des bases vectorielles et revue des connecteurs.
Ces contrôles doivent être associés à une gouvernance claire : propriétaire métier, propriétaire technique, responsable sécurité, classification des données traitées, analyse de risques, règles d’usage et processus de revue périodique.
Le NIST AI RMF insiste sur une approche de gestion des risques qui n’est pas ponctuelle, mais continue : gouverner, cartographier, mesurer et gérer les risques tout au long du cycle de vie du système IA.
Perspective pour les banques et assurances
Les assistants IA internes peuvent constituer une alternative plus maîtrisable que des usages dispersés d’outils externes, à condition d’être intégrés dans une gouvernance de sécurité rigoureuse. L’enjeu n’est pas de freiner leur adoption, mais de définir les conditions dans lesquelles ils peuvent être utilisés sans affaiblir les contrôles existants.
Pour les établissements financiers, la priorité consiste à réduire le shadow AI, maîtriser les connecteurs, appliquer le moindre privilège, auditer les accès documentaires, sécuriser les bases vectorielles et intégrer les scénarios IA dans les dispositifs de détection et de réponse.
La maturité ne se mesure pas à la présence d’un assistant IA interne, mais à la capacité à démontrer que ses usages, ses accès, ses données et ses risques résiduels sont compris, documentés et contrôlés.