IA vocale dans le secteur bancaire : les règles de la BaFin et de DORA pour 2026

IA vocale dans le secteur bancaire : ce que les directives de la BaFin sur l'IA dans le cadre de DORA signifient pour les agents téléphoniques IA

Oui, les banques et les assureurs peuvent déployer des agents téléphoniques basés sur l'IA, mais depuis les orientations de la BaFin sur l'IA dans le cadre de DORA (février 2026), ils ne peuvent plus être considérés comme un simple projet d'innovation parallèle à l'informatique. Un agent téléphonique IA est désormais un actif TIC à part entière au sein du cadre de gestion des risques TIC existant. La décision est capitale : le régulateur s'éloigne de la classification des risques de l'IA Act européen pour définir les systèmes d'IA en termes purement techniques comme des « systèmes de réseau et d'information ». L'IA perd son statut réglementaire particulier.

Pour les décideurs des établissements de crédit, cela est concret : la question n'est plus de savoir si votre agent vocal est une IA à haut risque, mais s'il figure dans l'inventaire des actifs, s'il est classé par risque, surveillé, couvert par un plan de continuité et soutenu par une stratégie de sortie testée. Cet article traduit ces directives en un cadre pratique pour la téléphonie.

Le message clé : l'IA est un actif TIC, pas un sujet à part

L'IA Act européen classe les systèmes d'IA par risque, des applications interdites aux systèmes à haut risque, jusqu'aux risques limités ou minimes. Des obligations graduées s'y rattachent : transparence, documentation, qualité des données, supervision humaine.

Pour les entreprises financières, cette vision centrée sur le produit est insuffisante. Elle ne répond pas à la question de gouvernance réelle : comment intégrer une application d'IA, indépendamment de sa classe de risque éthique, en toute sécurité dans le paysage informatique existant et la garder sous contrôle opérationnel ? C'est là que la BaFin intervient.

Le raisonnement du superviseur est simple et efficace. Un système d'IA est « basé sur une machine », ce qui signifie qu'il se compose de matériel et de logiciels. Cela en fait un « système de réseau et d'information » au sens de DORA, et donc un actif TIC classique. Trois conséquences en découlent :

• Intégration plutôt qu'isolement : l'IA n'est plus un sujet d'innovation isolé. Elle doit être intégrée dans le cadre de gestion des risques TIC existant et documenté. Un agent vocal « testé » par une unité commerciale en marge de l'informatique est, aux yeux du superviseur, de l'informatique fantôme (shadow IT).
• Focus sur le cycle de vie : au lieu d'une évaluation des risques ponctuelle avant le lancement, la BaFin attend une surveillance continue sur l'ensemble du cycle de vie technique, du développement et de l'entraînement jusqu'à l'exploitation en direct, en passant par le déclassement sécurisé et la suppression des données.
• Responsabilité et résilience : la conformité ne se mesure pas seulement à l'aune de la transparence algorithmique, mais à la résilience opérationnelle du système global face aux pannes, aux manipulations telles que l'empoisonnement des données et aux cyberattaques.

Avec cela, la BaFin comble le fossé entre les exigences abstraites de l'IA Act et la réalité opérationnelle dans les centres de données et les environnements cloud du secteur financier. Si vous avez déjà parcouru la checklist de conformité à l'IA Act pour l'IA vocale, vous n'avez pas terminé : la couche DORA s'ajoute par-dessus.

À qui s'adressent ces directives

La BaFin déduit le champ d'application directement de la structure de DORA. Elle s'adresse principalement aux entreprises financières qui doivent appliquer le cadre complet de gestion des risques TIC selon les articles 5 à 15 de DORA, en particulier les établissements de crédit CRR et les entreprises d'assurance sous Solvency II.

Pour ces institutions, les directives doivent être considérées comme l'interprétation faisant autorité des attentes du superviseur, même si le document est formellement qualifié d'« aide non contraignante ». En pratique, il définit la future référence d'audit. Les entreprises financières relevant du cadre simplifié de l'article 16 de DORA, comme les petites entreprises d'investissement ou les petits établissements de paiement, ne sont pas directement visées ; une évaluation distincte est nécessaire dans ces cas.

Proportionnalité : où se situe réellement votre agent vocal

