AI Red-Teaming im Betrieb: KI-Risiken kontinuierlich prüfen

Viele Organisationen testen KI-Anwendungen vor dem ersten Go-live, behandeln Sicherheit danach aber wie einen abgeschlossenen Meilenstein. Genau dort entsteht ein blinder Fleck: Prompts, Datenquellen, Rollen, Tool-Aufrufe und Nutzerverhalten verändern sich im laufenden Betrieb. AI Red-Teaming sollte deshalb kein einmaliger Stresstest sein, sondern ein wiederkehrender Kontrollprozess. Die zentrale These: Wer KI produktiv betreibt, muss Angriffe, Fehlverhalten und Kontrollversagen regelmäßig simulieren, messen und in technische sowie organisatorische Verbesserungen übersetzen.

AI Red-Teaming im Betrieb verstehen

AI Red-Teaming bezeichnet die gezielte Prüfung von KI-Systemen aus Angreifer- und Fehlersicht. Ein Team versucht kontrolliert, Schwächen sichtbar zu machen: Kann ein Modell zu unerwünschten Ausgaben gebracht werden? Lassen sich Systemregeln umgehen? Werden vertrauliche Informationen preisgegeben? Können Tool-Aufrufe missbraucht werden? Funktionieren Freigaben, Logging und Eskalationen auch unter Druck?

Wichtig ist die Abgrenzung zu klassischem Penetration Testing. Ein Penetration Test prüft häufig Infrastruktur, Anwendungen, APIs und Identitäten. AI Red-Teaming erweitert diese Sicht um Modellverhalten, Prompt Injection, Kontextmanipulation, Retrieval-Fehler, Datenabfluss, unsichere Agentenschritte und unerwartete Interaktionen zwischen Modell und Werkzeugen. Beides gehört zusammen, ist aber nicht identisch.

Ein typisches Missverständnis lautet: AI Red-Teaming sei nur für Modellanbieter relevant. In der Praxis entstehen viele Risiken erst im Unternehmenskontext. Ein Standardmodell wird mit internen Dokumenten, Berechtigungen, Plugins, Workflows und Fachprozessen verbunden. Dadurch verschiebt sich die Frage von "Ist das Modell sicher?" zu "Ist unser KI-System in unserem Betriebsmodell kontrollierbar?".

Ein zweites Missverständnis betrifft den Zeitpunkt. Red-Teaming vor dem Go-live ist sinnvoll, aber nicht ausreichend. Neue Datenquellen, geänderte Prompts, zusätzliche Rollen, andere Nutzergruppen oder Modellupdates können das Risikoprofil verändern. AI Red-Teaming im Betrieb bedeutet deshalb: wiederholen, vergleichen, dokumentieren und nachsteuern.

Warum jetzt? Treiber und Kontext

KI-Anwendungen wandern von isolierten Experimenten in echte Arbeitsabläufe. Sie unterstützen Support, Wissensmanagement, Softwareentwicklung, Dokumentenanalyse, Management-Reporting und zunehmend auch teilautomatisierte Prozessschritte. Damit steigt der potenzielle Schaden, wenn ein System falsche Empfehlungen gibt, sensible Daten offenlegt oder Aktionen ohne ausreichende Kontrolle vorbereitet.

Technisch werden KI-Systeme komplexer. Ein produktiver KI-Service besteht selten nur aus einem Chatfenster. Typischerweise wirken Modellzugriff, Prompt-Vorlagen, Retrieval, Vektorindizes, Berechtigungen, API-Integrationen, Tool-Gateways, Monitoring und Feedbackschleifen zusammen. Jede dieser Komponenten kann Schwächen einführen. Red-Teaming hilft, diese Kette nicht nur einzeln, sondern als Gesamtsystem zu prüfen.

Organisatorisch entsteht Druck, KI schneller nutzbar zu machen. Fachbereiche erwarten Produktivität, IT-Management erwartet Skalierbarkeit, Security erwartet Kontrolle, Datenschutz erwartet Zweckbindung und Nachvollziehbarkeit. Ohne einen wiederholbaren Prüfprozess wird jede KI-Freigabe zur Einzelfallentscheidung. Das ist langsam, schwer auditierbar und anfällig für Schatten-KI.

