Kant-en-klare agent-frameworks volstaan niet voor de banksector. Ja, dat is het uitgangspunt waar ik mee zou beginnen, en nee, een strakkere promptstrategie of een strengere API-gateway verandert daar niets aan.
Met een standaardstack bestaande uit LangChain, tools, een vector-database en een API-gateway kan een agent functioneren. Hij kan een intent doorsturen, context ophalen, een tool aanroepen en een goed uitgewerkt antwoord teruggeven. Prima. Maar in het bankwezen gaat het niet mis op het niveau van “kan hij de API aanroepen?”. Het bankwezen schiet tekort op het niveau van de vraag: “Was dit telefoongesprek toegestaan, binnen de vastgestelde grenzen, geverifieerd, geregistreerd en veilig om aan deze klant te laten zien?”. Dat is een ander architectuurprobleem.
Er zijn drie redenen waarom ik geen generieke agentstack in de buurt van productie-bankworkflows zou plaatsen zonder een speciale vertrouwenslaag toe te voegen.
Ten eerste zijn financiële gegevens gegevens over verplichtingen. Een onjuist antwoord van een chatbot in de detailhandel is gênant. Een onjuiste vermelding van het saldo, de transactiestatus, de toelichting op de kosten of de kredietbeslissing kan leiden tot juridische risico’s. Onder de FCA-verplichting jegens de consument, zo moet de instelling bijvoorbeeld aantonen dat klanten eerlijke, begrijpelijke en passende ondersteuning krijgen. Als het model een aflossingsoptie verzint of een product onjuist uitlegt, kun je niet gewoon je schouders ophalen en de schuld bij “de AI” leggen. De bank is verantwoordelijk voor de output. Daarom moet de architectuur elke feitelijke bewering behandelen als iets dat aan de hand van een bronsysteem moet worden geverifieerd.
Ten tweede is multi-tenancy niet alleen een keuze op het gebied van productontwerp. Als je vanaf één platform meerdere bankklanten, handelaren, bedrijfsonderdelen of regio’s bedient, moet er op elke laag sprake zijn van tenant-isolatie: invoervelden, geheugen, vectorindexen, toolrechten, logbestanden, Redis-sleutels, databaserijen, geheimen en auditexporten. Eén lek tussen tenants is geen bugmelding. Het kan een te melden incident zijn. Daarom houd ik niet van architecturen waarbij de agent ruime toegang heeft en de app-laag “onthoudt” om dingen later te filteren. Door later te filteren ontstaan er juist datalekken.
Ten derde is de LLM het minst betrouwbare onderdeel in de keten. Dat klinkt hard, maar het is een terechte aanname. Het model is probabilistisch. Het kan kwaadwillige instructies opvolgen, te veel vertrouwen stellen in opgehaalde context, of PII in een samenvatting blootgeven. Het kan een tool-aanroep genereren die geldig lijkt, totdat je de parameters nader bekijkt. Daarom zou ik het model nooit direct naast de kernbank-API’s laten draaien.
De veiligere aanpak is om het model te laten redeneren, maar de handhaving in deterministische systemen te laten plaatsvinden. Redeneren hoort thuis in de agentlaag. Handhaving hoort thuis in schemavalidators, beleidscontroles, machtigingen op tenantniveau, goedkeuringspoorten en auditlogs. Zodra je die scheiding aanbrengt, is de architectuur niet langer een aaneenschakeling van modelgestuurde API-aanroepen, maar wordt het een gecontroleerd vertrouwenssysteem, waarbij de LLM wordt behandeld als een nuttige maar onbetrouwbare redeneercomponent.
Een bepaald kader maakt het gemakkelijker om die scheiding toe te passen. Als ik naar een bankagent kijk, is de vraag die mij bezighoudt hoeveel bevoegdheid deze heeft en hoe ver die bevoegdheid moet reiken vanaf de persoon die deze heeft toegekend. Capaciteit geeft aan hoe goed de demo is. Bevoegdheid bepaalt hoeveel controle het systeem mag uitoefenen. Een briljant model dat is gekoppeld aan alleen-lezen-tools is een ‘thin assistant’. Een saai model met een permanente sleutel waarmee geld kan worden overgemaakt, is een ander probleem, en daarvoor zijn alle onderliggende lagen nodig. In het artikel heb ik die bevoegdheidsas onderverdeeld in vier klassen: assistent, orchestrator, operator en economische actor. Niet elke agent is een economische actor.
Inhuren
Over ons