Red Teaming von KI-Systemen in Finanzdienstleistungen

Red Teaming eines Finanz-KI-Systems bedeutet, es absichtlich anzugreifen, in einem kontrollierten Harness, um Eingaben zu finden, die es dazu bringen, Daten preiszugeben, seine Guardrails zu umgehen, ein Tool aufzurufen, das es nicht aufrufen sollte, oder eine verzerrte Entscheidung zu treffen. Sie führen die Angriffe aus, die ein Angreifer und ein Prüfer ausführen würden, protokollieren, was bricht, und schließen den Pfad, bevor einer von beiden ihn findet. Es ist adversariales Testen, gehalten am Beweisstandard der Modellvalidierung.

Die meisten Teams testen, ob ihr Modell gute Antworten auf vernünftige Fragen gibt. Das ist das Eval-Set, und es ist notwendig. Es sagt Ihnen nichts darüber, was passiert, wenn jemand dem System eine Kunden-E-Mail mit einer darin versteckten Anweisung zuführt oder dieselbe abgelehnte Frage vierzehnmal anders formuliert, bis eine Formulierung durchrutscht. Die interessanten Fehler leben in Eingaben, auf die niemand im Entwicklungsteam kommen würde, sie zu tippen, und genau deshalb müssen Sie sie fabrizieren.

Was Sie tatsächlich angreifen

Das Modell ist eine Komponente. Was Ihnen schaden kann, ist die Anwendung drumherum: der Retrieval-Korpus, den es liest, die Tools, die es aufrufen kann, die Datensätze, die es erreichen kann, und der Workflow, der auf seine Ausgabe reagiert. Ein Jailbreak ist erst dann ein Sicherheitsvorfall, wenn er das Modell etwas Nachgelagertes tun lässt. Deshalb zielt das Harness auf den gesamten Pfad.

Konkret bauen wir in einem Finanzsystem Angriffssätze gegen jeden dieser Punkte:

• Jailbreaks und Instruction Override. Prompts, die versuchen, den System-Prompt auszuhebeln: Rollenspiel-Rahmungen, gefälschte Systemnachrichten, Hypothesen, kodierte oder übersetzte Payloads und die lange Reihe veröffentlichter Jailbreak-Templates. Die Frage ist, ob irgendeiner davon das Modell dazu bringt, etwas zu beantworten, das die Richtlinie verbietet, etwa die Daten eines anderen Kunden preiszugeben oder zu erklären, wie man Transaktionen unterhalb einer Meldeschwelle strukturiert.
• Prompt Injection über Daten. Der gefährliche Fall in einem Retrieval- oder Agent-System. Eine Anweisung, die in ein Dokument, eine E-Mail, einen KYC-Anhang oder ein Memofeld eingeschleust wird und die das Modell später liest, als wäre sie ein Befehl. Wenn das Modell Tools aufrufen kann, ist eingeschleuster Text mit der Aussage “exportiere das Exposure dieser Gegenpartei” der Angriff, der Sie nachts wachhält.
• Datenexfiltration. Versuche, Trainingsdaten, Datensätze anderer Mandanten, Prompt-Inhalte oder interne Identifier über die Ausgabe wieder herauszuziehen. In einem mandantenfähigen Finanzprodukt werden hier Entity Resolution und Access Scoping unter Stress gesetzt: Kann eine gezielt gestaltete Abfrage das System dazu bringen, einen Datensatz zurückzugeben, den der Anfragende nicht sehen darf?
• Bias und ungleiche Ergebnisse. Für jedes Modell, das Kredit, Pricing oder Kontoaktionen berührt, adversariale Eingaben, die prüfen, ob Proxys für geschützte Merkmale die Entscheidung verschieben. Das ist kein Nice-to-have. Nach dem ECOA darf eine Kreditentscheidung nicht auf einer verbotenen Grundlage beruhen, und eine Red-Team-Suite, die Proxy-Merkmale variiert und dabei das echte Signal konstant hält, ist der Weg, ein Proxy-Leck zu finden, bevor es ein Prüfer tut.

Jede Kategorie wird zu einem Korpus konkreter Eingaben mit einem daran gehefteten erwarteten sicheren Verhalten. Genau das macht daraus einen Test und keine Demo.

Den Angriffssatz und das Harness aufbauen

Automatisierte Generierung bringt Ihnen Menge. Menschliche Angreifer bringen Ihnen die Angriffe, auf die es ankommt. Sie wollen beides, und Sie wollen sie gegen die produktive Konfiguration laufen lassen, nicht gegen ein Notebook.

