IA pour établissements bancaires : conformité ACPR, LCB-FT, DSP2 et données clients souveraines

Les données bancaires : ultra-sensibles par nature

Les données bancaires forment une catégorie à part dans l'univers des données d'entreprise. Elles ne sont pas simplement « sensibles » au sens du RGPD — elles bénéficient d'une protection spécifique via le secret bancaire (article L511-33 du Code monétaire et financier) et sont encadrées par une réglementation sectorielle dense.

Une fiche client bancaire typique contient : l'identité complète, la situation patrimoniale, les revenus, les charges, les habitudes de consommation (via les transactions), les projets de vie (crédit immobilier, épargne retraite), les éventuelles difficultés financières, les données biométriques si l'authentification forte est utilisée. C'est une radiographie quasi complète de la vie d'une personne.

Ces données sont protégées par :

• Le RGPD (Règlement Général sur la Protection des Données)
• Le secret bancaire (obligation professionnelle des établissements bancaires)
• Les obligations LCB-FT (Lutte contre le Blanchiment et le Financement du Terrorisme)
• Les exigences ACPR (Autorité de Contrôle Prudentiel et de Résolution)
• Le règlement DORA (Digital Operational Resilience Act) pour la résilience des SI

ACPR et systèmes algorithmiques : l'explicabilité comme obligation

L'Autorité de Contrôle Prudentiel et de Résolution (ACPR) a publié plusieurs analyses et recommandations sur l'utilisation de l'IA dans le secteur bancaire et financier. Sa position est claire : les systèmes algorithmiques utilisés pour des décisions de crédit, d'évaluation des risques ou de conformité doivent être explicables, auditables et documentés.

L'exigence d'explicabilité

Quand un algorithme refuse un crédit ou classe un client en catégorie de risque élevée, la banque doit être capable d'expliquer les raisons de cette décision — à l'ACPR lors d'un contrôle, mais aussi au client qui en fait la demande (droit RGPD à l'explication des décisions automatisées). Un modèle de type « boîte noire » — comme la plupart des LLM grand public — ne satisfait pas cette exigence.

Les modèles explicables préférés pour le scoring crédit sont : régression logistique avec scores de Shapley (SHAP values), arbres de décision interprétables, modèles de gradient boosting avec explicabilité post-hoc. Ces modèles peuvent être déployés sur votre infrastructure souveraine avec une explicabilité complète.

L'auditabilité par l'ACPR

L'ACPR peut demander à inspecter vos systèmes algorithmiques lors de ses contrôles sur place. Elle vérifie notamment : la documentation du modèle, les données d'entraînement et leur conformité, les tests de biais et de discrimination, les performances sur les populations protégées, les processus de validation et de surveillance. Un modèle cloud dont vous ne contrôlez pas les paramètres ne peut pas être audité de cette manière.

L'EU AI Act et la banque

L'EU AI Act classe explicitement les systèmes IA utilisés pour l'évaluation de la solvabilité et du scoring crédit comme des systèmes à haut risque. Ces systèmes doivent faire l'objet d'une évaluation de conformité avant déploiement, d'un enregistrement dans la base de données EU et d'une surveillance continue. Un modèle souverain que vous maîtrisez intégralement facilite cette conformité.

LCB-FT : l'IA au service de la lutte anti-blanchiment

La lutte contre le blanchiment de capitaux et le financement du terrorisme (LCB-FT) est une obligation légale pour tous les établissements de crédit français. Elle impose des obligations de vigilance (Know Your Customer, surveillance des transactions), de déclaration de soupçon à TRACFIN et de gel des avoirs.

Détection des opérations suspectes par IA

L'IA offre des capacités de détection des opérations suspectes bien supérieures aux systèmes à règles traditionnels. Elle peut analyser des milliers de signaux faibles simultanément : montant et fréquence des transactions, comportements inhabituels par rapport au profil client, réseaux de transactions entre plusieurs comptes, géolocalisation, horaires des opérations.

Les établissements bancaires qui ont déployé des modèles IA de détection LCB-FT rapportent une réduction de 50 à 70 % des faux positifs par rapport aux systèmes à règles — ce qui libère des ressources pour les investigations réelles et améliore la qualité des déclarations TRACFIN.

La responsabilité reste celle de l'établissement

