Der entscheidende Perspektivwechsel gegenüber klassischer Qualitätssicherung ist die Angreiferbrille. Herkömmliche Tests fragen: „Funktioniert die Funktion wie spezifiziert?“ Red Teaming fragt: „Unter welchen Bedingungen bricht das Verhalten, umgeht jemand die Schutzmechanismen, oder produziert das System schädliche, verzerrte oder rechtlich problematische Ergebnisse?“ Bei KI-Systemen – insbesondere bei generativen Modellen und lernenden Verfahren – ist dieser Blick besonders wichtig, weil ihr Verhalten nicht vollständig durch Regeln festgelegt, sondern statistisch aus Daten abgeleitet ist. Ein solches System kann in seltenen, aber kritischen Fällen anders reagieren, als seine Entwickler:innen erwarten.
Wichtig ist von Anfang an die Einordnung: Dieser Beitrag betrachtet Red Teaming ausschließlich als defensive Qualitäts- und Sicherheitsmaßnahme. Es geht darum, die eigenen Systeme im autorisierten Rahmen zu härten – nicht darum, fremde Systeme anzugreifen oder funktionsfähige Angriffe zu entwickeln. Der Wert liegt in der Methodik: einem strukturierten Prozess, der Risiken sichtbar, dokumentierbar und behebbar macht. Konkrete, wiederverwendbare Angriffstechniken sind bewusst nicht Gegenstand dieses Artikels.
Das Prinzip des Red Teaming ist deutlich älter als generative KI. In Militär, Nachrichtendiensten und später in der IT-Sicherheit war das „rote Team“ stets die Instanz, die absichtlich die Perspektive des Gegners einnahm, um blinde Flecken der Verteidigung zu finden. In der klassischen Cybersicherheit ist Red Teaming eine etablierte Disziplin, bei der ein autorisiertes Team realistische Angriffsszenarien durchspielt, um die Widerstandsfähigkeit einer Organisation zu prüfen. KI Red Teaming überträgt diese Denkweise auf ein neues Objekt: nicht Netzwerke und Server, sondern Modelle, Datenpipelines und KI-gestützte Anwendungen.
Der Unterschied zum klassischen IT-Kontext liegt im Prüfobjekt selbst. Ein KI-Modell hat keine feste, vollständig einsehbare Logik, sondern ein aus Daten gelerntes Verhalten. Deshalb reicht es nicht, technische Schnittstellen zu prüfen – man muss auch das inhaltliche Verhalten testen: Welche Ausgaben erzeugt das System, wenn man es geschickt in die Enge treibt, mehrdeutig anspricht oder mit ungewöhnlichen Eingaben konfrontiert? Genau diese Verbindung aus technischer und inhaltlicher Prüfung macht KI Red Teaming zu einer eigenständigen Disziplin.
Ein KI-System, das im Demo-Betrieb überzeugt, kann im Realbetrieb an Rändern versagen, die im normalen Test nie berührt wurden. Ein Kundenservice-Assistent etwa kann bei höflichen Standardfragen einwandfrei arbeiten und dennoch bei manipulativ formulierten oder emotional aufgeladenen Eingaben Aussagen treffen, die unternehmensschädigend, diskriminierend oder schlicht falsch sind. Solche Fälle tauchen in klassischen Testfällen selten auf, weil diese das erwartbare Verhalten prüfen – nicht das Verhalten unter absichtlichem Druck.
Genau hier setzt Red Teaming an. Es füllt die Lücke zwischen „funktioniert im Normalfall“ und „hält auch dem Missbrauch, dem Grenzfall und dem gezielten Umgehungsversuch stand“. Für Unternehmen ist das mehr als eine technische Übung: Es ist ein Baustein verantwortungsvoller KI-Einführung, der eng mit Themen wie Qualitätssicherung, Fairness und Vertrauenswürdigkeit verzahnt ist – und der, wie die folgenden Kapitel zeigen, zunehmend auch regulatorisch an Bedeutung gewinnt.
Qualitätssicherung im klassischen Sinn prüft, ob ein System die definierten Anforderungen erfüllt. Bei KI-Systemen umfasst das etwa die Messung von Genauigkeit, das Prüfen erwarteter Antworten und das Absichern von Standardabläufen. Diese Arbeit ist unverzichtbar – ohne solide QA gibt es kein belastbares Fundament. Aber sie prüft im Kern das erwartbare Verhalten. Sie stellt sicher, dass das System das Richtige tut, wenn es korrekt und gutwillig bedient wird.
Red Teaming ergänzt diese Sicht um das Unerwartete und das Böswillige. Es geht nicht darum, ob eine Funktion korrekt arbeitet, sondern darum, ob und wie sich das System unter absichtlichem Druck, mit ungewöhnlichen Eingaben oder in Grenzsituationen fehlverhält. Beide Disziplinen sind komplementär: QA legt das Fundament, Red Teaming testet die Belastbarkeit. Wer nur QA betreibt, übersieht systematisch genau jene Risiken, die im Ernstfall am teuersten werden. Eine weiterführende Perspektive auf strukturierte KI-Qualitätssicherung liefert unser Beitrag zur KI-QS in Kategorie 35.
Ein Penetrationstest prüft die technische Angreifbarkeit von IT-Systemen: Server, Netzwerke, Schnittstellen, Zugriffsrechte. KI Red Teaming teilt die angreiferorientierte Denkweise, richtet den Blick aber zusätzlich auf das Verhalten des Modells und die inhaltliche Ebene. Ein Penetrationstest könnte etwa aufdecken, dass eine Schnittstelle unzureichend authentifiziert ist. Red Teaming würde ergänzend prüfen, ob sich das Modell dahinter zu problematischen Ausgaben bewegen lässt, ob es sensible Trainingsinhalte preisgibt oder ob seine Schutzmechanismen durch geschickt formulierte Eingaben ausgehebelt werden können.
In der Praxis überlappen sich beide bei KI-gestützten Anwendungen. Eine vollständige Absicherung betrachtet die klassische Infrastruktur (Pentest-Perspektive) ebenso wie das KI-spezifische Verhalten (Red-Teaming-Perspektive). Deshalb ist es sinnvoll, beide Disziplinen zu kombinieren, statt sie gegeneinander auszuspielen – gerade dort, wo eine KI-Anwendung mit sensiblen Daten oder kritischen Entscheidungen verbunden ist.
Im Deutschen verschwimmen „Sicherheit“ und „Safety“ leicht, im Red Teaming sind sie klar getrennt. Security fragt: Kann ein böswilliger Akteur das System zu unerwünschtem Verhalten bewegen? Dazu gehört etwa, ob sich Schutzanweisungen aushebeln oder eingebaute Regeln umgehen lassen. Ein prominentes Feld ist hier die Prompt Injection, bei der über manipulierte Eingaben versucht wird, das beabsichtigte Verhalten eines Sprachmodells zu überschreiben – ein Thema, das wir in Kategorie 35 gesondert vertiefen.
Safety hingegen fragt: Kann das System – auch ohne böse Absicht des Nutzers – schädliche, gefährliche oder unangemessene Inhalte erzeugen? Hier geht es um den Schutz von Menschen vor problematischen Ausgaben, etwa gefährlichen Anleitungen, Falschinformationen mit Schadenspotenzial oder unangemessenen Inhalten. Beide Dimensionen greifen ineinander: Ein Security-Vorfall kann in ein Safety-Problem münden, wenn eine umgangene Schutzregel zu einer gefährlichen Ausgabe führt.
Bias und Fairness untersuchen, ob ein KI-System bestimmte Personengruppen systematisch benachteiligt – etwa bei der Bewertung von Bewerbungen, der Priorisierung von Anfragen oder der Formulierung von Empfehlungen. Solche Verzerrungen entstehen oft unbeabsichtigt aus den Trainingsdaten und sind ohne gezieltes Testen schwer zu erkennen. Red Teaming prüft hier mit strukturierten Szenarien, ob sich in den Ausgaben Muster unfairer Behandlung zeigen. Für die methodische Tiefe verweisen wir auf unseren Beitrag zu Bias und Fairness.
Robustheit betrachtet die Stabilität des Verhaltens: Wie reagiert das System auf verrauschte, unvollständige, ungewöhnlich formulierte oder gezielt gestörte Eingaben? Ein robustes System bleibt auch am Rand seines Erfahrungsbereichs zuverlässig oder erkennt zumindest, dass es unsicher ist. Die fünfte Dimension, der Datenschutz, prüft, ob das System sensible oder personenbezogene Informationen preisgibt – etwa Fragmente aus Trainingsdaten, interne Anweisungen oder Daten anderer Nutzer:innen. Gerade diese Dimension verbindet Red Teaming eng mit der DSGVO, worauf Kapitel 09 näher eingeht.
Die wichtigste und zugleich am häufigsten vernachlässigte Phase ist das Scoping. Bevor irgendetwas getestet wird, muss klar sein, was geprüft werden darf, mit welchen Mitteln, in welcher Umgebung und mit wessen ausdrücklicher Autorisierung. Ohne diesen Rahmen droht Red Teaming ins Beliebige abzugleiten – oder rechtliche und betriebliche Probleme zu verursachen. Ein guter Scope grenzt insbesondere ab, ob in einer Testumgebung oder am Produktivsystem geprüft wird, welche Daten verwendet werden dürfen und wann ein Test abzubrechen ist.
Die Autorisierung sollte immer schriftlich und von einer entscheidungsbefugten Stelle erfolgen. Das schützt nicht nur die Organisation, sondern auch das Red Team selbst: Wer im klar definierten, autorisierten Rahmen arbeitet, bewegt sich auf sicherem Grund. Werden externe Dienstleister eingebunden, gehört die Autorisierung samt Verschwiegenheits- und Datenschutzvereinbarungen in einen sauberen Vertrag.
Das Threat Modeling übersetzt die diffuse Frage „Was könnte schiefgehen?“ in konkrete, testbare Hypothesen. Dazu betrachtet man systematisch die relevanten Missbrauchsakteure – vom neugierigen Nutzer über den unzufriedenen Kunden bis zum gezielt böswilligen Dritten – und die Werte, die geschützt werden müssen: personenbezogene Daten, Reputation, Geschäftsgeheimnisse, die Unversehrtheit von Entscheidungen. Aus dieser Betrachtung ergibt sich, welche Testdimensionen für das konkrete System Priorität haben.
Ein gutes Threat Model ist kein akademisches Dokument, sondern eine praktische Landkarte. Es hält fest, welche Szenarien realistisch und folgenreich sind, und lenkt die begrenzte Testzeit dorthin, wo sie den größten Erkenntnisgewinn bringt. So wird aus einem potenziell endlosen „Wir probieren mal alles“ ein zielgerichteter, begründbarer Prüfplan.
Automatisierte Ansätze nutzen Werkzeuge, um große Mengen an Testfällen systematisch und wiederholbar durchzuspielen. Der große Vorteil liegt in der Skalierbarkeit: Was ein Mensch in Stunden prüft, lässt sich automatisiert in weit größerem Umfang und regelmäßig wiederholen – etwa nach jedem Modell-Update. Automatisierung eignet sich besonders für die Regressionsprüfung: Bereits gefundene Schwachstellen können immer wieder getestet werden, um sicherzustellen, dass sie behoben bleiben.
Qualitativ lassen sich automatisierte Werkzeuge grob in Kategorien einordnen: Es gibt Frameworks, die strukturierte Testkataloge über eine KI-Anwendung ausführen; Ansätze, bei denen ein Modell genutzt wird, um Testfälle gegen ein anderes Modell zu generieren; sowie Bewertungs- und Benchmark-Werkzeuge, die Ausgaben nach definierten Kriterien einordnen. Im Open-Source- wie im kommerziellen Umfeld existiert eine wachsende Landschaft solcher Werkzeuge. Für den Mittelstand ist weniger die Wahl eines bestimmten Produkts entscheidend als die Frage, ob das gewählte Werkzeug zum eigenen Risikoprofil, zur Systemlandschaft und zu den vorhandenen Kompetenzen passt.
Die entscheidende Erkenntnis lautet: Manuell und automatisiert sind keine Alternativen, sondern Ergänzungen. Automatisierung sorgt für Breite und Wiederholbarkeit – sie deckt systematisch bekannte Risikoklassen ab und hält sie unter Kontrolle. Manuelles Red Teaming sorgt für Tiefe und Kreativität – es entdeckt neue, kontextspezifische Schwachstellen, die automatisierte Kataloge noch nicht kennen. Neue manuelle Funde können anschließend in automatisierte Tests überführt werden, sodass die Regressionsprüfung mitwächst.
Für viele mittelständische Unternehmen ist ein pragmatischer Einstieg sinnvoll: eine überschaubare automatisierte Grundprüfung für die wichtigsten Risikoklassen, ergänzt durch gezielte manuelle Sitzungen für die kritischsten Anwendungsfälle. So entsteht ein belastbares Grundniveau, das mit steigender KI-Nutzung ausgebaut werden kann.
Im klassischen Bild stehen sich zwei Farben gegenüber: Das Red Team nimmt die Angreiferperspektive ein und sucht Schwachstellen; das Blue Team verteidigt, härtet und behebt. In vielen Organisationen hat sich zusätzlich das Bild des Purple Teaming etabliert – ein enges Zusammenspiel beider Seiten, bei dem Erkenntnisse des Red Teams unmittelbar in Verbesserungen des Blue Teams münden. Für den Mittelstand ist genau dieses kooperative Modell oft am wirkungsvollsten: Es geht nicht um einen Wettkampf, sondern um gemeinsames Härten.
Ein wirksames Red Team ist selten monodisziplinär. Idealerweise vereint es mehrere Perspektiven: technisches Verständnis der KI-Systeme, Domänenwissen aus dem jeweiligen Fachbereich, ein Gespür für Sicherheitsfragen sowie – gerade bei Bias und Safety – Sensibilität für gesellschaftliche und ethische Dimensionen. Diversität im Team ist dabei kein Selbstzweck: Unterschiedliche Hintergründe finden unterschiedliche Schwachstellen. Ein Team, das nur aus einer Perspektive besteht, hat systematische blinde Flecken.
Für kleinere Organisationen bedeutet das nicht, sofort ein großes internes Team aufzubauen. Oft genügt eine kleine, interdisziplinäre Gruppe, ergänzt um externe Expertise für die kritischsten Prüfungen. Entscheidend ist, dass die Menschen, die testen, unabhängig genug von den Menschen sind, die das System gebaut haben – sonst besteht die Gefahr, dass man die eigenen blinden Flecken einfach reproduziert.
Gerade weil Red Teaming bewusst die Angreiferperspektive einnimmt, braucht es verbindliche ethische Leitplanken. Ohne sie droht die Übung, selbst zum Risiko zu werden. Zu den zentralen Regeln defensiven Red Teaming gehören:
Der EU AI Act – die Verordnung (EU) 2024/1689 – verlangt für Hochrisiko-KI-Systeme nach aktuellem Stand unter anderem ein Risikomanagementsystem sowie ein angemessenes Niveau an Genauigkeit, Robustheit und Cybersicherheit. Red Teaming ist zwar nicht in jedem Kontext ausdrücklich als „Red Teaming“ benannt, es liefert aber genau die Art von Nachweis, die für diese Anforderungen relevant ist: strukturierte Tests, die belegen, dass ein System auf Schwachstellen geprüft und gehärtet wurde. Vertiefende Informationen zum Rechtsrahmen finden Sie in unserem Beitrag zum EU AI Act innerhalb dieser Kategorie.
International einflussreich ist das NIST AI Risk Management Framework (AI RMF), ein freiwilliges Rahmenwerk aus den USA, das den verantwortungsvollen Umgang mit KI-Risiken strukturiert. Es organisiert die Arbeit entlang von Funktionen wie dem Erkennen, Messen und Steuern von Risiken sowie einer übergreifenden Governance. Red Teaming lässt sich hier klar verorten: Es ist eine Methode, um KI-Risiken zu identifizieren und zu messen, und liefert damit Eingangsgrößen für das Risikomanagement. Für Unternehmen, die ohnehin ein Managementsystem für KI aufbauen, ist das AI RMF eine hilfreiche Landkarte, in die sich Red Teaming einfügt.
Ähnlich verhält es sich mit Managementnormen wie der ISO/IEC 42001 für KI-Managementsysteme: Sie schreiben kein bestimmtes Testverfahren vor, verlangen aber systematische Risikobetrachtung, Kontrollen und kontinuierliche Verbesserung. Red Teaming ist eine der Praktiken, mit denen sich diese Anforderungen konkret ausfüllen lassen. Wer eine strukturierte KI-Governance betreibt, kann Red Teaming als festen Baustein darin verankern.
Eine Besonderheit ergibt sich für General-Purpose-AI-Modelle (GPAI) – also breit einsetzbare Basismodelle. Für GPAI-Modelle, insbesondere solche mit systemischem Risiko, sieht der EU AI Act nach aktuellem Stand zusätzliche Pflichten vor, etwa zur Modellbewertung und zum Management systemischer Risiken. In diesem Zusammenhang wird adversariales Testen – also Red Teaming – als eine Methode diskutiert, um solche Modelle vor und während ihres Einsatzes auf Risiken zu prüfen. Für die meisten mittelständischen Unternehmen ist jedoch die Perspektive des nachgelagerten Nutzers relevanter: Wer ein GPAI-Modell in eigene Anwendungen integriert, sollte die vom Anbieter bereitgestellten Sicherheitsinformationen auswerten und die eigene Anwendung – nicht das Basismodell selbst – gezielt einem Red Teaming unterziehen.
Viele mittelständische Unternehmen tun sich schwer, ein vollwertiges internes Red Team aufzubauen – und müssen das auch nicht. Ein realistischer Einstieg besteht aus drei Bausteinen. Erstens: eine interne Grundfähigkeit, bei der eine kleine, interdisziplinäre Gruppe die eigenen KI-Anwendungen mit einfachen, strukturierten Tests regelmäßig prüft. Zweitens: externe Expertise für die kritischsten Systeme und für den Aufbau von Methodik, etwa in Form periodischer, tiefergehender Prüfungen. Drittens: eine klare Verankerung in der KI-Governance, damit Red Teaming nicht als einmalige Aktion verpufft, sondern wiederkehrender Bestandteil des KI-Lebenszyklus wird.
Dieser hybride Ansatz verbindet die Stärken beider Welten: das Kontextwissen der eigenen Leute mit dem unvoreingenommenen, spezialisierten Blick von außen. Gerade der Aufbau interner Methodik profitiert davon, wenn erfahrene Externe zunächst zeigen, wie strukturiertes Red Teaming abläuft, und das interne Team anschließend die Routineprüfungen übernimmt.
Externe Unterstützung empfiehlt sich vor allem in drei Situationen. Erstens bei hohem Risiko: Wenn ein KI-System sensible Entscheidungen trifft, personenbezogene Daten in großem Umfang verarbeitet oder in einer regulierten Domäne eingesetzt wird, ist der unabhängige, erfahrene Blick besonders wertvoll. Zweitens beim Kompetenzaufbau: Wenn das eigene Team die Methodik erst lernen soll, ist eine begleitete erste Runde ein effizienter Weg. Drittens bei Nachweisbedarf: Wenn Auftraggeber, Partner oder interne Governance einen unabhängigen Nachweis der KI-Sicherheit verlangen, hat eine externe Prüfung mehr Gewicht als eine reine Selbstprüfung. In diesem Zusammenhang ist Red Teaming eng mit dem Thema KI-Audit verwandt.
Unabhängig von der Wahl gilt: Externe Prüfungen brauchen einen sauberen vertraglichen Rahmen mit Autorisierung, Verschwiegenheit und einer datenschutzkonformen Regelung des Datenzugriffs. Ob und wie personenbezogene Daten im Rahmen einer externen Prüfung verwendet werden dürfen, ist eine Frage des Einzelfalls und sollte mit einer Fachjurist:in geklärt werden – dies ist keine Rechtsberatung.
Der Nutzen von Red Teaming liegt auf der Hand: Es macht Schwachstellen sichtbar, bevor reale Nutzer oder Angreifer sie finden. Es liefert dokumentierte Nachweise für Sorgfalt und Risikomanagement, die für Governance, Auftraggeber und regulatorische Anforderungen relevant sein können. Es stärkt das Vertrauen in KI-Systeme – intern wie extern – und trägt damit unmittelbar zu vertrauenswürdiger KI bei. Und es schafft Lernschleifen: Jeder Fund verbessert nicht nur das getestete System, sondern auch das Verständnis der Organisation für ihre KI-Risiken.
Ebenso wichtig ist es, die Grenzen zu kennen. Red Teaming kann Abwesenheit von Schwachstellen niemals beweisen – es kann nur zeigen, dass bestimmte Schwachstellen gefunden oder nicht gefunden wurden. Ein sauberer Bericht bedeutet nicht, dass ein System sicher ist, sondern dass die durchgeführten Tests keine weiteren Probleme aufgedeckt haben. Zudem ist Red Teaming eine Momentaufnahme: Ein System, das heute robust ist, kann nach einem Modell-Update, einer neuen Datenquelle oder einer geänderten Konfiguration neue Schwächen zeigen. Und schließlich hängt die Qualität stark von den Menschen und Methoden ab – ein oberflächliches Red Teaming vermittelt trügerische Sicherheit.
Daraus folgt kein Argument gegen Red Teaming, sondern ein Argument für seine richtige Einbettung: als wiederkehrender, ehrlich dokumentierter Prozess im Rahmen einer umfassenderen KI-Qualitäts- und Governance-Strategie, nicht als einmaliges Häkchen. Wer die Grenzen offen kommuniziert, verhindert, dass ein bestandenes Red Teaming zur Ausrede für nachlassende Wachsamkeit wird.
Red Teaming berührt den Datenschutz an mehreren Stellen. Zum einen kann Red Teaming selbst mit personenbezogenen Daten in Berührung kommen – etwa wenn Testfälle reale Daten verwenden oder wenn ein System im Test personenbezogene Informationen preisgibt. Zum anderen ist eine der fünf Testdimensionen ausdrücklich der Datenschutz: Red Teaming prüft, ob ein System sensible oder personenbezogene Daten unangemessen offenlegt. In beiden Rollen ist die DSGVO relevant.
Praktisch bedeutet das: Wer Red Teaming durchführt, sollte den Grundsatz der Datenminimierung beachten, wo möglich mit synthetischen oder anonymisierten Testdaten arbeiten, den Zugriff auf reale Daten strikt begrenzen und Funde vertraulich behandeln. Deckt ein Red Teaming auf, dass ein System personenbezogene Daten preisgibt, ist das nicht nur ein technischer Befund, sondern potenziell auch ein datenschutzrechtlich bedeutsames Thema, das entsprechend behandelt werden muss. Ob im konkreten Fall etwa eine Datenschutz-Folgenabschätzung berührt ist oder welche Rechtsgrundlage die Verwendung bestimmter Daten im Test trägt, ist eine Frage des Einzelfalls und sollte fachjuristisch geklärt werden.
