Template: Incident Response Plan für KI-Vorfälle

Wofür

Der Incident Response Plan beschreibt, was passiert, wenn ein Hochrisiko-KI-System einen schwerwiegenden Vorfall auslöst oder daran beteiligt ist: wer den Vorfall bewertet, wer die Uhr für die Meldefrist startet, wer meldet, und wie der Ablauf nachträglich belegbar bleibt. Er ist kein IT-Security-Playbook — Ausfälle, Angriffe und Datenschutzvorfälle haben ihre eigenen Prozesse. Der Plan hier setzt an der Frage an, die im Ernstfall entscheidet: Hat unser KI-System einen Schaden verursacht, der meldepflichtig ist, und binnen welcher Frist? Der Plan wird pro KI-System oder pro System-Familie geführt und mindestens jährlich sowie nach jedem realen Vorfall fortgeschrieben.

Wann es Pflicht ist

Art. 73 der KI-Verordnung (VO 2024/1689) verpflichtet Provider von Hochrisiko-KI-Systemen, schwerwiegende Vorfälle den Marktüberwachungsbehörden des Mitgliedstaats zu melden, in dem der Vorfall eingetreten ist. Was ein schwerwiegender Vorfall ist, definiert Art. 3 Nr. 49: Tod oder schwere Gesundheitsschädigung einer Person, schwere und irreversible Störung kritischer Infrastruktur, Verletzung unionsrechtlich geschützter Grundrechte oder schwerer Sach- bzw. Umweltschaden. Die Meldung erfolgt unverzüglich nach Feststellung eines Kausalzusammenhangs oder dessen begründeter Wahrscheinlichkeit, spätestens jedoch 15 Tage nach Kenntnisnahme. Für den Tod einer Person verkürzt sich die Frist auf 10 Tage, bei weitreichenden Verstößen und schweren irreversiblen Störungen kritischer Infrastruktur auf 2 Tage. Ist eine vollständige Meldung nicht fristgerecht möglich, sieht Art. 73 Abs. 5 eine unvollständige Erstmeldung mit nachfolgendem vollständigem Bericht vor. Deployer, die einen schwerwiegenden Vorfall feststellen, informieren nach Art. 26 Abs. 5 zuerst den Provider, dann Importeur oder Händler und die zuständige Marktüberwachungsbehörde. Ein eigenständiger Plan ist damit für beide Rollen nötig — Provider melden, Deployer erkennen und eskalieren.

Die Pflichten für Hochrisiko-KI greifen mit dem Enforcement-Termin 02.12.2027. Wer den Plan erst dann schreibt, hat ihn im Ernstfall nie geprobt.

Das Artefakt selbst

# Incident Response Plan (KI) — [System-Name], Version [X.Y]

## 1. Geltungsbereich
- KI-System / Modell-Version:
- Eigene Rolle: [ ] Provider  [ ] Deployer  [ ] beides
- Betroffene Rechtsräume (DE / EU27-Rest / UK / CH):
- Verantwortlich (Rolle, nicht Person):
- Datum / Review-Zyklus:

## 2. Was bei uns als schwerwiegender Vorfall gilt (Art. 3 Nr. 49)
| Kategorie | Konkretisierung für dieses System | Beispiel-Szenario |
|---|---|---|
| Tod / schwere Gesundheitsschädigung | | |
| Störung kritischer Infrastruktur | | |
| Verletzung von Grundrechten | | |
| Schwerer Sach- / Umweltschaden | | |
| Abgrenzung: NICHT meldepflichtig | | |

## 3. Erkennung und Eingang
- Meldewege (Support, Logging-Alarm, Deployer, Betroffene, Presse):
- Zentrale Eingangsstelle + Erreichbarkeit außerhalb Geschäftszeiten:
- Ersterfassung: Pflichtfelder des Eingangs-Tickets:

## 4. Trigger der Frist (kritisch)
- Definition "Kenntnisnahme" im eigenen Haus:
- Wer stellt Kenntnisnahme fest und dokumentiert Datum/Uhrzeit:
- Wer bewertet den Kausalzusammenhang (Rolle, Vertretung):

## 5. Fristen und Meldeempfänger
| Fall | Frist ab Kenntnisnahme | Empfänger | Verantwortliche Rolle |
|---|---|---|---|
| Regelfall | 15 Tage | Marktüberwachungsbehörde (Ereignisstaat) | |
| Tod einer Person | 10 Tage | | |
| Kritische Infrastruktur / weitreichender Verstoß | 2 Tage | | |
| Erstmeldung unvollständig (Art. 73 Abs. 5) | | | |
| Deployer-Meldung an Provider (Art. 26 Abs. 5) | unverzüglich | Provider, dann Importeur/Händler, Behörde | |

## 6. Parallele Meldepflichten (Abgleich, keine Ersetzung)
- Datenschutz (Meldung an Aufsichtsbehörde, eigene Frist):
- Sektorales Fachrecht (z. B. Medizinprodukte, Finanzaufsicht):
- Vertragliche Meldepflichten gegenüber Kunden:
- Wer koordiniert, damit Meldungen nicht widersprüchlich sind:

## 7. Untersuchung und Beweissicherung
- Sofortmaßnahmen zur Beweissicherung (Logs, Modellstand, Konfiguration):
- Änderungssperre am System bis Abstimmung mit der Behörde (Art. 73 Abs. 6):
- Zuständigkeit Root-Cause-Analyse:
- Risikobewertung und Korrekturmaßnahmen (Rückführung in Art. 9):

## 8. Kommunikation
- Interne Eskalationsstufen (Fach, Recht, Geschäftsleitung):
- Information betroffener Deployer / Nutzer:
- Externe Kommunikation, Freigabe durch:

## 9. Nachweisführung
- Vorfall-Register (Ort, Format, Aufbewahrungsdauer):
- Zu archivierende Belege pro Vorfall:
- Verknüpfung mit Post-Market Monitoring (Art. 72):

## 10. Probe und Freigabe
- Letzte Übung (Tabletop) am / Erkenntnisse:
- Geprüft durch / am:
- Nächstes Review:

Ausfüll-Anleitung

1. Abschnitt 1 zuerst klären. Provider- und Deployer-Rolle haben unterschiedliche Adressaten und Auslöser. Wer beides ist, führt beide Stränge sichtbar getrennt.
2. Abschnitt 2 ist die eigentliche Arbeit. Die abstrakten Kategorien aus Art. 3 Nr. 49 in Szenarien dieses konkreten Systems übersetzen. Ohne diese Übersetzung wird im Ernstfall unter Zeitdruck diskutiert statt gemeldet.
3. Die Abgrenzungszeile nicht auslassen. Zu dokumentieren, was bewusst nicht als schwerwiegender Vorfall gilt, macht die Bewertung überprüfbar — und schützt vor Reflex-Meldungen jeder Störung.
4. Abschnitt 4 entscheidet über Fristversäumnisse. "Kenntnisnahme" muss organisatorisch definiert sein: Kenntnis welcher Rolle, ab welchem Informationsstand. Ein Ticket im Support ohne definierte Weitergabe ist der häufigste stille Fristbeginn.
5. Fristen als Kalendertage rechnen, nicht als Arbeitstage, und die Eskalation über Wochenenden mitdenken. Die 2-Tage-Fälle sind ohne Rufbereitschaft nicht haltbar.
6. Abschnitt 6 ausfüllen, bevor es klemmt. Datenschutz- und Fachrechtsmeldungen laufen mit eigenen Fristen parallel — der Plan ersetzt sie nicht, er koordiniert sie.
7. Abschnitt 7 ernst nehmen: Untersuchungen, die das System verändern, dürfen die spätere Ursachenbewertung nicht unmöglich machen. Beweissicherung geht dem Hotfix voraus.
8. Erkenntnisse zurückspeisen. Jeder Vorfall ist ein Input für das Risk Assessment nach Art. 9 und das Post-Market Monitoring nach Art. 72. Ein Plan ohne Rückkopplung erzeugt denselben Vorfall zweimal.
9. Mindestens einmal proben. Ein Tabletop-Durchlauf mit einem erfundenen Szenario findet mehr Lücken als drei Review-Runden am Dokument.

Audit-Erwartung

Auditoren prüfen den Plan nicht als Text, sondern als Prozess. Typisch ist ein durchgespieltes Szenario: Ein Deployer meldet eine mutmaßlich diskriminierende Entscheidung — wer erfährt wann davon, wann beginnt die Frist, wer entscheidet über den Kausalzusammenhang, welche Logs werden gesichert? Erwartet werden benannte Rollen mit Vertretung, dokumentierte Erreichbarkeit und ein Vorfall-Register, in dem auch bewertete, aber nicht gemeldete Fälle mit Begründung stehen. Quergelesen wird mit dem Logging-Konzept nach Art. 12 (lässt sich der Vorfall überhaupt rekonstruieren?) und dem Risk Assessment nach Art. 9. Rote Flaggen sind ein Plan ohne definierten Fristbeginn, ein leeres Vorfall-Register bei laufendem Produktivbetrieb und Verantwortlichkeiten, die an Einzelpersonen statt an Rollen hängen.

Verwandte Artefakte

• Template: Logging-Konzept nach Art. 12 — ohne belastbare Logs keine Vorfall-Rekonstruktion
• Template: AI Risk Assessment nach Art. 9 — Vorfälle fließen als Input zurück
• Template: Human Oversight-Konzept nach Art. 14 — Eingriffe und Overrides sind oft der erste Vorfall-Indikator
• Template: Technische Dokumentation nach Anhang IV — der Plan wird dort referenziert
• Welche Use-Cases überhaupt hochrisiko sind: Use-Case-Bibliothek auf hochrisiko-ki.com

Mehr Kontext zu Meldepflichten und Marktüberwachung im EU AI Act gesamt: Leitfaden auf eu-ai-verordnung.de.

AEGIRA AI Guardian operationalisiert diese Artefakte als laufende Trust-Infrastructure — aegira.ai.