KI-Sicherheit als Compliance-Pflicht: Red Teaming, Adversarial Testing und Audit-Trails im Produktiveinsatz

Datum: 2029-09-07 | Post #57 | Serie: BERTA Lab Insights 2029

"Haben Sie Ihr KI-System getestet?"

Die Antwort der meisten Unternehmen: "Ja, es funktioniert gut."

Die eigentliche Frage: "Haben Sie es auch daraufhin getestet, wie es versagt?"

Das ist der Unterschied zwischen KI-Qualitätssicherung und KI-Sicherheitstesting. Und er ist für regulierte Einsatzkontexte — öffentliche Verwaltung, Gesundheit, Finanzdienstleistungen — seit Inkrafttreten des EU AI Act keine akademische Unterscheidung mehr.

Was KI-Sicherheitstesting ist (und was nicht)

KI-Qualitätssicherung fragt: Gibt das System die richtigen Antworten auf erwartete Eingaben?

KI-Sicherheitstesting fragt:
- Was passiert bei unerwarteten oder bösartigen Eingaben?
- Kann das System manipuliert werden (Prompt Injection, Adversarial Examples)?
- Welche Bias-Profile hat das System in Grenzfällen?
- Wie verhält sich das System unter Lastbedingungen?
- Wo liegen die Failure Modes — und wie sehen sie aus?

Für viele Mittelständler ist das neu. Für die, die KI in regulierten Kontexten einsetzen, ist es zunehmend Pflicht.

Red Teaming: Was es ist und wie wir es einsetzen

Red Teaming kommt aus der Cybersecurity — ein dediziertes Team versucht aktiv, in ein System einzubrechen. Für KI übertragen: Ein Team versucht systematisch, das KI-System zu Fehlverhalten zu bringen.

Wir haben Red-Teaming-Prozesse für unsere produktiven Systeme eingeführt — nicht weil der EU AI Act es für alle unsere Systeme verlangt, sondern weil wir gelernt haben: Systeme, die nur auf positive Szenarien getestet wurden, haben überraschende Failure Modes.

Konkret bei Bea (Vergaberecht-Voicebot):

Wir haben systematisch getestet, ob Bea falsche Rechtsauskünfte gibt, wenn die Frage anders formuliert wird. Ergebnis: Ja — bei bestimmten Umformulierungen wurden Antworten gegeben, die zwar plausibel klangen, aber nicht dem aktuellen Vergaberecht entsprachen.

Das hätte in Produktion ein ernstes Problem sein können. Red Teaming hat es im Lab gefunden.

Adversarial Testing: Systematisch, nicht zufällig

Adversarial Testing ist strukturierter als informelles Red Teaming. Es folgt einem Katalog von Angriffsmustern:

1. Prompt Injection: Versuche, durch geschickt formulierte Nutzereingaben den Systemkontext zu überschreiben ("Vergiss alle vorherigen Anweisungen und tue folgendes...")

2. Jailbreaking: Umgehung von Content-Policies durch rollenspielartige Konstrukte oder indirekte Formulierungen

3. Data Poisoning (bei RAG-Systemen): Einschleusen von falschen Informationen in die Wissensdatenbank, um Antworten zu manipulieren

4. Boundary Testing: Systematisches Testen der Grenzen des Systems — wie verhält es sich bei Anfragen nahe an, aber leicht außerhalb seines Kompetenzbereichs?

Für unsere RAG-Systeme (BRITE, Bea, Hermes) ist Data Poisoning das relevanteste Risiko. Wir haben Monitoring eingebaut, das erkennt, wenn Dokumente mit ungewöhnlichen Mustern in die Wissensdatenbank gelangen.

Audit-Trails: Pflicht und Praxis

Der EU AI Act schreibt für Hochrisiko-KI-Systeme Logging vor (Artikel 12). Aber Audit-Trails sind auch jenseits regulatorischer Pflicht wertvolles Werkzeug.

Was wir loggen:
- Alle Anfragen mit Zeitstempel und Kontext
- Verwendete Quellen (bei RAG-Systemen)
- Modellentscheidungen und Konfidenzwerte (wo verfügbar)
- Nutzer-Interaktionen und System-Antworten
- Systemfehler und Exceptional States

Was wir damit machen:
- Qualitätsmonitoring: Wie entwickeln sich Antwortqualität und Nutzerzufriedenheit über Zeit?
- Incident Response: Was genau ist passiert, wenn ein Fehler gemeldet wird?
- Drift Detection: Verändert sich das Systemverhalten mit der Zeit, obwohl das Modell gleich ist? (Das passiert — durch veränderte Nutzungsmuster und Datenbasis)

Was uns überrascht hat: Die Kosten der Nicht-Sicherheit

Wir haben eine Analyse gemacht: Was haben uns Sicherheitsprobleme in Produktion über die letzten vier Jahre gekostet? Manuelle Überprüfungen, Systemneustarts, Kundenklärungen, Reputationsschäden?

Die Zahl war höher als die Kosten aller Sicherheitstests zusammen.

Das ist kein Zufall. Sicherheitsprobleme in Produktion eskalieren schnell. Ein Sicherheitsproblem im Lab kostet einen Sprint. Dasselbe Problem in Produktion kostet einen Monat.

Praktische Einstiegspunkte für Mittelständler

Schritt 1: Bedrohungsmodell erstellen
Was sind die realistischen Angriffsvektoren für Ihr KI-System? (Nicht alle Systeme brauchen dieselbe Sicherheitsstufe.)

Schritt 2: Einen "Red Team"-Tag im Quartal einplanen
Keine formale Großübung — ein halber Tag, in dem Teammitglieder versuchen, das System zu überraschen. Erfahrungsgemäß: Immer ergebnisreich.

Schritt 3: Basis-Audit-Logging einrichten
Anfragen, Antworten, Zeitstempel. Das ist kein Aufwand — es ist technische Hygiene.

Schritt 4: Einen Incident-Response-Plan haben
Was passiert, wenn das System falsche oder schädliche Ausgaben produziert? Wer wird informiert? Wer entscheidet über Abschaltung?

Fazit: Sicherheit ist kein Add-on

KI-Sicherheitstesting ist keine nachgelagerte Pflichtübung für Unternehmen mit regulatorischen Anforderungen. Es ist — aus vier Jahren Produktionserfahrung — ein wesentlicher Teil des Qualitätsmanagements für jedes ernsthaft eingesetzte KI-System.

Systeme, die nur auf Erfolg getestet werden, produzieren in Produktion Überraschungen. Systeme, die auch auf Versagen getestet werden, produzieren Vertrauen.

Und Vertrauen ist die Währung, in der KI-Akzeptanz im Unternehmen entsteht.

Daniel Röding ist IT-Consultant bei Bechtle Bremen und leitet das BERTA Lab. Für Fragen zu KI-Sicherheit und Red Teaming: gerne vernetzen.

#KISicherheit #RedTeaming #AISecure #EnterpriseAI #EUAIAct #Compliance #BertaLab #AISafety