Zurück zu Richtlinienvorlagen
Richtlinie 11 von 15

Vorfallreaktionsrichtlinie für KI-Systeme

Erweitert den Vorfallreaktionsplan der Organisation um KI-spezifische Auslöser, Triage-Verfahren und regulatorische Meldepflichten.

1. Zweck

Diese Richtlinie definiert, wie [Name der Organisation] KI-spezifische Vorfälle erkennt, triagiert, eindämmt und behebt. Standard-IT-Vorfallreaktionspläne decken KI-Fehlerarten wie Modelldrift, Halluzinationen, Bias-Vorfälle, Prompt Injection oder Data Poisoning nicht ab. Diese Richtlinie schließt diese Lücke.

2. Geltungsbereich

Diese Richtlinie gilt für:

  • Alle KI-Systeme in der Produktion (intern und kundenorientiert).
  • Alle KI-bezogenen Sicherheitsvorfälle, Sicherheitsereignisse und Leistungsausfälle.
  • Alle Mitarbeitenden, die KI-Vorfälle erkennen, melden oder auf diese reagieren.
  • Vorfälle, die sowohl intern entwickelte als auch Drittanbieter-KI-Systeme betreffen.

3. KI-Vorfallkategorien

| Kategorie | Beschreibung | Beispiele |

| Sicherheit | KI-Ausgabe verursacht oder könnte Personen Schaden zufügen | Gefährliche medizinische Ratschläge, falsche Sicherheitsempfehlung, schädliche Inhalte für Minderjährige |

| Bias | KI erzeugt diskriminierende Ergebnisse bei geschützten Gruppen | Unterschiedliche Ablehnungsraten bei Einstellungen, verzerrte Bonitätsbewertung, unfaire Inhaltsmoderation |

| Cybersicherheit | Adversarialer Angriff oder unbefugter Zugriff auf KI-Systeme | Prompt Injection, Jailbreak, Modellextraktion, Datenexfiltration über KI, Data Poisoning |

| Datenschutz | KI legt personenbezogene oder vertrauliche Daten offen | Modellmemorierung von PII, Prompt-Leakage vertraulicher Daten, unbefugte Datenweitergabe über KI |

| Leistung | KI-Qualität fällt unter akzeptable Schwellenwerte | Genauigkeitsabfall, Zunahme von Halluzinationen, Latenzspitze, Modelldrift über Toleranz hinaus |

| Compliance | KI arbeitet außerhalb regulatorischer Grenzen | Fehlende Transparenzangaben, nicht autorisierte automatisierte Entscheidungen, entdeckte Dokumentationslücken |

4. Schweregrad-Klassifizierung

| Schweregrad | Kriterien | Reaktionszeit |

| Kritisch (P1) | Aktiver Schaden für Einzelpersonen, Datenschutzverletzung oder regulatorische Meldepflicht | Sofortige Reaktion, Eindämmung innerhalb von 1 Stunde |

| Hoch (P2) | Wesentliches Schadensrisiko, signifikanter Bias erkannt oder Sicherheitsverletzung eingedämmt aber nicht behoben | Reaktion innerhalb von 4 Stunden, Eindämmung innerhalb von 24 Stunden |

| Mittel (P3) | Leistungsverschlechterung, nicht-kritischer Bias oder identifizierte Compliance-Lücke | Reaktion innerhalb von 24 Stunden, Lösung innerhalb von 5 Werktagen |

| Niedrig (P4) | Geringes Qualitätsproblem, informatorische Feststellung oder kosmetisches Problem | Protokolliert und bei nächster planmäßiger Überprüfung behandelt |

5. Reaktionsprozess

Platzhaltertext. Füllen Sie mit der Sprache Ihrer Organisation für 5. Reaktionsprozess aus.

Phase 1: Erkennung und Meldung

  • Vorfälle können durch Monitoring-Warnungen, Nutzermeldungen, Audit-Feststellungen oder Drittanbieter-Benachrichtigungen erkannt werden.
  • Jeder Mitarbeitende, der einen KI-Vorfall vermutet, muss diesen sofort dem KI-Governance-Verantwortlichen oder dem Sicherheitsteam melden.
  • Die Meldung muss umfassen: Systemname, Vorfallbeschreibung, Schweregradeinschätzung und etwaige sofort ergriffene Maßnahmen.

Phase 2: Triage

  • Der KI-Governance-Verantwortliche (oder Sicherheit bei Sicherheitsvorfällen) weist den Schweregrad zu und stellt das Reaktionsteam zusammen.
  • Die Zusammensetzung des Reaktionsteams hängt von der Kategorie ab: Modellverantwortlicher (immer), Sicherheit (bei Sicherheits-/Datenschutzvorfällen), Recht (bei Compliance/regulatorischen Vorfällen), Datenverantwortlicher (bei Datenvorfällen).
  • Bei P1 und P2: Das KI-System kann bis zur Untersuchung ausgesetzt werden. Die Entscheidung zur Aussetzung trifft der KI-Governance-Verantwortliche oder der Sicherheitsteamleiter.

