Jedes Finance-AI-Projekt, das wir übernehmen, landet am Ende bei ungefähr denselben sechs Schichten: eine Datenschicht, die Point-in-Time-Korrektheit garantiert, Retrieval über Dokumente und Datensätze, das Modell, das die eigentliche Reasoning-Arbeit leistet, Guardrails, die einschränken, was es ausgeben darf, menschliche Prüfung dort, wo viel auf dem Spiel steht, und ein Audit-Trail, mit dem sich jede Entscheidung später rekonstruieren lässt. Die Topologie variiert. Die Grundform nicht.
Diese Konstanz ist es wert, ausgesprochen zu werden, denn die meisten Finance-AI-Projekte scheitern an denselben vorhersehbaren Stellen, und eine Referenzarchitektur ist im Grunde eine Liste genau dieser Stellen mit einer Verteidigung an jeder einzelnen. Was folgt, ist der Ausgangspunkt, den wir auf das erste Whiteboard skizzieren, bevor irgendjemand über die Wahl des Modells gestritten hat.
Die Datenschicht entscheidet über alles Nachgelagerte
Die Zahl, die das Modell liest, muss die Zahl sein, die in dem Moment gültig war, als die Entscheidung getroffen wurde. Das klingt offensichtlich und wird ständig verletzt. Ein Modell, das im Trainingsdatensatz einen Kreditantrag bewertet, sieht die Umsatzzahl eines Kreditnehmers, die zwei Quartale später korrigiert wurde. Diese Korrektur sickert rückwärts in die Features, die Offline-Evaluation sieht hervorragend aus, und das System bleibt an dem Tag hinter den Erwartungen zurück, an dem es einem Kreditnehmer begegnet, dessen Zukunft man nicht kennen kann. Lookahead ist der teuerste Bug in Finance AI und der am schwersten zu bemerkende, denn an einem leckenden System sieht alles gesund aus, bis es in Produktion ist.
Die Datenschicht trägt deshalb Pflichten, die eine Allzweck-Pipeline nicht hat:
- Point-in-Time-Korrektheit. Jeder Datensatz beantwortet die Frage „Was wussten wir, und wann wussten wir es?” – nicht nur „Was ist jetzt wahr?”.
- Lineage. Für jede Zahl, die das Modell konsumiert hat, können Sie das Quellsystem, den Extraktionsschritt und die Transformation benennen, die sie erzeugt hat.
- Entity Resolution. Dieselbe Gegenpartei taucht über vier Systeme hinweg als drei verschiedene Strings auf, und Sie brauchen eine einzige Identität, bevor Sie über Exposure oder Covenant-Historie nachdenken können.
- Reconciliation. Wenn zwei Quellen eine Zahl unterschiedlich melden, wird die Diskrepanz sichtbar gemacht und durch eine Regel aufgelöst – nicht stillschweigend gemittelt.
Machen Sie diese Schicht falsch, und kein Modell, kein Retrieval-Trick und kein Prompt rettet Sie. Machen Sie sie richtig, und vieles vom Rest ist gewöhnliches Engineering.
Retrieval und Modell sind der austauschbare Teil
Das ist die Schicht, über die am meisten diskutiert wird – und die am wenigsten darüber entscheidet, ob das System funktioniert. Retrieval holt die relevanten Filings, Vertragsklauseln, früheren Memos und internen Datensätze in den Kontext. Das Modell arbeitet mit ihnen. Beide sind weitgehend austauschbar; Sie werden das Modell mindestens einmal über die Lebensdauer des Systems ersetzen, und die Architektur sollte davon ausgehen.
Zwei Dinge verdienen hier Aufmerksamkeit. Erstens: Retrieval über Finanzdokumente wird durch semantische Suche allein selten gut bedient. Eine Anfrage nach einer bestimmten Covenant-Schwelle oder einem Posten in einem Filing ist ebenso sehr ein lexikalischer wie ein semantischer Match, und Hybrid Retrieval, das beides kombiniert, schlägt jede der beiden Varianten für sich genommen zuverlässig. Zahlen, definierte Begriffe und Abschnittsverweise sind ihrer Natur nach exakt, und dichte Embeddings verwischen sie.
Zweitens: Das Modell braucht ein Eval-Set, das die tatsächliche Arbeit abbildet, keinen generischen Benchmark. Für einen Kreditmemo-Assistenten heißt das: echte Memos mit bekannten, korrekten Zahlen und ein Grader, der die Zahlen prüft, nicht die Prosa. Für einen Transaction-Monitoring-Assistenten heißt das: gelabelte Alerts mit einem definierten False-Positive-Budget, denn die Kosten des Systems werden in den Analystenstunden gemessen, die für das Abarbeiten von Rauschen draufgehen. Ohne domänenspezifisches Eval-Set tunen Sie gegen ein Bauchgefühl, und Bauchgefühle driften.
Guardrails, Prüfung und Audit sind der Punkt, an dem Finance anders ist
Ein allgemeines KI-Produkt kann den Output des Modells direkt an den Nutzer ausliefern. Ein Finance-System kann das in der Regel nicht, weil der Output in eine Entscheidung einfließt, an deren anderem Ende ein Regulator, eine Gegenpartei oder eine Bilanz steht. Drei Schichten liegen zwischen dem Modell und der Konsequenz.
Guardrails schränken den Ausgaberaum ein, bevor irgendjemand ihn sieht. Eine Zahl, die das Modell meldet, muss auf eine abgerufene Quelle zurückführbar sein, sonst verlässt sie das System nicht; nicht belegte Zahlen sind der Fehlermodus, auf den es ankommt, und ein selbstbewusster Satz mit einer falschen Zahl darin ist schlimmer als eine Absicherung. Guardrails erzwingen außerdem die Grenzen, die das Modell nicht eigenständig überschreiten darf – etwa die Verweigerung einer Handlung dort, wo eine Regulierung wie der ECOA vorschreibt, wie eine Kreditentscheidung erklärt werden darf.
Menschliche Prüfung wird nach Wesentlichkeit platziert, nicht flächendeckend. Die Designfrage lautet: Welche Fälle gehen glatt durch, und welche halten für einen Menschen an? Steuern Sie nach der kalibrierten Konfidenz des Modells und den Kosten eines Fehlers: Fälle mit geringem Risiko und hoher Konfidenz werden zu Straight-Through Processing, und die Aufmerksamkeit des Prüfers gilt den mehrdeutigen und den teuren Fällen. Eine Prüfschicht, die einen Menschen bittet, alles zu kontrollieren, ist eine Prüfschicht, die im dritten Monat niemand mehr nutzt.
Der Audit-Trail ist keine Log-Datei. Für jede Entscheidung, die das System erzeugt hat, sollten Sie die Inputs so rekonstruieren können, wie sie zu diesem Zeitpunkt standen, dazu die abgerufene Evidenz, die Modellversion, die ausgelösten Guardrails und wer geprüft hat. Genau das erwartet SR 11-7 vom Model Risk Management und genau das erwartet der EU AI Act an Aufzeichnungspflichten für Hochrisikosysteme – und genau das wollen Sie auch, wenn zum ersten Mal eine Quartalsendzahl angezweifelt wird und jemand fragt, wie die Maschine zu ihr gekommen ist.
Wo Drift und Quartalsende wohnen
Zwei operative Realitäten liegen unter allen sechs Schichten. Modelle und Daten driften, deshalb ist das Eval-Set kein Launch-Gate, das man einmal besteht; es läuft nach Zeitplan gegen frische Daten, und eine Kalibrierung, die abrutscht, wird als Incident behandelt. Und Finance hat eine Uhr. Das Quartalsende konzentriert das Volumen und erhöht die Kosten jedes Fehlers genau in dem Moment, in dem der Durchsatzbedarf seinen Höhepunkt erreicht – die Steuerung der menschlichen Prüfung und die Guardrails müssen also unter Last halten, nicht nur in der Demo. Die Tage, die darüber entscheiden, ob ein Design funktioniert, sind die, an denen die Queue tief ist und der Abschluss ansteht. Ein Design, das nur hält, wenn der Traffic ruhig ist, hat diese Tage nie erlebt.
Häufige Fragen
Brauche ich einen Feature Store, um ein Finance-AI-System zu bauen?
Nicht am ersten Tag. Was Sie brauchen, sind Point-in-Time-korrekte Daten und Lineage; ein Feature Store ist eine Möglichkeit, reproduzierbare, leckagefreie Features zu erhalten, sobald mehrere Systeme dieselben Inputs teilen. Beginnen Sie mit der Datenschicht und fügen Sie den Store hinzu, wenn die Wiederverwendung ihn rechtfertigt.
Wo im Loop sollte ein Mensch sitzen?
An genau dem Punkt, an dem ein falscher Output Kosten verursacht, die das Modell nicht tragen kann: eine Freigabe, eine Meldung, eine Zahlungsauslösung. Steuern Sie nach Konfidenz und Wesentlichkeit, damit Prüfer die relevanten Fälle sehen, nicht jeden Fall.
Wodurch unterscheidet sich das von einem allgemeinen RAG-Stack?
Die Retrieval- und Modellschicht sehen ähnlich aus. Der Unterschied liegt in allem drumherum: Point-in-Time-Korrektheit in der Datenschicht, ein False-Positive-Budget für das Modell und ein Audit-Trail, der jede Entscheidung Monate später für einen Prüfer rekonstruiert.