Point critique : utiliser une IA pour la détection LCB-FT ne transfère pas la responsabilité à l'éditeur. En cas de manquement, c'est l'établissement qui est sanctionné par l'ACPR. Cette responsabilité impose de maîtriser intégralement le système IA : comprendre ses décisions, pouvoir l'auditer, le mettre à jour, et démontrer sa fiabilité à l'autorité de contrôle.

Un modèle LCB-FT déployé sur un cloud opaque dont vous ne contrôlez ni le fonctionnement ni les mises à jour est incompatible avec cette responsabilité.

DSP2, open banking et IA

La Directive sur les Services de Paiement 2 (DSP2) a ouvert le secteur bancaire à de nouveaux acteurs (fintechs, prestataires de services de paiement) via l'accès aux données de transaction des clients. L'IA est au cœur de la plupart des services construits sur l'open banking.

Analyse des données de transaction pour le conseil financier

Les LLM souverains peuvent analyser les données de transaction d'un client (avec son consentement explicite) pour fournir des conseils personnalisés : analyse de ses habitudes de dépenses, identification d'optimisations d'épargne, alertes sur des prélèvements inhabituels, recommandations de produits adaptés à son profil.

Ces analyses impliquent des données extrêmement personnelles — c'est précisément pourquoi elles doivent rester dans un environnement souverain. Le consentement DSP2 ne couvre pas le transfert de ces données à des LLM cloud tiers.

Détection de fraude dans les paiements DSP2

L'authentification forte des clients (SCA) est obligatoire sous DSP2. Les systèmes IA jouent un rôle croissant dans l'analyse de risque qui détermine quand la SCA peut être exemptée (selon les exemptions prévues par le règlement délégué). Ces systèmes d'analyse de risque doivent être documentés et auditables — même exigence que pour le scoring crédit.

DORA : résilience opérationnelle et IA

Le Digital Operational Resilience Act (DORA), applicable depuis janvier 2025, impose aux établissements financiers des exigences renforcées en matière de résilience opérationnelle numérique, incluant la gestion des risques liés aux prestataires tiers.

Classification des prestataires IA comme tiers critiques

Si vous utilisez un LLM cloud pour des fonctions critiques (scoring crédit, détection fraude), ce fournisseur cloud peut être qualifié de prestataire tiers critique au sens de DORA. Cela implique : évaluation précontractuelle approfondie, audits réguliers, plans de sortie, notification à l'ACPR.

En pratique, les grands hyperscalers cloud (AWS, Azure, Google) sont réticents à se soumettre aux audits que DORA impose aux tiers critiques. Cette résistance complique considérablement leur utilisation pour des fonctions bancaires critiques.

Résilience et continuité des systèmes IA

DORA impose des tests de résilience opérationnelle (dont des tests de pénétration avancés — TLPT) et des plans de continuité d'activité pour les fonctions critiques. Un système IA déployé on-premise ou dans un datacenter sous votre contrôle est beaucoup plus facile à intégrer dans ces plans de continuité qu'un service cloud tiers.

Pourquoi ChatGPT est inutilisable sur les données clients bancaires

La question revient souvent dans les banques de taille intermédiaire et les fintechs : peut-on utiliser ChatGPT ou Claude (Anthropic) pour analyser des données clients ? La réponse est non, pour plusieurs raisons cumulatives.

Violation du secret bancaire

Le secret bancaire (article L511-33 du Code monétaire et financier) interdit aux établissements de crédit de communiquer les informations confidentielles de leurs clients à des tiers non habilités. Un fournisseur LLM cloud américain est un tiers non habilité. Soumettre des données clients bancaires à son API constitue une violation du secret bancaire — indépendamment des contrats signés.

Violation du RGPD

Le RGPD exige une base légale pour chaque traitement de données personnelles. Le transfert de données de clients bancaires vers un LLM cloud américain pour leur traitement ne dispose généralement pas de base légale valable. De plus, ce transfert vers les États-Unis est soumis aux contraintes de Schrems II — les garanties offertes par les Privacy Shield-successors sont insuffisantes face au Cloud Act.

Risque d'entraînement des modèles