Phase 3: Eindämmung

  • Den unmittelbaren Schaden stoppen: System aussetzen, Angriffsvektor blockieren, auf vorherige Modellversion zurückrollen oder Zugriff einschränken.
  • Beweise sichern: Protokolle, Modellzustand, Ein-/Ausgabeproben, Monitoring-Daten.
  • Betroffene Parteien benachrichtigen, falls erforderlich (siehe Abschnitt 6).

Phase 4: Untersuchung

  • Ursache identifizieren: Handelt es sich um ein Modellproblem, Datenproblem, Infrastrukturproblem oder adversariale Handlung?
  • Umfang bestimmen: Wie viele Nutzer/Entscheidungen/Ausgaben waren betroffen? Über welchen Zeitraum?
  • Regulatorische Auswirkungen bewerten: Löst dies Meldepflichten aus?

Phase 5: Behebung

  • Ursache beheben (Retraining, Patch, Leitplanken aktualisieren, Datenpipeline reparieren).
  • Behebung durch Tests validieren, bevor der Produktionsdienst wiederhergestellt wird.
  • Monitoring aktualisieren, um ein Wiederauftreten zu erkennen.

Phase 6: Post-Vorfall-Review

  • Innerhalb von 10 Werktagen nach Behebung ein schuldzuweisungsfreies Post-Vorfall-Review durchführen.
  • Dokumentieren: Zeitachse, Ursache, Auswirkung, Reaktionsmaßnahmen, Erkenntnisse, Präventivmaßnahmen.
  • Ergebnisse bei P1- und P2-Vorfällen dem KI-Governance-Ausschuss vorlegen.
  • Richtlinien, Verfahren oder Kontrollen auf Basis der Erkenntnisse aktualisieren.

6. Meldepflichten

| Auslöser | Erforderliche Meldung | Frist |

| Verletzung des Schutzes personenbezogener Daten (DSGVO Art. 33) | Aufsichtsbehörde | Innerhalb von 72 Stunden nach Kenntnisnahme |

| Hohes Risiko für die Rechte Einzelner (DSGVO Art. 34) | Betroffene Einzelpersonen | Unverzüglich |

| Schwerwiegender KI-Vorfall (EU AI Act Art. 73) | Marktüberwachungsbehörde | Innerhalb von 15 Tagen nach Kenntnisnahme |

| Anbieter-KI-Vorfall | Intern: KI-Governance-Verantwortlicher + Recht | Innerhalb von 24 Stunden nach Anbieterbenachrichtigung |

7. Rollen und Verantwortlichkeiten

| Rolle | Vorfallreaktions-Verantwortlichkeiten |

| KI-Governance-Verantwortlicher | Triagiert Vorfälle, stellt Reaktionsteam zusammen, koordiniert Untersuchung, verwaltet Kommunikation. |

| Modellverantwortlicher | Stellt Systemkontext bereit, führt Eindämmung durch (Aussetzung/Rollback), leitet technische Untersuchung. |

| Sicherheit | Leitet Reaktion auf Sicherheitsvorfälle, sichert Beweise, führt forensische Analyse durch. |

| Recht | Bewertet Meldepflichten, entwirft Regulierungsbehörden-Kommunikation, berät zur Haftung. |

| Kommunikation | Verwaltet externe Kommunikation, falls öffentliche Offenlegung erforderlich ist. |

8. Regulatorische Ausrichtung

  • EU AI Act: Artikel 73 (Meldung schwerwiegender Vorfälle), Artikel 20 (Korrekturmaßnahmen).
  • DSGVO: Artikel 33-34 (Meldung von Verletzungen).
  • ISO/IEC 42001: Abschnitt 10.2 (Nichtkonformität und Korrekturmaßnahmen).
  • NIST AI RMF: MANAGE-Funktion (MG-4: Vorfallreaktion).
  • CoSAI AI IR Framework: Erkennungs-, Triage-, Eindämmungs- und Wiederherstellungs-Playbooks.

9. Überprüfung

Diese Richtlinie wird jährlich, nach jedem P1-Vorfall und bei Auftreten neuer Vorfallkategorien durch regulatorische Leitlinien oder Branchenerfahrung überprüft.

Dokumentenlenkung

| Feld | Wert |

| Richtlinienverantwortlicher | [KI-Governance-Verantwortlicher / CISO] |

| Genehmigt durch | [KI-Governance-Ausschuss] |

| Inkrafttreten | [Datum] |

| Nächste Überprüfung | [Datum + 12 Monate] |

| Version | 1.0 |

| Klassifizierung | Intern |

Bereit, diese Richtlinie umzusetzen?

Nutzen Sie VerifyWise, um diese Richtlinienvorlage anzupassen, bereitzustellen und die Compliance zu verfolgen.

Vorfallreaktionsrichtlinie für KI-Systeme | VerifyWise KI-Governance-Vorlagen