Incident Response bei KI-Vorfällen

Lernziele

Sie klassifizieren KI-Vorfälle in fünf Kategorien (Qualitätsfehler, Datenschutzvorfall, Sicherheitsvorfall, Compliance-Vorfall, Reputationsvorfall) und geben je ein konkretes Beispiel.

Sie beschreiben die fünf Phasen des KI-Incident-Response-Playbooks (Detect, Contain, Eradicate, Recover, Learn) mit ihren wesentlichen Maßnahmen.

Sie benennen die Rollen im Incident-Response-Prozess (KI-Beauftragte:r, IT, DSB, Geschäftsführung, Fachabteilung).

Sie wenden das Playbook auf ein konkretes Tabletop-Szenario an und identifizieren Sofortmaßnahmen sowie Meldepflichten.

Sie erklären die DSGVO-Meldepflicht nach Art. 33 (72-Stunden-Frist) im KI-Kontext.

Auf einen Blick

Worum geht es?

Es ist ein Dienstagnachmittag. Ein Account-Manager bemerkt, dass der interne Wissens-Assistent ihm auf eine Frage über ein laufendes Projekt detaillierte Informationen zu einem anderen Kundenprojekt ausgegeben hat — inklusive Angebotspreis und Kontaktdaten des Ansprechpartners beim Kunden. Der Account-Manager ist nicht für dieses Projekt zuständig und hätte diese Informationen nicht sehen dürfen.

Was jetzt passiert, entscheidet über Schwere und Konsequenz des Vorfalls. Ein strukturierter Incident-Response-Prozess stellt sicher, dass: (1) das System sofort gesichert wird, (2) die Ursache gefunden und behoben wird, (3) DSGVO-Meldepflichten eingehalten werden und (4) das System nach dem Vorfall besser ist als davor.

Ohne strukturierten Prozess passiert das Gegenteil: Das System läuft weiter und produziert möglicherweise weitere Datenlecks, die Ursache wird nicht systematisch gefunden, die 72-Stunden-Meldefrist nach DSGVO Art. 33 wird verpasst — und der Lerneffekt bleibt aus.

In dieser Lerneinheit erarbeiten Sie ein vollständiges 5-Phasen-Playbook für KI-Vorfälle und üben dessen Anwendung in einer Tabletop Exercise.

Lerntext — Theorie und Konzepte

KI-Vorfalls-Taxonomie — nicht alles ist gleich

Nicht jeder unerwünschte KI-Output ist ein Sicherheitsvorfall. Eine klare Taxonomie hilft bei der Reaktion:

Merksatz

Nicht jeder KI-Fehler ist ein meldepflichtiger Vorfall. Die Klassifizierung bestimmt die Reaktion — Überreaktion ist genauso problematisch wie Unterreaktion.

Das 5-Phasen-Playbook

Angelehnt an NIST Cybersecurity Framework und CERT-Methodik:

Abb. 106.1 — Incident-Response 5-Phasen-Playbook: Rollen und Kommunikationsflüsse

Phase 1 — DETECT (Erkennen)

Wie wird ein KI-Vorfall erkannt?

Automatisches Monitoring-Alert (Kosten-Spike, ungewöhnliche Query-Muster aus UE 104)

Mitarbeitenden-Meldung: „Der Assistent hat mir etwas Seltsames ausgegeben”

Kundenmeldung (besonders kritisch für Reputation)

Audit-Log-Auffälligkeit bei routinemäßiger Prüfung

Notwendig: Ein klarer Meldekanal — z. B. eine dedizierte E-Mail-Adresse (ki-vorfall@organisation.de) oder ein Intranet-Formular. Ohne Meldekanal werden Vorfälle nicht gemeldet.

Phase 2 — CONTAIN (Eindämmen)

Sofortmaßnahmen vor vollständiger Analyse:

KI-System temporär deaktivieren (Kill-Switch — jedes produktive KI-System braucht einen schnellen Deaktivierungsmechanismus)

Zugriff auf betroffene Daten einschränken

Betroffene Nutzer informieren: „System vorübergehend nicht verfügbar — Ursache wird untersucht”

Zeitstempel und erste Beschreibung dokumentieren (für Meldefristen)

Zielzeit: Eindämmung innerhalb von 1–2 Stunden nach Erkennung. Bei Datenschutzvorfällen beginnt die 72-Stunden-Uhr bereits mit dem Erkennen.

Phase 3 — ERADICATE (Ursache beheben)

Root Cause Analysis:

Was hat den Vorfall ausgelöst? (Prompt Injection? Fehler in Systemanweisung? Datenleck im RAG wegen falscher Zugriffssteuerung?)

Systemanweisung nachbessern, Guardrails stärken, Zugriffsrechte korrigieren

Bei Datenschutzvorfall: Welche Daten wurden verarbeitet? Sind betroffene Personen identifizierbar? Umfang des Lecks bestimmen

Phase 4 — RECOVER (Wiederherstellen)

Golden Test-Set durchlaufen nach Behebung (UE 103) — kontrollierter Beweis, dass das Problem gelöst ist

Kontrollierter Wiederanlauf des Systems

Kommunikation an Nutzer: System wieder verfügbar, kurze Erklärung der Ursache und getroffenen Maßnahmen

