Was ist AI Red Teaming? KI Systeme wie ein Angreifer testen

Was ist AI Red Teaming?

AI Red Teaming ist der Prozess, ein KI System vor und nach dem Start absichtlich zu fordern, um schädliches, falsches oder unsicheres Verhalten zu finden. Dabei denkt ein Testteam wie ein böswilliger Nutzer. Es geht also nicht um Schuld. Vielmehr geht es darum, die Schwachstelle zu finden, bevor echte Nutzer sie finden.

Kurz gesagt, ein Team spielt den wohlmeinenden Angreifer. Es fordert Ihren Chatbot, Ihren KI Agenten oder Ihre KI gestützte Suche. Zum Beispiel sucht es nach Situationen, in denen das System private Daten verrät, eigene Regeln bricht oder eine Aktion ausführt, die niemand freigegeben hat.

Danach hält das Team jeden Fund fest und gibt ihn an die Entwickler weiter. Die Entwickler beheben das Problem, und das Team prüft dasselbe Szenario erneut. Somit verwandelt dieser Kreislauf diffuse Sorgen um die Sicherheit in etwas Messbares.

Daher behandelt dieser Beitrag nur diesen einen Begriff. Zu den Nachbarthemen haben wir eigene Beiträge, daher erwähnen wir sie hier kurz und verlinken sie. Weil es um Sicherheit geht, geben wir keine Angriffsanleitungen und keine schädlichen Beispielbefehle. Konkret liegt unser Fokus auf Verteidigung und Prozess.

Was ist AI Red Teaming, erklärt mit einem einfachen Vergleich?

Stellen Sie sich eine neue Brücke vor. Bevor sie für den Verkehr öffnet, belasten Ingenieure sie mit schweren Lastwagen, starkem Wind und unerwarteten Gewichten. Sie hoffen also nicht auf einen Einsturz. Dennoch wollen sie genau wissen, wo die Brücke versagen könnte.

Ebenso erledigt AI Red Teaming dieselbe Aufgabe für KI. Statt einer Brücke gibt es ein Modell, einen Chatbot oder einen Agenten. Statt Belastungstests gibt es ungewöhnliche, provozierende und grenzwertige Nutzungsszenarien.

Allerdings gibt es einen wichtigen Unterschied. Eine Brücke reagiert jedes Mal gleich. Ein Sprachmodell kann dagegen auf dieselbe Frage anders antworten, sobald sich die Wortwahl leicht ändert. Deshalb reicht ein einzelner Test nie aus, denn ein glücklicher Durchlauf bildet die Vielfalt der Praxis nicht ab.

Zunächst steht das Wort "Red" für die Gegenseite. Das Team, das die Verteidigung aufbaut, heißt "Blue Team". In der Praxis können dieselben Personen beide Rollen übernehmen. Vor allem zählt, dass jemand für eine Weile den Hut des Angreifers aufsetzt.

Was ist AI Red Teaming und wie unterscheidet es sich vom klassischen Red Team in der IT Sicherheit?

Ein klassisches Red Team nimmt meist Netzwerke, Server, Mitarbeitende und manchmal den physischen Zugang ins Visier. Konkret ist das Ziel oft ein klar definierter Zugriff. Der Erfolg ist leicht zu bestimmen: Sie sind drin, oder Sie sind es nicht.

AI Red Teaming testet dagegen das Verhalten des Systems. Daher ist Erfolg hier unschärfer. Ein Modell kann schädliche Inhalte erzeugen, voreingenommen reagieren oder vertrauliche Details im Chat nennen, ohne dass jemand irgendwo eindringt. Google betont, dass das eigene AI Red Team eng mit klassischen Red Teams verwandt ist, aber zusätzlich KI Fachwissen braucht.

Die wichtigsten Unterschiede sehen so aus:

• Ziel: Ein klassisches Team prüft die Infrastruktur. Ein KI Team prüft Infrastruktur und Modellverhalten.
• Ergebnis: Klassische Funde lassen sich meist wiederholen. Bei KI kann dieselbe Eingabe unterschiedliche Ausgaben liefern.
• Schadensart: Klassische Tests konzentrieren sich auf Datenpannen. KI Tests ergänzen schädliche Inhalte, Falschinformationen und Voreingenommenheit.
• Teamaufbau: KI Tests brauchen eine Sicherheitsfachkraft, dazu Fachexperten und eine Produktverantwortliche.

