Red Teaming (KI)

Definition

Red Teaming im KI-Kontext bezeichnet strukturierte adversariale Sicherheitstests, bei denen Teams gezielt versuchen, ein KI-System zu manipulieren, zum Versagen zu bringen oder seine Sicherheitsrichtlinien zu umgehen. Ziel ist es, Failure-Modes, Missbrauchspotenzial und Sicherheitslücken vor dem Deployment zu identifizieren und zu mitigieren. Der Begriff stammt aus militärischen Übungen, etablierte sich in der Cybersicherheit in den 1990er Jahren und ist seit etwa 2020 fester Bestandteil der Sicherheitspraxis aller grossen KI-Labs.

Red Teaming ist eine zentrale Säule moderner AI-Safety-Architekturen. Anthropic, OpenAI, Google DeepMind, Meta und Mistral betreiben interne Red Teams, ergänzen sie um externe Auditoren wie METR, Apollo Research und die nationalen AI Safety Institutes und nutzen Red-Teaming-Ergebnisse als Voraussetzung für Trainings- und Deploy-Entscheidungen in Responsible Scaling Policies, Preparedness Frameworks und Frontier Safety Frameworks.

Mechanismus und Spezifikation

Red Teaming kombiniert mehrere methodische Schichten:

• Manuelles Red Teaming: Erfahrene Experten testen Modelle hands-on, oft mit Domänenwissen (Bio, Cyber, Recht, Medizin, CBRN). Sie probieren kreative Angriffsvektoren und dokumentieren Failure-Modes systematisch.
• Automatisiertes Red Teaming: Skripte, Fuzzing-Tools und Generator-Modelle erzeugen Tausende von Angriffsvariationen. Anthropic veröffentlichte 2024 Methoden, in denen Claude-Modelle andere Claude-Modelle attackieren (Claude as Attacker).
• Capability Evaluations: Strukturierte Tests gefährlicher Fähigkeiten, etwa Bioweapons-Wissen, Cyber-Offense-Capabilities, autonome Replikation. Frontier-Labore definieren Capability-Schwellen, deren Überschreitung weitere Sicherheitsmassnahmen auslöst.
• Domain-Red-Teaming: Vertiefte Tests in spezifischen Risiko-Domänen, oft mit externen Experten (Microbiologen, Chemiker, Sicherheitsforscher).
• Multi-Turn-Red-Teaming: Angriffe über lange Dialoge, in denen ein Angreifer schrittweise das Modell in einen unsicheren Zustand führt.
• Tool-Use-Red-Teaming: In agentischen Setups Tests mit Tool-Calls, Browser-Aktionen, Code-Ausführung, E-Mail-Versand. Indirekte Prompt Injection ist hier ein Hauptvektor.

Die Ergebnisse fliessen in Model Cards, System Cards und Transparency Reports. Bei Anthropic koppelt die Responsible Scaling Policy konkrete Deploy-Entscheidungen an Capability-Schwellen, die durch Red Teaming und Capability Evaluations bestätigt werden.

Praxis und Anwendung

Operative Red-Teaming-Praxis bei Frontier-Labs:

• Interne Teams: Anthropic Safety Team, OpenAI Red Teaming Network, Google DeepMind Safety, Meta Responsible AI. Permanente Teams mit gemischten Disziplinen.
• Externe Auditoren: METR (Model Evaluation and Threat Research), Apollo Research, UK AI Safety Institute, US AI Safety Institute. Externe Validierung vor Frontier-Releases.
• Bounty-Programme: Anthropic Universal Jailbreak Bounty (Belohnungen für robuste Jailbreaks gegen Claude), OpenAI Red Teaming Program (kontraktierte Tester für GPT-Releases).
• Wettbewerbe: DEF CON AI Village, RSA-Konferenz-Tracks, akademische Adversarial-ML-Challenges.
• Konferenzen: SafeAI@AAAI, NeurIPS-Workshops zu Adversarial Robustness, USENIX Security.

Wichtige Werkzeuge und Bibliotheken: PromptInject, Garak, NeMo Guardrails, Adversarial Robustness Toolbox, TextAttack, OpenAttack. Anbieter wie Robust Intelligence, HiddenLayer und Lakera bieten kommerzielle Red-Teaming-Services für Enterprise-Deployments.

Im EU AI Act ist adversariales Testen für General-Purpose-AI-Modelle mit systemischem Risiko Pflicht. NIST AI RMF empfiehlt Red Teaming als Bestandteil eines AI-Risk-Management-Programms. ISO/IEC 42001 verankert Red Teaming als Element zertifizierbarer KI-Management-Systeme.

Häufige Fehler

• Red Teaming als Pflichtübung: Tests ohne Konsequenzen für Deploy-Entscheidungen sind wirkungslos. Capability-Schwellen müssen verbindlich sein.
• Nur statische Angriffsbibliotheken: Wer ausschliesslich bekannte Jailbreaks testet, ignoriert die Evolution adversarialer Techniken. Live-Threat-Intelligence ist nötig.
• Fehlende Domain-Expertise: Bio-, Cyber- und CBRN-Risiken erfordern Fachleute, nicht nur ML-Engineers. Fehlende Expertise produziert falsche Sicherheitsgefühle.
• Single-Turn-Fixierung: Multi-Turn-Angriffe sind im Produktivbetrieb häufig, in Tests aber unterrepräsentiert.
• Mangelnde Diversität im Team: Red Teams ohne kulturelle, linguistische und disziplinäre Breite finden weniger Failure-Modes.
• Schwache Dokumentation: Findings, die nicht reproduzierbar dokumentiert sind, helfen weder dem Engineering- noch dem Governance-Prozess.
• Tool-Use-Red-Teaming vernachlässigt: Agentische Systeme mit Tool-Calls sind die gefährlichste Vektor-Klasse, aber oft am schwächsten getestet.
• Externe Validierung ausgelassen: Interne Teams entwickeln blinde Flecken. Externe Audits sind kein Nice-to-have.

Abgrenzung

• Penetration Testing: Klassische Cyber-Sicherheits-Tests von Infrastruktur, nicht von KI-Modellen. Methodisch verwandt, anderer Gegenstand.
• Capability Evaluations: Strukturierte Tests spezifischer Fähigkeiten (Bioweapons-Wissen, Cyber-Offense). Ein Teilbereich von Red Teaming.
• Adversarial Examples: Klassischer ML-Angriff über Eingabe-Perturbationen, methodisches Werkzeug innerhalb von Red Teaming.
• Bias-Auditing: Fokus auf diskriminierende Outputs, ein Teilaspekt von Red Teaming.
• AI Safety: Übergeordnetes Feld, Red Teaming ist ein Werkzeug innerhalb von AI Safety.
• Blue Teaming: Defensive Sicherheitspraxis, baut Mitigationen gegen die im Red Teaming gefundenen Vektoren.