Bei DSGVO-Relevanz: Meldung an Datenschutzbeauftragte:r prüfen. Bei Datenschutzverletzung mit Risiko für betroffene Personen: Meldepflicht an zuständige Datenschutzaufsichtsbehörde nach Art. 33 (72 Stunden ab Kenntnis). Bei hohem Risiko für Personen: Benachrichtigungspflicht der betroffenen Personen nach Art. 34.

Phase 5 — LEARN (Lernen)

Post-Mortem-Bericht erstellen (intern, 1–2 Seiten): Was ist passiert? Ursache? Reaktion? Was lief gut/schlecht?

Welche Systemänderungen, Prozessänderungen oder Schulungsmaßnahmen folgen?

Playbook aktualisieren und verbessern

Ergebnis im KI-Systemverzeichnis dokumentieren (UE 105)

Falls mehrere Vorfälle ähnlicher Art aufgetreten sind: Strukturelle Maßnahme statt Einzelfall-Behebung

Merksatz

Die 72-Stunden-Frist nach DSGVO Art. 33 beginnt ab dem Zeitpunkt der Kenntnis — nicht erst nach vollständiger Untersuchung. Im Zweifel lieber früher melden und Informationen nachliefern, als die Frist zu verpassen.

DSGVO-Meldepflicht im KI-Kontext

Die DSGVO-Meldepflicht nach Art. 33 greift, wenn eine Datenschutzverletzung vorliegt — das heißt, wenn personenbezogene Daten unrechtmäßig offengelegt, verloren oder unzugänglich gemacht wurden. Im KI-Kontext typisch:

Assistent gibt Kundendaten eines anderen Kunden aus

Personenbezogene Daten aus einem RAG-System werden unbeabsichtigt extrahiert

Memory-Funktion gibt Daten zwischen nicht berechtigten Nutzern weiter

Frist: 72 Stunden ab Kenntnis der Datenschutzverletzung (nicht ab Aufklärung der Ursache). Die Meldung an die zuständige Datenschutzaufsichtsbehörde muss innerhalb dieser Frist erfolgen — auch wenn noch nicht alle Details bekannt sind. Ergänzungen sind nachträglich möglich.

Vertiefung — KI-Incident-Response vs. klassische Cybersecurity-IR

Unterschiede zum klassischen IT-Incident-Response

Das 5-Phasen-Playbook für KI-Vorfälle lehnt sich an bewährte Methoden an (NIST CSF, CERT-Methodik), hat aber wesentliche KI-spezifische Charakteristika:

Nicht-Determinismus der Ursachenanalyse: Bei einem klassischen Sicherheitsvorfall kann ein Angriff oft auf einen einzelnen Exploit zurückgeführt werden. Bei KI-Vorfällen ist die Root Cause oft schwerer zu isolieren: War es die Systemanweisung, das Modell, der RAG-Kontext oder ein Zusammenspiel mehrerer Faktoren?

Eingeschränkte Reproduzierbarkeit: In der klassischen IT wird ein Exploit so lange reproduziert, bis er vollständig verstanden ist. Bei KI-Systemen ist exakte Reproduzierbarkeit nicht immer möglich — das Modell verhält sich probabilistisch, und der exakt gleiche Prompt kann beim nächsten Aufruf eine andere Antwort produzieren.

Erklärbarkeit gegenüber Betroffenen: Bei einem KI-Assistent, der versehentlich vertrauliche Daten ausgegeben hat: Welche Daten wurden genau ausgegeben? Wie wurde die Ausgabe vom Nutzer weiterverwendet? Diese Fragen sind häufig schwerer zu beantworten, wenn keine vollständige Protokollierung vorhanden ist.

Lesson: Logging ist für KI-Incident-Response noch wichtiger als in der klassischen IT. Ohne vollständige Protokollierung der Eingaben und Ausgaben ist Phase 3 (Eradicate) kaum durchführbar.

Präventive Maßnahmen: Vor dem Vorfall planen

Die effektivste Incident-Response ist die, die nie ausgeführt werden muss. Drei Präventiv-Maßnahmen gehören zur Baseline-Architektur jedes KI-Systems:

1. Vollständiges Logging: Alle Eingaben und Ausgaben werden mit Zeitstempel, Nutzer-ID und Session-ID protokolliert. Aufbewahrungsfrist: mindestens 90 Tage. Datenschutzkonformes Logging: Logs werden verschlüsselt gespeichert und der Zugriff ist auf autorisierte Personen beschränkt.

2. Kill-Switch-Mechanismus: Jedes produktive KI-System hat einen dokumentierten Deaktivierungsweg — typischerweise: API-Key deaktivieren im Anbieter-Dashboard oder Feature-Flag im eigenen System setzen. Dieser Weg muss in unter 5 Minuten ausführbar sein und in der Incident-Response-Checkliste dokumentiert sein.

3. Zugriffssteuerung auf Dateiebene im RAG-System: Das häufigste Datenleck-Szenario bei RAG-Systemen ist, dass Nutzer ohne Berechtigung auf Dokumente zugreifen, weil das RAG-System keine Zugriffssteuerung auf Dokumentenebene implementiert. Jedes Dokument in der Wissensbasis sollte Tags für die berechtigten Nutzergruppen haben, die vor der Ausgabe geprüft werden.