Même si les conditions d'utilisation des services entreprise des LLM cloud prévoient théoriquement de ne pas utiliser les données pour l'entraînement, l'auditabilité de ce engagement est nulle pour un établissement bancaire. L'ACPR s'intéresse à cette question et pourrait considérer qu'un tel recours ne satisfait pas les obligations de gestion des risques.

Cas d'usage concrets de l'IA souveraine en banque

Scoring crédit explicable

Un modèle de scoring crédit souverain combine des variables traditionnelles (revenus, charges, historique crédit) avec des analyses plus fines des données de comportement bancaire. Il génère pour chaque décision un rapport d'explicabilité : « Ce crédit a été refusé principalement en raison d'un taux d'endettement de 42 % (seuil : 35 %) et d'un reste à vivre insuffisant de 850 € (seuil : 950 €). » Ce rapport est utilisé à la fois pour la relation client et pour l'audit ACPR.

Chatbot conseiller souverain

Un LLM souverain déployé en interne peut servir d'assistant aux conseillers bancaires : il analyse le profil client en temps réel pendant l'entretien, suggère des produits adaptés, génère des propositions commerciales et prépare les documents contractuels — sans que les données clients ne quittent jamais le SI de la banque.

Analyse automatisée des documents KYC

L'onboarding client implique l'analyse de nombreux documents : pièces d'identité, justificatifs de domicile, bulletins de salaire, bilans pour les professionnels. Un LLM souverain avec capacités de vision documentaire peut extraire, vérifier et structurer ces informations automatiquement — réduisant le temps de traitement KYC de 40 à 50 % et améliorant la fiabilité des vérifications.

Détection d'anomalies et alertes LCB-FT

Un modèle d'anomalie entraîné sur les données de transaction de la banque détecte les comportements suspects en temps réel. Pour chaque alerte, un LLM local génère une analyse narrative structurée pour le chargé de conformité : contexte du client, nature de l'anomalie, comparaison avec des cas similaires, recommandation d'action (déclaration TRACFIN, blocage, surveillance renforcée).

Architecture IA souveraine pour un établissement bancaire

Une architecture IA souveraine pour la banque doit répondre à plusieurs contraintes simultanées : haute disponibilité, sécurité maximale, conformité réglementaire, performance pour des volumes de transactions potentiellement très élevés.

• Infrastructure : datacenters propriétaires ou cloud privé français certifié HDS/SecNumCloud, avec redondance géographique pour DORA
• Modèles : ELODIE (7B) pour les tâches conversationnelles et d'assistance, KEVINA 32B pour l'analyse complexe, scoring et détection fraude
• Sécurité : chiffrement de bout en bout, contrôle d'accès basé sur les rôles, journalisation exhaustive pour auditabilité ACPR
• Explicabilité : couche d'explicabilité (SHAP, LIME) intégrée à tous les modèles de décision
• Monitoring : surveillance continue des performances et des dérives (data drift, model drift) avec alertes automatiques

Questions fréquentes

L'ACPR a-t-elle publié des guidelines spécifiques sur l'IA ?

Oui. L'ACPR a publié plusieurs analyses et documents de réflexion sur l'IA dans le secteur bancaire, en lien avec l'Autorité des Marchés Financiers (AMF). Ces documents insistent sur les exigences d'explicabilité, de non-discrimination, de gouvernance des données et de maîtrise des risques liés aux tiers. L'ACPR participe également aux travaux européens sur l'IA dans la finance (EBA, ESMA, EIOPA).

Un outil IA interne sans données clients est-il soumis aux mêmes contraintes ?

Les contraintes s'appliquent proportionnellement à la sensibilité des données traitées. Un LLM utilisé uniquement sur de la documentation réglementaire publique ou des modèles génériques est moins contraint qu'un système traitant des données clients. En pratique, même les outils internes doivent être documentés et leur utilisation encadrée par une politique IA validée par la conformité.

Comment démontrer la conformité de notre IA à l'ACPR lors d'un contrôle ?

L'ACPR s'attend à trouver : une documentation complète du modèle (données d'entraînement, paramètres, performances), un processus de validation indépendant avant déploiement, un suivi des performances en production, des tests de non-discrimination, et un plan de surveillance et de gouvernance. Un modèle souverain dont vous contrôlez intégralement les paramètres peut satisfaire toutes ces exigences. Un modèle cloud opaque ne le peut pas.