Red Teaming für KI: vom Sicherheitstest zum Nachweis

Auf einen Blick

• Red Teaming ist in Europa seit dem 2. August 2025 keine freiwillige Übung mehr, seit Artikel 55 der KI-Verordnung für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck und systemischem Risiko gilt.
• Die Durchsetzung läuft: Das KI-Büro verfügt seit dem 2. August 2026 über seine Sanktionsbefugnisse, mit Bußgeldern bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes.
• Beim Hochrisiko-Regime verlief die Entwicklung umgekehrt. Der am 16. Juni 2026 gebilligte Digital-Omnibus verschiebt die Pflichten nach Anhang III auf den 2. Dezember 2027.
• Die meisten Organisationen sind keine Anbieter solcher Modelle. Ihre Exposition entsteht vertraglich, über Lieferantenprüfungen und Zusicherungsanfragen von Kunden.
• Eine undokumentierte Übung beweist nichts. Prüfer lesen die Akte: Geltungsbereich, Bedrohungsmodell, Testprotokoll, Kritikalität, Verantwortliche für die Behebung und den Nachtest.

Was Red Teaming wirklich ist, und was nicht

Red Teaming bedeutet, ein KI-System einem strukturierten Angriff auszusetzen, durchgeführt von Personen, deren Auftrag für die Dauer der Übung darin besteht, es scheitern zu lassen. Das Team formuliert Eingaben, die Schutzmechanismen umgehen sollen, manipuliert einen Suchindex, verkettet Werkzeugaufrufe, die niemand vorgesehen hatte, und protokolliert, wie sich das System verhält. Das Ziel ist keine Kennzahl. Das Ziel ist die Liste der Verhaltensweisen, die niemand beabsichtigt hat.

Wer die erste Ergebnisseite zu diesem Thema liest, käme zu dem Schluss, es handle sich um eine reine Sicherheitsdisziplin. Jede gut platzierte Seite beschreibt Angriffsvektoren, Methodenphasen und Werkzeuge. Diese Beschreibung ist zutreffend und unvollständig, denn sie lässt aus, was inzwischen über das Budget entscheidet: In der Europäischen Union ist diese Tätigkeit für eine Anbieterkategorie eine dokumentierte Rechtspflicht und für mehrere weitere eine dokumentierte Erwartung.

Zwei Abgrenzungen gehören an den Anfang.

Red Teaming, Benchmarks und Evaluierungen sind drei verschiedene Dinge

Benchmarks messen bekannte Fähigkeiten anhand eines festen Fragensatzes. Evaluierungen bewerten ein System anhand vorab definierter Kriterien. Beide beantworten die Frage, wie gut das System das tut, wonach gefragt wurde. Keines beantwortet die Frage, was es sonst noch tut.

Red Teaming existiert für diese zweite Frage. Die IBM-Forschung formuliert den Zweck unmissverständlich: Es geht darum, das zu erfassen, von dessen Nichtwissen man nichts weiß. Eine Benchmark-Suite kann keinen Fehlermodus aufdecken, für den niemand einen Test geschrieben hat, und genau diese Kategorie erzeugt Vorfälle.

Praktische Folge: Die Ansätze ergänzen einander, sie ersetzen einander nicht. Wer Leistungsfähigkeit gemessen hat, hat noch nicht auf Schaden geprüft.

Es ist auch kein umbenannter Penetrationstest

Ein Penetrationstest zielt auf die Infrastruktur: Netzwerk, API-Gateway, Identitätsschicht. Diese Arbeiten bleiben notwendig. Red Teaming zielt auf das Modell und sein Verhalten, das anders versagt. Für ein Modell, das sich überreden lässt, gibt es keinen Patch. Die Behebung besteht aus Nachtraining, Filterung, Verweigerungsrichtlinien, Rechteeinschränkung oder Überwachung, niemals aus einem Versionssprung.

Die Pflicht, die in den Suchergebnissen fehlt

