Leitfaden

AI Red Teaming: was es ist, wie es abläuft und wann Sie es brauchen

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

AI Red Teaming, auf Deutsch auch KI-Red-Teaming, ist ein strukturierter, gegnerischer Test eines KI-Systems: Ein Team versetzt sich in die Lage eines Angreifers und versucht gezielt, ein Sprachmodell, eine Chat-Anwendung oder einen KI-Agenten zu unerwünschtem Verhalten zu bringen, etwa zur Preisgabe vertraulicher Daten, zum Umgehen von Schutzregeln oder zum Missbrauch angebundener Werkzeuge. Anders als ein automatisierter Scan arbeitet es mit einem Bedrohungsmodell und konkreten Angriffszielen, anders als ein klassischer Pentest richtet es sich auch auf das Verhalten des Modells. Das Ergebnis ist ein Bericht, der zeigt, welche Szenarien gelungen sind, wie zuverlässig, und was dagegen hilft.

Was ist AI Red Teaming?

Das US-amerikanische National Institute of Standards and Technology (NIST) definiert AI Red Teaming in seinem Profil für generative KI (NIST AI 600-1) als strukturierte Testübung, mit der ein KI-System auf Fehler und Schwachstellen untersucht wird, zum Beispiel auf ungenaue, schädliche oder diskriminierende Ausgaben. Sie findet oft in einer kontrollierten Umgebung und in Zusammenarbeit mit den Entwicklern statt. An anderer Stelle beschreibt NIST das Ziel genauer: herausfinden, welches unerwünschte Verhalten ein Modell oder System zeigen kann, wie es zustande kommt, und die vorhandenen Schutzmaßnahmen unter Belastung zu testen. NIST nennt AI Red Teaming dort ausdrücklich eine Praxis, die sich noch entwickelt.

Für Unternehmen, die KI in eigene Produkte oder Abläufe einbauen, heißt das praktisch: Nicht das Modell an sich steht im Mittelpunkt, sondern das System, das Sie betreiben. Dazu gehören der Systemprompt, die angebundenen Datenquellen, die Werkzeuge, die ein Agent aufrufen darf, die Rechte, mit denen er arbeitet, und die Menschen, die mit ihm umgehen. Ein Red Team stellt die Frage, die ein Angreifer stellt: Was kann ich in genau diesem System erreichen, wenn ich es darauf anlege?

Drei Merkmale unterscheiden AI Red Teaming von anderen Prüfformen:

• Zielorientiert. Jeder Einsatz beginnt mit Angriffszielen, die für Ihr Geschäft relevant sind, etwa „Kundendaten eines fremden Mandanten auslesen“ oder „den Agenten zu einer Überweisung bringen“. Gemessen wird, ob das Ziel erreichbar ist.
• Kreativ und anpassend. Ein Red Team kombiniert Techniken, reagiert auf Antworten des Systems und verfolgt vielversprechende Spuren weiter. Das lässt sich nicht vollständig in eine feste Testliste gießen.
• Statistisch statt einmalig. Sprachmodelle können auf dieselbe Eingabe unterschiedlich antworten. Ein Angriff, der einmal scheitert, kann beim nächsten Versuch gelingen. Ergebnisse werden deshalb mit Wiederholungen und einer Erfolgsquote dokumentiert.

AI Red Teaming, KI-Pentest und automatisierte LLM-Scans

Die Begriffe werden im Markt nicht einheitlich verwendet. Manche Anbieter nennen jeden KI-Sicherheitstest „Red Teaming“, andere meinen damit nur Tests der Inhaltssicherheit eines Modells. Die folgende Abgrenzung beschreibt, was die drei Prüfformen typischerweise leisten. Entscheidend ist im Einzelfall, was im Angebot und im Scope tatsächlich steht.

Die drei Formen schließen sich nicht aus. Ein sinnvoller Aufbau ist häufig: automatisierte Scans als Daueraufgabe in der Entwicklung, ein KI-Pentest vor dem Livegang und AI Red Teaming dort, wo ein erfolgreicher Angriff besonders teuer wäre. Was ein KI-Pentest im Einzelnen prüft, zeigt unsere LLM-Pentest-Checkliste. Wie ein klassischer Penetrationstest abläuft, steht in Penetrationstest: Ablauf, Dauer und Kosten.