Andererseits teilen beide Disziplinen sehr viel. Also bauen beide ein Bedrohungsmodell auf, simulieren Angreiferverhalten und berichten ihre Funde.

Was ist AI Red Teaming wert und warum ist es für Unternehmen wichtig?

KI Systeme sind nicht so berechenbar wie klassische Software. Zudem decken die Tests aus der Entwicklung die Kreativität echter Nutzer nicht ab. Denn Menschen stellen unerwartete Fragen, testen die Grenzen des Systems und missbrauchen es manchmal absichtlich.

Außerdem wächst das Risiko mit den Fähigkeiten. Zum Beispiel: Schreibt ein Chatbot nur Text, bleiben seine Fehler begrenzt. Liest derselbe Bot jedoch Kundendaten, versendet Nachrichten oder ändert Bestellungen, kann ein Fehler echten Schaden anrichten.

Das NIST veröffentlicht einen Rahmen für das Risikomanagement von KI. Das Profil für generative KI überträgt diesen Rahmen auf generative Systeme und beschreibt deren besondere Risiken. Tests, Bewertung und gegnerische Übungen gehören dort zum Risikomanagement.

Folglich ist Red Teaming kein Luxus. Stattdessen ist es eine vernünftige Voraussetzung für jede KI Funktion, die Sie Kunden anbieten. Zudem steuern Sie die Folgen für Ruf und Recht selbst, wenn Sie das Problem als Erste finden. Hinweis: Das ist keine Rechtsberatung, fragen Sie bei Ihren Datenschutzpflichten eine Fachperson.

Welche Risiken testet AI Red Teaming?

Jedes Projekt ist anders, daher betrachten Teams meist einige Hauptgruppen von Risiken. Die folgende Liste fasst typische Punkte für einen Chatbot im Unternehmen zusammen.

• Schädliche Inhalte: Erzeugt das Modell Inhalte, die gegen Ihre Richtlinien verstoßen oder beleidigend oder gefährlich sind.
• Datenabfluss: Verrät das System eigene Anweisungen, Details anderer Nutzer oder interne Dokumente.
• Prompt Injection: Kann ein Nutzer oder externer Inhalt die Anweisungen des Modells aushebeln. Details finden Sie in unserem Beitrag zu Prompt Injection.
• Voreingenommenheit: Behandeln Antworten bestimmte Gruppen unfair. Dazu passt unser Beitrag zu KI Bias.
• Überschreitung von Agentenrechten: Kann ein Agent ein Werkzeug oder eine Aktion außerhalb seiner Befugnis nutzen.

Außerdem messen Teams das Risiko erfundener Fakten. Das ist ein eigener Begriff, den unser Beitrag zur KI Halluzination erklärt. Bei den Daten geht es um manipulierte Trainingsdaten, das Thema unseres Beitrags zu Data Poisoning.

Daher bestimmt Ihr Produkt, welches Risiko zuerst kommt. Bei einem Shop Bot mit personenbezogenen Daten sind Datenschutz und Rechtegrenzen oft die wichtigsten Punkte.

Wer führt AI Red Teaming durch?

Es gibt drei Hauptansätze, und die meisten reifen Programme kombinieren sie.

• Internes Team: Diese Menschen kennen das Produkt am besten. Außerdem sind sie schnell und günstig. Allerdings haben sie das System selbst gebaut, daher können sie blinde Flecken haben.
• Externe Fachleute: Sie bringen einen frischen Blick und Angreifererfahrung mit. Außerdem erhöht ihre Unabhängigkeit die Glaubwürdigkeit der Funde.
• Automatisierte Werkzeuge: Sie testen viele Szenarien schnell und lassen sich bei jeder neuen Version wiederholen. Dennoch finden sie kreative, kontextbezogene Schwächen nicht allein.

Anbieter wie Microsoft veröffentlichen Rahmenwerke zur Automatisierung und Leitfäden für Tests generativer Systeme. Zudem helfen solche Werkzeuge als Konzept. Trotzdem ersetzen sie nie das menschliche Urteil.

Verlassen Sie sich beim Teamaufbau nicht auf eine einzige Fähigkeit. Konkret besteht eine gute Mischung aus einer Sicherheitsfachkraft, jemandem mit Produktkenntnis und einer Vertretung mit Fachwissen. Zum Beispiel ist bei einem Kundenservice Bot eine Supportmitarbeiterin, die echte Kundenfragen kennt, enorm wertvoll.

