Ein Modell extrahiert einen Betrag aus einer Meldung. Es nennt den Wert 4,2 Millionen. Sind das Dollar oder Euro? Ist 4,2 die tatsächliche Zahl, oder hat das Modell eine 4,23 gerundet, auf die es ankam? Stand diese Zahl überhaupt im Dokument, oder hat das Modell eine plausibel wirkende Lücke gefüllt? Für sich genommen liefert keine dieser Fragen eine Antwort, die Sie vor einem Prüfer verteidigen könnten. Das Modell hat Prosa erzeugt, und Prosa ist nichts, worauf ein nachgelagertes Finanzsystem jemals handeln dürfen sollte.
Das ist der Teil der Finanz-KI, der die geringste Aufmerksamkeit bekommt und den größten Schaden anrichtet. Alle konzentrieren sich darauf, ob das Modell klug genug ist. Das schwierigere Problem besteht darin, seine Ausgabe langweilig genug zu machen: in der Form vorhersehbar, vor der Nutzung geprüft und im Zweifel ablehnbar. Eine Zahl, die in einem Hauptbuch landet, hat Konsequenzen. Der Weg, auf dem sie dorthin gelangt ist, muss einer sein, den Sie nachvollziehen können.
Die Form festlegen, bevor Sie dem Wert vertrauen
Der erste Schritt ist, überhaupt keinen Freitext mehr zu akzeptieren. Moderne Modelle unterstützen strukturierte Ausgabe und Function Calling: Sie übergeben dem Modell ein JSON-Schema, und es liefert einen Wert zurück, der diesem Schema entspricht. Statt nach “der Umsatzzahl” zu fragen und zu parsen, was auch immer zurückkommt, definieren Sie eine Funktion mit typisierten Argumenten: einen Betrag als Zahl, eine Währung als Enum, einen Zeitraum als Datum, ein Konfidenzfeld und eine Quellenstelle, auf die das Modell verweisen muss. Das Modell erfüllt diesen Vertrag, oder der Aufruf schlägt fehl.
Schon das beseitigt eine ganze Klasse von Fehlern. Sie parsen nicht länger “4,2 Millionen USD” aus einem Satz und hoffen, dass die Regex gehalten hat. Aber Schemakonformität ist nicht dasselbe wie Korrektheit. Eine durch ein JSON-Schema beschränkte Ausgabe garantiert, dass die Antwort wohlgeformt ist. Sie sagt nichts darüber aus, ob der Wert richtig ist, im plausiblen Bereich liegt oder überhaupt existiert. Das ist eine eigene Aufgabe, und wer sie überspringt, fährt damit auf die Nase.
Typen und Wertebereiche prüfen, bevor irgendetwas handelt
Die Ausgabevalidierung läuft nach dem Modell und bevor irgendein System den Wert liest. Das Schema verschafft Ihnen wohlgeformte Daten; die Validierung entscheidet, ob Sie danach handeln. Wir behandeln beides als getrennte Ebenen, weil sie aus unterschiedlichen Gründen versagen und unterschiedliche Reaktionen erfordern.
Die Prüfungen, die wir zwischen Modell und Hauptbuch schalten:
- Typ und Einheit: Der Betrag ist eine Zahl, die Währung ist eine, mit der Sie handeln, das Datum löst sich zu einem realen Berichtszeitraum auf
- Wertebereich und Plausibilität: Die Zahl liegt innerhalb von Grenzen, die Sie begründen können, sodass ein Quartalsumsatz von minus zwölf oder einer, der drei Größenordnungen vom Vorzeitraum abweicht, gestoppt statt gebucht wird
- Quellenbindung: Der Wert lässt sich an die vom Modell zitierte Stelle zurückbinden, sodass eine Extraktion, die auf nichts verweist, als Ablehnung und nicht als Ergebnis behandelt wird
- Feldübergreifende Konsistenz: Zeitraum, Währung und Entität stimmen miteinander und mit dem überein, was der restliche Datensatz bereits weiß
Ein Wert, der eine dieser Prüfungen nicht besteht, wird nicht durch die zweitbeste Schätzung ersetzt. Er wird an einen Menschen weitergeleitet oder abgelehnt. Der ganze Sinn besteht darin, dass nichts auf einer Zahl handelt, die das System nicht prüfen konnte.
Ablehnungen, Konfidenz und das Nicht-Handeln
Manchmal ist die richtige Ausgabe gar keine Ausgabe. Die Zahl steht nicht im Dokument, das Modell rät, oder das Konfidenzfeld kommt mit niedrigem Wert zurück. Ein Finanzsystem braucht für diesen Fall einen ausdrücklichen Pfad, genauso wie eine Kreditentscheidung einen Begründungscode braucht und kein Achselzucken. Wir machen die Ablehnung zu einem vollwertigen Rückgabewert mit eigener Behandlung, sodass eine Extraktion mit niedriger Konfidenz zur Prüfung in die Warteschlange geht, statt stillschweigend auf null zurückzufallen. Stille Standardwerte sind der Weg, auf dem aus einem fehlenden Wert ein falscher Wert wird, den niemand markiert hat.
Dann ist da noch die Grenze zwischen dem Modell und den Systemen, die es berührt. Modellaufrufe schlagen fehl, laufen in Zeitüberschreitungen und werden wiederholt, und ein erneuter Versuch, der dieselbe Transaktion zweimal bucht, ist schlimmer als der ursprüngliche Fehler. Die Aktion, die ein validierter Wert auslöst, muss daher idempotent sein: mit Quelldatensatz und Zeitraum als Schlüssel, sodass ein erneutes Abspielen ein No-Op ist und keine zweite Buchung. Bauen Sie den Idempotenzschlüssel zuerst, bevor Sie das Modell anbinden, denn Wiederholungen sind hier kein Sonderfall. Sie sind der Normalbetrieb von allem, was über ein Netzwerk mit einem LLM spricht.
Nichts davon macht das Modell klüger. Es macht die Ausgabe des Modells zu etwas, wofür Sie geradestehen können. Das Modell schlägt einen Wert vor; das Schema, die Validatoren und die Idempotenzschicht entscheiden, ob dieser Wert überhaupt etwas bedeuten darf. Im Finanzwesen ist diese Reihenfolge nicht optional. Eine Zahl, die Sie nicht prüfen können, ist eine Zahl, die Sie nicht buchen können.