Die Nachfrage nach Red Teaming für KI-Systeme ist in den vergangenen Monaten deutlich gestiegen, und mit ihr die Zahl der Angebote. Auf dem Papier ähneln sie sich stark: Prompt Injection, Jailbreaks, Datenabfluss, ein Bericht mit Empfehlungen. Die Unterschiede zeigen sich erst im Ergebnis, und dann ist das Budget ausgegeben. Ob ein Red Teaming Engagement verwertbare Erkenntnisse liefert oder ein beruhigendes Dokument ohne Aussagekraft, entscheidet sich zum größeren Teil vor dem ersten Test. Dieser Beitrag beschreibt, welche Festlegungen ein belastbarer Auftrag enthält und woran sich die Qualität des Ergebnisses prüfen lässt.
Der Zuschnitt entscheidet über den Wert
Der häufigste Fehler liegt im Umfang. Beauftragt wird ein Test des Modells, weil das Modell im Mittelpunkt der Diskussion steht. Das Risiko liegt aber selten im Modell allein, sondern in dem, was das System mit seinen Ausgaben tun kann. Ein Assistent, der nur Text zurückgibt, hat ein anderes Schadenspotenzial als einer, der Tickets anlegt, E-Mails versendet oder in einem Fachsystem schreibt. Der Zuschnitt sollte deshalb dem Weg folgen, den eine Eingabe bis zur Wirkung nimmt: über die Wissensquellen, die das System liest, die Werkzeuge, die es aufruft, und die Rechte, unter denen es handelt.
Ebenso wichtig ist ein ausdrückliches Bedrohungsmodell. Es legt fest, wer als Angreifer betrachtet wird, etwa ein externer Nutzer, ein interner Mitarbeiter mit legitimem Zugang oder ein Dritter, der Inhalte in eine Wissensquelle einschleust. Es benennt die Werte, die geschützt werden sollen. Fehlt diese Festlegung, testen die Prüfer das, was sie am besten kennen, und das ist nicht zwingend das, was für das Unternehmen am teuersten wäre.
Erfolgskriterien vor dem ersten Test
Ein Befund ist nur so viel wert wie die Skala, auf der er eingeordnet wird. Wenn nicht vorab geklärt ist, was als kritisch gilt, landen im Bericht Dutzende Einträge gleicher Farbe, und niemand kann entscheiden, womit begonnen werden soll. Belastbar ist eine Schwereskala, die sich am Geschäftsschaden orientiert und nicht an technischer Eleganz: Abfluss vertraulicher Daten, eine unberechtigte Handlung in einem Fachsystem, eine falsche Entscheidungsgrundlage, ein Reputationsschaden. Diese Skala wird gemeinsam mit dem Fachbereich festgelegt, der den Schaden im Ernstfall trägt.
Zum Auftrag gehört außerdem die Testumgebung. Tests auf einer Demo mit Beispieldaten und ohne angebundene Werkzeuge liefern Ergebnisse, die sich nicht auf den Betrieb übertragen lassen. Aussagekräftig ist eine produktionsnahe Umgebung mit denselben Anbindungen und Rechten, aber mit Testdaten. Wo in der Produktion getestet werden muss, braucht es vorab vereinbarte Abbruch- und Eskalationsregeln, damit ein erfolgreicher Angriff im Test keinen realen Schaden auslöst.
Woran ein verwertbarer Bericht zu erkennen ist
Ein guter Bericht enthält für jeden Befund einen reproduzierbaren Angriffsweg mit Vorbedingung, Ablauf, Wirkung und konkreter Gegenmaßnahme. Er ordnet die Befunde der Ebene zu, auf der sie entstehen, also Modell, System oder Agent, weil davon abhängt, wer sie beheben muss. Und er sagt ausdrücklich, was nicht geprüft wurde. Diese Abdeckungsangabe wird oft übersehen und ist doch entscheidend: Ein Bericht ohne Befunde ist nur dann eine gute Nachricht, wenn klar ist, welche Pfade tatsächlich getestet wurden.
Für die Steuerung braucht es zusätzlich eine Fassung, die ohne technische Übersetzung im Vorstand und im Prüfungsausschuss verwendet werden kann. Sie beantwortet drei Fragen: Welches Restrisiko besteht nach heutigem Stand, welche Maßnahmen sind priorisiert und bis wann umgesetzt, und welche Entscheidungen muss die Geschäftsleitung treffen, etwa über die Einschränkung von Rechten oder die Verschiebung eines Go-live. Ein Bericht, der nur für Techniker lesbar ist, erreicht die Ebene nicht, die über das Risiko entscheidet.
Ohne Retest bleibt die Behebung eine Behauptung
Eine Gegenmaßnahme ist erst dann wirksam, wenn der ursprüngliche Angriff an ihr scheitert und keine naheliegende Variante durchkommt. Genau das prüft der Retest. Er gehört in den ursprünglichen Auftrag und nicht in ein späteres Angebot, weil er sonst aus Budgetgründen entfällt. Bei KI-Systemen kommt hinzu, dass sich das Verhalten mit jedem Modellupdate verschieben kann. Eine Maßnahme, die heute greift, muss nach dem nächsten Wechsel erneut bestätigt werden.
Der nachhaltigste Teil eines Engagements ist deshalb die Übergabe. Die erfolgreichen Angriffe werden als Testfälle an das interne Team übergeben und in die Regressionstests aufgenommen, die vor jedem Release laufen. So wird aus einer einmaligen Prüfung eine wiederholbare Kontrolle. Anbieter, die ihre Testfälle nicht herausgeben wollen, verkaufen eine Abhängigkeit statt einer Absicherung.
Fazit und Empfehlung
Die Qualität eines Red Teaming entscheidet sich im Auftrag. Vor der nächsten Beauftragung empfehlen wir drei Schritte. Erstens auflisten, welche Handlungen das zu prüfende System auslösen kann, und den Umfang danach ausrichten statt nach dem Modell. Zweitens eine Schwereskala am Geschäftsschaden festlegen, gemeinsam mit dem Fachbereich, bevor der erste Test läuft. Drittens Retest und Übergabe der Testfälle vertraglich vereinbaren, damit aus dem Engagement eine dauerhafte Kontrolle wird.
ECODYNAMICS führt AI Security und Red Teaming Engagements genau in dieser Reihenfolge durch. In der ersten Woche legen wir mit Ihnen Umfang, Bedrohungsmodell und Erfolgskriterien fest, danach folgen die Tests auf Modell-, System- und Agentenebene, und ab der sechsten Woche begleiten wir die Härtung und verifizieren kritische Befunde im Retest. Sie erhalten einen priorisierten Bericht mit reproduzierbaren Angriffen und eine Fassung für Vorstand und Prüfungsausschuss. Wenn bei Ihnen ein Agent kurz vor dem produktiven Einsatz steht, sprechen Sie uns an.