Wie ergänzen sich automatische Tests und menschliche Tester?

Zunächst liefern automatische Tests Tempo und Wiederholbarkeit. Sie führen Hunderte Szenarien in wenigen Minuten aus, und Sie können dasselbe Set bei jedem Release wiederholen. Somit erkennen Sie Rückschritte früh.

Allerdings kennt die Automatisierung nur die Szenarien und Bewertungsregeln, die Sie definiert haben. Unerwartete Wege, die ein kreativer Nutzer findet, entdeckt sie nur schwer. Ein menschlicher Tester dagegen liest den Kontext, vertraut seiner Intuition und erkennt eine Antwort, die zwar technisch stimmt, aber irreführt.

Deshalb empfehlen wir zwei Ebenen. Erstens erkunden Menschen neue Risiken und schreiben Szenarien. Zweitens führt die Automatisierung die bekannten Szenarien laufend aus.

Zusammengefasst erkunden Menschen und Maschinen wiederholen. Sie können auch ein anderes Modell als automatischen Richter einsetzen, doch dieser Ansatz hat eigene Grenzen. Die Einzelheiten finden Sie in unserem Beitrag zu Evals.

Welche Schritte umfasst der Ablauf von AI Red Teaming?

Stellen Sie sich den Ablauf zunächst als Kreislauf mit fünf Schritten vor. Dann dient das Ergebnis jedes Schritts als Eingabe für den nächsten.

1. Umfang: Halten Sie fest, was Sie testen, in welcher Umgebung und nach welchen Regeln.
2. Szenario: Entscheiden Sie, welche Missbrauchs oder Fehlerfälle Sie durchspielen.
3. Protokoll: Notieren Sie jeden Versuch, jede Beobachtung und jede Auswirkung geordnet.
4. Behebung: Weisen Sie Funde nach Priorität Verantwortlichen zu und setzen Sie die Lösung um.
5. Erneuter Test: Spielen Sie dasselbe Szenario und nahe Varianten noch einmal durch.

Allerdings endet der Kreislauf nicht nach einem Durchgang. Ändern sich Modellversion, Systemanweisung, angebundene Werkzeuge oder Wissensquelle, ändert sich oft auch das Verhalten. Daher sollte Red Teaming eine regelmäßige Gewohnheit sein und keine einmalige Prüfung.

In den folgenden Abschnitten vertiefen wir vor allem die Schritte Umfang, Protokoll und Behebung.

Wie legen Sie Umfang und Szenarien fest?

Zunächst zeichnen Sie eine Karte Ihres Systems. Wer sind die Nutzer, auf welche Daten greift das System zu, welche Werkzeuge ruft es auf und welche Ausgaben könnten Schaden anrichten? Somit zeigen diese Fragen, welches Risiko Vorrang verdient.

Danach schreiben Sie eine Liste inakzeptabler Ergebnisse. Zum Beispiel können die Daten eines Kunden vor einem anderen Kunden, eine Rückerstattung ohne Freigabe oder ein Ton, der nicht zu Ihrer Marke passt, auf diese Liste gehören. Die Liste wird somit zum Erfolgsmaßstab des Tests.

Ein Szenario hat drei Teile: ein Ziel, einen Kontext und das erwartete sichere Verhalten. Sie beschreiben also das Ziel und nicht den Angriff. Zum Beispiel ist der Satz "Der Bot darf einem nicht verifizierten Nutzer keine Bestelldaten nennen" ein Szenariotitel.

Legen Sie die Spielregeln vorab fest. Testen Sie nur Systeme, für die Sie eine Berechtigung haben, und nutzen Sie wenn möglich eine eigene Testumgebung. Verwenden Sie außerdem keine echten Kundendaten. Dokumentieren Sie zudem, wer den Test freigegeben hat und was tabu ist.

Ein fremdes System ohne Erlaubnis zu testen, verursacht Probleme, selbst bei guten Absichten. Fehlt Ihnen die Berechtigung, lassen Sie es also bleiben.

Wie halten Sie Funde fest und setzen Prioritäten?

Zunächst erlaubt ein gutes Protokoll es einer anderen Person, den Fund nachzuvollziehen und zu wiederholen. Wir empfehlen daher, für jeden Fund die folgenden Felder auszufüllen.