Artikel 55 Absatz 1 Buchstabe a der KI-Verordnung verpflichtet Anbieter von KI-Modellen mit allgemeinem Verwendungszweck und systemischem Risiko, eine Modellbewertung nach standardisierten Protokollen und Werkzeugen durchzuführen, die dem Stand der Technik entsprechen, einschließlich der Durchführung und Dokumentation von Angriffstests, um systemische Risiken zu ermitteln und zu mindern. Der Text ergänzt, dass die Tests dem Risikoniveau und dem Stand der Technik angemessen sein müssen und unabhängige externe Fachleute einbeziehen können.

Drei Begriffe tragen die gesamte Last. Die Durchführung macht die Übung verpflichtend. Die Dokumentation macht den Nachweis verpflichtend. Angemessenheit bedeutet, dass ein kleiner Anbieter nicht am Programm eines Spitzenlabors gemessen wird, und umgekehrt, dass ein Spitzenlabor seine Pflicht nicht mit einem Wochenende Eingabetests erfüllt.

Ein Modell fällt in die Kategorie des systemischen Risikos, wenn die kumulierte Trainingsrechenleistung 10^25 FLOPs übersteigt oder das KI-Büro es nach anderen Kriterien benennt. Die Schwelle ist bewusst hoch angesetzt: Sie erfasst Entwickler von Spitzenmodellen, nicht das durchschnittliche Unternehmen.

Am schlechtesten verstanden sind die Fristen. Die Pflichten für Modelle mit allgemeinem Verwendungszweck gelten seit dem 2. August 2025 für Modelle, die nach diesem Datum in Verkehr gebracht werden. Für bereits vorhandene Modelle läuft die Frist bis zum 2. August 2027. Und seit dem 2. August 2026 verfügt das KI-Büro der Kommission über seine Durchsetzungsbefugnisse, mit Bußgeldern von bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Beim Regime, auf das sich alle zwei Jahre lang vorbereitet haben, ging es unterdessen zurück. Das Europäische Parlament billigte am 16. Juni 2026 die Änderungen des Digital-Omnibus und verschob die Pflichten für eigenständige Hochrisikosysteme nach Anhang III vom 2. August 2026 auf den 2. Dezember 2027, für produktintegrierte Systeme auf den 2. August 2028. Die Fristen für Modelle mit allgemeinem Verwendungszweck blieben unberührt.

Die Lage ist damit das Gegenteil dessen, was die meisten Compliance-Kalender unterstellen. Die Testpflicht der KI-Verordnung, die heute durchsetzbar ist, betrifft die Modelle mit allgemeinem Verwendungszweck, und Angriffstests bilden ihren Kern.

Der operative Weg führt über den Verhaltenskodex für Modelle mit allgemeinem Verwendungszweck. Sein am 10. Juli 2025 veröffentlichtes Kapitel zu Sicherheit und Gefahrenabwehr beschreibt den erwarteten Rahmen: Modellbewertungen, Red Teaming, Beobachtung nach dem Inverkehrbringen, Cybersicherheitsmaßnahmen, Meldung von Vorfällen und Verantwortlichkeit für das Modell. Die Unterzeichnung bleibt freiwillig, doch das KI-Büro hat erklärt, dass Unterzeichner als gutgläubig handelnd behandelt werden und ihre Zusagen in die Bemessung einer Sanktion einfließen. Näher kommt die Verordnung einem sicheren Hafen nicht, und dieser Hafen ruht auf Testnachweisen.

Wer tatsächlich Red Teaming betreiben muss

Für die meisten Leserinnen und Leser lautet die ehrliche Antwort: nicht Sie, jedenfalls nicht unmittelbar. Das gehört deutlich gesagt, denn die Anbieterinhalte zu dieser Suchanfrage legen eine allgemeine Pflicht nahe.

Anbieter von Modellen mit allgemeinem Verwendungszweck und systemischem Risiko. Gebunden durch Artikel 55, ab sofort durchsetzbar, mit Sanktion. Die Liste ist kurz, und die Betroffenen wissen es.

Anbieter von Hochrisikosystemen. Artikel 9 verlangt ein Risikomanagementsystem mit Tests über den gesamten Lebenszyklus, Artikel 15 verlangt Systeme, die zuverlässig arbeiten und Fehlern, Störungen sowie Versuchen widerstehen, ihre Verwendung oder Leistung zu verändern. Beide Artikel verwenden den Ausdruck Red Teaming nicht. Beide verlangen Tests unter Bedingungen, die den vorgesehenen Betrieb herausfordern, mit dokumentierter Methode und dokumentierten Ergebnissen. Anwendbar ab dem 2. Dezember 2027 für eigenständige Systeme nach Anhang III.

