Prompt Injection und Retrieval-Bias: Die Risiken, die SR 11-7 nie abgedeckt hat

SR 11-7 wurde 2011 verfasst, zwölf Jahre bevor irgendjemand im Finanzwesen eine Frage in ChatGPT eintippte und eine Zahl zurückbekam, die wie eine Antwort aussah. Die Leitlinien von Fed und OCC, die das Management von Modellrisiken für eine ganze Generation prägten, gingen davon aus, dass ein Modell etwas ist, das man baut, dokumentiert und gegen zurückgehaltene Daten validiert. Es hatte Eingaben, Gleichungen und Ausgaben, die sich reproduzieren ließen. Dieselben Daten zweimal verarbeitet, dasselbe Ergebnis erhalten. Diese Annahme galt über ein Jahrzehnt lang für Kredit-Scorecards, VaR-Engines und Pricing-Modelle.

Für ein großes Sprachmodell gilt sie nicht. Und genau in der Lücke zwischen dem, was SR 11-7 zu steuern geschaffen wurde, und dem, was ein LLM tatsächlich tut, leben die neuen Fehler.

Drei Fehler, die das alte Rahmenwerk nie benennen musste

Das klassische Modellrisiko kannte schon immer zwei große Kategorien: Das Modell ist grundlegend falsch, oder das Modell wird falsch eingesetzt. Beides gilt weiterhin. Doch ein LLM, das in einen Finanzprozess eingebunden ist, bringt drei Fehlerformen mit sich, für die ein Validierungs-Playbook von 2011 keine saubere Entsprechung hat.

Halluzination. Ein traditionelles Modell, dem Daten fehlen, gibt einen Fehler oder einen Nullwert zurück. Ein LLM hingegen erzeugt angesichts einer Lücke trotzdem eine selbstbewusste, flüssig formulierte, plausible Zahl. Die OWASP Top 10 für LLM-Anwendungen aus dem Jahr 2025 führen dies als Misinformation (LLM09) und benennen es unmissverständlich: Die Ausgabe klingt autoritativ, ob sie nun in irgendetwas Realem verankert ist oder nicht. In einem Kreditmodell löst ein fehlendes Feld eine Ausnahme aus. In einem LLM wird ein fehlendes Feld stillschweigend mit Erfindung gefüllt.

Prompt Injection. Das ist der Punkt, der die erfahrensten Intuitionen aushebelt. OWASP stuft Prompt Injection als das LLM-Risiko Nummer eins ein (LLM01), und die gefährliche Variante ist die indirekte Injection: Anweisungen, die in den Daten verborgen sind, die das Modell liest, nicht in der Frage, die der Nutzer stellt. Ein Modell ist kein statisches Artefakt, das man einmal validiert. Es ist ein Interpreter, der Anweisungen aus jedem Text entgegennimmt, der es erreicht, einschließlich einer Fußnote in einem hochgeladenen PDF, eines Kommentars in einer Tabelle oder eines Beschreibungsfelds, das aus Ihrem ERP gezogen wird. Die Daten sind die Angriffsfläche.

Retrieval-Bias. Die meisten LLM-Systeme im Finanzwesen nutzen Retrieval-Augmented Generation: relevante Dokumente abrufen, sie dem Modell übergeben und es um eine Antwort bitten. Die Qualität der Antwort ist davon abhängig, was der Retriever zutage gefördert hat. OWASP benennt die zugrunde liegenden Schwachstellen als Vector and Embedding Weaknesses (LLM08). Greift der Retriever das Deck des letzten Quartals statt des aktuellen Abschlusses ab oder liefert er drei optimistische Analystennotizen und keine einzige mahnende, dann argumentiert das Modell getreu über eine verzerrte Stichprobe und produziert eine selbstbewusste, falsche, vertretbar klingende Schlussfolgerung. Niemand hat etwas eingeschleust. Die Verzerrung liegt in dem, was abgerufen wurde.

Keiner dieser Fälle bedeutet, dass „das Modell fehlkalibriert ist”. Es sind keine Probleme, die man durch Backtesting gegen einen Holdout-Datensatz aufdeckt. Genau deshalb sieht ein für Scorecards konzipiertes Validierungs-Rahmenwerk sie nicht kommen.

Jeder Fehler lässt sich einer Kontrolle zuordnen. Nicht einem Haftungsausschluss.

Die bequeme Reaktion ist ein Banner mit der Aufschrift „KI kann Fehler machen”. Das ist keine Kontrolle. Es ist eine Haftungsverlagerung auf den Leser. Jeder dieser drei Fehler lässt sich etwas Konkretem zuordnen, das Sie aufbauen können, und die Form der Lösung ist in jedem Fall dieselbe: Hören Sie auf, das Sprachmodell jene Teile des Prozesses berühren zu lassen, in denen ihm kein Vertrauen gebührt.

Bei der Halluzination besteht die Kontrolle darin, dem Modell die Erzeugung von Zahlen gänzlich zu untersagen. Die Aufgabe des LLM ist es, die Frage zu verstehen und sie weiterzuleiten; die Zahlen stammen aus einem System of Record. Existiert die Zahl in den zugrunde liegenden Daten nicht, lautet die korrekte Ausgabe „nicht verfügbar”, zurückgegeben von der Datenschicht und nicht eine flüssige Schätzung, die das Modell synthetisiert hat. Das setzen Sie durch, indem Sie das Abrufen eines Werts von der Erzeugung von Sprache darüber trennen.