Kommunikationsmanagement im Incident Response

Neben dem technischen Playbook ist professionelles Kommunikationsmanagement ein oft vernachlässigter Erfolgsfaktor:

Eine vorbereitete Kommunikationsvorlage für den Worst Case ist genauso wichtig wie das technische Playbook. Fehler in der Kommunikation — zu langsam, zu technisch, oder inkonsistente Botschaften — können den Schaden erheblich vergrößern.

Erweiterte Tabletop-Fallstudie

Das folgende erweiterte Tabletop-Szenario gibt einen exemplarischen Ablauf des vollständigen 5-Phasen-Playbooks:

Szenario: Datenleck im RAG-Assistenten

Ein Account-Manager nutzt den internen Wissens-RAG-Assistenten. Die Antwort enthält nicht nur Informationen zu seinem eigenen Projekt, sondern auch Details aus einem Angebot für Kunde B — inklusive Angebotspreis und Name des Ansprechpartners. Der Account-Manager hat keinen Zugriff auf Projekte von Kunde B.

15:35 Uhr (Detect): Account-Manager meldet den Vorfall über den Meldekanal.

15:45 Uhr (Contain): KI-Beauftragte:r deaktiviert den API-Key. System offline. Rundmail an alle Nutzer: System vorübergehend nicht verfügbar. Screenshot der Ausgabe gesichert. Die 72-Stunden-Frist nach Art. 33 beginnt ab diesem Zeitpunkt.

16:30 Uhr (Eradicate — erste Analyse): IT prüft RAG-Konfiguration. Befund: Dokumente verschiedener Projekte befinden sich in einem gemeinsamen Vektorspeicher ohne Zugriffssteuerung auf Dokumentenebene. Root Cause: Fehlende Row-Level Security im Vektorspeicher.

Tag 2, 09:00 Uhr (Eradicate — Behebung): IT implementiert Nutzer-scoped Retrieval mit Berechtigungs-Tags.

Tag 2, 11:00 Uhr (Recover): Golden Test-Set wird ausgeführt — alle Tests bestanden. System wird wieder aktiviert.

Tag 2, 16:00 Uhr (Meldung an Behörde): Online-Meldung bei der zuständigen Datenschutzaufsichtsbehörde. Inhalt: Beschreibung des Vorfalls, Datenkategorien, Anzahl betroffener Personen, getroffene Maßnahmen.

Tag 3 (Kundeninformation): Telefonat mit Kunde B — transparente Information über den Vorfall und die getroffenen Maßnahmen.

Tag 5 (Post-Mortem): Systemänderung: Row-Level Security als Standard-Architekturprinzip. Prozessänderung: Neue Checkliste für RAG-Konfigurationen. KI-Systemverzeichnis aktualisiert.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

In IT-Dienstleistungsunternehmen können KI-Vorfälle in eigenen internen Systemen und in Systemen, die für Kunden betrieben werden, auftreten. Die Incident-Response muss beide Szenarien abdecken — mit klarer Unterscheidung, wer bei einem Kundenvorfall wen informiert.

Vignette: Ein IT-Beratungsunternehmen betreibt für einen Kunden einen dokumentenbasierten Wissensassistenten. Ein Mitarbeiter des Kunden meldet, dass der Assistent interne Dokumente eines anderen Kundenprojekts ausgegeben hat. Die Incident-Response-Kette aktiviert sich: Das Beratungsunternehmen deaktiviert das System, informiert den Kunden, startet die Root-Cause-Analyse. Da es sich um personenbezogene Daten handelt (Mitarbeiterdaten in den Dokumenten), wird der Datenschutzbeauftragte einbezogen und eine DSGVO-Meldung vorbereitet. Entscheidend: Das Beratungsunternehmen als Auftragsverarbeiter hat eine Meldepflicht gegenüber dem Kunden als Verantwortlichem — der Kunde entscheidet dann über die Meldung an die Aufsichtsbehörde.

Industrie & Fertigung

In Fertigungsunternehmen können KI-Vorfälle Produktionsprozesse betreffen — mit potenziell physischen Konsequenzen. Ein fehlerhafter Wartungshinweis eines KI-Assistenten kann eine Sicherheitsgefahr darstellen.

Vignette: Ein Produktionsleiter meldet, dass der KI-Wartungsassistent für eine bestimmte Maschinentype einen Wartungsschritt mit einem veralteten Grenzwert ausgegeben hat — der tatsächliche Grenzwert wurde in einem neueren Sicherheitsupdate geändert. Das ist kein Datenschutzvorfall, aber ein Sicherheitsvorfall mit potenziellem physischen Risiko. Der Assistent wird sofort deaktiviert, die Wissensbasis wird auf veraltete Grenzwerte durchsucht und aktualisiert. Das Ereignis fließt als neuer Testfall ins Golden Test-Set ein: „Sicherheitsrelevante Grenzwerte immer aus der aktuellsten Quelle beziehen.”

Finanzdienstleistung & Versicherung

Im Finanzsektor kann ein KI-Vorfall regulatorische Konsequenzen haben. DORA verlangt, dass Finanzinstitute wesentliche Vorfälle mit IT-Drittanbietern an die zuständige Behörde melden — das umfasst auch KI-Anbieter.

