Färdiga ramverk för chattbottar räcker inte till inom banksektorn. Ja, det är just där jag skulle börja, och nej, varken en mer överskådlig promptstrategi eller en strängare API-gateway förändrar det.
En standardstack med LangChain, verktyg, vektordatabas och en API-gateway kan göra en agent funktionsduglig. Den kan vidarebefordra en avsikt, hämta sammanhang, anropa ett verktyg och returnera ett välformulerat svar. Bra. Men inom banksektorn är det inte på nivån “kan den anropa API:et?” som det går snett. Bankverksamheten brister när det gäller frågan: “Var detta samtal tillåtet, inom ramen för befogenheterna, verifierat, loggat och säkert att visa för denna kund?”. Det är ett annat arkitekturproblem.
Det finns tre skäl till varför jag inte skulle placera en generisk agentstack i närheten av bankens produktionsarbetsflöden utan att först lägga till ett särskilt säkerhetslager.
För det första är finansiella uppgifter uppgifter om skulder. Ett felaktigt svar från en chatbot inom detaljhandeln är pinsamt. Felaktiga uppgifter om saldo, transaktionsstatus, avgiftsförklaringar eller kreditbeslut kan leda till juridiska risker. Enligt FCA:s konsumentansvar, till exempel måste institutionen visa att kunderna får rättvis, begriplig och lämplig support. Om modellen tar fram ett återbetalningsalternativ eller förklarar en produkt på felaktigt sätt kan man inte bara rycka på axlarna och skylla på “AI:n”. Banken bär ansvaret för resultatet. Därför måste arkitekturen behandla varje sakpåstående som något som måste verifieras mot ett källsystem.
För det andra är multitenancy inte bara ett val i produktutformningen. Om du betjänar flera bankkunder, handlare, affärsenheter eller regioner från en och samma plattform måste isoleringen mellan hyresgäster finnas på alla nivåer: inmatningsfält, minne, vektorindex, verktygsbehörigheter, loggar, Redis-nycklar, databasrader, hemligheter och revisionsutdrag. En enda läcka mellan hyresgäster är inte bara ett felrapporteringsärende. Det kan vara en incident som måste rapporteras. Det är därför jag inte gillar arkitekturer där agenten har omfattande åtkomst och applikationslagret “kommer ihåg” att filtrera informationen i efterhand. Det är just genom att filtrera i efterhand som dataläckor uppstår.
För det tredje är LLM den minst tillförlitliga komponenten i kedjan. Det låter hårt, men det är en rimlig slutsats. Modellen är probabilistisk. Den kan följa skadliga instruktioner, lita för mycket på hämtad kontext eller avslöja personuppgifter i en sammanfattning. Den kan generera ett verktygsanrop som ser giltigt ut tills man granskar parametrarna. Därför skulle jag aldrig låta modellen ligga direkt intill kärnbankens API:er.
Det säkrare tillvägagångssättet är att låta modellen resonera, men att behålla tillämpningen i deterministiska system. Resonemang hör hemma i agentlagret. Genomförandet hör hemma i schemavaliderare, policykontroller, behörigheter på hyresgästnivå, godkännandegrindar och revisionsloggar. När man väl har gjort den uppdelningen upphör arkitekturen att vara en kedja av modelldrivna API-anrop och blir istället ett kontrollerat förtroendesystem, där LLM behandlas som en användbar men opålitlig resonemangskomponent.
Ett visst perspektiv gör det lättare att tillämpa denna uppdelning. När jag betraktar en bankagent är den fråga som intresserar mig hur stor befogenhet den har och hur långt denna befogenhet måste sträcka sig från den människa som beviljat den. Kapaciteten visar hur bra demonstrationen är. Befogenheten avgör hur mycket kontroll systemet tillåts utöva. En briljant modell kopplad till skrivskyddade verktyg är en enkel assistent. En trög modell med en permanent nyckel som kan flytta medel är ett annat problem, och den behöver alla underliggande lager. I artikeln delar jag upp den här befogenhetsaxeln i fyra klasser – assistent, orkestrator, operatör och ekonomisk aktör. Inte alla aktörer är ekonomiska aktörer.
Anlita oss
Om oss