• Name und Ziel des Szenarios.
• Systemversion, Version der Anweisung und Testdatum.
• Kurze Zusammenfassung von beobachtetem und erwartetem Verhalten.
• Wie oft sich der Fund bei mehreren Versuchen wiederholt hat.
• Mögliche Auswirkung auf Daten, Geld, Ruf oder Sicherheit.
• Schweregrad und verantwortliche Person.

Die Ausgaben eines Modells schwanken, deshalb genügt ein einzelner erfolgreicher Versuch nicht als Beweis. Führen Sie das Szenario mehrmals aus und notieren Sie, wie oft es auftritt. So wird aus der vagen Aussage "manchmal passiert es" eine messbare Information.

Dann denken Sie die Priorität als Auswirkung mal Wahrscheinlichkeit. Ein häufiger Fund, der vertrauliche Daten offenlegt, steht ganz oben. Ein seltener Fund mit geringer Wirkung kann dagegen warten, also später folgen.

Außerdem sollten Sie den Rohtext schädlicher Ausgaben nicht mit einem großen Kreis teilen. Bewahren Sie den Bericht dort auf, wo nur die nötigen Personen Zugriff haben.

Wie funktionieren Behebung und erneuter Test?

Die Behebung beschränkt sich nicht auf eine Methode. Je nach Problem greifen Sie auf unterschiedlichen Ebenen ein.

• Systemanweisung und Aufgabengrenzen präzisieren.
• Bei Eingabe und Ausgabe Guardrails ergänzen.
• Rechte von Werkzeugen auf das Minimum senken und bei riskanten Aktionen eine menschliche Freigabe einbauen.
• Falsche oder riskante Dokumente aus der Wissensquelle entfernen.
• Bei Bedarf Modell oder Anbieter wechseln.

Nach der Behebung spielen Sie dasselbe Szenario unbedingt erneut durch. Testen Sie außerdem nahe Varianten, denn eine einzelne Formulierung zu sperren, ist keine echte Lösung.

Zudem kann jede Behebung ein neues Problem erzeugen. Zum Beispiel kann eine zu strenge Regel dazu führen, dass der Bot berechtigte Fragen ablehnt. Sammeln Sie deshalb Ihre alten Szenarien in einem Regressionsset und führen Sie es nach jeder Änderung aus. Wie Sie dieses Set messen, behandelt unser Beitrag zu LLM Evals.

Wann sollten Sie AI Red Teaming durchführen, vor oder nach dem Start?

Die Antwort lautet: beides. Ein Test vor dem Start fängt offensichtliche Probleme ab, bevor sie live gehen. Dann fängt ein Test nach dem Start neues Verhalten ab, das die echte Nutzung zeigt.

Drei Auslöser sollten eine Runde Red Teaming starten:

• Direkt bevor Sie eine neue KI Funktion für Kunden öffnen.
• Nach einer wichtigen Änderung an Modell, Systemanweisung, Wissensquelle oder angebundenen Werkzeugen.
• Wenn die Live Nutzung eine unerwartete Beschwerde oder einen Vorfall hervorbringt.

Planen Sie außerdem in regelmäßigen Abständen kleine Runden. Denn Nutzer entdecken mit der Zeit neue Wege. Somit erweitern Sie Ihr Szenarioset, statt in jeder Runde bei null zu beginnen.

Anders gesagt ist Red Teaming kein Projekt, sondern eine Gewohnheit über den gesamten Lebenszyklus des Produkts. Am besten wirkt es zusammen mit der Überwachung nach dem Start.

Wie präsentieren Sie einen Red Teaming Bericht der Geschäftsführung?

Denn die Geschäftsführung will Entscheidungen, keine technischen Details. Bauen Sie den Bericht daher um drei Fragen auf: Was haben wir gefunden, wie ernst ist es und was tun wir dagegen?

Setzen Sie oben eine kurze Zusammenfassung ein. Beschreiben Sie Umfang, getestete Version und die drei kritischsten Funde in zwei bis drei Sätzen. Danach folgt eine Tabelle der Funde, sortiert nach Schweregrad.

Nennen Sie zu jedem Fund eine verantwortliche Person und einen Zieltermin. Sonst liest man den Bericht, aber niemand handelt. Zum Beispiel wird aus "Identitätsprüfung ins Backend verlegen" eine echte Aufgabe, sobald sie eine Besitzerin hat.