Vignette: Eine Bank bemerkt über ihr Monitoring-System, dass ein KI-Assistent für Kundenbetreuer in einem kurzen Zeitfenster ungewöhnlich hohe API-Kosten verursacht hat — ein Hinweis auf eine mögliche Prompt-Injection-Attacke, die das Modell zu langen, ressourcenintensiven Ausgaben veranlasst hat. Die Incident-Response-Kette wird aktiviert: System offline, Logs analysiert, API-Key rotiert. Ergebnis: Eine gezielte Injection hatte das System zu einem „Infinity-Loop” in der Ausgabe veranlasst. DORA-Meldeformular wird ausgefüllt — die zuständige Behörde wird über den Sicherheitsvorfall informiert.

Öffentliche Verwaltung

In der öffentlichen Verwaltung können KI-Vorfälle besondere Transparenzpflichten auslösen. Behörden sind im Rahmen des Informationsfreiheitsgesetzes verpflichtet, Informationen über KI-Vorfälle auf Anfrage herauszugeben.

Vignette: Eine Bundesbehörde setzt einen KI-Assistenten für die automatische Vorkategorisierung eingehender Anträge ein. Ein Sachbearbeiter stellt fest, dass der Assistent Anträge aus einer bestimmten Region systematisch einer niedrigeren Prioritätsstufe zuordnet — ohne erkennbaren sachlichen Grund. Das ist ein Compliance-Vorfall: mögliche algorithmische Diskriminierung. Das System wird sofort pausiert. Die Behörde informiert den Datenschutzbeauftragten und leitet eine interne Prüfung ein. Ergebnis: Ein Trainingsdaten-Bias im Basis-Modell führte zu geografischer Ungleichbehandlung. Das Modell wird durch ein alternatives Modell ersetzt. Der Vorfall wird im Jahresbericht der Behörde transparent kommuniziert.

Warnung — Sicherheitsrisiken

OWASP LLM Top 10 — Incident-Response-Relevanz:

LLM01 — Prompt Injection: Die häufigste Angriffsform auf KI-Systeme im Unternehmenskontext. Ein manipulierter Input (direkt vom Nutzer oder indirekt über verarbeitete Dokumente) kann das System dazu bringen, Systemanweisungen zu ignorieren, vertrauliche Daten auszugeben oder unerwünschte Aktionen auszuführen. Im Incident-Response: Sofortiger Systemstopp, Log-Analyse auf Injection-Muster, Guardrail-Stärkung.

LLM06 — Sensitive Information Disclosure: Ein KI-System gibt versehentlich sensible Informationen aus — das klassische Datenleck-Szenario. In RAG-Systemen: unzureichende Zugriffssteuerung auf Dokumentenebene. In Memory-Systemen: Daten aus vorherigen Sitzungen werden an neue Nutzer weitergegeben. Im Incident-Response: Umfang des Lecks quantifizieren, DSGVO-Meldepflicht prüfen.

Data Leakage durch unvollständiges Logging: Ohne vollständige Protokollierung (Eingaben, Ausgaben, Zeitstempel, Nutzer-ID) ist die Phase 3 des Playbooks (Eradicate) praktisch nicht durchführbar. Logging ist die Grundvoraussetzung für jeden Incident-Response-Prozess.

Handlungsprinzip: Jedes produktive KI-System braucht drei Dinge: vollständiges Logging, einen definierten Meldekanal, und einen Kill-Switch. Diese drei Elemente müssen vor dem Go-Live vorhanden sein — nicht erst im Krisenfall.

Übung 1 — Vorfalls-Klassifizierung

Aufgabe: Sie klassifizieren fünf Vorfallsbeschreibungen und leiten die Priorität und erste Maßnahme ab.

Material: Vorfalls-Taxonomie-Tabelle (oben).

Schritt-für-Schritt:

Lesen Sie die fünf Szenarien.

Klassifizieren Sie jeden Vorfall nach der Taxonomie.

Bestimmen Sie die Priorität (Kritisch / Hoch / Mittel / Niedrig).

Formulieren Sie die wichtigste erste Maßnahme.

Prüfen Sie: Besteht eine DSGVO-Meldepflicht?

Szenarien: (A) Der Angebots-Assistent erstellt eine Tabelle mit einem falschen Preis. (B) Ein Mitarbeiter bemerkt, dass der Wissens-Assistent seinen eigenen Systemprompt ausgegeben hat. (C) Der Assistent nennt den vollständigen Namen und die Telefonnummer eines anderen Kunden. (D) Ein Red-Teamer meldet, dass er durch einen Jailbreak auf interne Kalkulationen zugegriffen hat. (E) Der Assistent generiert auf eine HR-Anfrage hin einen Text mit diskriminierendem Inhalt.

Zeitrahmen: 10 Minuten Einzelarbeit oder Gruppen

Musterlösung Übung 1:

Übung 2 — Tabletop Exercise

Aufgabe: Sie bearbeiten das Eingangs-Szenario (Assistent gibt Kundendaten eines anderen Kunden aus) im Team durch alle 5 Phasen des Playbooks.

Schritt-für-Schritt:

Rollen zuweisen: KI-Beauftragte:r, IT-Security, Datenschutzbeauftragte:r, meldende Person, Geschäftsführung.