Betreiber. Keine unmittelbare gesetzliche Testpflicht. Die Pflicht kommt über den Vertrag: Beschaffungsfragebögen, Zusicherungsanlagen, Auditrechte, Gewährleistungsklauseln. Praktisch erreicht Red Teaming auf diesem Weg die Mehrheit der Organisationen, und zwar meist als Frage, die binnen dreißig Tagen zu beantworten ist. Diese Antwort zu strukturieren ist zuerst eine Governance-Aufgabe, wie unsere Analyse der Herausforderungen der KI-Governance zeigt.

Alle übrigen. Freiwillig, und zunehmend erwartet. Versicherer fragen danach. Großkunden ebenso. Aufsichtsräte interessieren sich dafür nach dem ersten öffentlichen Vorfall in ihrer Branche.

Eine weitere Gruppe verdient Erwähnung: Organisationen, deren KI-Bestand nicht vollständig bekannt ist. Red Teaming lässt sich nicht auf etwas anwenden, das nicht inventarisiert wurde, und nicht gemeldete Nutzung erklärt, warum viele Programme nur einen Bruchteil der tatsächlichen Angriffsfläche abdecken. Das Personalwesen liefert dafür ein deutliches Beispiel, wie unsere Analyse zum KI-Recruiting zeigt.

Was die einzelnen Regelwerke tatsächlich verlangen

Die Regelwerke stimmen in der Tätigkeit überein und unterscheiden sich deutlich in ihrer Verbindlichkeit.

Regelwerk	Anforderung	Verwendeter Begriff	Verbindlich?
KI-Verordnung Art. 55 Abs. 1 lit. a	Modellbewertung einschließlich dokumentierter, risikoangemessener Angriffstests	Angriffstests	Ja, für Modelle mit systemischem Risiko, durchsetzbar seit 2. August 2026
KI-Verordnung Art. 9 und Art. 15	Tests über den Lebenszyklus unter fordernden Bedingungen, Methode und Ergebnisse dokumentiert	Tests	Ja, für Hochrisiko, ab 2. Dezember 2027
Verhaltenskodex, Kapitel Sicherheit und Gefahrenabwehr	Modellbewertungen, Red Teaming, Marktbeobachtung, Meldung von Vorfällen	Red Teaming	Freiwillig, fließt aber in Sanktionen ein
NIST AI RMF, Measure 1.1	Angriffsteams und Angriffstests zur Aufdeckung gefährlicher Fähigkeiten und emergenter Eigenschaften	Red Teaming	Freiwillig
NIST AI 600-1, Profil generative KI	Red Teaming vor und nach dem Einsatz, über zwölf Risikokategorien	Red Teaming	Freiwillig
ISO/IEC 42001	Keine eigene Klausel; Testaufzeichnungen stützen das Managementsystem	Test und Evaluierung	Zertifizierbar
OWASP GenAI Red Teaming Guide	Phasenweise Tests: Modell, Implementierung, System, Laufzeit	Red Teaming	Praxisstandard
CSA und OWASP Agentic AI Red Teaming Guide	Zwölf agentische Bedrohungskategorien auf dem MAESTRO-Modell	Red Teaming	Praxisstandard

Aus dieser Tabelle folgen zwei Beobachtungen.

Erstens nennt ISO/IEC 42001 den Begriff nie, was alle überrascht, die nach einer Klausel suchen. Die Norm verlangt den Nachweis, dass Risiken erkannt, Maßnahmen getestet und Ergebnisse überprüft wurden. Ein Red Teaming-Bericht mit nachvollziehbarer Behebungsspur erfüllt das, ein reiner Leistungsbenchmark nicht.