Seien Sie deshalb ehrlich. Nennen Sie auch Bereiche, die Sie nicht getestet haben, denn die Geschäftsführung muss diese Lücken kennen. Ob das Restrisiko akzeptabel ist, entscheidet die Geschäftsführung; Ihre Aufgabe ist es, diese Entscheidung mit Fakten zu stützen.

Welche ethischen und rechtlichen Grenzen gelten für AI Red Teaming?

Red Teaming ist eine genehmigte Tätigkeit. Gehört das System Ihnen oder haben Sie eine schriftliche Erlaubnis, ist alles in Ordnung. Das System anderer ohne Erlaubnis zu testen, kann ernste Folgen haben, auch bei guter Absicht.

Nutzen Sie einen externen Modellanbieter, lesen Sie auch dessen Nutzungsbedingungen. Anbieter können eigene Regeln und Meldewege für Tests festlegen. Weil sich diese Regeln ändern können, prüfen Sie den aktuellen Text immer auf der offiziellen Seite.

Achten Sie also auch bei Daten auf Sorgfalt. Verwenden Sie keine echten personenbezogenen Kundendaten als Testeingabe. Taucht in der Testausgabe doch ein personenbezogenes Datum auf, schwärzen Sie es im Bericht und beschränken Sie den Zugriff. In diesem Fall können Ihre Datenschutzpflichten greifen.

Schließlich ist dieser Beitrag keine Rechtsberatung. Bei Pflichten nach Datenschutzrecht fragen Sie eine Fachanwältin oder einen Fachanwalt.

Noch eine Regel: Wer eine gefundene Schwachstelle ausnutzt, wechselt von der Verteidigung auf die Seite des Angriffs. Red Teaming dient ausschließlich der Verbesserung.

Welche Fähigkeiten braucht ein AI Red Teaming Team?

Denn ein starkes Team kommt nicht aus einem einzigen Fachgebiet. Die Ergebnisse sind solider, wenn die folgenden Fähigkeiten zusammenkommen.

• Sicherheitsdenken: Ein System mit den Augen eines Angreifers lesen.
• Fachwissen: Wissen, wie die Arbeit wirklich läuft und welche Fehler teuer sind.
• KI Kompetenz: Verstehen, warum ein Modell uneinheitlich reagieren kann.
• Schreibkompetenz: Funde klar, kurz und umsetzbar beschreiben.
• Ethisches Bewusstsein: Mit potenziell schädlichen Inhalten verantwortungsvoll umgehen.

Außerdem ist Neugier die wichtigste weiche Fähigkeit in dieser Arbeit. Konkret fragt ein guter Tester ständig, was passiert, wenn das System dies tut.

Fehlen Ihrem Team einige dieser Fähigkeiten, ist externe Hilfe sinnvoll. Trotzdem muss das interne Team, das das Produkt kennt, mitarbeiten, denn Externe kennen Ihren Geschäftskontext nicht so gut wie Sie.

Was unterscheidet AI Red Teaming von Penetrationstest, Evals und Guardrails?

Diese vier Begriffe werden oft verwechselt, doch jeder beantwortet eine andere Frage. Die folgende Tabelle fasst die Unterschiede zusammen.

Zusammengefasst findet Red Teaming Schwächen, Evals messen die Qualität und Guardrails schützen zur Laufzeit. Der Penetrationstest deckt die klassische Infrastruktur ab.

Daher ersetzt keiner den anderen. Dann liefert Red Teaming Ideen für neue Guardrails. Evals beweisen dann immer wieder, dass die Behebung wirkt. Steht diese Kette, hört Sicherheit auf, eine einmalige Anstrengung zu sein.

Wie sieht AI Red Teaming in einem echten Unternehmensszenario aus?

Der folgende Fall ist ein Beispielszenario und kein echter Kunde. Nehmen wir an, ein Online Shop hat einen Chatbot, der Fragen zu Bestellungen und Rückgaben beantwortet.

Zunächst zieht das Team den Umfang: Rückgaberegeln, Bestellstatus und Produktinformationen. Dann schreibt es die inakzeptablen Ergebnisse auf. Die Bestellung eines anderen Kunden anzuzeigen, einen Rabatt außerhalb der Regeln zu versprechen und in einem markenfremden Ton zu sprechen, stehen auf der Liste.

