Der KI-Kontroll-Stack für Finanzdaten: eine Referenzarchitektur

Ein fünfschichtiges Kontrollmodell für KI auf Finanzdaten: Datenqualität, deterministische Berechnung, Output-Prüfung, Zugriffssteuerung und revisionssichere Protokollierung.

Ein Controller fragt den KI-Assistenten nach dem Free Cashflow des letzten Quartals. Die Antwort kommt in zwei Sekunden, selbstbewusst, sauber formatiert, scheinbar mit Quelle. Die Zahl liegt um 4 % daneben. Niemand bemerkt es, weil es nichts gibt, womit man es bemerken könnte. Das Modell hat eine Kennzahl abgerufen, im Kopf etwas gerechnet und das Ergebnis ausgegeben. Kein zweites Augenpaar, keine Neuberechnung, kein Protokoll.

Genau diese Lücke schleppen die meisten Einführungen von „KI im Finanzbereich” mit sich herum. Das Modell ist in Ordnung. Was fehlt, ist die Architektur darum herum. Wenn die Frage lautet, ob ein CFO eine KI-generierte Zahl vor einem Prüfungsausschuss vertreten kann, hängt die Antwort fast vollständig davon ab, was zwischen dem Sprachmodell und dem Hauptbuch sitzt.

Dies ist eine Referenzarchitektur für genau diese Mitte. Stellen Sie sich fünf Kontrollschichten vor, von denen jede einen anderen Fehler abfängt – so übereinander gestapelt, dass eine Zahl einen Menschen nicht erreichen kann, ohne alle Schichten durchlaufen zu haben.

Warum ein einzelnes Modell keine Kontrolle ist

Beginnen wir mit den unbequemen Benchmark-Daten. Bei Aufgaben rund um Finanztabellen erreichen die stärksten Modelle des Jahres 2026 in der Spitze rund 82 % Genauigkeit – grob gerechnet ein Fehler auf sechs Fragen. Bei anspruchsvollerem mehrstufigem Finanz-Reasoning liegen selbst Spitzenmodelle im hohen 80er- bis niedrigen 90er-Prozentbereich, und sie scheitern bei zeitbezogenem Schlussfolgern und Szenarioarbeit – also genau dem, woraus der Finanzbereich besteht. Kein eigenständiges Sprachmodell kommt auf Fehlerquoten, die niedrig genug für den unbeaufsichtigten Produktivbetrieb wären. Das ist kein Prompt-Problem, das sich wegoptimieren ließe. Es ist eine Eigenschaft der Art und Weise, wie diese Systeme Text erzeugen.

Das Designziel ist also nicht ein besseres Modell. Es geht darum, die schwächste Fähigkeit des Modells – zuverlässig zu rechnen – irrelevant zu machen und seine stärkste Fähigkeit – lesen und erklären – mit Kontrollen zu umgeben. Jede der folgenden Schichten erfüllt genau eine Aufgabe.

Schicht 1: Datenqualität an der Grenze

„Garbage in” ist nach wie vor die häufigste Ursache falscher Antworten – und das Unspektakulärste, was es zu beheben gilt. Bevor irgendetwas das Modell erreicht, müssen die Eingangsdaten abgestimmt sein, nicht bloß vorhanden. Das heißt: Zahlen aus QuickBooks, Xero, NetSuite, Sage, einer SAP- oder Oracle-Instanz, einem Data Warehouse oder einem hochgeladenen PDF-Auszug münden in ein einziges Modell, das sich auf das Hauptbuch zurückführen lässt. Zugeordnete Konten, einheitliche Perioden, eliminierte Intercompany-Beziehungen, ein dokumentierter Kontenplan.