Zweitens beschreiben die amerikanischen und die europäischen Instrumente dieselbe Praxis mit unterschiedlicher Verbindlichkeit. Das Berkeley-Profil für Modelle mit allgemeinem Verwendungszweck ordnet Red Teaming unter Measure 1.1 des NIST AI RMF ein, um gefährliche Fähigkeiten, Schwachstellen und emergente Eigenschaften aufzudecken, und wiederholt es als Lebenszykluskontrolle unter Manage 1.3, 2.3 und 2.4. NIST AI 600-1 empfiehlt Red Teaming vor und nach dem Einsatz über zwölf Risikokategorien. Keines der beiden Dokumente sieht Bußgelder vor. Beide sind das, was eine europäische Prüfstelle als Stand der Technik akzeptieren wird, wenn Artikel 55 fragt, an welchem Maßstab getestet wurde.

Im deutschen Kontext übernimmt das BSI diese Ankerfunktion. Seine Prüfliste zur Härtung von LLM-Systemen gegen Umgehungsangriffe nennt Red Teaming ausdrücklich als durchzuführende Maßnahme. Sie begründet keine neue Rechtspflicht, setzt aber das Sorgfaltsniveau, das eine Marktüberwachungsbehörde als angemessen ansehen wird.

Den Geltungsbereich so festlegen, dass die Befunde tragen

Die meisten Berichte scheitern nicht am Test, sondern am Geltungsbereich. Die Übung findet echte Probleme, und danach kann niemand mehr sagen, für welchen Systemstand sie galten.

Das Ziel präzise benennen. Basismodell, spezialisierte Variante, Suchschicht, Werkzeug- und Agentenfläche, ausgelieferte Anwendung. Festhalten, was im Geltungsbereich liegt, was nicht, und warum. Ein Test des Basismodells deckt nicht das darauf gebaute Produkt ab.

Alle Versionen festschreiben. Modellstand, Version der Systemeingabe, Momentaufnahme des Suchindex, Konfiguration der Schutzmechanismen, Werkzeugrechte. Ein Befund gegen einen unbenannten Stand lässt sich nicht nachtesten, und ein nicht testbarer Befund ist kein Nachweis.

Schäden aus der eigenen Taxonomie ableiten. Generische Listen erzeugen generische Befunde. Wenn das Risikoregister nicht autorisierte finanzielle Verpflichtungen und die Offenlegung von Kundendaten als Hauptexpositionen ausweist, gehören diese zuerst in den Geltungsbereich, und der Bericht muss begründen, warum die übrigen zurückgestellt wurden. Diese Begründung macht Ihre Risikobereitschaft für eine Prüfstelle sichtbar.

Die Frage der Unabhängigkeit bewusst entscheiden. Artikel 55 sieht unabhängige externe Fachleute ausdrücklich vor. Interne Teams kennen das System besser und kosten weniger. Externe Teams lassen sich schwerer beiseiteschieben und wiegen im Nachweis schwerer. Die Wahl gehört schriftlich begründet, denn sie wird hinterfragt.

Den Geltungsbereich auf agentische Systeme ausweiten. Einzelschritt-Eingabetests reichen nicht mehr, sobald ein System über Autonomie, Gedächtnis und Werkzeuge verfügt. Der Leitfaden der Cloud Security Alliance und von OWASP ordnet diese Arbeit dem MAESTRO-Bedrohungsmodell und zwölf Kategorien zu, darunter die Übernahme von Berechtigungen und Steuerung, das Umgehen der menschlichen Kontrollinstanz, Zielmanipulation, Manipulation von Gedächtnis und Kontext, Ausnutzung von Mehr-Agenten-Systemen, Wirkungsradius und die Nachverfolgbarkeit des Agenten. Der letzte Punkt wiegt schwerer, als er klingt: Lassen sich die Handlungen eines Agenten im Nachhinein nicht zurechnen, liegt zuerst ein Versagen der Rechenschaftspflicht vor, erst danach ein Sicherheitsproblem.

Welche Nachweise Red Teaming hinterlassen muss

Das ist der Teil, den die Suchergebnisse vollständig auslassen, und er entscheidet, ob das Geld gut angelegt war. Stellen Sie sich die Akte vor, die eine Prüfstelle in achtzehn Monaten öffnet.

Die Geltungsbereichsnotiz. Datiert, versioniert, mit Ausschlüssen und deren Begründung.

