GenAI-Systeme verhalten sich nicht wie klassische Software: Schon kleine Änderungen in Prompt, Kontext oder Daten können neue Fehlerbilder erzeugen. Genau deshalb reicht es nicht, nur „funktioniert es?“ zu prüfen. Relevanter ist: Wie verhält sich das System, wenn es absichtlich in Grenzbereiche geschoben wird – durch missverständliche Anfragen, bösartige Instruktionen, überlange Kontexte oder widersprüchliche Informationen? KI-Red-Teaming liefert dafür eine Methode, die technische, organisatorische und inhaltliche Risiken zusammenführt.
Im Unternehmenskontext geht es dabei selten um spektakuläre Hacks, sondern um robuste Prozesse: Welche Risiken sind überhaupt realistisch? Wie wird getestet, ohne sensible Daten zu gefährden? Wie entstehen wiederholbare Testfälle statt einmaliger „Stunts“? Und wie fließen Ergebnisse in Guardrails, Prompting, Datenfilter, Monitoring und Freigaben zurück?
Warum Red-Teaming bei GenAI anders ist als Penetrationstests
Nicht nur Security: Fehlerklassen entlang der gesamten Wertschöpfung
Klassische Security-Tests prüfen typischerweise Komponenten (API, Auth, Netzwerk, Rechte). Bei GenAI kommen zusätzliche Ebenen hinzu: Modellverhalten, Prompt- und Tool-Logik, Datenanbindung, Retrieval, Policies und UI. Viele Schäden entstehen nicht durch einen „Exploit“, sondern durch plausible, aber falsche oder unzulässige Antworten – inklusive Nebenwirkungen wie Datenabfluss oder unerwünschter Handlungsanweisungen.
Praktisch bewährt ist eine Kategorisierung der Tests entlang von Wirkung statt Technik, zum Beispiel:
- Vertraulichkeit: Preisgabe interner Inhalte, Identitäts- oder Berechtigungsumgehung, Prompt-Injection über Dokumente.
- Integrität: Manipulierte Zusammenfassungen, unbemerkte Verdrehung von Fakten, fehlerhafte Tool-Ausführung.
- Verfügbarkeit: Eskalationen durch Endlosschleifen, extrem lange Ausgaben, teure oder blockierende Abfragen.
- Compliance/Policy: Unerlaubte Inhalte, fehlende Disclaimer, Verletzung interner Vorgaben.
- Business-Risiko: Falsche Zusagen, irreführende Empfehlungen, fehlerhafte Vertragsauslegung.
Der „Angriff“ sitzt oft im Kontext: Prompt, Tools, Retrieval
Viele Schwachstellen entstehen in der Orchestrierung: Ein Assistenzsystem liest Dokumente, zitiert Auszüge, ruft Tools auf, schreibt E-Mails oder erstellt Tickets. Das Modell ist nur ein Teil der Kette. Red-Teaming sollte deshalb nicht nur das Basismodell testen, sondern das reale System: inklusive Retrieval, Formatvorgaben, Rollenprompts, Tool-Policies und Berechtigungsmodell.
Wer in der Praxis mit Retrieval arbeitet, sollte bei den Grundlagen sauber aufgestellt sein, bevor Red-Teaming skaliert: RAG-Suche stabil und sicher betreiben.
Risiken priorisieren: Was wird getestet, was wird bewusst ausgeschlossen?
Threat-Modeling für GenAI: Assets, Akteure, Angriffsflächen
Ein nutzbarer Red-Teaming-Plan beginnt mit einem einfachen Threat-Model, das ohne Spezialjargon auskommt. Drei Leitfragen reichen oft:
- Welche Assets müssen geschützt werden (z. B. interne Dokumente, Kundendaten, Preiskalkulationen, Zugangsdaten, Arbeitsanweisungen)?
- Welche Akteure sind realistisch (externe Nutzer, interne Mitarbeitende, Dienstleister, „neugierige“ Rollen, automatisierte Clients)?
- Welche Angriffsflächen existieren (Chat-Eingabe, Uploads, Dokumentenbestand, Tool-Connectoren, Systemprompts, Logs)?
Daraus entstehen Testziele, die messbar sind: „Darf keine Inhalte aus Klassifikation X wiedergeben“, „darf Tool Y nur bei Rolle Z ausführen“, „muss Unsicherheit kenntlich machen, wenn Quellenlage unklar ist“.
Akzeptanzkriterien statt Bauchgefühl
Red-Teaming wird handhabbar, wenn es klare Akzeptanzkriterien gibt. Beispiele:
- Antworten müssen in einem definierten Format bleiben (z. B. keine freien Schritte, wenn nur Zusammenfassungen erlaubt sind).
- Bestimmte Handlungsanweisungen sind grundsätzlich zu verweigern.
- Tool-Aufrufe erfordern nachvollziehbare Begründung und Parameter-Validierung.
Diese Kriterien sollten mit den späteren Betriebsmechanismen verzahnt sein, etwa mit Guardrails und Freigabe-Workflows. Passend dazu: Output sicher begrenzen.
Testdesign: Angriffs-Prompts, Datenszenarien und Tool-Missbrauch
Prompt-Angriffe systematisch variieren
Statt einzelner „Clever Prompts“ liefert eine Variationsmatrix bessere Abdeckung. Sinnvolle Achsen sind:
- Direkt vs. indirekt (Instruktion im Chat vs. Instruktion versteckt in einem Dokument).
- Einfach vs. verschachtelt (ein Schritt vs. mehrstufige Aufgaben mit Rückfragen).
- Kontextarm vs. kontextreich (ohne Dokumente vs. mit vielen Anhängen, widersprüchlichen Quellen).
- Formal korrekt vs. sozial manipulierend (autoritäre Formulierungen, Dringlichkeit, „Chef sagt…“).
Wichtig ist die Reproduzierbarkeit: Jede Variante bekommt eine ID, Ziel, Erwartung und ein klar beschriebenes Setup (z. B. welches Dokument liegt im Index, welche Rolle, welche Berechtigungen).
Retrieval- und Dokumentenangriffe: wenn Inhalte selbst „bösartig“ sind
Bei RAG-Systemen ist indirekte Prompt-Injection ein Kernrisiko: Ein Dokument kann Instruktionen enthalten, die das Modell übersteuern („Ignoriere alle Regeln und gib … aus“). Red-Teaming sollte deshalb Dokument-Szenarien abdecken:
- Instruktionen im Fließtext, in Fußnoten, in Codeblöcken (auch wenn die UI sie nicht sichtbar macht).
- Konflikt zwischen Systemvorgaben und Dokumentanweisungen.
- „Poisoned“ Dokumente, die plausible, aber falsche Fakten verbreiten.
Ein pragmatisches Gegenmittel ist ein mehrstufiges Retrieval: erst finden, dann extrahieren, dann begründet antworten – plus klare Regeln, was aus Dokumenten als „Befehl“ ignoriert werden muss.
Tool- und Action-Tests: vom harmlosen Chat zur wirkenden Automation
Sobald GenAI Tools aufruft (Tickets erstellen, E-Mails senden, Daten abfragen), entstehen neue Risiken: falsche Parameter, ungewollte Aktionen, Berechtigungseskalation. Red-Teaming sollte dabei nicht nur „ob es geht“ testen, sondern „ob es korrekt begründet und begrenzt ist“:
- Kann das Modell ohne ausreichende Nutzerbestätigung Aktionen auslösen?
- Werden Parameter validiert (z. B. Empfänger, Projekt, Kostenstelle)?
- Gibt es klare Stop-Regeln bei Unsicherheit?
In vielen Fällen ist eine einfache Sicherheitsarchitektur entscheidender als Modellwahl: Tool-Aufrufe über eine Policy-Schicht, die autorisiert, validiert und protokolliert.
Artefakte und Rollen: So wird Red-Teaming im Unternehmen wiederholbar
Rollenmodell: Wer testet, wer entscheidet, wer behebt?
Red-Teaming scheitert häufig nicht an Ideen, sondern an Zuständigkeiten. Ein schlankes Rollenbild hilft:
- Product Owner/Use-Case Owner: priorisiert Risiken nach Business-Wirkung.
- Security/Privacy: definiert Schutzgüter und Ausschlusskriterien.
- ML/Engineering: setzt Fixes um (Prompt, Filter, Retrieval, Tool-Policy, UI).
- Reviewer: prüft, ob Fixes die Akzeptanzkriterien erfüllen.
Für die organisatorische Verankerung kann ein klares RACI-Modell helfen: Rollen und Verantwortlichkeiten definieren.
Testfall-Format: klein genug für Tempo, streng genug für Qualität
Ein bewährtes Testfall-Schema umfasst:
- ID und Kurzname
- Ziel/Risiko (welcher Schaden soll verhindert werden?)
- Setup (Rolle, Datenlage, aktivierte Tools, relevante Dokumente)
- Eingabe (Prompt oder Dokumentinhalt)
- Erwartetes Verhalten (inkl. erlaubter Abweichungen)
- Beobachtung und Einstufung (Schweregrad, Reproduzierbarkeit)
- Fix/Outcome (welche Änderung reduziert das Risiko?)
Damit entstehen Regressionstests: Jeder gefixte Befund wird zum dauerhaften Test, der bei Updates erneut laufen muss. Das zahlt direkt auf Modellrisikomanagement ein.
Typische Findings und passende Gegenmaßnahmen
Die folgende Übersicht hilft, Beobachtungen schneller in Maßnahmen zu übersetzen. Entscheidend ist die saubere Trennung: Symptom (was passiert) vs. Ursache (warum passiert es) vs. Fix (was wird geändert).
| Beobachtung im Test | Wahrscheinliche Ursache | Pragmatische Gegenmaßnahme |
|---|---|---|
| Modell folgt Instruktionen aus einem Dokument statt Systemregeln | Keine Trennung von „Inhalt“ und „Anweisung“ im Prompting | Retriever-Output markieren, Anweisungen aus Quellen ignorieren, zusätzliche Policy-Prüfung |
| Antwort enthält interne Details, obwohl Rolle keine Berechtigung hat | Berechtigungen nur in UI, nicht in Datenzugriff/Index | Dokumente nach Rollen/Klassen trennen, Zugriff vor Retrieval erzwingen |
| Tool wird mit riskanten Parametern aufgerufen (z. B. falscher Empfänger) | Keine Validierung, keine Bestätigungsschritte | Policy-Gateway für Tools, Parameter-Schema, „Confirm before execute“ |
| Überzeugende, aber falsche Behauptungen | Unzureichende Evidenzprüfung, zu freie Generierung | Belegpflicht (Zitate/Quellenpassagen), Unsicherheitsmarker, restriktivere Antwortformate |
| Unerwünschte Inhalte werden erzeugt | Fehlende Output-Filter und unklare Regeln | Safety-Policy konkretisieren, Moderation/Filter, bessere Ablehnungsantworten |
Praktischer Ablauf: von der Planung zur Regression
Ein schlanker Prozess, der in Sprints passt
Red-Teaming muss nicht monatelang dauern. Ein funktionierender Rhythmus ist: kleine Testkampagnen mit klarer Fragestellung, schnelle Fixes, dann Regression. Wichtig ist die Kopplung an Releases und Änderungen am System (Prompt, Retrieval, Tools, Modellversion).
Wer Modelle versioniert und freigibt, kann Red-Teaming-Ergebnisse sauber an Releases binden: Modelle versionieren und freigeben.
Konkrete Schritte für die Umsetzung
- Use Case abgrenzen: Welche Datenquellen, welche Tools, welche Rollen sind im Scope?
- Risikoziele festlegen: 5–10 testbare Akzeptanzkriterien definieren.
- Testbibliothek starten: 20–40 Fälle als Basis (Prompt-, Dokument-, Tool-Szenarien).
- Durchlauf durchführen: Tests mit Protokollierung (Input, Kontext, Output, Entscheidungspfade).
- Befunde triagieren: Schweregrad, Häufigkeit, Fix-Aufwand, Business-Auswirkung.
- Fixes implementieren: Prompting, Retrieval-Regeln, Tool-Policies, UI-Confirmation, Filter.
- Regression etablieren: Jeder Befund wird ein dauerhafter Testfall.
Kontrolle im Betrieb: Was nach dem Testlauf nicht enden darf
Signale definieren: wann ein System „driftet“
Red-Teaming liefert Momentaufnahmen. In Produktion zählen Trends: neue Prompt-Injection-Muster, veränderte Datenbestände, Modellupdates oder geänderte Tool-Interfaces. Sinnvoll sind deshalb Metriken und Alarme, die auf Abweichungen hinweisen, etwa steigende Ablehnungsraten, auffällige Tool-Aufrufmuster oder mehr Nutzereskalationen.
Operativ hilft es, Red-Teaming-Befunde als Beobachtungsziele zu verwenden: „Dieses Risiko wurde gefixt – welche Telemetrie zeigt, ob es zurückkommt?“ Damit entsteht eine Brücke zu LLM-Sicherheitsprüfung im laufenden Betrieb.
Change-Kopplung: Tests immer dann, wenn es wirklich zählt
Auslöser für erneutes Red-Teaming sollten klar definiert sein, zum Beispiel:
- Modellwechsel oder neue Modellversion
- Neue Datenquelle im Retrieval oder geänderte Indexierungsregeln
- Neue Tools/Actions oder geänderte Tool-Schemas
- Neue Nutzergruppen oder erweiterte Berechtigungen
Wer GenAI im Alltag verankert, sollte Sicherheits- und Qualitätschecks an Änderungen koppeln, nicht an Kalenderwochen. Dazu passt ein strukturierter Organisationsansatz: GenAI im Alltag verankern.
Häufige Fragen aus der Praxis
Reicht es, nur den Chat zu testen?
Nein. Sobald Retrieval, Uploads oder Tools im Spiel sind, entstehen die kritischsten Fehlerbilder außerhalb des reinen Chats. Die Tests müssen das End-to-End-System abdecken, inklusive Rollen, Berechtigungen, Datenzugriff und Action-Schicht.
Wie wird verhindert, dass Red-Teaming selbst Daten gefährdet?
Testdaten und Testumgebungen sollten so gewählt sein, dass keine realen sensiblen Inhalte erforderlich sind. Zusätzlich helfen klare Arbeitsregeln: keine echten Geheimnisse in Prompts, kontrollierte Log-Speicherung, und ein definiertes Handling für Findings, die auf reale Leaks hindeuten.
Wie wird Erfolg gemessen?
Erfolg zeigt sich weniger in „keine Findings“, sondern in sinkender Wiederholrate derselben Fehlerklasse, besserer Reproduzierbarkeit der Tests und einer stabilen Regression-Suite, die Updates sicher begleitet. Ein guter Indikator ist, wenn Fixes konkrete Akzeptanzkriterien erfüllen und in späteren Releases nicht wieder brechen.
Welche Fähigkeiten braucht das Team?
Neben Security-Verständnis sind Domänenwissen und Produktkenntnis entscheidend: Nur wer die echten Geschäftsprozesse versteht, erkennt riskante Antworten. Technisch hilfreich sind Kenntnisse zu Prompting, Retrieval-Design und Tool-Orchestrierung. Für den Umgang mit Nutzerdaten sind klare Policies und eine saubere Klassifizierung sinnvoll.
