Vor wenigen Jahren bedeutete „Red-Teaming“ bei LLMs oft, dass einige Forschende ein Wochenende lang versuchten, Sicherheitsfilter mit kreativen Prompts zu umgehen. 2026 ist daraus eine strukturierte Engineering-Disziplin geworden: mit Methodik, automatisierten Tools, dokumentierten Schwachstellenklassen und kontinuierlichen Tests vor und nach dem Deployment.
Der Grund ist einfach: Die Angriffsfläche ist gewachsen. Eine systematische Studie aus 2025 untersuchte mehr als 1.400 adversariale Prompts gegen GPT-4, Claude 2, Mistral 7B und Vicuna und fand besonders hohe Erfolgsraten bei rollenbasierten Prompt-Injections, Logikfallen und Encoding-Tricks. Für Produktteams ist die Konsequenz klar: Gehen Sie davon aus, dass Ihr Modell angegriffen wird. Gehen Sie davon aus, dass Nutzer Sicherheitsgrenzen testen. Und gehen Sie davon aus, dass einfache Prompt-Regeln allein nicht ausreichen.
LLM-Red-Teaming ist deshalb kein akademischer Sicherheitstest mehr. Es ist ein praktischer Prozess, mit dem Teams herausfinden, wie ein KI-System unter adversarialen Bedingungen reagiert: bei Prompt Injection, Jailbreaks, Datenabfluss, Tool-Missbrauch, Bias, Halluzinationen oder mehrstufigen Angriffen auf Agenten-Workflows.
Dieser Leitfaden richtet sich an AI Leads, Security Engineers und Product Manager, die LLM-Systeme mit echten Sicherheitsanforderungen ausrollen. Der Fokus liegt nicht auf einzelnen Exploit-Prompts, die sich ständig verändern, sondern auf einem belastbaren Red-Teaming-Programm, das in Produktentwicklung, CI/CD und Governance integriert werden kann.
Was Red-Teaming tatsächlich bedeutet
Ein LLM zu red-teamen bedeutet, das System absichtlich unter Druck zu setzen, um Sicherheits-, Zuverlässigkeits- und Compliance-Schwächen zu finden, bevor externe Nutzer oder Angreifer sie ausnutzen. Dabei wird nicht nur das Basismodell getestet. Getestet wird das gesamte System: System Prompt, Retrieval, Tools, Agentenlogik, Berechtigungen, Guardrails, Logging, Moderation und Output-Kontrollen.
Diese Unterscheidung ist entscheidend. Viele Risiken entstehen nicht im Modell allein, sondern in der Produktintegration. Ein Modell kann relativ sicher antworten, aber ein Tool mit zu breiten Berechtigungen ausführen. Ein Chatbot kann personenbezogene Daten nicht direkt ausgeben, aber über Retrieval versehentlich vertrauliche Dokumente zusammenfassen. Ein Agent kann einzeln harmlose Schritte kombinieren und dadurch riskante Aktionen auslösen.
Gutes Red-Teaming betrachtet deshalb Modellverhalten und Systemverhalten gemeinsam. Die zentrale Frage lautet: Welche unerwünschten Ergebnisse kann ein motivierter Nutzer über alle verfügbaren Eingaben, Kontexte und Werkzeuge hinweg erzeugen?
Die Schwachstellen-Taxonomie, die abgedeckt werden muss
Prompt Injection
Prompt Injection versucht, die ursprünglichen Instruktionen eines Systems zu überschreiben oder umzuleiten. Das kann direkt über den Nutzerprompt geschehen oder indirekt über Dokumente, Webseiten, E-Mails oder andere Inhalte, die das Modell verarbeitet. Besonders gefährlich ist indirekte Prompt Injection in RAG- und Agentensystemen, weil die Angriffsanweisung nicht vom Nutzer selbst kommen muss.
Jailbreaking
Jailbreaking zielt darauf ab, Sicherheitsrichtlinien des Modells zu umgehen. Typische Muster sind Rollenspiele, hypothetische Szenarien, mehrstufige Umformulierungen, Encodings oder Autoritätsbehauptungen. Einzelne Jailbreak-Techniken altern schnell, aber die zugrunde liegende Logik bleibt: Der Angreifer versucht, die Grenze zwischen erlaubter und verbotener Antwort systematisch zu verschieben.
PII- und sensitive Datenlecks
LLM-Systeme können sensible Informationen über Trainingsdaten, Retrieval-Kontexte, Logs, Uploads oder Tools offenlegen. Red-Teaming muss prüfen, ob das System personenbezogene Daten, vertrauliche Geschäftsdetails, Zugangsinformationen oder interne Dokumente ausgibt, wenn es dazu manipuliert wird. In europäischen Deployments ist dieser Bereich besonders relevant für Datenschutz und regulatorische Nachvollziehbarkeit.
Halluzination und Fehlinformation
Nicht jede Sicherheitslücke ist ein klassischer Angriff. Ein System kann Risiken erzeugen, indem es falsche Informationen mit hoher Sicherheit präsentiert. In Finance, Healthcare, Legal, Defense oder Industrie kann das zu realen Schäden führen. Red-Teaming sollte deshalb auch Situationen testen, in denen das Modell unter Unsicherheit, Zeitdruck oder widersprüchlichem Kontext antwortet.
Tool- und Agentenmissbrauch
Sobald ein LLM Tools aufrufen kann, verschiebt sich das Risiko. Das Problem ist dann nicht nur eine falsche Antwort, sondern eine falsche Aktion: E-Mails senden, Daten löschen, Tickets erstellen, Code ausführen, CRM-Felder verändern oder Dateien abrufen. Red-Teaming muss Berechtigungen, Bestätigungsschritte, Kontextgrenzen und Tool-Auswahl testen.
Bias und Diskriminierung
LLM-Systeme können Entscheidungen, Empfehlungen oder Moderationsurteile systematisch verzerren. Red-Teaming sollte deshalb auch geschützte Merkmale, Sprachvarianten, kulturelle Kontexte und unterschiedliche Nutzergruppen berücksichtigen. Für Unternehmen ist das nicht nur ein Ethikthema, sondern auch ein Governance- und Reputationsrisiko.
Die fünfphasige Methodik
Phase 1: Reconnaissance
Der erste Schritt ist das Verständnis des Systems. Welche Modelle werden verwendet? Welche Prompts steuern das Verhalten? Welche Tools sind verfügbar? Welche Datenquellen werden per RAG eingebunden? Welche Nutzerrollen existieren? Welche Sicherheitsziele gelten? Ohne diese Kartierung testet das Team zufällig statt systematisch.
Phase 2: Angriffsgenerierung
Auf Basis der Systemkarte werden Angriffsszenarien erstellt. Gute Testsets kombinieren bekannte Schwachstellenklassen mit domänenspezifischen Risiken. Für einen Kundensupport-Bot unterscheiden sich die Szenarien von einem Legal-Copilot, einem medizinischen Assistenten oder einem Defense-Analysewerkzeug. Die Angriffe sollten einfache Single-Turn-Prompts, mehrstufige Konversationen und indirekte Eingaben umfassen.
Phase 3: Ausführung
Die Angriffe werden kontrolliert ausgeführt und protokolliert. Wichtig ist Reproduzierbarkeit: Modellversion, Promptversion, Retrieval-Kontext, Parameter, Tool-Aufrufe und Guardrail-Reaktionen müssen dokumentiert werden. Sonst kann das Team später nicht prüfen, ob eine Schwachstelle wirklich behoben wurde.
Phase 4: Validierung und Triage
Nicht jeder auffällige Output ist ein kritischer Befund. Die Ergebnisse müssen nach Schweregrad, Wahrscheinlichkeit, Business Impact und regulatorischer Relevanz priorisiert werden. Ein harmloser Stilbruch ist anders zu behandeln als ein reproduzierbarer Datenabfluss oder ein Tool-Aufruf ohne Berechtigung.
Phase 5: Mitigation und Re-Test
Red-Teaming endet nicht mit einem Bericht. Jede relevante Schwachstelle braucht eine Gegenmaßnahme und einen erneuten Test. Mögliche Mitigations sind Prompt-Änderungen, zusätzliche Guardrails, Tool-Berechtigungen, Retrieval-Filter, Output-Moderation, Human Approval oder Produktänderungen. Erst der Re-Test zeigt, ob das Risiko tatsächlich reduziert wurde.
Tooling-Landschaft 2026
DeepTeam
DeepTeam eignet sich für strukturierte Red-Teaming-Läufe, bei denen Angriffe systematisch generiert, ausgeführt und ausgewertet werden sollen. Für Teams, die bereits LLM-Evaluation automatisieren, ist es ein naheliegender Schritt, Sicherheitstests in dieselbe Qualitätssicherungslogik zu integrieren.
PyRIT von Microsoft
PyRIT ist besonders nützlich für reproduzierbare Security-Workflows und die Orchestrierung adversarialer Tests. Es hilft Teams, Angriffsszenarien zu strukturieren, Ergebnisse zu speichern und Tests wiederholbar zu machen. Für Enterprise- und Forschungsumgebungen ist diese Nachvollziehbarkeit wichtig.
Garak von NVIDIA
Garak ist ein bekanntes Open-Source-Tool für die Prüfung von LLM-Schwachstellen. Es kann verschiedene Angriffsklassen abdecken und eignet sich gut, um Basisschwächen eines Modells oder einer Integration sichtbar zu machen. Wie bei allen Tools gilt: Es ersetzt nicht die domänenspezifische Risikoanalyse.
PromptBench, Promptfoo und weitere Tools
Promptfoo, PromptBench und ähnliche Werkzeuge helfen bei Regressionstests, Prompt-Vergleichen und automatisierten Evaluationsläufen. Sie sind besonders hilfreich, wenn Sicherheits- und Qualitätsanforderungen bei jeder Änderung am Prompt oder Modell erneut geprüft werden sollen.
Eigene Harnesses für Geschäftslogik
Viele kritische Risiken sind unternehmensspezifisch. Ein Standardtool weiß nicht, welche CRM-Aktion gefährlich ist, welche Dokumentklasse vertraulich ist oder welche Kombination aus Nutzerrolle und Tool-Aufruf verboten sein sollte. Deshalb brauchen reife Teams oft eigene Test-Harnesses, die Business-Logik, Berechtigungen und Workflows abbilden.
Single-Turn vs. Multi-Turn Red-Teaming
Single-Turn-Tests sind wichtig, aber unzureichend. Viele reale Angriffe entstehen über mehrere Interaktionen: Der Nutzer baut Vertrauen auf, verändert den Kontext schrittweise, fordert Zwischenantworten an oder kombiniert scheinbar harmlose Schritte. Multi-Turn-Red-Teaming prüft, ob Sicherheitsgrenzen auch über längere Konversationen stabil bleiben.
Das ist besonders relevant für Agenten. Ein Agent kann zuerst Informationen sammeln, dann ein Tool wählen, dann eine Aktion ausführen. Jeder Schritt kann isoliert plausibel sein, aber zusammen ein Risiko erzeugen. Red-Teaming muss diese Sequenzen testen, nicht nur einzelne Antworten.
Defense in Depth: Warum Einzelmaßnahmen scheitern
Input-Schicht
Input-Filter können offensichtliche Angriffe erkennen, sollten aber nie die einzige Verteidigung sein. Angriffe lassen sich umformulieren, kodieren oder über indirekte Quellen einschleusen. Input-Kontrollen sind ein erster Filter, kein Sicherheitsmodell.
Modell- und Prompt-Schicht
System Prompts, Rollenbeschreibungen und Modellrichtlinien definieren gewünschtes Verhalten. Sie sind notwendig, aber manipulierbar. Sicherheit darf nicht ausschließlich davon abhängen, dass das Modell eine Instruktion befolgt.
Output-Schicht
Output-Moderation kann sensible Informationen, toxische Inhalte oder unerlaubte Handlungsanweisungen erkennen. Sie ist besonders wertvoll als zweite Kontrolle nach der Generierung. Allerdings muss sie an den Domänenkontext angepasst werden, sonst entstehen zu viele False Positives oder False Negatives.
Tool- und Zugriffskontrollschicht
Tools brauchen minimale Berechtigungen, explizite Allow-Lists und, bei riskanten Aktionen, menschliche Bestätigung. Ein LLM sollte nicht durch Prompting allein entscheiden können, ob eine irreversible Aktion ausgeführt wird.
Monitoring- und Observability-Schicht
Auch nach dem Deployment muss das System überwacht werden. Logs, Fehlermuster, Nutzerfeedback und Sicherheitsereignisse liefern neue Testfälle. Ohne Monitoring wird Red-Teaming zu einer einmaligen Momentaufnahme statt zu einer kontinuierlichen Sicherheitsdisziplin.
Red-Teaming als kontinuierliche Disziplin betreiben
Vor dem Deployment
Vor dem Launch sollte jedes relevante LLM-System einen strukturierten Red-Teaming-Lauf durchlaufen. Ziel ist nicht absolute Sicherheit, sondern das Finden der wahrscheinlichsten und folgenreichsten Fehler, solange sie noch kontrolliert behoben werden können.
CI/CD-Integration
Wenn Prompts, Modelle, Retrieval-Indizes oder Tools geändert werden, sollten zentrale Sicherheitstests automatisch laufen. Kleine Änderungen können unerwartete Regressionen erzeugen. CI/CD-Tests verhindern, dass bekannte Schwachstellen versehentlich zurückkehren.
Kontinuierliches Produktionsmonitoring
Produktionsdaten zeigen, welche Angriffe und Fehlverwendungen tatsächlich auftreten. Diese Signale sollten in neue Testfälle übersetzt werden. So wächst das Red-Teaming-Programm mit dem Produkt.
Regelmäßige Deep-Dive-Engagements
Zusätzlich zu automatisierten Tests sind periodische manuelle Red-Team-Engagements sinnvoll. Externe oder unabhängige Tester erkennen oft Muster, die interne Teams übersehen. Für regulierte Branchen kann ein dokumentierter Deep Dive auch Teil der Lieferanten- oder Audit-Anforderungen sein.
Wann menschliche Red-Teamer unverzichtbar bleiben
Automatisierte Tools skalieren bekannte Angriffsmuster. Menschen finden oft die kreativen, kontextabhängigen und geschäftskritischen Lücken. Sie verstehen Produktlogik, Nutzerpsychologie, regulatorische Grauzonen und domänenspezifische Schäden. Besonders bei neuen Agenten-Workflows, sensiblen Daten, Defense-Anwendungen oder öffentlich sichtbaren KI-Produkten bleibt menschliches Red-Teaming zentral.
Der beste Ansatz kombiniert beides: automatisierte Regressionstests für bekannte Risiken und menschliche Exploration für neue Schwachstellenklassen. So entsteht ein Sicherheitsprozess, der nicht nur schneller, sondern auch intelligenter wird.
Was das für europäische KI-Teams bedeutet
Europäische Unternehmen müssen LLM-Sicherheit zunehmend mit Datenschutz, EU AI Act, Lieferantenprüfung, Datenresidenz und Auditierbarkeit verbinden. Red-Teaming sollte deshalb nicht als isolierter Security-Test verstanden werden, sondern als Teil der KI-Governance. Die Ergebnisse müssen dokumentiert, versioniert und in Risikoentscheidungen übersetzt werden.
Für Unternehmen in regulierten oder sicherheitskritischen Bereichen ist besonders wichtig, dass Red-Teaming nachvollziehbar bleibt: Welche Systeme wurden getestet? Welche Schwachstellenklassen waren im Scope? Welche Befunde wurden priorisiert? Welche Mitigations wurden umgesetzt? Welche Restrisiken wurden akzeptiert?
Das ehrliche Fazit
LLM-Red-Teaming ist 2026 keine optionale Zusatzprüfung mehr. Es ist eine Kernkomponente sicherer KI-Produktentwicklung. Ein Modell kann in Standardtests nützlich, höflich und korrekt wirken und unter adversarialen Bedingungen trotzdem Daten preisgeben, Tools missbrauchen oder gefährliche Antworten erzeugen.
Teams, die Red-Teaming früh integrieren, erkennen diese Fehler, bevor sie in Produktion sichtbar werden. Teams, die warten, bis Nutzer sie finden, zahlen später mit Incident Response, Vertrauensverlust und regulatorischem Risiko.
Wenn Sie LLM-Red-Teaming für die Produktion aufbauen
DataVLab unterstützt KI-Teams bei der Konzeption und Durchführung von LLM-Evaluation, Red-Teaming, menschlicher Sicherheitsbewertung und Qualitätskontrolle. Wir helfen dabei, Testsets, Rubrics und Review-Prozesse aufzubauen, die nicht nur technische Schwachstellen finden, sondern auch die Anforderungen von Governance, Datenschutz und produktiver KI-Sicherheit abdecken.