Un élément clé est le principe de proportionnalité selon l'article 4 de DORA. Les exigences évoluent en fonction du profil de risque et de la pertinence systémique. Pour la pratique de gouvernance, cela signifie différencier selon la criticité de la fonction supportée :

• Fonctions critiques ou importantes : applications d'IA qui pilotent des processus métier essentiels ou prennent des décisions ayant un impact direct sur la situation financière ou les résultats, comme les algorithmes de scoring de crédit ou le traitement automatisé des sinistres. Des contrôles et mesures de sécurité complets sont obligatoires ici, incluant des tests de résilience étendus et des devoirs de documentation intensifs.
• Fonctions de support : systèmes d'IA à moindre risque sous supervision humaine continue qui ne prennent aucune décision autonome. Ici, les garanties peuvent être réduites dans une mesure appropriée selon le principe de proportionnalité.

Pour les applications de téléphonie, cette distinction est la décision de conception la plus importante. Un agent vocal n'est pas intrinsèquement critique : il le devient par ce que vous lui permettez de décider. Le tableau suivant illustre des scénarios bancaires types :

L'implication pratique : votre classification des systèmes d'IA concernant le support de fonctions critiques doit être documentée, afin que l'adéquation des mesures prises soit démontrable aux auditeurs et au superviseur. Les institutions qui s'en tiennent délibérément aux fonctions de support lors du déploiement, en confiant toute action ayant un impact financier à un humain, réduisent considérablement le temps de mise en production. Le transfert d'appel vers un agent humain n'est donc pas un détail fonctionnel, mais un levier de contrôle réglementaire.

La fondation : stratégie et gouvernance

La stratégie et la gouvernance forment la base d'une gestion des risques continue. Les directives nomment trois piliers.

Intégration stratégique et feuille de route. L'organe de direction doit adopter une stratégie IA cohérente, intégrée à la stratégie commerciale et DORA globale. Contrairement à l'informatique standard, l'IA nécessite une feuille de route technologique pour piloter les besoins spécifiques en ressources, puissance de calcul, volumes de données, et les investissements nécessaires en amont.

Responsabilité du conseil et littératie IA. La responsabilité ultime des risques liés à l'IA incombe à l'organe de direction selon l'article 5 de DORA. Cela suppose une expertise démontrable pour évaluer indépendamment comment les décisions algorithmiques affectent le modèle économique. La responsabilité des résultats de l'IA doit être attribuée sans faille entre l'informatique et les métiers.

Préparation des processus et intégration du contrôle interne. Avant la mise en œuvre technique, les processus métier doivent être validés pour leur capacité à gérer des résultats probabilistes, c'est-à-dire non déterministes. Les prestataires tiers TIC impliqués nécessitent une évaluation des risques distincte. Les fonctions de contrôle interne, gestion des risques, conformité et audit interne doivent être impliquées tôt et proportionnellement dans le cycle de vie.

Ce dernier point est le plus sous-estimé en pratique. Un modèle de langage répond de manière probabiliste : la même question peut produire deux formulations légèrement différentes. Un processus qui dépend d'une sortie identique mot pour mot est inadapté à l'IA, quelle que soit la qualité du modèle.

Développement et tests : informatique fantôme et chaîne d'approvisionnement

Pour la phase de mise à disposition, les directives mettent en lumière deux thèmes.

Intégrité de la chaîne d'approvisionnement. L'informatique fantôme non réglementée dans les unités métier doit être évitée ; les solutions low-code sont tout autant soumises aux normes DORA. Cela est particulièrement important pour l'IA vocale, car les plateformes modernes sont délibérément assez simples pour qu'une unité métier puisse se lancer sans l'informatique. C'est précisément l'erreur à ne pas commettre. L'intégrité de la chaîne d'approvisionnement doit également être assurée : validation stricte des données d'entraînement contre l'empoisonnement, plus examen rigoureux des bibliothèques open-source et du code généré par IA.

Développement sécurisé et stratégies de test étendues. Pour contrôler le problème de la « boîte noire », le processus de développement doit agir comme un filet de sécurité : versionnage complet du code, des données d'entraînement et des paramètres du modèle, plus une gestion stricte des changements pour les mises à jour du modèle, incluant des stratégies de retour arrière testées. Comme les tests fonctionnels conventionnels échouent souvent face à l'IA probabiliste, les tests doivent être élargis : les tests adverses simulent des attaques ciblées, et pour l'IA générative, la revue humaine sécurise la fiabilité des résultats.

