KI in Banken: Wer nur das Modell kontrolliert, kontrolliert zu wenig

Clean Code, der unkontrolliert Tokens verbrennt, ist nicht clean. Für Banken, Versicherer und FinTechs ist ineffiziente KI kein Nachhaltigkeitsthema, sondern ein Betriebsrisiko: teuer, langsam, schwer prüfbar und abhängig von Dritten.

von Thomas Steirer, CTO bei Nagarro

Token sind dabei aber vielmehr Signal als Steuerungsgröße.

Wer unnötig viele Tokens verbraucht, bewegt häufig zu viele Daten, ruft Modelle zu oft auf oder hat den Workflow nicht sauber geschnitten.“

Die tatsächliche Kontrolle beginnt deshalb nicht beim Token-Zähler, sondern bei der Transaktion.

Nicht das Modell allein entscheidet über Kontrolle

In vielen KI-Debatten dreht sich alles um Modelle, doch in der Finanz-IT ist das zu kurz gedacht. Das Modell ist zwar wichtig, aber es ist nur ein Teil eines größeren Ablaufs. Entscheidend ist nicht, welches Modell eine Bank nutzt, sondern welche Transaktion sie kontrolliert.

Ein Beispiel aus dem Corporate Banking zeigt das: Ein Relationship Manager will einen Kreditvorschlag vorbereiten. Was auf den ersten Blick wie ein Fall für einen KI-Assistenten aussieht, ist technisch gesehen eine Kette aus Dokumentenprüfung, Bonitätsprüfung, Financial Spreading, Ratio-Berechnung, Projektion, Proposal-Erstellung, Review und Übergabe an den Wholesale Relationship Manager. Das Sprachmodell ist darin nur eine Komponente. Es trifft keine Entscheidungen und sollte auch nicht so tun.

Genau hier beginnt Green Code: nicht bei einem Carbon-Dashboard, das nachträglich an einen schlechten Prozess gehängt wird, sondern am Anfang bei der Architekturfrage.“

Green Code meint in diesem Zusammenhang nicht nur Nachhaltigkeit. Gemeint ist auch ein effizienterer, kontrollierbarer und wirtschaftlicherer Betrieb von KI-Systemen. Welche Schritte benötigen Sprache, welche Arithmetik und welche eine API, die die Bank längst besitzt? Und bei welchen ist der Mensch erforderlich, der am Ende verantwortlich ist?

Der monolithische Prompt ist keine Architektur

Problematisch wird es dort, wo GenAI wie eine große Texteingabemaschine behandelt wird. Alles wird in den Kontext geschoben, dem Modell überlassen und als Sprachproblem behandelt. Das mag auf den ersten Blick bequem erscheinen, kann in der regulierten Finanz-IT jedoch gefährlich werden.

Ein Kredit-Workflow braucht eine geführte Oberfläche. Während ein offener Chat den Kontext aufbläht, entscheidet ein geführter Flow, welche Informationen in den Kontext gelangen. Interaction Design wird somit zum Instrument der Token-Kontrolle.“

Auch Arithmetik gehört nicht in den Prompt, denn Finanzkennzahlen, Ratio-Berechnungen und Projektionen sind deterministische Operationen. Sie sollten als Skills oder Services ausgeführt werden, nicht als generierter Text. Ein Modell kann erklären, strukturieren und formulieren, doch das Rechnen muss die Komponente übernehmen, die dafür gebaut wurde. Dasselbe gilt für Daten aus Bestandssystemen: Systems of Record werden abgefragt, nicht in einen Vector Store kopiert, um später wieder unscharf daraus herausgesucht zu werden.

Validierung vor Generierung

Ein weiterer unterschätzter Effizienzhebel ist die Reihenfolge im Workflow. Im Kreditprozess werden Handelslizenz, Gesellschaftsvertrag und Identitätsdokumente zuerst geprüft. Ist die Legitimität nicht geklärt, darf die teure Finanzanalyse gar nicht erst starten.

Ein Workflow, der Fehler spät erkennt, verschwendet Rechenzeit und Fachzeit. Ein Workflow, der Fehler früh stoppt, ist günstiger, schneller und besser prüfbar.“

Deshalb reicht es nicht, nur das einzelne KI-Modell zu kontrollieren. Entscheidend ist der gesamte KI-gestützte Vorgang. In unserem Beispiel ist das der Kreditvorschlag vom Dokumentencheck bis zur finalen Übergabe. Erst auf dieser Ebene lassen sich Kosten, Latenz, Tokenverbrauch, Datenzugriffe, CO₂-Schätzung und Audit-Evidenz sinnvoll messen.