Phase 1 DETECT: Wie wurde der Vorfall entdeckt? Wer informiert wen? Was wird dokumentiert?

Phase 2 CONTAIN: Was sind die ersten drei Sofortmaßnahmen? Wer führt sie aus? In welchem Zeitrahmen?

Phase 3 ERADICATE: Was sind die zwei wahrscheinlichsten Root Causes? Welche Tests werden durchgeführt?

Phase 4 RECOVER: Was muss erfüllt sein, bevor das System wieder live geht? Liegt eine DSGVO-Meldepflicht vor?

Phase 5 LEARN: Welche Systemänderung und welche Prozessänderung folgen?

Zeitrahmen: 20 Minuten Gruppen-Tabletop (4–5 Personen), 10 Minuten Plenumspräsentation

Musterlösung Übung 2 (Auszug Phase 2): Sofortmaßnahmen: (1) API-Key des RAG-Assistenten deaktivieren — System offline setzen. (2) Betroffene Nutzergruppe informieren: „System vorübergehend nicht verfügbar.” (3) Screenshot/Log der problematischen Ausgabe sichern und mit Zeitstempel versehen. Zeitrahmen: Alle drei Maßnahmen innerhalb von 60 Minuten nach Meldung. Zuständig: IT-Security führt aus, KI-Beauftragte:r koordiniert.

Cheat-Sheet — Incident Response Kurzreferenz

5 Phasen: Detect → Contain → Eradicate → Recover → Learn

72-Stunden-Frist (DSGVO Art. 33): - Beginnt ab Kenntnis — nicht ab Abschluss der Untersuchung - Lieber früh melden und Informationen nachliefern

Drei Vorraussetzungen vor Go-Live: 1. Vollständiges Logging (Eingaben, Ausgaben, Zeitstempel, Nutzer-ID) 2. Meldekanal (ki-vorfall@organisation.de oder Formular) 3. Kill-Switch (API-Key-Deaktivierung in < 5 Min. möglich)

Vorfalls-Klassifizierung: - Qualitätsfehler → niedrig, kein Meldepflicht - Datenschutzvorfall → hoch, DSGVO Art. 33 prüfen - Sicherheitsvorfall → kritisch, sofortige Eindämmung - Compliance-Vorfall → hoch, Rechtsberatung - Reputationsvorfall → situativ, Kommunikation einbeziehen

Rollen: KI-Beauftragte:r (koordiniert) + IT (technisch) + DSB (Datenschutz) + GF (bei Schwere Vorfällen)

Post-Mortem: Pflicht nach jedem Vorfall — schriftlich, blameless, 1–2 Seiten

Prompt-Vorlage — Incident-Response-Playbook für KI-Sicherheitsvorfälle erstellen

Prompt für einen KI-Assistenten:

„Ich entwickle ein Incident-Response-Playbook speziell für KI-Sicherheitsvorfälle in unserem Unternehmen. Wir setzen intern drei KI-Systeme ein: einen Wissensassistenten, ein E-Mail-Klassifizierungssystem und einen Code-Review-Assistenten.

Erstelle ein praxistaugliches Incident-Response-Playbook für KI-Vorfälle mit folgenden Bausteinen:

1. Vorfallsklassifikation (3 Schweregrade mit konkreten Beispielen): - Schweregrad 1 (Kritisch): Sofortmaßnahmen erforderlich — Beispiele aus unserem KI-Kontext - Schweregrad 2 (Erhöht): Maßnahmen innerhalb von 4 Stunden — Beispiele - Schweregrad 3 (Normal): Maßnahmen im nächsten Arbeitstag — Beispiele

2. Sofortmaßnahmen bei Schweregrad 1 (detaillierte Schritt-für-Schritt-Anleitung): Was tue ich in den ersten 30 Minuten? Wer wird informiert? Wie dokumentiere ich?

3. DSGVO-Meldepflicht-Prüfung: Wann löst ein KI-Vorfall die 72-Stunden-Meldepflicht nach DSGVO Art. 33 aus? Checkliste mit Ja/Nein-Fragen.

4. Kommunikationsvorlagen: Interne Erstmeldung (an IT und Geschäftsführung), externe Meldung (an Datenschutzbehörde, falls erforderlich)

5. Post-Incident-Review: Welche Fragen werden nach jedem Vorfall gestellt? Wie fließen Erkenntnisse in die Systemverbesserung ein?

Ton: Operativ, klar, für technische und nicht-technische Mitarbeitende lesbar. Maximale Länge: 800 Wörter.”

Erwartetes Ergebnis: Ein einsatzbereites Playbook-Dokument, das als Anhang zur KI-Governance-Dokumentation geführt und im Ernstfall ohne Vorbereitung angewendet werden kann.

Reflexionsfragen

Welche der fünf Vorfalls-Kategorien ist für Ihre Organisation angesichts der genutzten KI-Systeme am wahrscheinlichsten — und wie ist man darauf vorbereitet?

Die 72-Stunden-Frist für die DSGVO-Meldung beginnt ab Kenntnis. Ab welchem Moment im Eingangs-Szenario beginnt die Frist?

Ein Mitarbeiter meldet einen möglichen KI-Vorfall, ist aber unsicher, ob es wirklich einer ist. Wie soll die Organisation damit umgehen?