Pour les agents vocaux, le « versionnage » ne couvre pas seulement le modèle, mais aussi le prompt système et la base de connaissances. Modifier le prompt d'un agent bancaire en production sans approbation et sans chemin de retour arrière est un changement non documenté, avec les mêmes conséquences réglementaires qu'un déploiement non documenté dans le système bancaire central.

Exploitation en direct et déclassement : les quatre domaines d'action

Pour la phase d'exploitation, les directives traduisent les articles 8 à 11 de DORA en quatre domaines d'action. Le tableau ci-dessous les traduit en exigences pour une plateforme d'IA vocale :

Notamment, le cycle de vie ne se termine qu'avec le déclassement sécurisé : les modèles obsolètes et les données doivent être supprimés de manière irrécupérable pour éviter les fuites ou les abus. Presque personne ne planifie cela à l'avance, et les auditeurs posent systématiquement la question.

Du côté de la plateforme, ce ne sont pas des exigences exotiques. L'historique des appels et l'analyse post-appel fournissent les journaux d'inférence exigés par les articles 8 et 10 ; via API et webhooks, ces données peuvent être répliquées dans le SIEM ou l'entrepôt de données existant de l'institution au lieu de rester dans un tableau de bord tiers.

Intégration et cloud : le véritable obstacle

Parce que les systèmes d'IA performants sont principalement fournis via une infrastructure cloud externe plutôt que par un centre de données interne, les directives se concentrent sur le contrôle de ces risques d'externalisation. Pour l'IA vocale, c'est la section critique : pratiquement chaque plateforme est un accord d'externalisation.

Évaluation des risques étendue et due diligence. Avant la signature du contrat, l'inventaire des risques doit anticiper des facteurs dynamiques tels que le réentraînement du modèle ou les changements de structure du modèle. La due diligence ne peut s'arrêter au fournisseur ; elle doit évaluer explicitement le risque de fuite de données non autorisée et l'adéquation du fournisseur aux normes techniques et réglementaires.

Cybersécurité spécifique au cloud. Pour les environnements d'entraînement ou d'inférence hébergés en externe, les vecteurs d'attaque tels que l'empoisonnement des données ou les attaques adverses doivent être identifiés et contrés. Lorsque des fonctions critiques ou importantes sont externalisées, un niveau de sécurité « adéquat » ne suffit pas : le fournisseur doit démontrer qu'il respecte les normes actuelles les plus élevées.

Transparence dans la chaîne contractuelle. Le contrôle de la sous-traitance sans faille est décisif, car les systèmes d'IA reposent souvent sur des chaînes d'approvisionnement complexes. L'institution doit savoir à tout moment où le traitement des données a lieu physiquement. Les SLA doivent aborder de manière contraignante la sensibilité des modèles d'IA à la latence et à la capacité de calcul, soutenus par des droits d'audit exécutoires profondément dans la chaîne.

Stratégie de sortie et verrouillage fournisseur (vendor lock-in). Parce que les services d'IA cloud propriétaires encouragent le verrouillage, les contrats doivent garantir l'exportation des modèles, des données d'entraînement et des métadonnées dans des formats interopérables. Des sauvegardes régulières sur un stockage indépendant et des scénarios de migration validés sont obligatoires.

Pour le choix du fournisseur, cela signifie : une plateforme qui possède votre numéro de téléphone, ne divulgue pas le modèle et bloque l'exportation des données de conversation est difficile à justifier sous DORA. À l'inverse, le BYOC (Bring Your Own Carrier) désamorce deux points à la fois : l'institution garde le contrôle de ses numéros et de son contrat de téléphonie, et changer de fournisseur reste possible sans que les clients aient à composer un nouveau numéro. C'est une stratégie de sortie qui tient la route, plutôt qu'une simple déclaration d'intention. L'accord de traitement des données (DPA) et les divulgations de traitement des données qui l'accompagnent constituent la base de votre dossier de due diligence.

Mise en œuvre étape par étape