Die falsche Kennzahl führt zur falschen Optimierung

Viele Organisationen messen zuerst die Inferenzkosten: Input-Tokens plus Output-Tokens mal Preis. Das ist einfach, aber häufig nutzlos. In einem Kreditprozess verursachen Rework, Eskalationen, unklare Begründungen und Review-Schleifen in der Regel höhere Kosten als der Modellaufruf.

Weniger Tokens sind somit nicht automatisch besser.“

Wenn ein System 50 Cent an Inferenzkosten spart, dafür aber fünf Minuten zusätzliche Review-Arbeit auslöst, ist nichts gewonnen. Die bessere Kennzahl heißt „Cost per completed proposal“: Was kostet ein abgeschlossener Kreditvorschlag inklusive Modellaufrufen, Tool-Calls, Extraktion, Spreading, Review-Zeit und Nacharbeit?

Green Code bedeutet also nicht, blind zu sparen, sondern kontrolliert zu entscheiden, wo Aufwand tatsächlich Wert erzeugt.“

Token-Budgets dürfen keine Evidenz abschneiden

Jede KI-Transaktion benötigt daher harte Budgets, ohne dass eine stumpfe Runtime-Truncation-Regel angewendet wird. In einer Kreditentscheidung Evidenz abzuschneiden, um unter einem Limit zu bleiben, ist kein Effizienzgewinn. Vielmehr steuert ein gutes Token-Budget die Kontextzusammenstellung: Welche Felder, extrahierten Werte, Policy-Passagen und Tool-Ergebnisse gehören hinein? Wenn das Budget nicht ausreicht, muss der Prozess an einen Menschen eskaliert werden und das Ereignis muss protokolliert werden.

Dasselbe gilt für ungesteuertes Retrieval, also den Abruf von Daten und Dokumenten (wie Bonitätsauskünften, Kontodaten oder Identitätsnachweisen) aus internen Datenbanken oder externen Quellen. Ein Kreditvorschlag, der vierzig Passagen zitiert, ist nicht besser erklärt, sondern schlechter steuerbar.

Model Routing ist eine Kontrollentscheidung

Wichtig ist die Nutzung eines angemessenen Modells: Legitimitätsprüfungen, Bonitätsprüfungen, Kennzahlen, Projektionen und Policy-Matching gehören in deterministische Schichten, kleinere Modelle oder Bestandssysteme. Große Sprachmodelle hingegen gehören dorthin, wo tatsächlich Sprache entsteht: Interpretation, Erklärung, Zusammenfassung, strukturierte Proposal-Erstellung.

Zum Routing selbst gehört ein Protokoll. Wenn zwei Antragsteller unterschiedliche Modellqualitäten erhalten, kann daraus ein Konsistenz- und Fairnessproblem entstehen. Deshalb muss jedes Modell-Tier dieselbe Mindestqualität aufweisen, es müssen klare Routing-Gründe vorliegen und eine laufende Evaluation erfolgen.

Prompt-Änderungen gehören in den Code-Review

Messbarkeit gehört deshalb in die CI/CD-Pipeline. Release-Gates sollten gegen repräsentative Transaktionen laufen: Token-Verbrauch, Retrieval Recall, Entscheidungsqualität, Kosten, Latenz und Truncation Events.

Eine Änderung des Prompt-Templates muss denselben Review-Pfad nehmen wie eine Code-Änderung.“

Auch Architecture Decision Records müssen KI-tauglich werden. Sie sollten unter anderem den Geschäftsprozess, Kritikalität, Datenklassen, Routing Policy, Token- und Retrieval-Budgets, Human Oversight und Retention dokumentieren. Das klingt bürokratisch, ist aber das Mindestmaß an Engineering, damit KI in regulierten Prozessen produktiv laufen kann. Die sauberste KI-Architektur ist nicht die, die am meisten generiert. Sie ist die, die am klarsten trennt: Sprache zu Sprache, Arithmetik zu Arithmetik, Daten zu Systems of Record und nicht zuletzt Entscheidungen zu verantwortlichen Menschen. Alles andere ist kein Fortschritt, sondern Legacy-IT mit einem Sprachmodell davor. Thomas Steirer, Nagarro