Ein Wort zu automatisierten Werkzeugen: Sie sind auch im Red Teaming nützlich, etwa um viele Varianten eines Angriffs zu erzeugen. NIST AI 600-1 nennt ausdrücklich Red Teaming, bei dem generative KI menschliche Teams unterstützt, und hält fest, dass es kostengünstiger sein kann als rein menschliche Teams. Die Bewertung, ob ein Treffer in Ihrem System echten Schaden bedeutet, bleibt aber Aufgabe von Menschen, die Ihr System verstehen.

Ablauf eines AI-Red-Teaming-Einsatzes

Ein Einsatz ist ein Projekt mit klaren Grenzen, kein offenes Ausprobieren. Die folgenden sechs Schritte haben sich bewährt und decken sich mit dem, was der GenAI Red Teaming Guide von OWASP als ganzheitlichen Ansatz beschreibt.

1. Ziel, Scope und Erlaubnis schriftlich festlegen

Am Anfang stehen drei Fragen: Was soll geprüft werden (Chat-Anwendung, interner Assistent, Agent mit Werkzeugen, ein bestimmter Workflow)? In welcher Umgebung (Testsystem mit realistischen, aber unkritischen Daten oder Produktion)? Und was ist ausdrücklich ausgeschlossen? Dazu gehören Testkonten mit unterschiedlichen Rollen, ein Ansprechpartner für den Notfall und Regeln, was bei einem kritischen Fund sofort passiert. Ohne schriftliche Beauftragung durch den Betreiber findet kein Test statt. Das gilt auch für KI-Systeme, die auf fremden Plattformen laufen: Deren Nutzungsbedingungen setzen eigene Grenzen.

2. Bedrohungsmodell erstellen

Das Bedrohungsmodell beschreibt, wer Ihr System angreifen könnte und was er damit erreichen will. Typische Angreiferrollen sind ein anonymer Besucher im Chat, ein angemeldeter Kunde, der an fremde Daten will, ein Mitarbeiter mit zu weiten Rechten und ein Dritter, der Text in Dokumente, E-Mails oder Webseiten schleust, die Ihr System später liest. Aus den Rollen, den Daten und den Werkzeugen ergeben sich die Angriffsziele, die geprüft werden. Wo die Vertrauensgrenzen bei Agenten liegen, beschreibt unser Überblick KI-Agent-Sicherheit.

3. Angriffsszenarien planen

Für jedes Ziel plant das Team konkrete Szenarien und ordnet sie einer gemeinsamen Sprache zu, damit Befunde vergleichbar bleiben. Dafür eignet sich MITRE ATLAS mit seinen Kennungen für Taktiken und Techniken (mehr dazu unten). Ein Szenario hält fest: Angreiferrolle, Einstiegspunkt, verwendete Techniken, erwartete Wirkung und woran ein Erfolg erkennbar ist.

4. Durchführen und wiederholen

Die Durchführung kombiniert manuelle Angriffe mit werkzeuggestützten Varianten. Jedes Szenario wird mehrfach ausgeführt, auch in leicht abgewandelter Form, über mehrere Gesprächsrunden und über alle Eingangswege, auf denen Text das Modell erreicht. Gelingt ein Angriff, wird er so dokumentiert, dass Ihr Team ihn nachvollziehen kann: genaue Eingaben, Antwort, ausgelöste Aktion, Zeitpunkt und Modellversion.

5. Bewerten

Ein Befund ist nicht die merkwürdige Antwort, sondern die Wirkung. Ein Modell, das einen unhöflichen Satz schreibt, ist etwas anderes als ein Agent, der Daten an eine fremde Adresse sendet. Bewertet wird deshalb nach Auswirkung (welche Daten, welche Aktion, welcher Schaden), Voraussetzungen (anonym oder nur mit Konto) und Zuverlässigkeit (wie viele von zehn Versuchen gelingen).

6. Bericht und Nachtest

Der Bericht beschreibt je Angriffspfad das Ziel, die Schritte, den Nachweis, die Erfolgsquote, die Einordnung in ATLAS und einen konkreten Vorschlag, wie sich der Pfad schließen lässt. Eine Zusammenfassung für die Geschäftsführung ordnet die Ergebnisse ein. Nach den Korrekturen prüft ein Nachtest, ob die Pfade geschlossen sind. Weil schon ein Modellwechsel oder ein neuer Systemprompt das Verhalten verschieben kann, gehört eine Regel dazu, wann wieder getestet wird.

Typische Angriffsziele

Welche Ziele geprüft werden, ergibt sich aus dem Bedrohungsmodell. Vier Gruppen kommen in fast jedem Einsatz vor. Die ATLAS-Kennungen in der Tabelle stammen aus den von MITRE veröffentlichten ATLAS-Daten (Stand September 2026).