1. Définir le cas d'usage. Commencez délibérément par des fonctions de support : horaires, rendez-vous, routage, FAQ. Tout ce qui a un impact financier reste pour l'instant entre les mains des humains.
2. Documenter la criticité. Écrivez pourquoi l'agent ne supporte pas de fonction critique ou importante. Ce raisonnement est votre preuve de proportionnalité selon l'article 4 de DORA.
3. Ajouter à l'inventaire des actifs. Modèle, version du prompt, base de connaissances, voix, numéro de téléphone, fournisseur et sous-fournisseurs, avec un responsable nommé.
4. Exécuter la revue d'externalisation. Due diligence du fournisseur, clarifier les lieux de traitement, divulguer la chaîne de sous-traitance, convenir des droits d'audit et des SLA sur la latence et la disponibilité.
5. Tester avant la mise en service. Tests fonctionnels, tests de charge à densité d'appels réaliste, tests adverses contre l'injection de prompt, évaluation humaine de la qualité des réponses.
6. Mettre en place la surveillance. Pas seulement la disponibilité : taux d'abandon, taux d'escalade, qualité des réponses, latence. Alertes sur la dérive. Répliquer les journaux dans vos propres systèmes.
7. Tester le BCM et la sortie. Repli vers le routage ou une annonce en cas de panne. Exécutez l'exportation des artefacts une fois pour de vrai, ne vous contentez pas d'une assurance contractuelle.
8. Établir la gestion des changements. Chaque changement de prompt ou de modèle passe par une approbation, un test et un chemin de retour arrière documenté.
9. Planifier le déclassement. Définissez dès maintenant comment les versions de modèles obsolètes et les données de conversation seront supprimées de manière sécurisée.

Bonnes pratiques et erreurs courantes

• Erreur : l'unité métier commence seule. Le marketing ou les opérations d'agence « testent rapidement » un agent vocal. C'est exactement l'informatique fantôme que la BaFin vise, no-code inclus.
• Erreur : changements de prompt sans processus de changement. Le prompt est une configuration de production, pas un champ de texte. Versionnez-le, approuvez-le, gardez un retour arrière prêt.
• Erreur : surveillance de la disponibilité uniquement. Un agent peut être joignable à 100 % et répondre moins bien depuis trois semaines. L'article 10 demande une détection d'anomalies, pas seulement le temps de fonctionnement.
• Erreur : sortie sur le papier uniquement. Une clause de sortie sans exportation testée n'est pas une sortie. Répétez la migration une fois.
• Bonne pratique : authentifier avant de divulguer. Tout ce qui dépasse les informations publiques ne doit être fait qu'après une identification propre, idéalement via saisie au clavier plutôt qu'un numéro de compte énoncé oralement.
• Bonne pratique : l'escalade par défaut. Un agent qui transfère proprement à un humain en cas d'incertitude reste une fonction de support, le levier de conformité le moins cher disponible.
• Bonne pratique : garder les journaux en interne. Si les données de conversation ne vivent que dans un tableau de bord fournisseur, le lignage des données est difficile à prouver. Répliquez-les dans votre SIEM.

Exemple concret : une banque régionale de 40 agences

Une banque régionale de 40 agences et environ 600 employés a un problème classique : le lundi matin entre 9h et 11h, le volume d'appels atteint des pics tels qu'une part substantielle des appelants abandonne la file d'attente. Les demandes sont principalement banales : horaires, rendez-vous, questions sur les documents à apporter.

Le périmètre réglementairement propre : l'agent vocal décroche, répond aux questions sur les horaires et les documents à partir d'une base de connaissances maintenue, prend les rendez-vous, et route tout le reste vers un humain. Pas d'informations de compte, pas de blocage de carte, pas de pré-qualification. Cela en fait une fonction de support : documentée, justifiée, enregistrée dans l'inventaire.

Les numéros de téléphone restent chez l'opérateur existant de l'institution via BYOC, les données de conversation circulent par webhook dans l'entrepôt de données de la banque, et le repli en cas d'incident de plateforme est le routage classique vers la ligne de l'agence. La preuve DORA reste proportionnée, et la voie vers la prochaine étape d'expansion est ouverte, car l'inventaire, le processus de changement et la surveillance existent déjà.

Conclusion

