KI-Red-Teaming & Tests zur adversarialen Robustheit von Modellen und LLM-Anwendungen

LLM-Anwendungen und Agenten scheitern auf Weisen, die klassische Penetrationstests nicht sehen: Ein höflicher Satz kann einen System-Prompt preisgeben, eine E-Mail kann die Werkzeuge eines Agenten kapern, eine präparierte Eingabe kann einen Klassifikator umkippen. KI-Red-Teaming greift das Modell oder die Anwendung systematisch an, bevor es Angreifer tun. Angreifer-LLMs erzeugen Tausende von Proben, Bewertungsmodelle beurteilen die Antworten, und Menschen erkunden die kreativen Fälle. Das Ergebnis ist eine messbare Angriffserfolgsrate, eine Korrekturliste und ein Audit-Nachweis.

Problem & Nutzen

• Heute: Viele Teams liefern LLM-Funktionen nach einer Handvoll manueller „Versuch es kaputt zu machen“-Sitzungen aus oder verlassen sich auf die Sicherheitszusagen des Anbieters. Befunde sind anekdotisch, nicht wiederholbar und gehen verloren, sobald sich Modell, Prompt oder Guardrail ändern.
• KI-Nutzen: Angriffserzeugung und Bewertung sind automatisiert, sodass dieselbe Suite bei jedem Modell- Upgrade, jeder Prompt-Änderung oder jedem neuen Werkzeug läuft. Die Abdeckung wächst von Dutzenden auf Tausende von Proben; Menschen konzentrieren sich auf neuartige mehrstufige Angriffe und geschäftsspezifische Schäden.
• Pflicht: Anbieter von KI-Modellen mit allgemeinem Verwendungszweck und systemischem Risiko müssen adversariale Tests durchführen und dokumentieren (KI-Verordnung Art. 55 Abs. 1 lit. a); Hochrisiko-Systeme müssen ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen, einschließlich Widerstandsfähigkeit gegen adversariale Eingaben (Art. 15) [1]. Der GPAI-Verhaltenskodex (Kapitel Sicherheit) nennt Modellbewertung und adversariale Tests als erwartete Praxis [2].
• Reifegrad der Leitlinien: Der OWASP GenAI Red Teaming Guide, die NIST-Taxonomie zu adversarialem ML (AI 100-2) und MITRE ATLAS liefern gemeinsames Vokabular und Angriffskataloge [3][4][5].

Varianten

• Red-Teaming auf Modellebene: Anbieter von Basismodellen und Feintuner testen Sicherheitsablehnungen, CBRN-/Cyber-Uplift-Bewertungen, Verzerrungen und Missbrauch (vor allem GPAI-Anbieter, Großunternehmen).
• Red-Teaming auf Anwendungsebene: Chatbots, RAG-Assistenten, Copilots: Prompt Injection, Datenabfluss, Preisgabe des System-Prompts, übermäßige Handlungsfreiheit, mandantenübergreifende Lecks.
• Red-Teaming für Agenten und Werkzeuge: indirekte Injection über Dokumente/Web/MCP-Werkzeugausgaben, Werkzeug- Missbrauch, Rechteausweitung über Werkzeuge hinweg (Verweis auf SEC-013).
• Klassische adversariale Robustheit: Umgehung, Vergiftung und Modellextraktion gegen Bild-, Tabellen- und Betrugsmodelle (z. B. Betrugs- oder Malware-Klassifikatoren).
• Kontinuierliches Red-Teaming in CI/CD: ein kleinerer Probensatz als Freigabeschranke.
• Öffentlicher Sektor / KMU: vor dem Go-live eines bürger- oder kundenseitigen Chatbots eine verwaltete Prüfung einkaufen, statt ein Team aufzubauen.
• Privatnutzung: nicht anwendbar.

So funktioniert es

1. scope & threat model (SEC-012)
2. attack objectives per risk category
3. probe generation (static libraries + attacker LLM, multi-turn, encodings, languages)
4. execution against target (API / UI / agent with sandboxed tools)
5. scoring (rule checks + LLM judge + human sampling)
6. triage (severity, exploitability, business impact)
7. fix (prompt, guardrails SEC-010, tool permissions, model choice, data)
8. retest
9. report & evidence archive; regression suite into CI/CD