Warum ist ein Post-Mortem-Bericht nach einem KI-Vorfall wichtig — auch wenn der Vorfall intern geblieben ist und kein externer Schaden entstanden ist?

Wie integrieren Sie den KI-Incident-Response-Prozess in bestehende IT-Security-Prozesse in Ihrer Organisation?

Welche drei Präventivmaßnahmen haben das beste Kosten-Nutzen-Verhältnis für KI-Incident-Prevention?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing: 45 Min — Empfohlene Aufteilung: 15 Min Input (Taxonomie + 5-Phasen-Playbook + DSGVO Art. 33), 20 Min Übung 2 (Tabletop Exercise), 10 Min Auswertung.

Methodische Empfehlung: Die Tabletop Exercise ist die methodisch stärkste Übung in diesem Modul. Rollen konsequent vergeben — wer KI-Beauftragter ist, darf nicht gleichzeitig den Datenschutzbeauftragten spielen. Die Rollentrennung macht die Koordinationsherausforderung in einem echten Incident greifbar. Ideal: 4–5 Personen pro Gruppe.

Stolpersteine: - „72 Stunden ist viel Zeit”: Darauf eingehen, dass die Untersuchung innerhalb dieser Zeit kaum vollständig abgeschlossen ist — die Meldung erfolgt mit vorläufigen Informationen. Es ist besser, eine unvollständige Meldung rechtzeitig abzugeben, als eine vollständige Meldung zu spät. - „Wir haben einen IT-Security-Prozess, der reicht”: KI-spezifische Aspekte einbringen — insbesondere den Nicht-Determinismus bei der Root-Cause-Analyse und die OWASP-LLM-Spezifika (Injection, Disclosure), die in klassischen IT-Security-Playbooks nicht abgedeckt sind. - Kill-Switch-Skepsis: „Das Abschalten kostet uns Produktivität.” Darauf eingehen: Unbeabsichtigte Datenlecks, die weiterlaufen, kosten mehr als eine Stunde Systemausfall.

Diskussionsfragen: 1. Haben Sie in Ihrer Organisation bereits einen Meldekanal für KI-Vorfälle? Wenn nein: Was würde es kosten, einen einzurichten? 2. Wer ist in Ihrer Organisation für die DSGVO-Meldung bei einem KI-Datenleck verantwortlich? 3. Welche der drei Präventivmaßnahmen (Logging, Meldekanal, Kill-Switch) fehlt am ehesten?

Tafelbild:

KI-INCIDENT-RESPONSE — 5 PHASEN



1. DETECT 2. CONTAIN 3. ERADICATE

Monitoring- Kill-Switch Root Cause

Alert oder aktivieren Analysis

Mitarbeiter- Nutzer Guardrails

Meldung informieren stärken



4. RECOVER 5. LEARN

Golden Test-Set Post-Mortem

durchlaufen Playbook

Kontrollierter aktualisieren

Wiederanlauf KI-Verzeichnis

DSGVO-Meldung aktualisieren

(wenn nötig)

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Fokus auf 5-Phasen-Playbook und Vorfalls-Taxonomie; Übung 1 (Klassifizierung) ist niedrigschwellig. - Power-User: Vertiefung mit DORA-Meldeanforderungen, technischen Details zur Row-Level Security in RAG-Systemen, automatisierter Anomalie-Erkennung im Monitoring.

Materialliste: - Incident-Response-Checkliste (alle 5 Phasen mit Checkboxen, druckbar) - Rollenkarten für Tabletop Exercise (KI-Beauftragter, IT-Security, DSB, Meldender, GF) - Kontaktdaten der zuständigen Datenschutzaufsichtsbehörde

Übergang zur nächsten UE: UE 107 behandelt die Rolle der KI-Beauftragten. Brückenformulierung: „In jeder Phase des Incident-Response-Prozesses haben wir eine Rolle immer wieder gesehen: die der KI-Beauftragten. UE 107 klärt, was diese Rolle genau umfasst, welche Kompetenzen sie braucht — und wie sie in Ihrer Organisation verankert werden kann.”

Tipp zur Branchenauswahl: Für Finanzgruppen: DORA-Meldepflichten als Erweiterung des DSGVO-Frameworks einführen. Für Industriegruppen: physische Sicherheitsimplikationen von fehlerhaften KI-Ausgaben betonen. Für Verwaltungsgruppen: Transparenzpflicht und Informationsfreiheitsgesetz als zusätzliche Kommunikationsebene einbeziehen.

Vertiefung II — Reifegrade des KI-Incident-Response: Von der Reaktion zur Prävention

Maturity-Modell für KI-Incident-Response

Incident-Response-Fähigkeiten entwickeln sich nicht über Nacht. Ein Maturity-Modell hilft Organisationen, ihren aktuellen Stand einzuschätzen und den nächsten Schritt zu definieren:

Stufe 0 — Keine Strukturen: Vorfälle werden ad hoc behandelt. Kein Meldekanal, kein Playbook, kein Logging. Reaktion hängt von den zufällig anwesenden Personen ab.

Stufe 1 — Grundstruktur: Meldekanal existiert (E-Mail-Adresse oder Formular). Ein einfaches 5-Phasen-Playbook ist dokumentiert. Logging ist eingerichtet, aber nicht systematisch ausgewertet. Die 72-Stunden-Frist ist bekannt.