Das Bedrohungsmodell. Der zugrunde gelegte Rahmen ausdrücklich benannt: MITRE ATLAS, MAESTRO, die OWASP-GenAI-Taxonomie oder ein eigener, auf einen davon abgebildet.

Das Testprotokoll. Was versucht wurde, von wem, mit welchen Werkzeugen, an welchem Datum, gegen welchen Stand. Bei automatisierten Läufen wird die Konfiguration festgehalten, nicht nur die Ausgabe.

Befunde mit Kritikalität und Begründung. Die Begründung wiegt schwerer als die Einstufung. Eine Prüfstelle kann ein Hoch bestreiten und die Akte dennoch annehmen, wenn die Argumentation lesbar ist.

Behebungsentscheidungen mit Verantwortlichem und Termin. Jeder Befund erhält einen Status: behoben, gemindert, akzeptiert oder mit Prüftermin zurückgestellt.

Restrisiko auf der richtigen Ebene akzeptiert. Eine Person mit entsprechender Befugnis bestätigt, dass die verbleibende Exposition gegenüber einer schriftlichen Schwelle tragbar ist.

Nachweis des Nachtests. Der Beleg, dass die Maßnahme wirkt, im selben Test, gegen den benannten Stand. Ohne ihn bleibt die Behebungsspalte eine Behauptung.

Zwei Zustände gehören benannt. Undokumentiertes Red Teaming beweist nichts, wie gut auch immer getestet wurde. Und ein Bericht mit Befunden ohne Behebungsspur ist schlechter als gar kein Bericht, weil er dauerhaft belegt, dass Sie es wussten. Behörden und Kläger lesen dieses Dokument gleich.

Wo Red Teaming in die übrige Governance-Akte greift

Red Teaming, das in einem PDF endet, ist gescheitert, unabhängig von den Befunden. Vier Anschlüsse machen es wirksam.

Das Risikoregister. Befunde werden zu Einträgen mit Verantwortlichem und Prüftermin, im selben System wie alle anderen Risiken. Leben sie in einer separaten Sicherheitsliste, klafft in der Governance-Akte eine Lücke an der Stelle der Verbindung.

Die Meldung von Vorfällen. Ein Befund, der sich später im Betrieb verwirklicht, wird zur Frage nach Artikel 73, und zuerst wird gefragt, ob Sie davon wussten.

Die Beobachtung nach dem Inverkehrbringen. Red Teaming ist eine punktuelle Sonde. Die Beobachtung ist die fortlaufende Hälfte, und der Verhaltenskodex nennt beide. Ein Programm mit nur einer Hälfte ist ein halbes Programm.

Transparenzberichte. Das Berkeley-Profil führt die Ergebnisse in Modell- und Systemkarten, wobei Angaben, die das Missbrauchspotenzial erhöhen würden, verantwortungsvoll weggelassen werden. Dieser Vorbehalt ist nicht optional: Eine funktionierende Umgehung zu veröffentlichen ist ein Offenlegungsfehler, keine Transparenz.

Fünf Mängel, die den Nachweis entwerten

Einen Stand testen und einen anderen ausliefern. Der häufigste Mangel. Der Bericht beschreibt ein System, das es nicht mehr gibt.

Den Geltungsbereich auf Prompt Injection verengen. Prompt Injection ist der bekannte Fehlermodus, nicht der teuerste. Werkzeugrechte und Agentenautonomie erzeugen die Vorfälle mit finanzieller Wirkung.

Keine Kritikalitätsskala. Wenn alles mittel ist, wird nichts priorisiert, und die Begründung, die eine Prüfstelle lesen will, existiert nicht.

Befunde ohne Verantwortliche. Ein nicht zugewiesener Befund ist eine Notiz. Er wird bei der nächsten Prüfung noch offen sein, und die Termine werden es belegen.

Kein Nachtest. Die Maßnahme wird behauptet statt belegt. Das ist die häufigste Lücke in ansonsten soliden Red Teaming-Programmen und die am günstigsten zu schließende.

Häufige Fragen

Ist Red Teaming gesetzlich vorgeschrieben?

