KI-Red-Teaming

Was ist KI-Red-Teaming?

KI-Red-Teaming ist die Praxis, das eigene KI-System gezielt anzugreifen – mit Jailbreaks, Injection-Payloads und Missbrauchsszenarien –, um Schwachstellen zu finden, bevor es echte Angreifer oder Nutzer tun. Es überträgt die adversariale Denkweise klassischer Security-Red-Teams auf das Modellverhalten und deckt sowohl böswillige Angriffe als auch ganz gewöhnliche Eingaben ab, die schädliche Ausgaben erzeugen.

Die wichtigsten Punkte

• Red Teaming testet das eingesetzte System, nicht nur das Modell. Ihre Prompts, Tools, Retrieval-Quellen und Guardrails schaffen allesamt Angriffsfläche, die die eigenen Sicherheitstests des Basismodells nie gesehen haben.
• Der Umfang reicht über Security hinaus. Neben Jailbreaks und Prompt Injection prüfen Red Teams auf schädliche Ratschläge, Datenschutzlecks, Bias und Agenten, die aus harmlos wirkenden Anfragen destruktive Aktionen ableiten.
• Am besten funktioniert es als wiederkehrende Pipeline statt als einmaliges Audit: Befunde werden zu Regressionstests, die bei jedem Modellwechsel, jeder Prompt-Änderung und jedem neuen Tool erneut laufen.
• Automatisierung skaliert die Arbeit. Angreifer-LLMs generieren und mutieren adversariale Eingaben zu Tausenden, während Menschen die Strategie steuern und mehrdeutige Ergebnisse beurteilen.
• Regulierungsbehörden und Enterprise-Käufer erwarten zunehmend dokumentierte adversariale Tests, sodass Red-Team-Berichte zugleich als Governance-Nachweis dienen.

So funktioniert es

Ein Red-Team-Einsatz beginnt mit einem Bedrohungsmodell: Wer würde dieses System angreifen, was wäre das Ziel, und wie sähe ein schädliches Versagen selbst ohne Angreifer aus. Bei einem Kundensupport-Bot sind die Risiken vielleicht markenschädigende Ausgaben und Datenlecks. Bei einem Coding-Agenten mit Repository-Zugriff erweitert sich die Liste um exfiltrierte Secrets und bösartige Commits. Dieses Modell bestimmt, welche Angriffsfamilien relevant sind – von Jailbreak-Techniken und in abgerufenem Inhalt platzierten Injection-Payloads bis zu Social-Engineering-Framings und mehrstufiger Manipulation.

Die Durchführung mischt manuelle und automatisierte Arbeit. Erfahrene Tester bringen Kreativität mit, verketten Techniken und nutzen den spezifischen Produktkontext auf Weisen aus, die Skripte übersehen; Microsofts AI Red Team destillierte in seinem 2025er Bericht über Lektionen aus dem Angriff auf mehr als 100 generative KI-Produkte seine interne Bedrohungsmodell-Ontologie in acht Kernlektionen, die meisten davon zu genau diesem menschlichen Urteilsvermögen [1]. Automatisierte Testrahmen bringen Abdeckung, spielen Bibliotheken bekannter Angriffe erneut ab und nutzen ein zweites Modell, um Varianten zu erzeugen, bis etwas trifft. Der Aufwand, ein gut verteidigtes System zu brechen, kann enorm sein: In Anthropics Bug-Bounty-Programm 2025 zu den Constitutional Classifiers investierten 183 aktive Red-Teamer geschätzte über 3.000 Stunden über zwei Monate, ohne einen universellen Jailbreak zu finden, und eine spätere öffentliche Demo zog 339 Jailbreaker über mehr als 300.000 Chat-Interaktionen an [2]. Jeder Befund wird mit der genauen Eingabe, dem Fehler und einer Schweregradbewertung protokolliert und anschließend an das Build-Team übergeben, das ihn per Prompt-Änderung, zusätzlichen Guardrails, reduzierten Tool-Berechtigungen oder Eskalation an den Anbieter behebt.

