Standard-Agenten-Frameworks reichen für den Bankensektor nicht aus. Ja, das ist der Punkt, mit dem ich beginnen würde, und nein, eine optimierte Prompt-Strategie oder ein strengerer API-Gateway ändern daran nichts.
Ein Standard-Stack mit LangChain, Tools, einer Vektordatenbank und einem API-Gateway kann einen Chatbot funktionsfähig machen. Er kann eine Absicht weiterleiten, Kontext abrufen, ein Tool aufrufen und eine ausgefeilte Antwort zurückgeben. Gut und schön. Aber im Bankwesen scheitert man nicht an der Frage: “Kann er die API aufrufen?”. Das Bankwesen versagt auf der Ebene der Frage: “War dieser Anruf zulässig, im Rahmen der Befugnisse, überprüft, protokolliert und für diesen Kunden unbedenklich?”. Das ist ein anderes Architekturproblem.
Es gibt drei Gründe, warum ich einen generischen Agent-Stack nicht ohne eine spezielle Vertrauensschicht in der Nähe von Produktions-Banking-Workflows einsetzen würde.
Erstens: Finanzdaten sind Verbindlichkeitsdaten. Eine falsche Angabe in einem Chatbot für den Einzelhandel ist peinlich. Eine falsche Angabe zum Kontostand, zum Transaktionsstatus, zur Gebührenerläuterung oder zur Kreditentscheidung kann rechtliche Risiken nach sich ziehen. Gemäß dem Verbraucherpflichten gemäß FCA, … So muss das Institut beispielsweise nachweisen, dass Kunden eine faire, verständliche und angemessene Betreuung erhalten. Wenn das Modell eine Rückzahlungsoption erfindet oder ein Produkt falsch erklärt, kann man nicht einfach mit den Schultern zucken und “der KI” die Schuld geben. Die Bank ist für das Ergebnis verantwortlich. Daher muss die Architektur jede sachliche Aussage so behandeln, als müsse sie anhand eines Quellsystems überprüft werden.
Zweitens ist Multi-Tenancy nicht nur eine Frage der Produktgestaltung. Wenn Sie mehrere Bankkunden, Händler, Geschäftsbereiche oder Regionen über eine einzige Plattform bedienen, muss auf jeder Ebene eine Mandantenisolierung gewährleistet sein: Eingabeaufforderungen, Speicher, Vektorindizes, Tool-Berechtigungen, Protokolle, Redis-Schlüssel, Datenbankzeilen, Geheimnisse und Audit-Exporte. Ein einziger mandantenübergreifender Datenleck ist kein Bug-Ticket. Es kann sich um einen meldepflichtigen Vorfall handeln. Aus diesem Grund mag ich keine Architekturen, bei denen der Agent weitreichenden Zugriff hat und die Anwendungsschicht sich “merkt”, die Daten später zu filtern. Durch das nachträgliche Filtern entstehen Datenlecks.
Drittens ist das LLM die am wenigsten vertrauenswürdige Komponente in der Kette. Das klingt hart, ist aber die richtige Annahme. Das Modell arbeitet probabilistisch. Es kann böswillige Anweisungen befolgen, dem abgerufenen Kontext zu viel Vertrauen schenken oder personenbezogene Daten in einer Zusammenfassung offenlegen. Es kann einen Tool-Aufruf generieren, der gültig erscheint, bis man die Parameter genauer unter die Lupe nimmt. Daher würde ich das Modell niemals direkt neben den Kernbank-APIs laufen lassen.
Der sicherere Ansatz besteht darin, das Modell die Schlussfolgerungen ziehen zu lassen, die Durchsetzung jedoch in deterministischen Systemen zu belassen. Das Schlussfolgern gehört in die Agentenebene. Die Durchsetzung gehört in Schema-Validatoren, Richtlinienprüfungen, mandantenbezogene Berechtigungen, Genehmigungsschritte und Prüfprotokolle. Sobald man diese Trennung vornimmt, ist die Architektur nicht mehr eine Kette modellgesteuerter API-Aufrufe, sondern wird zu einem kontrollierten Vertrauenssystem, in dem das LLM als nützliche, aber unzuverlässige Schlussfolgerungskomponente behandelt wird.
Ein bestimmter Ansatz erleichtert die Umsetzung dieser Trennung. Wenn ich mir einen Bankagenten anschaue, interessiert mich vor allem, wie viel Befugnis er besitzt und wie weit diese Befugnis vom Menschen, der sie erteilt hat, entfernt ist. Die Leistungsfähigkeit gibt Auskunft darüber, wie gut die Demo ist. Die Befugnis bestimmt, wie viel Kontrolle das System ausüben darf. Ein brillantes Modell, das an schreibgeschützte Tools angebunden ist, ist ein „Thin Assistant“. Ein träges Modell, das über einen permanenten Schlüssel verfügt, mit dem Gelder bewegt werden können, stellt ein anderes Problem dar und benötigt alle darunterliegenden Schichten. In dem Artikel unterteile ich diese Autoritätsachse in vier Klassen – Assistent, Orchestrator, Operator und wirtschaftlicher Akteur – Nicht jeder Akteur ist ein Wirtschaftsakteur.
Einstellen
Über uns