• Angreifer-Modelle: Ein LLM formuliert Ausgangsziele in Jailbreaks, Rollenspiele und mehrstufige Eskalationen um (Strategien im Stil von PAIR/TAP/Crescendo) und verändert Proben, die teilweise erfolgreich sind.
• Bewertungsmodelle (Judges): Ein LLM-as-Judge klassifiziert, ob eine Antwort gegen die Richtlinie verstieß; die Judges sind selbst unvollkommen, daher kalibriert eine geschichtete menschliche Stichprobe sie.
• Mensch-in-der-Schleife (Human-in-the-Loop): Menschen legen Umfang und Einsatzregeln fest, prüfen alle Befunde mit hohem Schweregrad, führen kreative manuelle Angriffe durch und entscheiden über die Freigabe. Tests gegen von Dritten gehostete Modelle erfordern die Bedingungen und die Genehmigung des Anbieters.
• Sicherheit des Tests selbst: gegen eine Staging-Umgebung mit Testdaten und abgeschotteten Werkzeugen testen; schädliche Ausgaben unter Zugriffskontrolle speichern; die Produktion nicht mit echten Kundendaten testen.

Datenaufbereitung

Red-Teaming braucht wenige Geschäftsdaten, aber guten Kontext: den System-Prompt und die Architektur der KI-Anwendung, ihre Werkzeugberechtigungen, die erreichbare Wissensbasis und Richtliniendokumente, die festlegen, was als Verstoß gilt. In einem KMU liegen diese im Repository der Entwickler, in der Verwaltungskonsole des Anbieters und eher in den Köpfen als in Dokumenten.

Typische Lücken: kein schriftliches Bedrohungsmodell und keine Liste unzulässiger Ausgaben, undokumentierte Werkzeugberechtigungen, keine Staging-Umgebung mit realistischen, aber synthetischen Daten und kein Regressionstestsatz aus früheren Vorfällen.

Schritte zur Vorbereitung: 1. Anwendungsumfang, Datenflüsse und Werkzeugrechte dokumentieren (SEC-012 für das Bedrohungsmodell). 2. Eine Staging-Kopie mit synthetischen oder pseudonymisierten Daten anlegen (PREP-022); niemals mit echten Kundendaten testen. 3. Die Richtlinie als prüfbare Regeln aufschreiben und erste Proben samt erwartetem Verhalten sammeln (PREP-018). 4. Schweregradkategorien festlegen (PREP-019). 5. Befunde als wachsende Regressionssuite aufbewahren (PREP-021 für Rückmeldungen).

Werkzeuge: Markdown oder ein Wiki für den Umfang, ein Git-Repository für Proben, promptfoo- oder garak-Konfigurationen. Grober Aufwandsanteil: 10–20 Prozent; die Hauptarbeit ist das Testen selbst. Zur allgemeinen Bereitschaft siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg C — Open-Source-Scanner wie garak, PyRIT oder promptfoo laufen auf bescheidener Hardware, benötigen nur Testdaten, und dieselben Evaluierungswerkzeuge dienen später weiteren KI-Projekten (Baukasten-Effekt); kommerzielle Plattformen sind auf größere Programme zugeschnitten.
• Großunternehmen: Weg B — ein eigenes Test-Harness auf Cloud-KI-Diensten (Angreifer- und Judge-Modelle, EU-Region), eingebunden in CI/CD und den Governance-Prozess, passt besser zu einem zentralen, wiederkehrenden Programm als ein einzelnes Produkt; Weg A für externe Pentest-Dienste obendrauf.
• Entwickler: Weg C — Open-Source-Frameworks sind die Standardwerkzeuge und lassen sich erweitern und lokal in der CI ausführen.
• Öffentlicher Sektor: Weg C — selbst betriebene Angreifer- und Judge-Modelle auf souveräner Infrastruktur vermeiden es, Prompts, System-Prompts und Befunde an Dritte zu senden; nur zertifizierte Dienste einkaufen.