Dann findet das Team beim Test einige Schwachstellen. Der Bot verlangt bei Bestellabfragen nicht genug Identitätsprüfung. Außerdem macht er beim Beharren auf einem Rabatt manchmal ein Versprechen, zu dem er nicht befugt ist.

Die Behebung hat deshalb mehrere Ebenen. Die Prüfung der Identität überlassen Sie nicht der Textentscheidung des Bots, stattdessen erzwingt sie das Backend. Bei Entscheidungen wie Rabatt und Erstattung macht der Bot nur einen Vorschlag, und eine Mitarbeiterin gibt frei. Danach spielt das Team dieselben Szenarien erneut durch.

Somit sinkt das Risiko nicht auf null, aber messbar. Zudem hat das Team ein fertiges Szenarioset für die nächste Version.

Wie verändert sich AI Red Teaming bei Agentensystemen?

Agenten antworten nicht nur, sie nutzen auch Werkzeuge. Sie versenden Nachrichten, fragen Datenbanken ab, öffnen Dateien oder verbinden sich mit externen Diensten. Daher verschiebt sich der Test von der Frage, was das Modell sagte, zur Frage, was das Modell tat.

Einer der wichtigsten Punkte ist hier die Überschreitung von Befugnissen. OWASP behandelt das in seiner Risikoliste für Anwendungen mit großen Sprachmodellen unter dem Begriff "Excessive Agency". Anders gesagt ist es schon ein Risiko, einem System mehr Funktionen, Rechte oder Autonomie zu geben, als es braucht.

Beim Test von Agenten stellen Sie zum Beispiel diese Fragen:

• Auf welche Werkzeuge kann der Agent zugreifen, und ist dieser Zugriff wirklich nötig.
• Gibt es bei Aktionen, die sich nicht zurücknehmen lassen, eine menschliche Freigabe.
• Kann der Agent eine Anweisung in einem gelesenen Dokument für seine eigene Aufgabe halten.
• Wird jeder Werkzeugaufruf protokolliert.

Den Aufruf von Werkzeugen erklären wir im Beitrag zu Function Calling und das Anbindungsprotokoll im Beitrag zu MCP. Hier ergänzen wir nur: Rechte so eng wie möglich zu halten, ist die günstigste und wirksamste Verteidigung.

Welche Grenzen und Risiken hat AI Red Teaming?

Wie jede Sicherheitsmethode bietet Red Teaming keine absolute Gewähr. Daher beweist ein Test, der keinen Fehler findet, nicht, dass es keinen gibt. Er zeigt nur, dass Sie in den geprüften Szenarien kein Problem gesehen haben.

Außerdem haben Ergebnisse ein kurzes Haltbarkeitsdatum. Ändern sich Modell, Anweisung oder ein angebundenes Werkzeug, können Funde veraltet sein. Notieren Sie daher im Bericht immer Datum und Version.

Anthropic beschreibt, dass verschiedene Methoden des Red Teaming jeweils eigene Stärken und Schwächen haben und dass fehlende Standards den Vergleich von Systemen erschweren. Anders gesagt bedeutet "Wir haben Red Teaming gemacht" bei zwei Firmen nicht gleiche Qualität.

Zudem tragen auch menschliche Tester eine Last. Lange mit verstörenden Inhalten zu arbeiten, kann ermüden. Achten Sie deshalb auf Aufgabenwechsel und das Wohlbefinden der Tester.

Schließlich droht trügerische Sicherheit. "Wir haben getestet, also ist es sicher" ist ein schlechter Satz. "In diesem Umfang haben wir bei dieser Version diese Funde gesehen" ist viel ehrlicher.

Wie sieht eine Checkliste für den Chatbot eines kleinen Unternehmens aus?

Sie können auch ohne großes Team klein anfangen. Die folgende Liste genügt für eine einfache erste Runde.