Stufe 2 — Geübte Strukturen: Das Playbook wurde mindestens einmal in einer Tabletop Exercise durchgespielt. Rollen sind klar benannt und bekannt. DSGVO-Meldeprozess ist geübt. Post-Mortem-Kultur beginnt zu entstehen.

Stufe 3 — Proaktive Prävention: Monitoring-System löst automatisch Alerts aus. Logging wird regelmäßig auf Muster ausgewertet. Red-Teaming-Übungen werden durchgeführt (UE 98). Jedes neue KI-System wird vor Go-Live mit dem Incident-Response-Playbook abgeglichen.

Stufe 4 — Kontinuierliche Verbesserung: Post-Mortem-Ergebnisse fließen systematisch in die Systemarchitektur ein. Branchenweites Austauschformat mit anderen Organisationen. Automatisierte Anomalie-Erkennung mit Alerting-Integrationen.

Die meisten Organisationen zu Beginn ihrer KI-Governance befinden sich auf Stufe 0 oder 1. Das Ziel dieser Schulung ist Stufe 1 zu Stufe 2.

Forensische Spurensicherung bei KI-Vorfällen

Ein oft übersehener Aspekt: Wenn ein KI-Vorfall passiert, muss nicht nur das System gesichert, sondern auch die Beweise für eine spätere Analyse und mögliche rechtliche Verwendung gesichert werden.

Digitale Forensik bei KI-Vorfällen umfasst:

Logs sichern: Unmittelbar nach der Erkennung eines Vorfalls werden Logs in unveränderlicher Form gespeichert (Read-only-Kopie, zeitgestempelt). Logs, die regelmäßig überschrieben werden, können innerhalb von Stunden verloren gehen.

Eingabe-Ausgabe-Paare sichern: Der exakte Prompt und die exakte Antwort des KI-Systems werden dokumentiert — inklusive Zeitstempel und Nutzer-ID (pseudonymisiert, wenn personenbezogen).

Systemzustand dokumentieren: Welche Version des Modells lief zum Zeitpunkt des Vorfalls? Welche Systemanweisung war aktiv? Welche RAG-Dokumente waren im Index?

Chain of Custody: Wer hat auf die gesicherten Daten zugegriffen? Diese Dokumentation ist für rechtliche Auseinandersetzungen wichtig.

Diese forensische Dokumentation ermöglicht im Nachgang eine präzise Root-Cause-Analyse und ist bei DSGVO-Meldungen hilfreich, um den genauen Umfang des Datenlecks zu quantifizieren.

Das Blameless Post-Mortem als Kulturinstrument

Aus der Site-Reliability-Engineering-Praxis (Google, Netflix) stammt das Konzept des Blameless Post-Mortem: Eine Nachbesprechung nach einem Vorfall, die keine Schuldigen sucht, sondern systematische Ursachen analysiert.

Warum Blameless? Wenn Mitarbeitende fürchten, nach einem Vorfall persönlich schuldig gesprochen zu werden, werden Vorfälle nicht gemeldet. Oder sie werden kleingeredet. Oder die Ursachenanalyse bleibt oberflächlich, um niemanden zu belasten. Das Ergebnis: Das System verbessert sich nicht.

Struktur eines Blameless Post-Mortem (KI-spezifisch):

Zeitstrahl des Vorfalls: Was ist wann passiert? (Faktenbasiert, ohne Wertung)

Impact-Beschreibung: Was war der messbare Schaden? (Datenkategorien, Nutzeranzahl, Systemausfall-Dauer)

Root-Cause-Analyse: Was war die technische Ursache? (Nicht: Wer hat einen Fehler gemacht)

Contributing Factors: Welche Faktoren haben den Vorfall begünstigt oder verschlimmert? (Unzureichendes Logging? Fehlende Zugriffssteuerung?)

Action Items: Konkrete Systemänderungen, Prozessänderungen, Trainingsmaßnahmen — mit Verantwortlichen und Deadlines.

Was gut funktioniert hat: Explizite Würdigung der Maßnahmen, die effektiv waren.

Kulturelles Signal: Ein Post-Mortem, das im nächsten Team-Meeting geteilt wird und in die Wissensbasis einfließt, signalisiert: Sie lernen aus Fehlern und verbessert sich die Organisation dadurch — nicht indem Schuldige gesucht werden.

Regulatorische Meldepflichten im Überblick

Neben der DSGVO Art. 33 gibt es in spezifischen Sektoren weitere Meldepflichten, die bei KI-Vorfällen relevant werden können:

Für Organisationen, die unter NIS2 oder DORA fallen, sind KI-Vorfälle potenziell unter mehreren Regelwerken meldepflichtig — mit unterschiedlichen Fristen. Diese Parallelität muss im Incident-Response-Playbook abgebildet sein. Die schnellste Frist ist immer maßgeblich.

Merksatz

In regulierten Sektoren wie Finanz oder kritischer Infrastruktur können bei einem KI-Vorfall mehrere Meldepflichten mit unterschiedlichen Fristen gleichzeitig ausgelöst werden. Das Playbook muss alle relevanten Regelwerke abdecken — die kürzeste Frist bestimmt den Takt.