Weg A — Kaufen (Standardsoftware)

• Kommerzielle Plattformen und Dienste: Giskard (französisch, EU; LLM-Scan und kontinuierliches Red-Teaming), Lakera (Schweiz; Lakera Red, inzwischen Teil von Check Point), Mindgard, HiddenLayer, Protect AI (Palo Alto Networks), Robust Intelligence (Cisco AI Defense), Promptfoo (Enterprise-Edition; 2026 von OpenAI übernommen, Open-Source-Kern wird fortgeführt) sowie die KI-Sicherheitsangebote großer Beratungshäuser. Auch Hyperscaler bieten Funktionen, z. B. den Azure AI Foundry AI Red Teaming Agent (auf Basis von PyRIT).
• A wählen, wenn: keine KI-Sicherheitskompetenz im Haus ist, ein Go-live-Termin drängt oder ein Kunde einen unabhängigen Bericht verlangt. Prüfen Sie EU-Hosting, ob Testdaten Ihren Mandanten verlassen, und wie oft die Angriffsbibliothek aktualisiert wird.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Ein Spitzenmodell (Claude, GPT, Gemini, Mistral in EU-Regionen) als Angreifer und Judge nutzen, orchestriert mit Werkzeugen wie PyRIT oder promptfoo. Beachten Sie, dass manche Anbieter die Erzeugung von Angriffsinhalten einschränken; prüfen Sie die Nutzungsrichtlinien und beantragen Sie Red-Team-Ausnahmen, wo sie angeboten werden.
• In der CI (GitHub Actions/GitLab) orchestrieren und Ergebnisse an ein SIEM oder Ticketsystem übergeben.
• B wählen, wenn: Sie hohe Qualität bei Angreifer und Judge wollen und keine GPU-Kapazität haben.

Weg C — Selbst betreiben (Open Source)

• Werkzeuge: NVIDIA garak (LLM-Schwachstellenscanner), Microsoft PyRIT (Python Risk Identification Tool), promptfoo (MIT-lizenzierte Evaluierungs- und Red-Team-CLI), DeepTeam/DeepEval, die Open-Source-Bibliothek von Giskard, Meta Purple Llama / CyberSecEvals, UK AISI Inspect für Evaluierungen, Adversarial Robustness Toolbox (ART) für klassisches ML sowie Datensätze wie HarmBench, AdvBench und JailbreakBench [6][7][8].
• Modelle: Angreifer-/Judge-Modelle mit offenen Gewichten, etwa aus den Familien Llama, Qwen oder Mistral, betrieben über vLLM oder Ollama; Safeguard-Klassifikatoren wie Llama Guard oder ShieldGemma als zusätzliche Judges.
• Hardware: HW2 genügt, um Ziele mittlerer Größe mit einem quantisierten Judge von ca. 30B zu prüfen; HW3 für höhere Judge-Qualität. Betriebsaufwand: ein Ingenieur in Teilzeit zur Pflege von Proben und Pipelines.
• Vorteil: Keine sensiblen Prompts oder Systemanweisungen verlassen Ihr Haus.

Weg D — Eigenes Training

Lohnt sich für große Anbieter: ein eigenes Angreifer-Modell auf erfolgreichen früheren Exploits feintunen oder einen domänenspezifischen Judge auf gelabelten Verstößen trainieren (Hunderte bis Tausende Beispiele aus Ihrer eigenen Richtlinie). Adversariales Training klassischer Modelle (ART), wenn Umgehung eine reale Bedrohung ist.

Stand der Technik (2026)