• Beschreiben Sie Aufgabe und Tabuthemen des Bots in einem Absatz.
• Listen Sie alle Daten und Werkzeuge auf, auf die der Bot zugreift.
• Legen Sie fünf bis zehn inakzeptable Ergebnisse fest.
• Bereiten Sie für jedes Ergebnis ein Testszenario vor.
• Testen Sie in einer Umgebung ohne echte Kundendaten.
• Spielen Sie jedes Szenario mehrmals mit unterschiedlicher Formulierung durch.
• Tragen Sie die Ergebnisse mit Datum und Version in eine Tabelle ein.
• Ordnen Sie die Funde nach Schweregrad und weisen Sie Verantwortliche zu.
• Wiederholen Sie nach jeder Behebung dieselben Szenarien.
• Legen Sie einen Termin fest, um die Liste bei jeder Systemänderung zu wiederholen.
• Prüfen Sie auch die nicht freigegebene Nutzung von Werkzeugen durch Mitarbeitende; unser Beitrag zu Shadow AI behandelt das.

Diese Liste ist ein Anfang. Zum Beispiel können Sie in der ersten Runde mit nur drei Punkten beginnen und dann erweitern. Bei kritischeren Systemen sollten Sie sich von einer unabhängigen Fachperson unterstützen lassen.

Welche typischen Fehler passieren beim AI Red Teaming?

Diese Fehler sehen wir in der Praxis am häufigsten:

• Einmal vor dem Start testen und dann aufhören.
• Nur Entwickler testen lassen und die Fachexperten ausschließen.
• Ohne Umfang nach dem Motto "mal sehen, was wir finden" beginnen.
• Funde ohne Schweregrad als flache Liste führen.
• Nach einer Behebung alte Szenarien nicht erneut ausführen.
• Sich nur auf Textausgaben konzentrieren und Werkzeugrechte nicht hinterfragen.
• Rohe schädliche Ausgaben in einem Kanal teilen, den alle lesen können.

Die meisten dieser Fehler entstehen, weil man den Prozess als Haken auf einer Liste sieht. Tatsächlich ist Red Teaming das Bemühen, das Verhalten des Systems zu verstehen. Lernen verbessert sich durch Wiederholung.

Machen Sie Funde außerdem nicht zum Mittel der Schuldzuweisung. Bestraft man ein Team dafür, dass es einen Fehler findet, findet es beim nächsten Mal weniger.

Welche offiziellen Quellen sollten Sie zu AI Red Teaming lesen?

Wenn Sie tiefer einsteigen möchten, finden Sie unten die Primärquellen. Alle sind Seiten der Anbieter oder Institutionen selbst, prüfen Sie den aktuellen Inhalt also dort.

• NIST Rahmen für das Risikomanagement von KI: der allgemeine Rahmen für das Risikomanagement.
• NIST Profil für generative KI: Risiken generativer Systeme und empfohlene Maßnahmen.
• OWASP Top 10 für LLM und GenAI: typische Risiken für Anwendungen mit großen Sprachmodellen.
• Dokumentation des Microsoft AI Red Team: Leitfäden zu Teamaufbau und Automatisierung.
• Überblick zum Google AI Red Team: Angriffsarten und gewonnene Erkenntnisse.
• Anthropic Beitrag zum Red Teaming: Stärken und Schwächen verschiedener Methoden.

Diese Quellen enthalten anbieterspezifische Details. Daher halten Sie es bei der Übertragung auf Ihr Produkt einfach und konzentrieren sich auf die Konzepte. Für Modellnamen, Versionen oder Grenzwerte prüfen Sie immer die aktuelle Dokumentation des Anbieters.

Wo sollten Sie mit AI Red Teaming anfangen?

Die praktische Antwort auf die Frage, was ist AI Red Teaming, lautet: Ihr System kontrolliert zu fordern, bevor es Ihre Nutzer tun. Fangen Sie klein an. Ein Chatbot, fünf inakzeptable Ergebnisse und je ein Szenario sind eine gute erste Runde.

Danach halten Sie die Funde fest, beheben sie und testen erneut. Sitzt der Prozess, ergänzen Sie laufende Messung mit Evals und Schutz zur Laufzeit mit Guardrails. Außerdem sollten Sie bei Agenten die Rechte von Anfang an eng fassen.

Als Talha Aslan und Team unterstützen wir KI Projekte bei Umfang und Risikobewertung. Wenn Sie möchten, melden Sie sich über unsere Seite zur KI Beratung oder unsere Lösung zur Chatbot Entwicklung.

Dieser Beitrag ist allgemeine Information. Bei Fragen zu Sicherheit, Datenschutz und Recht wenden Sie sich an Ihre Fachperson. Keine Testmethode bietet eine vollständige Sicherheitsgarantie.