Vorfallmanagement fuer KI-Systeme
Wenn es passiert: KI-Sicherheitsvorfaelle erkennen, eindaemmen und aufarbeiten — mit Playbooks und Eskalationsstufen.
Premium-Kursinhalt
Diese Lektion gehört zu einem Premium-Kurs. Upgrade auf Pro, um alle Premium-Kurse und Inhalte freizuschalten.
- Zugang zu allen Premium-Kursen
- 1000+ KI-Skill-Vorlagen inklusive
- Jede Woche neue Inhalte
🔄 Kurzer Rueckblick: In Lektion 5 hast du dein ISMS um KI-spezifische Controls erweitert — ISO 27001 Mapping und ISO 42001 Ergaenzung. Jetzt geht es um den Ernstfall: Was tun, wenn ein KI-Sicherheitsvorfall eintritt?
Es passiert. Trotz aller Massnahmen wird ein KI-System kompromittiert — ein Chatbot leakt Daten, ein Modell wurde vergiftet, ein Angreifer extrahiert dein proprietaeres Modell. Was jetzt?
Warum KI-Vorfaelle anders sind
| Klassischer IT-Vorfall | KI-Sicherheitsvorfall |
|---|---|
| Klare Ursache (Bug, Fehlkonfiguration) | Drei parallele Ursachenkategorien |
| Patch schliesst die Luecke | Modell-Retrain noetig (Tage bis Wochen) |
| Eindeutige Anomalie-Erkennung | Schwer erkennbare Manipulation |
| Statischer Schaden (Daten weg) | Dynamischer Schaden (Modell produziert weiter falsche Ausgaben) |
| Forensik: Logs, Netzwerkverkehr | Forensik: + Modellverhalten, Trainingsdaten, Eingabemuster |
KI-Incident-Response: 6-Phasen-Modell
Phase 1: Erkennung
Drei Erkennungswege fuer KI-Vorfaelle:
| Erkennungsweg | Beispiel | Werkzeug |
|---|---|---|
| Automatisch | Anomalie in Modell-Ausgaben, Drift-Alert | Monitoring-Dashboard |
| Nutzer-Meldung | „Der Chatbot hat mir komische Antworten gegeben" | Feedback-Kanal |
| Externer Hinweis | Security-Forscher meldet Schwachstelle | Responsible-Disclosure-Prozess |
Phase 2: Klassifizierung
Nicht jeder Vorfall ist gleich dringend. Drei Schweregrade:
| Schweregrad | Kriterien | Beispiel | Reaktionszeit |
|---|---|---|---|
| Kritisch | Personenbezogene Daten betroffen, System aktiv kompromittiert | Chatbot leakt Kundendaten | Sofort (< 1 Stunde) |
| Hoch | Modell-Integritaet gefaehrdet, keine Datenexfiltration | Data Poisoning entdeckt | < 4 Stunden |
| Mittel | Anomalie erkannt, kein bestaetigter Angriff | Ungewoehnliches API-Nutzungsmuster | < 24 Stunden |
Phase 3: Eindaemmung
Sofort-Massnahmen nach Schweregrad:
- Kritisch: System offline nehmen. Keine Diskussion, kein „Moment, lass mich erst schauen"
- Hoch: System in Read-Only-Modus oder auf bekannt-gutes Modell zurueckrollen
- Mittel: Erhoehtes Monitoring, betroffene Funktion deaktivieren
KI-spezifische Eindaemmung:
- Prompt Injection: Input-Filter verschaerfen, betroffene Datenquellen isolieren
- Data Poisoning: Training stoppen, letztes sauberes Modell wiederherstellen
- Model Extraction: API-Zugang sperren, betroffene API-Keys rotieren
✅ Quick Check: Warum ist „Erst analysieren, dann eindaemmen" bei KI-Vorfaellen gefaehrlich? (Tipp: Das System produziert weiter Schaden — jede Anfrage kann weitere Daten leaken oder weitere vergiftete Ausgaben erzeugen.)
Phase 4: Ursachenanalyse
Drei parallele Analyse-Straenge:
| Strang | Fragen | Werkzeuge |
|---|---|---|
| Eingabe | Gab es boesartige Eingaben? Prompt Injection? | Eingabe-Logs, Pattern-Matching |
| Daten | Wurden Trainingsdaten manipuliert? Wann? Von wem? | Provenienz-Logs, Diff-Analyse |
| Modell | Hat sich das Modellverhalten geaendert? Drift? | Performance-Metriken, A/B-Vergleich |
Phase 5: Behebung
| Ursache | Behebung | Zeitaufwand |
|---|---|---|
| Prompt Injection | Input-Filter + System-Prompt Hardening | Stunden |
| Data Poisoning | Vergiftete Daten entfernen + Modell-Retrain | Tage bis Wochen |
| Model Extraction | API-Haertung + Rate Limiting + Watermarking | Stunden bis Tage |
| Modell-Drift | Retraining mit aktualisierten Daten | Tage |
Phase 6: Aufarbeitung (Lessons Learned)
Dokumentiere jeden Vorfall systematisch:
| Feld | Inhalt |
|---|---|
| Vorfall-ID | KI-INC-2026-001 |
| Erkennungsdatum | Datum + Uhrzeit |
| Schweregrad | Kritisch / Hoch / Mittel |
| Betroffenes System | System-Name + Version |
| Angriffsvektor | Eingabe / Daten / Modell |
| Angriffsmethode | z.B. Indirekte Prompt Injection ueber RAG |
| Auswirkung | z.B. 200 Kundendatensaetze exponiert |
| Eindaemmungszeit | Zeit von Erkennung bis Eindaemmung |
| Behebungsmassnahmen | Konkrete Aktionen |
| DSGVO-Meldung | Ja/Nein + Datum |
| Lessons Learned | Was aendern wir? |
Meldepflichten bei KI-Vorfaellen
Du hast potenziell drei Meldepflichten:
| Pflicht | Rechtsgrundlage | Frist | Empfaenger |
|---|---|---|---|
| DSGVO | Art. 33 (Behoerde), Art. 34 (Betroffene) | 72 Stunden / unverzueglich | Datenschutzbehoerde / Betroffene |
| EU AI Act | Art. 73 (schwerwiegende Vorfaelle) | Unverzueglich | Marktueberwachungsbehoerde |
| NIS2 | Art. 23 (bei wesentlichen Einrichtungen) | 24h Fruehwarnung, 72h Meldung | BSI |
Key Takeaways
- KI-Vorfaelle sind komplexer als klassische IT-Vorfaelle — drei parallele Ursachenkategorien
- Erst eindaemmen, dann analysieren — bei KI-Vorfaellen waechst der Schaden mit jedem Request
- 6-Phasen-Modell: Erkennung → Klassifizierung → Eindaemmung → Ursachenanalyse → Behebung → Aufarbeitung
- Drei Meldepflichten beachten: DSGVO, EU AI Act, NIS2
- Jeder Vorfall wird dokumentiert — die Lessons Learned verbessern die Schutzmassnahmen
Up Next
In der naechsten Lektion schauen wir uns die Lieferkette an: Welche Risiken bringen Cloud-KI-Anbieter mit, und wie pruefst du sie?
Wissenscheck
Erst das Quiz oben abschließen
Lektion abgeschlossen!