• Automatisierte mehrstufige Angreifer finden inzwischen Jailbreaks gegen die meisten eingesetzten Modelle; veröffentlichte Benchmarks (HarmBench, JailbreakBench) zeigen, dass kein Modell gegen alle Angriffsklassen robust ist [7][8].
• Agentenangriffe dominieren: Indirekte Prompt Injection über Werkzeugausgaben und Dokumente ist das wichtigste praktische Risiko agentischer Systeme; OWASP führt Prompt Injection in seiner LLM-Top-10 an erster Stelle [3][9].
• Werkzeugkonvergenz: Probenformate werden um PyRIT, garak und promptfoo-Plug-ins vereinheitlicht, die auf OWASP- und MITRE-ATLAS-Kategorien abgebildet sind; Berichte ordnen Befunde der KI-Verordnung und ISO/IEC 42001 zu.
• Grenzen und Fehlerbilder: Die Angriffserfolgsrate hängt von Judge und Angreifer ab; Ergebnisse sind nicht deterministisch und modellversionsspezifisch; das Bestehen einer Suite sagt wenig über unbekannte Angriffe aus; LLM-Judges übersehen subtile Schäden und markieren harmlose Texte zu oft; die Abdeckung nicht englischer (z. B. deutscher) Angriffe ist oft schwächer; die Behebung einer Probenklasse kann eine andere verschlechtern. Betrachten Sie die Zahl als Trendindikator, nicht als Sicherheitsgarantie.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Werkzeuge und GPU: Derselbe HW2-/HW3-Server und dieselben Judge-Modelle dienen der Evaluierungsarbeit in SEC-010 (Guardrail-Abstimmung), und Fähigkeiten von Angreifer-LLMs überschneiden sich mit SEC-007 (Infrastruktur-Pentests).
• Vorgelagert: SEC-012 liefert das Bedrohungsmodell, das die Tests eingrenzt; SEC-013 liefert das Inventar der zu testenden KI-Systeme und Agenten; SEC-016 behandelt bösartige Modellartefakte.
• Nachgelagert: SEC-010 erhält aus den Befunden neue Guardrail-Regeln; SEC-022 nutzt die Nachweise für die Dokumentation nach der KI-Verordnung.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage für die Einrichtung, Abonnement oder Preis je Auftrag; verwaltete Prüfungen dauern Wochen.
• Weg B: 2–6 Wochen für eine in die CI eingebundene Pipeline; die Kosten bestehen hauptsächlich aus API-Tokens für Angreifer- und Judge-Aufrufe (Tausende mehrstufiger Konversationen pro Lauf).
• Weg C: 1–3 Monate bis zur Reife; GPU-Server plus Ingenieur in Teilzeit.
• Kennzahlen: Angriffserfolgsrate je Kategorie und Version, Anzahl offener kritischer Befunde, mittlere Behebungszeit, Übereinstimmung von Judge und Mensch, Abdeckung der OWASP-/ATLAS-Kategorien, Anteil der Releases, die durch die Suite freigegeben werden, Regressionsrate.

Menschen & Veränderung

Binden Sie zuerst die Geschäftsführung für Umfang, Budget und Genehmigung ein, da Tests gehosteter Modelle die Erlaubnis des Anbieters brauchen. Die Fachbereichsleitung, die die KI-Anwendung verantwortet, und die IT-Sicherheit legen gemeinsam die Einsatzregeln fest; die IT stellt die Staging-Umgebung bereit; die bzw. der Datenschutzbeauftragte bestätigt, dass keine echten personenbezogenen Daten in die Tests gelangen, und entscheidet über eine Datenschutz-Folgenabschätzung (DSFA) für die Anwendung selbst (GUIDE-005); die Rechtsabteilung prüft die Anbieterbedingungen und die Haftung.

Betriebsrat: in der Regel nein. Die Tests richten sich gegen Systeme, nicht gegen Beschäftigte, daher wird §87 Abs. 1 Nr. 6 BetrVG normalerweise nicht ausgelöst. Ausnahmen: Wenn menschliche Red-Team-Übungen Social Engineering gegenüber Beschäftigten einschließen oder Ergebnisse einzelnen Entwicklern zugeordnet werden, beziehen Sie den Betriebsrat ein, und informieren Sie ihn nach §90 Abs. 1 Nr. 3 frühzeitig über KI-Projekte (GUIDE-004). In Behörden prüfen Sie den Personalrat.