Ökonomisch ist AI Red-Teaming eine Investition in Betriebsstabilität. Es verhindert nicht jedes Problem, reduziert aber Überraschungen. Je früher Schwächen in Datenzugriff, Rollenmodell, Prompt-Design oder Tool-Berechtigungen auffallen, desto günstiger lassen sie sich beheben. Besonders wertvoll ist Red-Teaming dort, wo KI-Systeme nahe an sensiblen Informationen oder operativen Aktionen arbeiten.

Wie AI Red-Teaming im Betrieb funktioniert

AI Red-Teaming im Betrieb braucht einen festen Prozess, kein loses Ausprobieren einzelner Prompts. Der Ablauf beginnt mit einer klaren Systembeschreibung: Welche Nutzergruppen gibt es? Welche Datenquellen werden verwendet? Welche Tools darf das System aufrufen? Welche Entscheidungen oder Aktionen sind erlaubt? Welche Schutzmaßnahmen existieren bereits?

Darauf folgt die Definition realistischer Angriffsszenarien. Diese Szenarien sollten nicht nur Modellantworten prüfen, sondern den gesamten Daten- und Aktionsfluss. Ein guter Testfall beschreibt Ausgangslage, Ziel des Angriffs, erwartete Schutzwirkung, erlaubte Testgrenzen und Bewertungskriterien. Wichtig ist, dass Red-Teaming kontrolliert stattfindet: mit Freigabe, Testumgebung oder begrenztem Umfang, klaren Rollen und sauberer Protokollierung.

Aus Architektursicht gehören mehrere Komponenten zusammen:

• ein KI-Systeminventar mit Owner, Datenquellen, Modellzugriffen und Tool-Rechten
• Risikokategorien für Datenabfluss, Manipulation, unerlaubte Aktionen, Bias und Qualitätsversagen
• Testkataloge für Prompt Injection, Jailbreaks, Retrieval Poisoning, Rollenmissbrauch und Tool-Missbrauch
• technische Guardrails für Eingaben, Ausgaben, Berechtigungen und Freigaben
• Logging und Tracing für Nutzeranfrage, Kontextquellen, Modellantwort und Tool-Aufruf
• ein Verbesserungsprozess, der Befunde priorisiert und in Backlog, Policy oder Betrieb überführt

Der wichtigste Punkt ist die Rückkopplung. Ein Red-Team-Befund darf nicht als isolierter Sicherheitsbericht enden. Er muss zu konkreten Maßnahmen führen: Prompt-Anpassung, Datenbereinigung, Berechtigungsreduktion, zusätzliche Freigabe, bessere Fehlermeldung, Monitoring-Regel, Schulung oder Architekturänderung. Danach wird erneut getestet, ob die Maßnahme wirkt.

Praxis: Anwendungsfälle und Entscheidungslogik

Ein erster Use Case ist ein interner Wissensassistent. Er greift auf Richtlinien, Projektunterlagen, Tickets oder Betriebsdokumentation zu. AI Red-Teaming prüft hier, ob Nutzer über geschickte Fragen an Informationen gelangen, die außerhalb ihrer Rolle liegen, ob veraltete Dokumente bevorzugt werden oder ob Quellenkontext falsch zusammengeführt wird. Wenn der Assistent nur öffentlich freigegebene interne Informationen nutzt, reicht ein schlanker Testkatalog. Wenn vertrauliche oder personenbezogene Informationen eingebunden sind, braucht es strengere Zugriffstests, Datenklassifizierung und Protokollierung.

Ein zweiter Use Case ist ein KI-Assistent im IT-Support. Er klassifiziert Tickets, schlägt Lösungen vor und kann vielleicht Runbooks anstoßen. Hier liegt das Risiko weniger in einer falschen Formulierung als in einer falschen Aktion. Red-Teaming sollte prüfen, ob manipulierte Tickettexte den Assistenten zu riskanten Vorschlägen bringen, ob Runbook-Freigaben greifen und ob Eskalationen nachvollziehbar dokumentiert werden. Wenn Tool-Aufrufe nur vorgeschlagen werden, ist das Risiko geringer. Wenn sie automatisch ausgeführt werden, sind Least Privilege, Sandbox-Tests, Vier-Augen-Freigaben und Rollback-Fähigkeit Pflicht.

