AI Red Teaming

AI Red Teaming ist das geplante Angreifen einer KI-Anwendung durch das eigene Team, um Schwachstellen zu finden, bevor echte Angreifer es tun. Getestet werden Sprachmodelle (LLMs, also Systeme wie ChatGPT) und KI-Agenten (Programme, die eigenständig Werkzeuge wie E-Mail oder Datenbanken bedienen). Tester versuchen gezielt, Schutzregeln auszuhebeln (Jailbreak), interne Daten auszuleiten oder das System zu missbräuchlichen Aktionen zu bringen. Sie halten fest, wie der Angriff funktioniert, was er anrichtet und wie dringend er gestoppt werden muss. Das ist keine einmalige Übung, sondern eine wiederkehrende Test-Disziplin mit eigenem Werkzeug-Kasten, Fachprofil und Berichtsweg.

Was ist AI Red Teaming?

AI Red Teaming prüft das KI-System selbst und macht sichtbar, an welchen Eingaben, Werkzeug-Zugriffen und Datenwegen ein Sprachmodell oder Agent falsch reagiert. Zur Angriffsfläche zählen die Benutzer-Eingabe (Prompt), das Modell selbst, angebundene Wissensquellen (die sogenannten RAG-Quellen, also Dokumente, aus denen sich das Modell zur Laufzeit bedient), der Gesprächsverlauf über mehrere Züge und (bei Agenten) die Werkzeug-Aufrufe sowie die Weitergabe an Unter-Agenten. Der Begriff wurde im Oktober 2023 im Zuge der US-Regierungsverordnung zu KI-Sicherheit (Executive Order) in seiner heutigen Form etabliert und in drei Standard-Rahmenwerken verankert: dem NIST AI Risk Management Framework (US-amerikanisches KI-Risiko-Regelwerk), dem EU AI Act (KI-Gesetz der EU) und den OWASP LLM Top 10 (Rangliste der wichtigsten Sprachmodell-Schwachstellen).

Das Test-Programm folgt einem stabilen Kategorien-Katalog: Direct und Indirect Prompt Injection, Jailbreak, Tool-Missbrauch, Datenabfluss über die Antwort, Multi-Turn-Manipulation, Multi-Modal-Angriffe (Bild, Audio, Dokument-Layout) und agenten-spezifische Vektoren wie RAG-Poisoning oder MCP-Tool-Hijacking. OWASP LLM Top 10 und MITRE ATLAS liefern die Referenz-Frames, an denen sich die Test-Kategorien orientieren.

Der heutige Referenz-Stack besteht aus [Microsoft PyRIT](https://github.com/Azure/PyRIT) (Python Risk Identification Toolkit) als Open-Source-Framework mit den vier Bausteinen Target, Orchestrator, Converter und Scorer, [NVIDIA garak](https://github.com/NVIDIA/garak) als LLM-Vulnerability-Scanner mit über zwanzig Probe-Familien und UK AISI Inspect als breiteres Evaluations-Framework. MITRE ATLAS ergänzt keine Tests, dafür die Wissensbasis adversarialer Techniken gegen ML-Systeme.

Regulatorisch verlangt der EU AI Act für GPAI-Modelle mit systemischem Risiko und für Hochrisiko-Systeme dokumentiertes adversarial testing; der GPAI Code of Practice konkretisiert nachvollziehbare Test-Kategorien, dokumentierte Methodik und Reporting-Pflichten gegenüber dem AI Office. NIST AI RMF verankert Red Teaming in der Measure-Phase. Frontier-Labs wie Anthropic (Responsible Scaling Policy, Frontier Red Team) und [OpenAI](https://openai.com/index/openai-preparedness-framework/) (Preparedness Framework, System Cards pro Release) setzen die methodischen Maßstäbe.

Abgrenzung zu Pen-Test, Evals, Guardrails und Bug Bounty

Vier Verfahren werden im Alltag oft vermischt, obwohl sie unterschiedliche Aufgaben lösen. Die Trennung ist die Voraussetzung dafür, dass ein KI-Sicherheits-Programm alle Ebenen abdeckt.

Ein Pen-Test schaut auf die Infrastruktur um das Modell herum und übersieht die Modell-Ebene. Evals geben einen Score, aber keinen Angriffsweg. Guardrails sind Ziel und Komplement des Red Teamings, weil ein Red Team validiert, ob die Filter unter adversarialem Druck halten. Bug Bounty ist ein zeitlich unbefristetes, honorierendes Programm für externe Beitragende und ergänzt Red Teaming, ersetzt es aber nicht: Ein Red-Team-Engagement liefert methodisch dokumentierte Coverage, ein Bounty liefert unstrukturierte Meldungen aus der Community.

Guardrails ohne Red Teaming vertrauen darauf, dass Vendor-Voreinstellung und eigene Konfiguration zusammen tragen. Red Teaming ohne Evals sieht die Sicherheit, aber keine Antwort-Qualität. Eine belastbare KI-Sicherheitsarbeit kombiniert alle vier Verfahren mit definierten Übergaben zwischen den Teams.

Beispiel: Support-Agent mit einer Red-Team-Suite

Ein produktiver Support-Agent mit RAG-Anbindung, Ticket-Tool und Kundendatenbank soll vor dem Go-Live geprüft werden. Ein Workshop mit zwanzig adversarialen Prompts liefert eine Momentaufnahme vom Test-Tag; sechs Wochen später nach dem nächsten Modell-Update sagt der Report nichts mehr aus. Der Auditor fragt nach dokumentiertem adversarial testing, das Protokoll dokumentiert einen Stichproben-Termin ohne Wiederholung.

Mit einer Red-Team-Suite auf PyRIT-Basis läuft die Testreihe versioniert: definierte Test-Cases pro OWASP-LLM-Top-10-Kategorie, ein Multi-Turn-Orchestrator gegen die eigene Antwort-Policy, eine RAG-Sandbox mit Indirect-Prompt-Injection-Payloads in Dokumenten und Mails, ein Scorer, der die Domänen-Policy kalibriert bewertet. Die Suite läuft an drei Integrationspunkten: als Pre-Production-Gate vor jedem Release mit Schwellenwerten pro Kategorie, als Regression-Suite bei jedem Vendor-Modell-Update (etwa GPT-5.x auf Claude-4.x) gegen die Baseline und als Continuous-Sampling wöchentlich gegen das Produktiv-System. Findings landen mit Trace-ID im gleichen Tracking-System wie Modell-Metriken, kritische Kategorien haben dokumentierte Eskalations-Pfade in die AI-Governance. Der Audit-Trail für den AI Act entsteht als Nebenprodukt und beantwortet die Coverage-Frage nachweisbar.