+150 XP

Automatiser le support client dans la finance régulée

# Automatiser le support client dans la finance régulée

Un client écrit à votre banque à 2 heures du matin : « Quelqu'un a débité 340 $ sur ma carte dans un magasin où je ne suis jamais allé. Je veux être remboursé. » Ce seul message déclenche une horloge juridique. Sous la Regulation E (Reg E, la règle fédérale qui encadre les virements électroniques et la résolution des erreurs pour les consommateurs aux États-Unis), la banque doit respecter des délais stricts d'enquête et, dans de nombreux cas, accorder un crédit provisoire sous 10 jours ouvrés.

Imaginez maintenant un LLM (large language model, l'IA derrière les chatbots comme ChatGPT) qui traite ce message. Bien fait, vous résolvez les litiges plus vite, moins cher, 24 h/24. Mal fait, vous avez raté une échéance réglementaire, donné un conseil non autorisé ou promis un remboursement que vous ne pouvez pas honorer.

Cette leçon montre comment construire un agent de support qui reste dans les clous.

Pourquoi l'automatisation du support est différente en finance

Dans la plupart des secteurs, une erreur de chatbot signifie un client agacé. Dans la finance régulée, une erreur peut signifier une violation de conformité (le non-respect d'une règle appliquée par des régulateurs comme le CFPB, le Consumer Financial Protection Bureau).

Trois limites comptent avant tout :

  • La résolution des erreurs Reg E. Les délais et les règles de crédit provisoire ne se négocient pas. L'agent ne peut pas rejeter un litige à la légère ni inventer un délai.
  • Les disclosures. Certaines mentions doivent être délivrées dans une formulation précise. L'agent ne peut pas reformuler une disclosure légalement obligatoire en quelque chose de plus sympathique mais faux.
  • Aucun conseil financier non autorisé. « Vous devriez transférer votre épargne sur notre compte-titres » venant d'un bot sans licence, c'est un problème sérieux. Même « vous serez probablement remboursé » peut être lu comme une garantie.

Le principe de conception central : le LLM est une couche de conversation, pas un décideur. Il explique, collecte et route. Il n'arbitre pas les litiges et n'improvise pas de politique.

Architecture : retrieval et guardrails

Le pattern gagnant ici, c'est le RAG (retrieval-augmented generation), où le modèle répond à partir d'un texte extrait de vos documents approuvés plutôt que de sa propre mémoire.

Pourquoi le RAG compte : un LLM brut affirmera avec aplomb un délai de « 45 jours » à moitié mémorisé de ses données d'entraînement. C'est ce qu'on appelle une hallucination (une réponse assurée mais fabriquée). Le RAG force le modèle à citer votre politique réelle et à jour.

Voici le flux :

1. Le message client arrive.

2. Le système récupère le texte approuvé pertinent : vos procédures Reg E, la FAQ litiges et les disclosures obligatoires.

3. Le LLM rédige une réponse fondée uniquement sur ce texte récupéré.

4. Les guardrails (contrôles automatisés) inspectent le brouillon avant qu'il n'atteigne le client.

5. Les cas à risque élevé sont routés vers un humain.

La couche de guardrails

Les guardrails font la différence entre une démo et un système déployable. Construisez-les en couches :

  • Classification en entrée. Détectez l'intention et le risque. « Où est mon relevé ? » est à faible risque. « J'ai été débité deux fois » déclenche le parcours litige Reg E.
  • Grounding par retrieval. Exigez que la réponse cite des extraits sources. Si rien de pertinent n'est récupéré, l'agent annonce qu'il va mettre en relation avec un humain, il ne devine pas.
  • Filtres en sortie. Bloquez les formulations qui ressemblent à du conseil ou à une garantie (« vous devriez investir », « vous serez certainement remboursé »).
  • Injection de disclosures. Quand un sujet exige une formulation légale exacte, insérez le texte approuvé mot pour mot au lieu de laisser le modèle le réécrire.
  • Déclencheurs de handoff humain. Les litiges au-dessus d'un seuil en dollars, les réclamations répétées ou tout indice de difficulté financière partent vers une personne.

Une version simple du contrôle en sortie :

python
BLOCKED_PATTERNS = [
    r"you should (invest|buy|sell|move your money)",
    r"(guarantee|guaranteed|you will definitely get)",
    r"this is (financial|legal|investment) advice",
]

def passes_guardrails(draft, retrieved_docs):
    # Doit être fondé sur la politique récupérée
    if not retrieved_docs:
        return False, "no_source"
    # Ne doit pas contenir de langage de conseil ou de garantie
    for pattern in BLOCKED_PATTERNS:
        if re.search(pattern, draft, re.IGNORECASE):
            return False, "advice_or_guarantee"
    return True, "ok"

C'est délibérément grossier. Les contrôles regex attrapent les violations évidentes à faible coût. Associez-les à un second LLM jouant le rôle de classifier (« Cette réponse donne-t-elle un conseil en investissement ? Oui/Non ») pour la nuance.

Traiter un litige Reg E, étape par étape

Suivons le message de 2 heures du matin dans le système.

Étape 1 : classifier. L'agent reconnaît une réclamation pour transaction non autorisée. C'est un litige formel, pas une question générale.

Étape 2 : collecter des faits structurés. L'agent pose des questions scriptées et validées par la conformité : date de la transaction, montant, commerçant, si la carte est toujours en possession du client. Il n'improvise pas.

Étape 3 : énoncer le processus, pas le résultat. L'agent explique la suite en utilisant une formulation récupérée et approuvée :

> « J'ai ouvert un litige pour le débit de 340 $. Nous allons enquêter et respecter les délais imposés par la Regulation E fédérale. Vous pouvez avoir droit à un crédit provisoire pendant l'enquête. Un spécialiste reviendra vers vous. »

Notez ce qu'il n'a pas dit : il n'a pas promis de remboursement, ni annoncé un résultat précis, ni inventé un délai.

Étape 4 : tout logger. Chaque message, horodatage et source récupérée est stocké. En finance, ce qui n'est pas loggé n'a pas eu lieu. Les régulateurs attendent une piste d'audit.

Étape 5 : router. L'enquête formelle revient à un humain formé ou à un système à base de règles distinct. Le travail du LLM s'arrête à la prise en charge et à l'explication.

Pour les règles sous-jacentes, le CFPB publie des explications en langage clair sur les virements électroniques et la résolution des erreurs. Fondez votre corpus de retrieval sur le texte réglementaire réel, pas sur le résumé d'un blog.

🎬 [VIDEO: "How Retrieval-Augmented Generation (RAG) Works" - youtube.com - une explication claire et non technique du grounding des LLM sur vos propres documents]

Tests et monitoring

Vous ne pouvez pas mettre ça en production et passer à autre chose. Les agents de support régulés exigent une évaluation continue.

Red-team avant le lancement. Essayez délibérément de casser l'agent. Demandez-lui des conseils boursiers. Déclarez un litige puis tentez d'obtenir une promesse de remboursement. Utilisez des formulations hostiles. Loggez chaque échec et ajoutez un guardrail.

Constituez un jeu d'évaluation. Rassemblez de vrais transcripts de support (anonymisés). Labellisez le comportement correct. Faites tourner l'agent dessus après chaque changement. Cela détecte les régressions (un correctif qui casse discrètement autre chose).

Monitorez en production. Suivez le taux de handoff humain, le taux de blocage par les guardrails et les réclamations clients sur le bot. Une chute soudaine des handoffs peut signifier que l'agent dépasse son périmètre.

Gardez un humain dans la boucle pour la zone grise. L'objectif n'est pas zéro humain. C'est d'avoir des humains sur les 15 % de cas qui portent 85 % du risque.

Vérification des acquis

1. La leçon décrit le LLM comme une « couche de conversation, pas un décideur ». Quelle est la raison principale de ce principe de conception dans la finance régulée ?

2. Pourquoi une erreur de chatbot dans la finance régulée est-elle traitée comme fondamentalement différente d'une erreur de chatbot dans la plupart des autres secteurs ?

3. Un client signale un débit non autorisé de 340 $ à 2 heures du matin. Pourquoi ce seul message crée-t-il une « horloge juridique » que l'agent automatisé doit respecter ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses. Parmi les propositions suivantes, lesquelles constituent des rôles ou comportements appropriés pour la couche de conversation LLM telle que décrite dans la leçon ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses. Parmi les propositions suivantes, lesquelles font partie des limites que la leçon identifie comme les plus importantes pour un agent de support en finance ?

Sélectionnez toutes les réponses correctes.

Modes de défaillance courants à éviter

Le rembourseur zélé. Le modèle, cherchant à rendre service, annonce au client que son argent arrive. Correctif : bloquer le langage de garantie et ne jamais laisser le LLM annoncer un résultat.

La politique périmée. Votre procédure Reg E a changé, mais le corpus de retrieval contient encore la version de l'an dernier. Correctif : traiter le document store comme un actif contrôlé et versionné, avec un propriétaire et un calendrier de mise à jour.

Le devineur sûr de lui. Le retrieval ne renvoie rien de pertinent, alors le modèle comble le vide de mémoire. Correctif : forcer un handoff quand le grounding échoue. Le silence plus un humain est plus sûr qu'une réponse fluide et fausse.

La dérive vers le conseil. Un client demande « Que devrais-je faire du remboursement ? » et le bot suggère un produit. Correctif : classer toute question d'argent tournée vers l'avenir comme du conseil et décliner poliment.

Le paraphraseur de disclosure. Le modèle « améliore » une disclosure obligatoire en quelque chose de plus clair mais juridiquement différent. Correctif : injecter le texte requis mot pour mot et interdire au modèle de l'éditer.

Pourquoi ça rapporte

Bien fait, un agent de support LLM traite le travail à fort volume et faible complexité : expliquer les processus, collecter les détails d'un litige, répondre à « où est mon relevé ». Les spécialistes humains se concentrent sur les jugements et les cas limites.

La valeur n'est pas seulement le coût. C'est la cohérence. Un agent bien groundé donne la même réponse conforme à 2 heures du matin qu'à 14 heures, à chaque fois, avec un log d'audit complet. Cette cohérence est en soi un actif de conformité.

À retenir

  • Le LLM explique et collecte ; il n'arbitre jamais. Gardez la décision chez les humains ou dans des systèmes à base de règles.
  • Fondez chaque réponse sur des documents approuvés (RAG). Aucune source pertinente récupérée signifie un handoff humain, pas une supposition.
  • Les guardrails sont le produit. Bloquez le langage de conseil et de garantie, injectez les disclosures obligatoires mot pour mot et routez les cas à risque élevé vers des personnes.
  • Respectez l'horloge Reg E. Énoncez le processus et les délais à partir du texte approuvé ; ne promettez jamais un résultat précis.
  • Loggez tout et testez en continu. Dans la finance régulée, une piste d'audit et un jeu d'évaluation ne sont pas des options.

Précédent

Hyper-personnalisation des produits financiers

Suivant

Fairness, explainability et conformité réglementaire