Training & Ausrichtung
Red Teaming
Bevor es andere tun: gezielt versuchen, das eigene System zu Fehlverhalten zu bringen — Jailbreaks, Prompt-Injection, Datenabfluss, peinliche Antworten. Gute Red Teams denken wie Angreifer und dokumentieren wie Buchhalter. Für kritische Anwendungen gehört das wiederholt in den Kalender, nicht einmalig vor den Launch: Jedes Modell-Update verschiebt die Schwachstellen.
Ein Beispiel
Ein Team versucht systematisch, den eigenen Kundenassistenten zu Aussagen zu bringen, die er nicht treffen darf: rechtsverbindliche Zusagen, Rabatte, medizinische Empfehlungen. Nicht mit Tricks aus Fachartikeln, sondern mit dem, was Kunden wirklich schreiben — hartnäckigen Nachfragen, emotionalen Schilderungen, Behauptungen über frühere Zusagen. Nach zwei Tagen liegen elf Fälle vor, in denen der Assistent zu weit ging. Alle elf werden zu Testfällen, die vor jeder Freigabe durchlaufen.
Genauer betrachtet
Eine Gruppe versucht planvoll, das System zu Fehlverhalten zu bringen: verbotene Auskünfte, Umgehung der Systemanweisung, Datenabfluss, Prompt Injection über eingespeiste Dokumente. Die Ergebnisse werden zu festen Testfällen.
Warum das zählt
Red Teaming ist keine Formalie und auch nicht dasselbe wie ein Penetrationstest: Gesucht werden nicht Sicherheitslücken im klassischen Sinn, sondern Eingaben, bei denen sich das System anders verhält als vorgesehen. Zwei Dinge machen den Unterschied zwischen Ritual und Nutzen. Erstens: Es muss jemand tun, der nicht gebaut hat — Erbauer testen entlang ihrer eigenen Annahmen. Zweitens: Jeder Fund muss in einen automatischen Test wandern, sonst kommt er nach dem nächsten Modellwechsel zurück.
Häufig missverstanden
Einmalig zur Abnahme durchgeführt ist es eine Momentaufnahme. Jede Modellversion und jedes neue Werkzeug eröffnen neue Wege. Red Teaming gehört in den Betrieb, nicht in die Einführung.