Die Kontrolle liegt hier in der Abstimmung selbst: eine Tie-out-Prüfung, die lautstark fehlschlägt, wenn das zusammengesetzte Modell nicht auf den Cent genau mit dem Quell-Hauptbuch übereinstimmt. Besteht Schicht 1 nicht, läuft nichts Nachgelagertes. Eine saubere Berechnung auf schmutzigen Eingangsdaten ist nichts weiter als eine selbstbewusste falsche Antwort. Genau dieses abgestimmte Fundament lassen die meisten Teams aus, und es ist der Grund, warum ihre Demos in dem Moment zusammenbrechen, in dem echte Daten ins Spiel kommen – ein Punkt, den wir ausführlich in warum ein Tabellenblatt das falsche Fundament für KI im Finanzbereich ist behandeln.

Schicht 2: Deterministische Berechnung

Dies ist die tragende Schicht. Das Sprachmodell berechnet niemals den Free Cashflow, kehrt niemals eine Kennzahl um und entscheidet niemals, ob eine Veränderung absolut oder prozentual zu lesen ist. Es erkennt, wonach der Nutzer fragt und welche Größen beteiligt sind, und ruft dann eine deterministische Engine auf, die die eigentliche Formel auf das abgestimmte Modell anwendet.

Gleiche Eingaben, gleiches Ergebnis, jedes Mal. Ein Controller kann das Ergebnis so belegen, wie er eine Tabellenzelle belegen würde: auf die Operanden zurückverfolgen, die Formel prüfen, neu berechnen. Die Arithmetik lebt im Code mit einer festen Definition, nicht in einer Wahrscheinlichkeitsverteilung über Tokens. Das ist die eine Veränderung, die Sie von „meistens richtig” zu „richtig und belegbar” bringt – und der Grund, warum deterministische und wiederholbare Berechnung zu der Erwartung geworden ist, mit der Prüfer an KI-Ergebnisse herangehen.

Schicht 3: Output-Prüfung

Selbst bei sauberen Eingaben und deterministischer Berechnung wollen Sie eine Kontrolle zwischen dem Ergebnis der Engine und dem Nutzer. Die Output-Prüfung ist ein Satz von Regeln, die jede Antwort durchlaufen, bevor sie angezeigt wird: Liegt die Zahl in einem plausiblen Bereich? Geht die Bilanz auf? Stimmt das Vorzeichen für einen Mittelabfluss? Bewegt sich der Umsatz dieses Quartals in einem nachvollziehbaren Korridor der Vorquartale?

Das sind keine KI-Urteile. Es sind dieselben Plausibilitätsprüfungen, die ein versierter Analyst reflexartig durchführt – als deterministische Zusicherungen kodiert. Schlägt eine fehl, wird die Antwort zurückgehalten und markiert, statt ausgeliefert. Aufsichtsbehörden erwarten zunehmend genau diese Art von verhaltensbasierter Validierung – also zu prüfen, was das System ausgibt, statt nur das Modell zu inspizieren –, denn bei einem Anbieter-LLM gehören die Gewichte ohnehin nicht Ihnen und sind nicht einsehbar. Diese Einschränkung behandeln wir in Output-basierte Validierung für Anbieter-LLMs.

Schicht 4: Zugriffssteuerung

Wer darf fragen, und was darf er sehen? Eine KI-Oberfläche, die Berechtigungen einebnet, ist ein Datenleck mit Chatfenster. Die Kontrollschicht muss dieselben Beschränkungen auf Ebene von Einheit, Periode und Feld durchsetzen wie die zugrunde liegenden Systeme, und sie muss jede Abfrage einer realen menschlichen Identität zuordnen – nicht einem gemeinsam genutzten Dienstkonto, das den Prüfpfad wertlos macht.

Bei KI fällt das stärker ins Gewicht als bei einem statischen Bericht, weil die Oberfläche zu offenen Fragen einlädt. Jemand aus einem regionalen Team, der eine breit gefasste Frage stellt, sollte keine Konzernzahlen zurückbekommen, nur weil das Modell hilfsbereit war. Die Zugriffssteuerung sitzt im Pfad der Abfrage, nicht nachträglich angeflanscht.

Schicht 5: Revisionssichere Protokollierung