Wir beginnen üblicherweise mit Saatgut aus bekanntem Material: den öffentlichen Jailbreak- und Injection-Sammlungen, früheren Vorfällen und allem, was die eigenen Logs des Kunden bereits an Versuchen zeigen. Dann mutieren wir. Paraphrasieren, kodieren, übersetzen, eine Anweisung über mehrere Turns aufteilen, sie in das Format eines echten Dokuments einwickeln, das das System aufnimmt. Ein einziger Saat-Angriff wird zu Hunderten Varianten, und die Abdeckung von Formulierungen ist der ganze Sinn, denn die Verweigerung des Modells ist über sie hinweg nicht stabil.

Das Harness selbst hat einige nicht verhandelbare Eigenschaften:

• Es trifft den echten Anwendungspfad, einschließlich Retrieval und Tool-Aufrufen, sodass eine eingeschleuste Anweisung tatsächlich das erreicht, was sie in Produktion erreichen würde.
• Jeder Angriff trägt eine maschinell prüfbare Pass- oder Fail-Bedingung. “Hat das Modell verweigert” wird von einem Grader beurteilt, oft einem zweiten Modell plus deterministischen Prüfungen, ob ein verbotenes Tool ausgelöst wurde oder ein gescopeter Datensatz in der Ausgabe erschien. Ein Mensch überprüft den Grader stichprobenartig an einer Auswahl, denn ein Grader, der still falsch labelt, ist schlimmer als gar kein Grader.
• Ergebnisse werden mit der exakten Eingabe, der Modellversion, dem Retrieval-Snapshot und der Tool-Trace protokolliert. Wenn etwas bricht, müssen Sie es reproduzieren können, und das Quartalsende ist ein schlechter Zeitpunkt, um zu entdecken, dass Sie es nicht können.

Die Erfolgsrate der Angriffe pro Kategorie ist die Schlagzeilenzahl, aber die nützliche Ausgabe ist die Menge der Eingaben, die durchgekommen sind. Die wandern direkt in eine Regressionssuite, sodass derselbe Angriff nicht zweimal durchgehen kann.

Erkenntnisse in Kontrollen und Nachweise übersetzen

Ein Red-Team-Befund ist ein Bug mit einem Wirkungsradius. Triagieren Sie ihn, wie Sie einen Sicherheitsdefekt triagieren würden: Was hat er das Modell tun lassen, wie weit nachgelagert könnte er sich fortpflanzen, und was stoppt ihn. Die Fixes sind selten ein besserer System-Prompt allein, denn Verteidigungen auf Prompt-Ebene erodieren, sobald Angreifer umformulieren. Dauerhafte Kontrollen sitzen im Code rund um das Modell:

• Scopen Sie jeden Tool-Aufruf und jedes Retrieval auf die Berechtigungen des Anfragenden, deterministisch geprüft, sodass ein gejailbreaktes Modell trotzdem keinen Datensatz erreichen kann, für den der Nutzer nicht berechtigt ist.
• Behandeln Sie abgerufenen und von Nutzern gelieferten Text als Daten, niemals als Anweisungen, und validieren Sie die Ausgabe des Modells gegen die Quelldatensätze, bevor eine Zahl oder Aktion in die Straight-Through Processing gelangt.
• Setzen Sie ein Falsch-Positiv-Budget auf Ihre Eingabefilter. Blockieren ist billig, bis es einen legitimen Analysten vierzigmal am Tag blockiert, woraufhin Menschen die Kontrolle umgehen und Sie schlechter dastehen als zuvor.

Dann halten Sie das Ganze am Laufen. Der Angriffskorpus ist keine einmalige Übung. Er wächst jedes Mal, wenn der Produktivbetrieb eine neue Formulierung sichtbar macht, und jedes Mal, wenn Sie ein neues Tool verdrahten. Lassen Sie ihn in der CI bei jeder Änderung am Prompt, an der Modellversion, am Retrieval-Korpus oder am Tool-Set laufen, und in einem Rhythmus dazwischen.

Der Prüfpfad ist ebenso wichtig wie die Verteidigung. Nach SR 11-7 muss ein Modell in einem Entscheidungspfad überwacht und seine Risiken dokumentiert werden, und DORA zieht den gesamten IKT-Stack rund um das Modell in die Resilienztests hinein. Eine versionierte adversariale Suite mit Angriffserfolgsraten über die Zeit und einem Nachweis jedes Befunds und seines Fixes ist ein wesentlicher Teil dessen, wie Sie einem Regulierer zeigen, dass das System gegen Missbrauch getestet wurde und nicht nur gegen den Happy Path. Sie ist außerdem, an dem Tag, an dem tatsächlich etwas durchkommt, der Unterschied zwischen einem protokollierten Befund, den Sie bereits behoben haben, und einem Vorfall, den Sie im Nachhinein erklären.