Praxis: Aufbau eines internen KI-Vorfalls-Lernregisters

Jenseits des Einzelfall-Post-Mortems empfiehlt sich ein aggregiertes Vorfalls-Lernregister: Eine interne Wissensbasis, die alle aufgetretenen Vorfälle (auch kleine Qualitätsfehler) strukturiert dokumentiert und für die Weiterentwicklung des Systems zugänglich macht.

Felder im Lernregister: - Datum und Kurzbeschreibung - Vorfalls-Kategorie (aus der Taxonomie) - Betroffenes System - Root Cause (aus dem Post-Mortem) - Getroffene Maßnahme - Neuer Testfall im Golden Test-Set? (Ja/Nein, Testfall-ID) - Playbook-Update? (Ja/Nein, Version)

Dieses Register ist das institutionelle Gedächtnis der KI-Incident-Response. Es verhindert, dass dieselbe Schwachstelle zweimal ausgenutzt wird, und ist ein wertvolles Werkzeug beim Onboarding neuer KI-Beauftragter.

Vertiefung II — Strategische Ebene — Sonderfall: KI-gestützte Desinformation als Incident-Typ

Wenn das eigene KI-System zur Desinformations-Quelle wird

Ein zunehmend relevanter Incident-Typ, der in klassischen Incident-Response-Playbooks noch selten vorkommt: Ein KI-System generiert Inhalte, die sachlich falsch sind und — wenn weitergeleitet — zu Desinformation führen. Besonders kritisch, wenn diese Inhalte: - Regulatory-relevante Informationen betreffen (falsche Rechtsauskunft, falsche medizinische Information) - In Kundenkommunikation einfließen - In Berichte oder Analysen eingehen, die als verlässlich gelten

Dieser Incident-Typ ist ein Qualitätsfehler mit potenziell hoher Schadwirkung — nicht zwingend ein Datenschutzvorfall, aber ein Vertrauensvorfall.

Spezifische Maßnahmen: - Sofortige Rückholung der fehlerhaften Kommunikation (soweit möglich) - Proaktive Korrektur-Kommunikation an betroffene Empfänger - Root-Cause: War die Systemanweisung unklar über Qualitätsgrenzen? War das Modell-Wissen veraltet (Trainingsdaten-Cutoff)? Fehlender Human-in-the-Loop vor Versand? - Playbook-Ergänzung: Desinformations-Incidents als eigene Kategorie aufnehmen

Vertiefung IV — Prävention durch Architektur: Security by Design für KI-Systeme

Das OWASP-LLM-Threat-Model in der Systemarchitektur

Bevor ein KI-System entwickelt oder deployed wird, lohnt ein strukturiertes Threat-Modeling nach dem OWASP-LLM-Framework. Die zehn OWASP-LLM-Risikokategorien werden als Checkliste durchgearbeitet:

Dieses Threat-Model wird vor der Produktivsetzung dokumentiert und mindestens jährlich aktualisiert. Es ist Teil des Incident-Prevention-Konzepts — weil es zeigt, gegen welche Angriffsszenarien Gegenmaßnahmen getroffen wurden.

Das Prinzip der minimalen Exposition

Jede unnötige Exposition eines KI-Systems ist ein unnötiges Risiko. Praktische Umsetzung des Minimal-Exposition-Prinzips:

Kein direkter Internet-Zugang für das KI-System, sofern nicht ausdrücklich erforderlich

Kein direkter Datenbankzugriff, sofern nicht ausdrücklich erforderlich — stattdessen gefilterte Abfragen über eine definierte API

Minimale Systemberechtigungen: Das KI-System darf nur die Ressourcen ansprechen, die für seinen Einsatzzweck unmittelbar notwendig sind

Session-Isolation: Jede Nutzersitzung ist vollständig von anderen Sitzungen isoliert (kein Durchsickern von Session-Daten)

Diese Prinzipien reduzieren die Angriffsfläche und damit die Wahrscheinlichkeit eines erfolgreichen Incidents — unabhängig davon, wie gut das Incident-Response-Playbook ist.

Incident Response und KI-Versicherungen: Ein aufkommender Markt

Seit 2023 bieten erste Versicherungsgesellschaften spezifische KI-Haftpflicht- und KI-Betriebsunterbrechungs-Policen an. Für Organisationen, die kritische Prozesse auf KI-Systeme stützen, ist diese Möglichkeit eine Ergänzung zum technischen Incident-Response-Playbook.

Was KI-Versicherungen typischerweise abdecken: - Haftpflicht für Schäden durch fehlerhafte KI-Ausgaben (z. B. falsche medizinische oder rechtliche Auskünfte) - Betriebsunterbrechungskosten bei Ausfall eines KI-Systems - Kosten der DSGVO-Compliance nach einem Datenleck (Anwaltskosten, Behördenkommunikation)

Voraussetzung für Versicherbarkeit: Die Versicherer verlangen typischerweise Nachweise über implementierte Governance-Maßnahmen — Nutzungsrichtlinie, Vendor Assessments, Logging, Incident-Response-Playbook. Wer die Governance-Hausaufgaben aus Modul 9 gemacht hat, ist in einer deutlich besseren Verhandlungsposition für KI-Versicherungen.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.