Definition: Ein KI-Incident-Response-Playbook ist ein vorab abgestimmter, schriftlicher Ablaufplan für Sicherheits- und Fehlfunktionsvorfälle an KI-Systemen. Es legt fest, wer bei welchem Vorfalltyp was in welcher Reihenfolge tut, welche technischen Hebel zur Eindämmung bereitstehen und welche Meldepflichten zu prüfen sind. Es ergänzt den allgemeinen Incident-Response-Plan um KI-spezifische Szenarien.
Warum ein eigenes Playbook für KI?
Klassische Notfallpläne gehen von kompromittierten Konten, Schadsoftware oder ausgefallenen Servern aus. Bei KI-Systemen sieht ein Vorfall oft anders aus: Das System läuft technisch einwandfrei, liefert aber schädliche, falsche oder vertrauliche Ausgaben. Ein Chatbot gibt nach einer manipulierten Eingabe interne Preislisten preis, ein KI-Agent verschickt E-Mails, die niemand beauftragt hat, oder ein Modell-Update des Anbieters verändert das Verhalten eines Klassifikators unbemerkt. Ohne vorbereitete Abläufe verliert das Team in solchen Fällen wertvolle Zeit mit der Frage, ob überhaupt ein Sicherheitsvorfall vorliegt.
Typische Vorfallkategorien
| Szenario | Erste Maßnahmen |
|---|---|
| Prompt Injection mit Datenabfluss | Betroffene Funktion oder Datenquelle trennen, Logs sichern, abgeflossene Daten eingrenzen |
| Agent führt unerwünschte Aktionen aus (Excessive Agency) | Tool-Berechtigungen entziehen, ausstehende Aktionen stoppen, Auswirkungen rückgängig machen |
| Manipulierte Wissensbasis (RAG) oder Data Poisoning | Verdächtige Dokumente in Quarantäne, auf letzten geprüften Index zurücksetzen |
| Kompromittierte API-Schlüssel für KI-Dienste | Schlüssel widerrufen, Nutzung und Kosten prüfen, Missbrauch dokumentieren |
| Schädliche oder diskriminierende Ausgaben | Funktion einschränken, menschliche Prüfung vorschalten, Ursache analysieren |
| Deepfake-Betrugsversuch gegen das Unternehmen | Zahlungen stoppen, Rückruf über bekannten Kanal, Beweise sichern |
Aufbau des Playbooks entlang der Vorfallphasen
1. Vorbereitung
- KI-Inventar mit Systemverantwortlichen, Anbieterkontakten und Abhängigkeiten griffbereit halten.
- Technische Notschalter vorsehen: Feature-Flags zum Abschalten einzelner Funktionen, Widerruf von API-Schlüsseln, Rückfall auf eine manuelle Bearbeitung.
- Prompt-, Antwort- und Tool-Logs so konfigurieren, dass sie für eine Analyse ausreichen und lange genug aufbewahrt werden.
- Versionsstände von Modellen, System-Prompts und Vektorindizes sichern, um zurückrollen zu können.
2. Erkennung und Bewertung
Definieren Sie Auslöser: Hinweise von Nutzern, Alarme aus der Überwachung, ungewöhnliche Kosten, Meldungen des Anbieters. Legen Sie Kriterien für den Schweregrad fest, etwa betroffene Daten, Außenwirkung, Anzahl betroffener Personen und ob das System Aktionen ausführen kann.
3. Eindämmung
Ziel ist, den Schaden zu stoppen, ohne Beweise zu vernichten. Oft genügt es, einzelne Werkzeuge oder Datenquellen zu deaktivieren, statt das gesamte System abzuschalten. Sichern Sie vor jeder Änderung den aktuellen Zustand.
4. Beseitigung und Wiederherstellung
Ursache beheben, etwa Eingabefilter und Berechtigungen anpassen, manipulierte Dokumente entfernen oder ein geprüftes Modell wiederherstellen. Vor der Wiederinbetriebnahme mit den ursprünglichen Angriffsmustern testen und die Funktion schrittweise freigeben.
5. Nachbereitung
Lessons Learned dokumentieren, Risikobewertung und Playbook aktualisieren, bei Bedarf Schulungen anpassen.
Meldepflichten prüfen
- DSGVO: Bei einer Verletzung des Schutzes personenbezogener Daten Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33), ggf. Benachrichtigung Betroffener (Art. 34).
- NIS2/BSIG: Für betroffene Einrichtungen bei erheblichen Sicherheitsvorfällen Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht nach einem Monat.
- EU AI Act: Anbieter von Hochrisiko-KI-Systemen müssen schwerwiegende Vorfälle an die Marktüberwachungsbehörde melden (Art. 73); Betreiber informieren in solchen Fällen den Anbieter. Diese Pflichten greifen mit der Anwendbarkeit der Hochrisiko-Regeln – nach dem Digital Omnibus ab 2. Dezember 2027 (Anhang III) bzw. 2. August 2028 (Anhang I).
- Verträge und Versicherung: Informationspflichten gegenüber Kunden und Cyberversicherern beachten.
Praxistipps
- Das Playbook kurz halten: eine Seite pro Szenario mit Checkliste und Kontakten.
- Rollen doppelt besetzen, damit Urlaub oder Krankheit die Reaktion nicht blockieren.
- Mindestens einmal jährlich eine Tabletop-Übung mit einem realistischen KI-Szenario durchführen.
- Den KI-Anbieter einbinden: Klären Sie vertraglich, wie schnell er bei Vorfällen unterstützt und welche Logs er liefern kann.
Fazit
Ein KI-Incident-Response-Playbook sorgt dafür, dass Ihr Team bei einem KI-Vorfall nicht improvisieren muss: klare Szenarien, vorbereitete Notschalter und geprüfte Meldewege. SecTepe unterstützt bei der Erstellung und beim Üben solcher Playbooks sowie im Ernstfall mit Incident Response.
Häufige Fragen
Brauchen wir ein separates Dokument oder eine Ergänzung des bestehenden Notfallplans?
In der Regel genügt eine Ergänzung: Der bestehende Incident-Response-Prozess bleibt der Rahmen, das KI-Playbook liefert die szenariospezifischen Schritte und technischen Hebel.
Wer sollte im KI-Vorfallteam vertreten sein?
Neben IT-Sicherheit mindestens der fachliche Systemverantwortliche, der Datenschutz, bei Außenwirkung die Kommunikation und bei Bedarf die Rechtsabteilung sowie der KI-Anbieter.
Weitere Begriffe in „KI & Machine Learning“
- Adversarial Machine Learning
- AI Poisoning
- AI Red Teaming
- Algorithmic Accountability
- Algorithmic Bias (algorithmische Verzerrung)
- Chatbot-Sicherheit
- DSGVO-konforme KI-Systeme
- Edge AI
- EU AI Act Compliance
- Explainable AI (XAI)
- Federated Learning
- Homomorphe Verschlüsselung (Homomorphic Encryption)