Les frameworks d'agents prêts à l'emploi ne suffisent pas dans le secteur bancaire. Oui, c'est par là que je commencerais, et non, une stratégie de prompt plus claire ou une passerelle API plus stricte n'y changent rien.
Une infrastructure standard comprenant LangChain, des outils, une base de données vectorielle et une passerelle API permet de rendre un agent opérationnel. Celui-ci est capable d’acheminer une intention, de récupérer le contexte, d’appeler un outil et de renvoyer une réponse aboutie. Très bien. Mais dans le secteur bancaire, les difficultés ne se situent pas au niveau de la simple capacité à “ appeler l’API ”. Le secteur bancaire échoue au niveau suivant : “ Cet appel a-t-il été autorisé, circonscrit, vérifié, consigné et peut-il être présenté sans risque à ce client ? ”. C'est un autre problème d'architecture.
Il y a trois raisons pour lesquelles je n'intégrerais pas une pile d'agents générique à proximité des flux de travail bancaires en production sans ajouter une couche de confiance dédiée.
Tout d'abord, les données financières sont des données relatives au passif. Une réponse erronée fournie par un chatbot destiné à la vente au détail est gênante. Une erreur concernant le solde, le statut d'une transaction, l'explication des frais ou une décision de crédit peut entraîner un risque juridique. En vertu de la Obligation de la FCA envers les consommateurs, par exemple, l'établissement doit démontrer que ses clients bénéficient d'un accompagnement équitable, compréhensible et adapté. Si le modèle propose une option de remboursement erronée ou explique un produit de manière incorrecte, on ne peut pas s'en désintéresser en rejetant la faute sur “ l'IA ”. La banque est responsable du résultat. L'architecture doit donc traiter chaque affirmation factuelle comme un élément à vérifier par rapport à un système source.
Deuxièmement, la multi-location n'est pas seulement un choix de conception du produit. Si vous servez plusieurs clients bancaires, commerçants, unités opérationnelles ou régions à partir d’une seule plateforme, l’isolation des locataires doit être assurée à chaque niveau : invites, mémoire, index vectoriels, autorisations d’outils, journaux, clés Redis, lignes de base de données, secrets et exportations d’audit. Une seule fuite inter-locataires ne constitue pas un simple ticket de bug. Il peut s’agir d’un incident à signaler. C’est pourquoi je n’apprécie pas les architectures dans lesquelles l’agent dispose d’un accès étendu et où la couche applicative “ se souvient ” de filtrer les données ultérieurement. C’est précisément ce filtrage a posteriori qui est à l’origine des fuites de données.
Troisièmement, le LLM est l'élément le moins fiable de la chaîne. Cela peut paraître sévère, mais c'est une hypothèse justifiée. Le modèle est probabiliste. Il peut suivre des instructions malveillantes, accorder une confiance excessive au contexte récupéré ou divulguer des données à caractère personnel dans un résumé. Il peut générer un appel d'outil qui semble valide jusqu'à ce que l'on examine les paramètres. Je ne laisserais donc jamais le modèle interagir directement avec les API bancaires centrales.
L'approche la plus sûre consiste à laisser le modèle raisonner, tout en conservant l'application des règles dans des systèmes déterministes. Le raisonnement relève de la couche des agents. L'application des règles relève des validateurs de schémas, des contrôles de politique, des autorisations au niveau du locataire, des portes d'approbation et des journaux d'audit. Une fois cette distinction établie, l'architecture cesse d'être une chaîne d'appels d'API pilotés par un modèle pour devenir un système de confiance contrôlé, dans lequel le LLM est considéré comme un composant de raisonnement utile mais peu fiable.
Une certaine approche facilite la mise en œuvre de cette distinction. Lorsque j’examine un agent bancaire, la question qui m’intéresse est de savoir quel niveau d’autorité il détient et quelle distance cette autorité doit parcourir depuis la personne qui la lui a conférée. La « capacité » indique la qualité de la démonstration. L’« autorité » détermine le degré de contrôle que le système est autorisé à exercer. Un modèle brillant relié à des outils en lecture seule est un assistant léger. Un modèle peu performant disposant d’une clé permanente permettant de transférer des fonds pose un problème différent et nécessite toutes les couches sous-jacentes. Dans cet article, je divise cet axe d’autorité en quatre catégories : assistant, orchestrateur, opérateur et acteur économique. Tous les agents ne sont pas des acteurs économiques.
Nous recruter
À propos