Avec ces directives, la BaFin transforme les exigences réglementaires abstraites en un cadre opérationnel. Même sans le statut de circulaire, le document définit effectivement le futur standard d'or pour la pratique d'audit. Pour les agents téléphoniques IA dans le secteur bancaire, la route ne passe pas par la question de savoir si vous pouvez, mais par l'inventaire des actifs, la classification de criticité documentée, une surveillance réelle, des plans de continuité testés et une stratégie de sortie crédible.

La bonne nouvelle : les institutions qui limitent le cas d'usage aux fonctions de support et confient les actions à impact financier aux humains peuvent avancer proportionnellement et atteindre la production beaucoup plus rapidement. Famulor est conçu exactement pour cela : hébergement dans l'UE, accord de traitement des données, BYOC pour un contrôle total sur les numéros et l'opérateur, journaux d'appels exportables pour le lignage des données, et un chemin de transfert propre vers le personnel humain.

Prochaine étape : parlez à notre équipe entreprise de votre cas d'usage spécifique et de la documentation d'externalisation, ou voyez comment Famulor soutient les services financiers aujourd'hui. Si vous avez d'abord besoin du business case, le calculateur de ROI montre en quelques minutes ce que l'automatisation de vos appels permet d'économiser.

FAQ

Une banque peut-elle déployer un agent téléphonique IA ?

Oui. La BaFin n'interdit pas la téléphonie par IA ; elle classe les systèmes d'IA comme des actifs TIC classiques sous DORA. Le déploiement est autorisé si l'agent est enregistré dans l'inventaire des actifs, classé par risque, surveillé et couvert par un plan de continuité.

Quel est le message clé des directives de la BaFin sur l'IA sous DORA ?

Les systèmes d'IA sont des « systèmes de réseau et d'information » et donc des actifs TIC classiques. Ils perdent leur statut réglementaire spécial et doivent être pleinement intégrés dans le cadre de gestion des risques TIC existant sur l'ensemble du cycle de vie.

À qui s'adressent ces directives ?

Principalement aux entreprises financières appliquant le cadre complet de gestion des risques TIC selon les articles 5 à 15 de DORA, en particulier les établissements de crédit CRR et les assureurs Solvency II. Les entreprises relevant du cadre simplifié de l'article 16 de DORA ne sont pas directement visées.

Un agent vocal est-il une fonction critique ?

Pas automatiquement. Ce qui compte, c'est s'il prend des décisions autonomes affectant la situation financière ou les résultats. L'information et la prise de rendez-vous sont généralement des fonctions de support ; le blocage de carte ou la pré-qualification de crédit ne le sont pas.

Qu'exige la BaFin lors de l'externalisation vers un fournisseur cloud ?

Une due diligence étendue incluant le risque de fuite de données, la transparence sur toute la chaîne de sous-traitance, des SLA sur la latence et la capacité de calcul, des droits d'audit exécutoires et une stratégie de sortie avec exportation dans des formats interopérables.

Qui est responsable des risques liés à l'IA au sein de l'institution ?

La responsabilité ultime incombe à l'organe de direction selon l'article 5 de DORA, c'est-à-dire le conseil d'administration complet. Cela nécessite une expertise démontrable (« littératie IA ») et une attribution des responsabilités sans faille entre l'informatique et les métiers.

La conformité à l'IA Act européen suffit-elle ?

Non. L'IA Act régit les devoirs liés aux produits et applications par classe de risque. DORA et les directives de la BaFin ajoutent des exigences opérationnelles pour la résilience, la surveillance, l'externalisation et la gestion de la continuité.

Qu'est-ce qui compte comme informatique fantôme dans le contexte de l'IA vocale ?

Une unité métier qui met en service un agent vocal sans l'informatique, la conformité et l'audit interne. La BaFin précise que les solutions low-code et no-code sont tout autant soumises aux normes DORA.

Comment le BYOC aide-t-il avec la stratégie de sortie ?

Avec le BYOC, les numéros de téléphone et le contrat de téléphonie restent chez l'institution. Changer de fournisseur devient possible sans changer de numéro, une stratégie de sortie qui tient la route en pratique plutôt qu'une simple clause contractuelle.

Quand le cycle de vie d'un système d'IA se termine-t-il ?

Uniquement au déclassement sécurisé. Les modèles obsolètes, les artefacts de modèle et les données associées doivent être supprimés de manière irrécupérable pour éviter les fuites et les abus. Planifiez cela avant la mise en service, pas après.