Ein dritter Use Case betrifft Softwareentwicklung. Coding-Assistenten und agentische Entwicklerwerkzeuge arbeiten mit Repositorys, Issues, Build-Logs und manchmal Secrets. AI Red-Teaming prüft, ob schädliche Anweisungen in README-Dateien, Tickets oder Codekommentaren das System beeinflussen, ob vertrauliche Inhalte in Ausgaben geraten und ob generierter Code unsichere Muster einführt. Wenn der Assistent nur lokal Vorschläge macht, liegt der Fokus auf Qualität und Datenabfluss. Wenn er Pull Requests erstellt oder Befehle ausführt, wird daraus ein Betriebs- und Supply-Chain-Thema.

Ein vierter Use Case ist Management-Reporting. KI kann Statusberichte, Risiken und Kostenentwicklungen zusammenfassen. Red-Teaming prüft, ob das System aus lückenhaften Quellen zu harte Schlussfolgerungen zieht, Annahmen nicht kennzeichnet oder sensible Projektdetails in falsche Empfängerkreise bringt. Wenn Berichte entscheidungsvorbereitend sind, braucht es Quellenhinweise, Annahmenkennzeichnung und fachliche Freigabe.

Die Entscheidungslogik ist pragmatisch: Wenn ein KI-System nur allgemeine Inhalte erzeugt und keine sensiblen Daten nutzt, genügt ein leichter Red-Team-Check vor größeren Änderungen. Wenn interne Daten, Nutzerrollen oder Retrieval im Spiel sind, sollte Red-Teaming Teil jedes produktiven Releases sein. Wenn Tool-Aufrufe, Automatisierung oder externe Kommunikation betroffen sind, braucht es regelmäßige Tests, technische Kontrollpunkte und eine formale Risikoabnahme.

Risiken, Grenzen, Kontrollmechanismen

Das offensichtlichste Risiko ist Prompt Injection. Nutzer oder externe Inhalte versuchen, Systemregeln zu überschreiben, Daten preiszugeben oder Folgeaktionen zu manipulieren. Gegenmaßnahmen sind robuste Systemprompts, Trennung von Instruktionen und Daten, Kontextfilter, Tool-Freigaben, Ausgabekontrollen und Tests mit realistischen Angriffsmustern. Wichtig ist: Prompt-Härtung allein reicht nicht, wenn Berechtigungen zu breit sind.

Datenabfluss ist ein zweites Kernrisiko. KI-Systeme können Informationen aus internen Quellen zusammenführen und dadurch mehr offenlegen, als eine einzelne Quelle sichtbar machen würde. Kontrollmechanismen sind rollenbasierter Zugriff, Datenklassifizierung, Maskierung, Quellenbindung, Logging und klare Regeln für Export, Zusammenfassung und externe Weitergabe. Besonders kritisch sind Systeme, die über mehrere Fachbereiche hinweg suchen.

Ein drittes Risiko liegt in Retrieval Poisoning und Kontextmanipulation. Wenn ein KI-System Dokumente, Tickets oder Webseiten als Kontext nutzt, können manipulierte Inhalte die Antwort beeinflussen. Gegenmaßnahmen sind Quellenvertrauen, Dokumentenfreigaben, Aktualitätsmarker, getrennte Indizes für unterschiedliche Vertrauensstufen und Warnungen bei widersprüchlichem Kontext.

Tool-Missbrauch ist bei agentischen Systemen besonders relevant. Ein Modell kann überzeugend erklären, warum ein API-Aufruf, eine Dateiänderung oder eine Ticketaktion sinnvoll sei, obwohl die Grundlage unsicher ist. Kontrollmechanismen sind minimale Rechte, explizite Freigaben, erlaubte Aktionslisten, Budget- und Schrittgrenzen, Sandbox-Ausführung, Rate-Limits und ein Stoppschalter für Workflows.