Stellen Sie Red-Teaming als Qualitätssicherung dar, nicht als Schuldzuweisung: Die Befunde betreffen das System. Wählen Sie eine Anwendung mit mäßigem Risiko als Pilot (GUIDE-009) und halten Sie den ersten Bericht kurz, mit konkreten Korrekturen. Fördern Sie die KI-Kompetenz von Entwicklern und Anwendungsverantwortlichen mit einem Workshop zu Prompt Injection und Jailbreaks (Art. 4 KI-Verordnung, GUIDE-006, GUIDE-013). Typische Sorge: die Angst, Markteinführungen zu verzögern; begegnen Sie ihr mit automatisierten Regressionsprüfungen in der CI. Menschen legen den Umfang fest, prüfen alle Befunde mit hohem Schweregrad und entscheiden über die Freigabe.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Tätigkeit selbst ist ein minimales Risiko. Sie erzeugt Nachweise für Pflichten an anderer Stelle: Art. 15 (Robustheit, Cybersicherheit) für Hochrisiko-Systeme, Art. 55 Abs. 1 lit. a für GPAI mit systemischem Risiko, Art. 4 KI-Kompetenz für das Team [1]. Das Red-Teaming sollte außerdem das Zielsystem auf nach Art. 5 verbotenes Verhalten (z. B. manipulative Techniken) und auf die Transparenz nach Art. 50 prüfen.
• DSGVO: Angriffe können personenbezogene Daten aus Trainingsdaten oder RAG-Korpora herauslösen; verwenden Sie synthetische oder Testdaten, behandeln Sie Protokolle mit abgeflossenen Daten als personenbezogene Daten und wenden Sie Datenminimierung und Aufbewahrungsfristen an. Auftragsverarbeitungsverträge (AVV) gelten, wenn ein Anbieter die Tests durchführt.
• Sicherheit und Recht: Tests von Diensten Dritter ohne Erlaubnis können gegen Nutzungsbedingungen und Computerstrafrecht verstoßen; holen Sie eine schriftliche Genehmigung und Einsatzregeln ein. NIS2 und DORA (Resilienztests) können solche Tests zum Teil einer umfassenderen Pflicht machen.
• Risiken und Gegenmaßnahmen: schädliche Testausgaben (Zugriff beschränken, nicht breit teilen), falsche Sicherheit (Grenzen der Abdeckung benennen), Preisgabe von System-Prompts an externe SaaS (bei sensiblen Prompts Weg C bevorzugen), Verzerrung der Judges (menschliche Kalibrierung).

Erste Schritte

1. Die KI-Systeme im Geltungsbereich inventarisieren (SEC-013) und nach Datenzugriff und Werkzeugmacht ordnen.
2. Einsatzregeln festlegen: Umfang, Testumgebung, Daten, Genehmigung, Eskalation.
3. garak oder promptfoo mit den Plug-ins der OWASP LLM Top 10 gegen einen Staging-Chatbot laufen lassen; Ausgangswert festhalten.
4. Die wichtigsten Befunde beheben (Prompt, Werkzeugberechtigungen, Guardrails SEC-010) und zur Bestätigung erneut laufen lassen.
5. Eine verkleinerte Suite als Freigabeschranke in die CI aufnehmen und eine vierteljährliche, von Menschen geführte Übung planen.

Quellen

1. Regulation (EU) 2024/1689 (AI Act), Art. 15 and Art. 55 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. European Commission — General-Purpose AI Code of Practice — https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
3. OWASP GenAI Security Project — https://genai.owasp.org/
4. NIST AI 100-2e2025 Adversarial Machine Learning taxonomy — https://csrc.nist.gov/pubs/ai/100/2/e2025/final
5. MITRE ATLAS — https://atlas.mitre.org/
6. NVIDIA garak — https://github.com/NVIDIA/garak
7. Microsoft PyRIT — https://github.com/Azure/PyRIT
8. promptfoo red teaming docs — https://www.promptfoo.dev/docs/red-team/
9. HarmBench — https://www.harmbench.org/
10. Giskard — https://www.giskard.ai/