Der Schritt, der reife Teams von reinem Theater unterscheidet, ist das, was danach passiert. Jeder bestätigte Fehler wird zu einem dauerhaften Regressionstest, und die gesamte Suite läuft kontinuierlich: bei Modellversions-Upgrades, bei Prompt-Änderungen, bei jedem neuen Tool oder jeder neuen Datenquelle. Modellverhalten verschiebt sich zwischen Versionen auf Weisen, die gewöhnliche Tests nie bemerken, und der gestern behobene Jailbreak neigt dazu, zurückzukehren.

Beispiel

Bevor ein Unternehmen einen Agenten startet, der eingehende E-Mails liest und mit CRM-Zugriff Antworten entwirft, führt es ein zweiwöchiges Red Team durch. Ein Tester konzentriert sich auf indirekte Injection und schickt dem Agenten E-Mails mit Anweisungen, versteckt in Signaturen und zitierten Thread-Verläufen. Ein Testrahmen feuert einige Tausend generierte Varianten auf eine Staging-Kopie ab. Ergebnis: Der Agent ignorierte die meisten Payloads, gehorchte aber einem Framing, das sich als interne IT-Mitteilung ausgab, und fasste separat bereitwillig den CRM-Datensatz eines anderen Kunden zusammen, als eine E-Mail beiläufig nach „dem anderen Konto" fragte. Keiner der beiden Fälle war ein Jailbreak im klassischen Sinn; der zweite war eine schlichte Autorisierungslücke. Das Team beschränkte CRM-Abfragen auf das eigene Konto des Absenders, fügte das IT-Mitteilungsmuster einem Eingabeklassifikator hinzu, und beide Angriffstranskripte laufen nun jede Nacht gegen Staging.

Häufige Missverständnisse

Das Missverständnis lautet, Red Teaming sei abgeschlossen, sobald das Modell besteht, als wäre Sicherheit eine Eigenschaft, die man einmalig zertifiziert. Ein Modell, das heute jedem bekannten Jailbreak widersteht, steckt in einem Produkt, dessen Prompts, Tools und Datenquellen sich wöchentlich ändern, und jede Änderung öffnet die Frage erneut. Teams, die Red Teaming als Launch-Gate behandeln, bekommen eine Momentaufnahme; Teams, die es als dauerhafte Testsuite behandeln, bekommen Schutz.

FAQ

Wie unterscheidet sich KI-Red-Teaming vom klassischen Security-Red-Teaming? Klassische Red Teams greifen Infrastruktur an: Netzwerke, Credentials, Anwendungscode. KI-Red-Teams greifen Verhalten an und nutzen natürliche Sprache sowie präparierte Daten, um ein probabilistisches System zum Fehlverhalten zu bringen. Die Disziplinen laufen in agentischen Systemen zusammen, wo ein Verhaltens-Exploit wie eine eingeschleuste Anweisung in eine echte Infrastruktur-Kompromittierung kaskadieren kann.

Brauchen wir ein dediziertes Team, oder können wir es automatisieren? Kleine Teams gewinnen echten Wert aus automatisierten Tools plus einer strukturierten internen Übung vor jedem Launch. Automatisierung deckt bekannte Angriffsklassen günstig ab; Menschen finden die neuartigen, produktspezifischen Fehler. Deployments mit hohem Risiko rechtfertigen meist externe Spezialisten, deren Befunde dann Ihre automatisierte Suite speisen.

Wie oft sollten KI-Systeme einem Red Teaming unterzogen werden? Kontinuierlich für die automatisierte Suite und ereignisgesteuert für tiefere Durchgänge: vor dem Launch, nach jedem Modell-Upgrade und nach dem Hinzufügen von Tools, Datenquellen oder Berechtigungen. Der Auslöser ist Veränderung, denn in der Praxis entstehen die meisten Regressionen durch eine Änderung, die niemand für riskant hielt.

Quellen

1. arXiv (Microsoft AI Red Team, Bullwinkel et al.). Lektionen aus dem Red Teaming von mehr als 100 generativen KI-Produkten, destilliert in acht Kernlektionen. https://arxiv.org/abs/2501.07238. Abgerufen im August 2026.
2. Anthropic. Bug-Bounty-Programm zu den Constitutional Classifiers: 183 Red-Teamer, über 3.000 Stunden, kein universeller Jailbreak; öffentliche Demo mit 339 Jailbreakern über mehr als 300.000 Interaktionen. https://www.anthropic.com/news/constitutional-classifiers. Abgerufen im August 2026.