Qualitätsrisiken entstehen, wenn Red-Teaming zu eng verstanden wird. Nicht jeder kritische Fehler ist ein Angriff. Ein KI-System kann auch durch mehrdeutige Anforderungen, schlechte Datenqualität, Modelländerungen oder unklare Fachbegriffe scheitern. Deshalb sollte AI Red-Teaming mit Evaluation, Monitoring und fachlicher Qualitätssicherung verbunden werden. Die beste Kontrolle ist eine Kombination aus Angriffssimulation, Messung realer Nutzung und sauberem Incident-Prozess.

Die Grenze von Red-Teaming liegt darin, dass es keine vollständige Sicherheit beweist. Es zeigt bekannte und plausibel simulierte Schwächen. Deshalb darf ein bestandener Test nicht als Freibrief gelten. Er ist ein Signal im Risikomanagement, ergänzt durch Architekturreviews, Datenschutzprüfung, Monitoring, Nutzerschulung und regelmäßige Nachtests.

Umsetzung: 30-60-90-Tage-Plan

In den ersten 30 Tagen sollte Transparenz entstehen. IT-Management und Security sollten alle produktiven und geplanten KI-Systeme inventarisieren, ihre Datenquellen und Tool-Rechte erfassen und pro System einen fachlichen sowie technischen Owner benennen. Für ein bis zwei priorisierte Systeme wird ein erster Red-Team-Testkatalog erstellt.

• KI-Systeme, Datenquellen, Nutzerrollen und Tool-Rechte erfassen
• Risiko nach Datenklasse, Automatisierungsgrad und Nutzerkreis grob bewerten
• Testgrenzen, Verantwortlichkeiten und Freigabeprozess definieren
• erste Szenarien für Prompt Injection, Datenabfluss und Tool-Missbrauch formulieren
• Befunde in einem nachvollziehbaren Register dokumentieren

Nach 60 Tagen sollte der Prozess in einem kontrollierten Pilot laufen. Ein ausgewähltes KI-System wird mit realistischen Szenarien getestet. Wichtig ist die Verbindung von Befund und Maßnahme: Jede Schwäche erhält eine Priorität, einen Owner und eine Entscheidung, ob sie technisch, prozessual oder organisatorisch behandelt wird.

• Red-Team-Tests gegen ein priorisiertes System durchführen
• Logs und Traces prüfen: Anfrage, Kontext, Antwort, Tool-Aufruf
• Guardrails und Berechtigungen anhand echter Befunde nachschärfen
• Wiederholungstests für behobene Schwächen einplanen
• Abnahmekriterien für produktive KI-Änderungen definieren

Nach 90 Tagen sollte AI Red-Teaming Teil des Betriebsmodells sein. Neue oder geänderte KI-Funktionen durchlaufen abhängig vom Risiko einen leichten oder vertieften Test. Befunde fließen in Architekturentscheidungen, Security-Policies, Schulungen und Release-Freigaben ein. Zusätzlich sollte ein regelmäßiger Review prüfen, ob neue Datenquellen, Rollen oder Modelländerungen das Risikoprofil verändert haben.

• Red-Teaming in Release- und Change-Prozesse integrieren
• Standard-Testkataloge für typische KI-Systemklassen pflegen
• Metriken für Befunde, Wiederholungsfehler und Behebungszeiten etablieren
• Incident-Runbooks für KI-spezifische Vorfälle ergänzen
• Quartalsweise Nachtests für kritische KI-Systeme planen

Fazit

AI Red-Teaming ist kein Misstrauensvotum gegen KI, sondern Betriebsdisziplin. Je stärker KI-Systeme mit internen Daten, Rollen und Werkzeugen verbunden werden, desto wichtiger wird die regelmäßige Prüfung ihrer realen Angriffs- und Fehlerszenarien. Der Nutzen liegt nicht nur im Finden einzelner Schwächen, sondern im Aufbau eines lernenden Kontrollprozesses. IT-Management sollte Red-Teaming deshalb als festen Bestandteil von KI-Governance, Security und Delivery behandeln.

Wenn du KI-Systeme produktiv einsetzt, starte mit einem begrenzten Red-Team-Pilot und übersetze jeden Befund konsequent in Architektur-, Policy- oder Betriebsverbesserungen.