In der Europäischen Union ja, für eine bestimmte Gruppe. Artikel 55 Absatz 1 Buchstabe a der KI-Verordnung verpflichtet Anbieter von Modellen mit allgemeinem Verwendungszweck und systemischem Risiko zur Durchführung und Dokumentation von Angriffstests; diese Pflichten sind seit dem 2. August 2026 durchsetzbar. Für Anbieter von Hochrisikosystemen verlangen Artikel 9 und Artikel 15 ab dem 2. Dezember 2027 dokumentierte Tests unter fordernden Bedingungen, ohne den Begriff zu verwenden. Für alle übrigen ist die Pflicht vertraglich, nicht gesetzlich.

Wen trifft die Pflicht nach der KI-Verordnung?

Anbieter von Modellen mit allgemeinem Verwendungszweck, deren kumulierte Trainingsrechenleistung 10^25 FLOPs übersteigt oder die das KI-Büro als systemisch riskant benennt. Das ist eine kleine Gruppe von Entwicklern von Spitzenmodellen. Betreiber dieser Modelle erben die Erwartungen über den Vertrag, und auf diesem Weg erreicht die Anforderung die meisten Organisationen.

Worin unterscheidet sich Red Teaming von einem Penetrationstest?

Ein Penetrationstest greift die Infrastruktur an und liefert Schwachstellen mit Patches. Red Teaming greift das Modellverhalten an und liefert Fehlermodi ohne Patch. Die Behebung besteht aus Nachtraining, Filterung, Verweigerungsrichtlinie, Rechteeinschränkung oder Überwachung. Beides ist nötig, keines ersetzt das andere.

Wie oft sollte ein KI-System geprüft werden?

Koppeln Sie den Takt an Veränderung statt an den Kalender. Ein neues Basismodell, eine Spezialisierung, ein neues Werkzeug oder eine neue Integration, eine wesentliche Änderung der Systemeingabe oder ein neuer Einsatzkontext rechtfertigen jeweils eine neue Übung. Ergänzen Sie eine periodische Grundlinie, für die meisten Systeme jährlich, und behandeln Sie Tests nach dem Einsatz getrennt von Tests davor.

Lässt sich Red Teaming automatisieren?

Teilweise, und die Aufteilung ist für den Nachweis entscheidend. Automatisierte Sonden liefern Breite, Wiederholbarkeit und den Mechanismus für den Nachtest, genau das, was die Dokumentation braucht. Menschliche Teams finden den neuartigen Weg, den keine Sondenbibliothek enthält. Ein rein automatisiertes Programm erzeugt eine saubere Akte mit einem vorhersehbaren blinden Fleck.

Was verlangt eine Prüfstelle nach der Übung?

Die Geltungsbereichsnotiz mit Versionen, das Bedrohungsmodell und seinen Rahmen, das Testprotokoll, Befunde mit Kritikalität und Begründung, Verantwortliche und Termine der Behebung, die Annahme des Restrisikos samt Unterschrift sowie den Nachweis des Nachtests. Geprüft wird die Nachweiskette, nicht die Übung, denn nur die Kette überdauert.

Fazit

Die Suchergebnisse behandeln Red Teaming als Sicherheitsdienstleistung; in dieser Lesart schrumpft die Entscheidung zu einer Budgetzeile eines technischen Teams. Die regulatorische Lage sagt etwas anderes. Angriffstests sind die Pflicht der KI-Verordnung, die heute durchsetzbar ist, während das Hochrisiko-Regime, auf das sich alle vorbereitet haben, mehr als ein Jahr entfernt liegt, und was die Pflicht erfüllt, ist nicht die Übung, sondern die Spur, die sie hinterlässt.

Diese Verschiebung ändert die Zuständigkeit. Das Testen bleibt bei denen, die Systeme brechen können. Die Geltungsbereichsnotiz, die Begründung der Kritikalitäten, das Behebungsregister und die Unterschrift unter das Restrisiko gehören in die Governance, denn sie sind die einzigen Unterlagen, die je gelesen werden. Beginnen Sie mit der Akte, die Sie vorlegen müssten, und beauftragen Sie dann das Red Teaming, das sie füllt. Unsere Plattform für KI-Governance zeigt, wie diese Bausteine an einem Ort zusammenkommen.