Assistants IA financiers : limiter les données dès la première question

Un assistant financier peut recevoir bien plus de données que nécessaire. Séparer les questions publiques des demandes liées à un compte permet de concevoir un parcours plus sobre et plus sûr.

Un utilisateur cherche une explication sur des frais. Pour aider l’assistant, il joint spontanément une capture de son compte : nom, solde, opérations récentes, parfois coordonnées. Le problème de conception commence à cet instant. Une question générale vient de provoquer la collecte d’informations qui n’étaient peut-être pas nécessaires à la réponse.

Pour les équipes produit et les responsables de la relation client, la première décision devrait porter sur les informations dont chaque demande a réellement besoin. Le choix du modèle et la qualité rédactionnelle des réponses viennent ensuite. Un assistant capable de lire un relevé complet ne devrait pas recevoir ce relevé par défaut.

Séparer l’information publique du dossier individuel

La CNIL définit la minimisation par des données adéquates, pertinentes et limitées à ce qui est nécessaire à la finalité poursuivie. Appliqué à un assistant, ce principe oblige à décrire précisément le service rendu : expliquer une notion, retrouver une page d’aide ou examiner une situation personnelle ne requiert pas le même contexte.

Prenons un scénario fictif : une personne demande à un assistant généraliste où consulter une information publique sur BYDFi, puis ajoute une capture de son historique personnel. La première demande appelle une recherche documentaire ; la pièce jointe introduit un dossier individuel. Le parcours devrait proposer de retirer ce document et préciser quand il faut passer par un canal officiel adapté. Ce scénario illustre un choix de conception, sans présumer des outils employés par cette entreprise.

Cette séparation peut apparaître dès l’accueil. Une entrée "comprendre un service" ouvre une conversation sans données de compte. Une entrée "obtenir de l’aide sur mon dossier" explique les informations nécessaires et les conditions d’accès au service concerné. Le visiteur comprend ainsi ce qu’il peut communiquer avant de commencer à écrire.

Prévenir la collecte dans l’interface

Une consigne enfouie dans les conditions d’utilisation aide peu au moment de joindre un fichier. Le rappel doit être placé près du champ concerné : ne transmettre aucun mot de passe, code de connexion ou secret d’accès ; retirer les informations étrangères à la demande. Pour une question générale, on peut commencer par désactiver les pièces jointes et proposer une reformulation sans données personnelles.

Lorsqu’un document est nécessaire, demander un extrait précis limite le périmètre de collecte. L’écran devrait expliquer quelles lignes sont utiles et quelles informations peuvent être masquées. Un contrôle automatique peut repérer certains contenus à risque, mais il faut prévoir ses erreurs : un numéro peut passer inaperçu, et un texte anodin peut être bloqué. Une solution de remplacement doit rester accessible.

Dans ses conseils sur les chatbots publiés le 19 février 2021, la CNIL recommande notamment une mise en garde avant utilisation et un mécanisme de purge lorsque des données sensibles sont fournies de manière imprévue. Ces recommandations concernent les catégories sensibles au sens du RGPD ; elles ne signifient pas que toute donnée financière relève juridiquement de cette catégorie. Une information de compte peut néanmoins exiger une forte protection.

Suivre les données au-delà de la conversation

Retirer une donnée de la réponse affichée ne démontre pas qu’elle a disparu du traitement. L’équipe doit examiner ce qui a été transmis au modèle, ajouté aux journaux techniques, conservé dans l’outil de support ou intégré à un jeu d’évaluation. Pour chaque copie, il faut identifier une finalité, des personnes autorisées et une règle de conservation.

La CNIL rappelle que la durée de conservation dépend de la finalité du traitement. Une conversation d’orientation et un échange nécessaire au suivi d’une réclamation peuvent donc appeler des durées différentes. Fixer une durée unique pour toutes les conversations évite une décision de conception, sans résoudre les besoins réels du service. Le responsable du traitement doit pouvoir justifier les durées retenues.

Le contrat et les paramètres du fournisseur méritent aussi une vérification concrète. Qui accède aux messages ? Existe-t-il une réutilisation pour améliorer un modèle ? Comment une suppression est-elle appliquée aux différents systèmes ? Les réponses doivent être documentées pour la configuration effectivement utilisée, puis réexaminées lors d’un changement d’outil ou de finalité.

Tester avec des dossiers fictifs avant l’ouverture

Une recette utile commence par des demandes ordinaires, puis ajoute volontairement des informations superflues : coordonnées dans une question générale, capture trop large, document concernant un tiers. Les essais devraient utiliser des données fictives et vérifier le chemin complet, de la saisie aux journaux, ainsi que la suppression prévue.

Les indicateurs peuvent suivre les pièces jointes demandées sans nécessité, les données évitées avant transmission, les erreurs de filtrage et les orientations vers un interlocuteur humain. Chaque échec doit conduire à une correction identifiable : modifier une consigne, réduire un accès ou supprimer un champ. L’équipe dispose alors d’éléments concrets pour décider si le service peut être ouvert, et pour vérifier ce qui change à la version suivante.