Die letzte Schicht zeichnet alles auf, was die anderen vier getan haben – in einer Form, die sich nicht stillschweigend ändern lässt. Für jede Antwort: wer gefragt hat, was gefragt wurde, welche Quelldaten und welche Version in die Berechnung eingeflossen sind, welche Formel gelaufen ist, was die Output-Prüfungen zurückgegeben haben und welche Zahl ausgegeben wurde. Append-only, mit Zeitstempel, aufbewahrt.

Das ist es, was aus einer Zahl eine belastbare Zahl macht. Monate später, wenn ein Aufsichtsratsmitglied eine Kennzahl hinterfragt oder ein Prüfer einen Nachweis verlangt, spielen Sie den Eintrag erneut ab und reproduzieren das exakte Ergebnis aus den exakten Eingaben. Im Protokoll laufen auch die regulatorischen Erwartungen leise zusammen – die Model-Risk-Rahmenwerke von 2026, die SR 11-7 abgelöst haben, setzen stark auf Nachvollziehbarkeit und Reproduzierbarkeit, und die Protokollierungspflichten des EU AI Act weisen in dieselbe Richtung.

Wie die Schichten gemeinsam kontrolliert versagen

Der Sinn des Stapelns ist Verteidigung in der Tiefe. Ein fehlerhafter Quellwert wird in Schicht 1 abgefangen. Ein Denkfehler tritt gar nicht erst auf, weil Schicht 2 das Schlussfolgern aus der Berechnung entfernt hat. Ein Ergebnis außerhalb des plausiblen Bereichs wird in Schicht 3 zurückgehalten. Ein Nutzer, der Daten sieht, die er nicht sehen sollte, wird in Schicht 4 gestoppt. Und falls dennoch etwas schiefgeht, lässt Sie Schicht 5 präzise herausfinden, was und wann.

Seien Sie ehrlich, was die Grenzen angeht. Diese Architektur macht das Sprachmodell nicht genau; sie macht die Ungenauigkeit des Modells unschädlich. Sie macht die menschliche Prüfung bei folgenreichen Zahlen nicht überflüssig; sie macht diese Prüfung schnell und fundiert statt zu einem Vertrauenssprung. Und sie verursacht Latenz und Entwicklungsaufwand – die deterministische Engine, die Abstimmung, die Protokollierung sind echte Arbeit. Der Gegenwert ist ein Ergebnis, das ein Controller tatsächlich unterschreiben wird.

Eine verlockende Abkürzung verdient es, benannt zu werden: ein LLM über ein Protokoll wie MCP an Ihr ERP anbinden und die Sache für erledigt erklären. Das verschafft dem Modell geregelten Zugriff auf Live-Daten, was ungefähr Schicht 4 entspricht, lässt das Modell aber fragile Arithmetik auf rohen Hauptbuchfeldern betreiben – ohne Abstimmung und ohne deterministische Berechnung. Der Abruf ist nicht der schwierige Teil. Die mittleren Schichten sind es.

Das Fazit

Wenn Sie sich eines merken: Das Modell ist die unwichtigste Komponente in einem vertrauenswürdigen KI-Finanzsystem. Der Wert liegt im abgestimmten Fundament darunter und in den Kontrollen darum herum. Bauen Sie diese fünf Schichten, und KI kann den ganzen Tag abrufen, erklären und Szenarien modellieren – mit jeder Zahl bis zur Quelle nachverfolgbar. Lassen Sie sie weg, und Sie haben eine schnelle Methode, um selbstbewusste Fehler zu erzeugen.

Rexfin ist die Schicht, die diese Arbeit leistet – ein abgestimmtes Modell, eine deterministische Berechnungs-Engine und revisionssichere Protokollierung, während das LLM beim Reasoning und Abruf bleibt, wo es stark ist. Wenn Sie sehen möchten, wie eine Zahl von der Antwort in einer Vorstandspräsentation bis zur Buchung im Hauptbuch zurückverfolgt wird, buchen Sie eine Demo.