Datenabfluss

Das häufigste Geschäftsrisiko. Ein Assistent, der auf Kundendaten, Verträge oder interne Wikis zugreift, kann Inhalte an Personen ausgeben, die sie nicht sehen dürfen. Das Red Team prüft, ob Rechtefilter in der Datenanbindung greifen, ob sich fremde Datensätze über geschickte Fragen erreichen lassen und ob Daten über Umwege wie Links, Bilder oder Werkzeugaufrufe nach außen gelangen.

Jailbreak

Ein Jailbreak bringt das Modell dazu, eigene Schutzregeln oder die Vorgaben des Betreibers zu ignorieren. Für ein Unternehmen ist er vor allem dann relevant, wenn diese Regeln geschäftliche Grenzen absichern sollen, etwa keine verbindlichen Zusagen, keine Rabatte, keine Auskunft zu bestimmten Themen. Das Red Team prüft, ob diese Grenzen nur im Prompt stehen oder auch technisch durchgesetzt werden.

Prompt-Injection als Hebel

Prompt-Injection ist selten das Ziel, aber oft der Weg dorthin. Besonders die indirekte Form, bei der Anweisungen in Dokumenten, E-Mails oder Webseiten stecken, öffnet Angreifern ohne eigenes Konto eine Tür. Wie Sie das systematisch testen, zeigt unser Testplan Prompt-Injection testen.

Tool-Missbrauch bei Agenten

Sobald ein Agent Werkzeuge aufruft, wird aus einer falschen Antwort eine falsche Handlung: eine E-Mail an die falsche Adresse, ein Datenbankeintrag, ein Ticket, eine Zahlung. Das Red Team prüft, welche Werkzeuge mit welchen Rechten erreichbar sind, ob riskante Aktionen eine Bestätigung brauchen und ob sich mehrere harmlose Schritte zu einem schädlichen verketten lassen. Die Risikoklassen dazu ordnet die OWASP Top 10 für Agentic Applications ein.

Rahmenwerke als Orientierung

Keines der folgenden Rahmenwerke ist eine Prüfnorm, nach der ein Red Teaming „bestanden“ werden kann. Sie geben eine gemeinsame Sprache, eine Struktur für den Einsatz und Anschluss an das Risikomanagement.

MITRE ATLAS

ATLAS steht für Adversarial Threat Landscape for AI Systems. MITRE beschreibt es als öffentliche Wissensbasis zu Taktiken, Techniken und Verfahren von Angreifern, die auf KI-Systeme zielen. Die veröffentlichten Daten enthalten neben Taktiken und Techniken auch Gegenmaßnahmen und Fallstudien und verweisen an mehreren Stellen auf das bekannte Rahmenwerk MITRE ATT&CK. Für einen Einsatz ist ATLAS vor allem als Ordnungssystem nützlich: Jeder Befund bekommt eine Kennung, die Ihr Security-Team, Ihre Dienstleister und spätere Tests gleich verstehen.

OWASP GenAI Red Teaming Guide

Das OWASP GenAI Security Project hat den GenAI Red Teaming Guide am 22. Januar 2025 veröffentlicht. Er beschreibt einen ganzheitlichen Ansatz in vier Bereichen: Bewertung des Modells, Prüfung der Implementierung, Bewertung der Infrastruktur und Analyse des Laufzeitverhaltens. Laut der Ankündigung behandelt er auch Herausforderungen agentischer KI und richtet sich an Fachleute aus Sicherheit und KI-Entwicklung gleichermaßen. Für Ihre Planung ist er eine gute Prüfliste, ob ein Angebot nur das Modell oder das ganze System abdeckt. Die Risiken selbst beschreibt die OWASP Top 10 für LLM-Anwendungen.

NIST AI RMF und NIST AI 600-1

Das AI Risk Management Framework (AI RMF 1.0) hat NIST am 26. Januar 2023 veröffentlicht. Es ist zur freiwilligen Anwendung gedacht und gliedert das KI-Risikomanagement in vier Funktionen: Govern, Map, Measure und Manage. Am 26. Juli 2024 folgte NIST AI 600-1, ein branchenübergreifendes Profil des AI RMF für generative KI. Es empfiehlt Red Teaming an mehreren Stellen und unterscheidet je nach Anwendungsfall vier Formen:

• Allgemeine Öffentlichkeit: Nutzer ohne besondere KI- oder Technikkenntnisse, die das System so verwenden, wie es auch später verwendet wird.
• Experten: Fachleute mit Wissen über den Einsatzbereich, zum Beispiel Medizin, Biotechnologie oder Cybersicherheit.
• Kombination: Experten, die zum Beispiel die Eingaben von Laien prüfen oder abwandeln.
• Mensch und KI: Red Teaming, bei dem generative KI menschliche Teams unterstützt.

NIST betont außerdem, dass die Qualität der Ergebnisse vom Hintergrund und der Fachkenntnis des Red Teams abhängt und dass Ergebnisse vor der Übernahme in Entscheidungen zusätzlich ausgewertet werden sollten. Für ein Unternehmen heißt das: Die Ergebnisse eines Einsatzes gehören in den Measure-Teil Ihres Risikomanagements, nicht in eine Schublade.

Was der EU AI Act zu Angriffstests sagt

Der AI Act (Verordnung (EU) 2024/1689) verlangt in Art. 55 Abs. 1 lit. a von Anbietern von KI-Modellen mit allgemeinem Verwendungszweck mit systemischem Risiko eine Modellbewertung, zu der die Durchführung und Dokumentation von Angriffstests gehört. Ob und welche Pflichten aus dem AI Act für Ihr Unternehmen gelten, ist eine Rechtsfrage. Dieser Artikel ist keine Rechtsberatung. Einen Überblick gibt AI Act und KI-Governance.

Wann braucht ein Unternehmen AI Red Teaming?

Nicht jede KI-Anwendung braucht einen Red-Teaming-Einsatz. Ein interner Textassistent ohne Zugriff auf vertrauliche Daten und ohne Werkzeuge ist mit einem sauberen Pentest und regelmäßigen automatisierten Tests meist gut bedient. AI Red Teaming lohnt sich, wenn mindestens einer dieser Punkte zutrifft:

• Das System greift auf personenbezogene, vertrauliche oder mandantenbezogene Daten zu.
• Ein Agent kann handeln: E-Mails senden, Datensätze ändern, Code ausführen, Bestellungen oder Zahlungen auslösen.
• Das System liest Inhalte, die Dritte beeinflussen können, etwa eingehende E-Mails, hochgeladene Dokumente oder Webseiten.
• Die Anwendung ist öffentlich erreichbar, und ein Fehlverhalten wäre für Ihre Marke oder Ihre Kunden sichtbar.
• Ein Großkunde, ein Investor oder ein Prüfer fragt nach belastbaren Nachweisen zur Sicherheit Ihrer KI-Funktionen.
• Ein großer Umbau steht an: neues Modell, neue Werkzeuge, neue Datenquellen oder der Schritt vom Assistenten zum Agenten.

Für kleinere Teams ist ein gestuftes Vorgehen realistisch: zuerst die eigenen Basics anhand der Checkliste und mit automatisierten Tests, dann ein KI-Pentest vor dem Livegang, und ein Red-Teaming-Einsatz für die zwei oder drei Szenarien, die Ihnen wirklich schlaflose Nächte bereiten würden.

Was AI Red Teaming nicht leistet

Ein Red-Teaming-Einsatz zeigt, welche der geprüften Angriffspfade zum Zeitpunkt des Tests gelungen sind. Er ist keine Garantie, dass es keine weiteren gibt, und keine Zertifizierung. Weil Modelle, Prompts, Werkzeuge und Datenquellen sich ändern, ist das Ergebnis eine Momentaufnahme. Den größten Wert hat es, wenn die gefundenen Szenarien danach als feste Regressionstests in Ihre Entwicklung übergehen und Sie bei größeren Änderungen nachtesten.

Häufige Fragen

Weiterlesen

• LLM-Pentest: die Checkliste für KI-Anwendungen vor dem Livegang
• Prompt-Injection testen: Testplan, Testfälle und Bewertung
• Die OWASP Top 10 für LLM-Anwendungen, praktisch erklärt
• KI-Agent-Sicherheit: der Überblick
• Die OWASP Top 10 für Agentic Applications, praktisch erklärt
• Leistung: KI-Pentest & MCP-Sicherheit

Quellen

• NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (Juli 2024)
• NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST: AI Risk Management Framework
• MITRE ATLAS
• MITRE ATLAS Data (GitHub, Stand 2026.09)
• OWASP GenAI Security Project: GenAI Red Teaming Guide
• OWASP GenAI Security Project: Announcing the OWASP Gen AI Red Teaming Guide
• EUR-Lex: Verordnung (EU) 2024/1689 (KI-Verordnung)