Bei der Prompt Injection besteht die Kontrolle in der Isolation zwischen dem, was das Modell liest, und dem, was das Modell tun kann. Behandeln Sie alle abgerufenen Inhalte als nicht vertrauenswürdige Eingabe, genauso wie eine Webanwendung Formulardaten von Nutzern behandelt. Text, der aus einem Dokument gezogen wird, darf eine Antwort informieren, aber er darf niemals beeinflussen können, welche Berechnung ausgeführt wird oder gegen welches Konto sie läuft. Der Anweisungssatz wird durch Ihren Code festgelegt und ist nicht durch etwas verhandelbar, das in eine Lieferantenrechnung geschrieben wurde.

Beim Retrieval-Bias besteht die Kontrolle aus Nachvollziehbarkeit plus Determinismus. Jede Zahl, die eine KI zutage fördert, sollte einen Quellenverweis auf eine bestimmte Quellzeile in einem abgestimmten Modell tragen, sodass ein Prüfer nicht nur die Zahl, sondern auch die Stichprobe nachvollziehen kann, aus der sie stammt. Und die Berechnungen auf Basis dieser Zahlen, Wachstumsraten, Margen, Runway, Covenant-Kennzahlen, sollten durch eine deterministische Engine laufen, die jedes Mal dasselbe Ergebnis liefert, und nicht durch eine Token-Vorhersage, die je nach Formulierung eine andere Antwort produziert.

Der architektonische Zug: Abruf und Berechnung sind verschiedene Aufgaben

Die einzige Idee, die allen drei Kontrollen zugrunde liegt, ist Trennung. Abruf ist ein Suchproblem. Berechnung ist ein Rechenproblem. Sprache ist ein Darstellungsproblem. SR 11-7 musste diese nie unterscheiden, weil alte Modelle alle drei deterministisch erledigten. LLMs verschmelzen sie zu einem einzigen probabilistischen Klumpen, und in dieser Verschmelzung konzentriert sich das Risiko.

Auf diesem Gestaltungsprinzip ist Rexfin aufgebaut. Verbinden Sie Ihre Buchhaltungs- und Finanzdatenplattformen, QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, ein Data Warehouse, oder laden Sie Abschlüsse direkt hoch, und die Plattform baut ein einziges abgestimmtes Finanzmodell, das mit dem Hauptbuch übereinstimmt. Dieses Modell ist die alleinige Quelle der Wahrheit. Wenn die KI eine Frage stellt, ruft sie Zahlen aus diesem Modell ab, anstatt sie zu erfinden. Die Berechnung läuft durch eine deterministische Engine, nicht durch das LLM, sodass dieselbe Frage stets dieselbe Zahl zurückgibt. Und jede Ausgabe lässt sich bis zu einer Quellzeile zurückverfolgen, was eine selbstbewusste Antwort in eine überprüfbare verwandelt.

Konkret gesagt: Eine per Prompt Injection in ein hochgeladenes PDF eingeschleuste Anweisung kann eine Covenant-Berechnung nicht umschreiben, weil die Berechnung Code ist und kein Vorschlag, dem das Modell frei folgen darf. Ein verzerrter Abruf kann eine Wachstumsrate nicht stillschweigend aufblähen, weil die Rate deterministisch aus abgestimmten Zahlen berechnet wird und der Quellenverweis genau zeigt, welche Zahlen. Eine halluzinierte Zahl kann es nicht bis in ein Board-Deck schaffen, weil das Modell nicht das ist, was die Zahlen produziert.

Was dies nicht löst

Ehrlichkeit über die Grenzen ist Teil der Kontrolle. Die Isolation der Berechnung vom Abruf macht Ihren Abruf nicht perfekt; ist das abgestimmte Modell falsch, dann ist die nachvollziehbare Antwort nachvollziehbar falsch, was immer noch besser ist als stillschweigend falsch, aber nicht dasselbe wie richtig. Determinismus validiert die zugrunde liegenden Daten nicht, er hindert das Modell lediglich daran, neue Fehler obendrauf zu setzen. Und keine Architektur beseitigt die Notwendigkeit menschlicher Prüfung bei wesentlichen Entscheidungen. Was sie tut, ist den Wirkungsradius des LLM von „alles, was es sagt, ist eine potenzielle Finanzzahl” auf „es hilft Ihnen, Zahlen zu finden und zu formulieren, für die ein deterministisches System bereits bürgt” zu verkleinern. Das ist eine weit kleinere zu steuernde Fläche und eine weit leichter zu validierende.

Ein skeptischer CFO sollte sich nicht mit „die KI ist sorgfältig” zufriedengeben. Sorgfältig ist keine Kontrolle. Die Frage, die man jedem KI-Finanzwerkzeug stellen sollte, ist enger und härter: Was genau verhindert mechanisch, dass eine vom Modell erfundene Zahl, oder eine Zahl, zu deren Erzeugung ein vergiftetes Dokument es angewiesen hat, eine Entscheidung erreicht? Lautet die Antwort ein Konfidenzwert oder ein Haftungsausschluss, dann lautet die Antwort: nichts.

Für das umfassendere Bild, wie diese Kontrollen zusammenpassen, siehe die Themensäule zur KI-Governance im Finanzwesen, die Referenzarchitektur für einen KI-Kontroll-Stack und warum die Validierung von Anbieter-LLMs am Output und nicht an den Gewichten ansetzen muss.

Wenn Sie Abruf, deterministische Berechnung und durchgängige Nachvollziehbarkeit an Ihrem eigenen Hauptbuch in Aktion sehen möchten, vereinbaren Sie eine Demo und bringen Sie eine Zahl mit, der Sie sich bislang nicht zu vertrauen getraut haben.