DORA-Incident-Response, wenn die KI das IKT-Risiko ist

Unter DORA ist ein KI-System, das ausfällt, ein IKT-bezogener Vorfall. Und wenn es eine kritische oder wichtige Funktion über die Klassifizierungsschwellen hinaus verschlechtert, wird daraus ein schwerwiegender Vorfall mit laufender Meldefrist: eine Erstmeldung, ein Zwischenbericht und ein Abschlussbericht an Ihre zuständige Behörde. Das Unangenehme daran ist, dass KI leise ausfällt. Ein Modell kann weiter antworten, während seine Antworten schlechter werden, und DORA rechnet auch das mit. Die eigentliche Arbeit liegt also bei Erkennung und Klassifizierung, nicht beim Meldeformular.

Die meisten Incident-Prozesse in einer Bank wurden um Dinge herum gebaut, die stehenbleiben: eine Zahlungsstrecke fällt aus, eine Datenbank verweigert Verbindungen, ein Batch-Job wirft einen Fehler. KI liefert Ihnen eine Kategorie, mit der diese Runbooks nicht umgehen können. Der Scoring-Dienst läuft, die Latenz ist normal, das Dashboard ist grün, und die False-Positive-Rate Ihres Transaktionsüberwachungsmodells hat sich seit dem letzten Refresh des Feature Store verdoppelt. Niemand wurde alarmiert. Unter DORA ist das dennoch ein IKT-Vorfall, wenn es eine kritische oder wichtige Funktion trifft, und die Tatsache, dass Sie es drei Tage lang nicht bemerkt haben, ist selbst schon der Befund.

Erkennung muss bis in die Teile des Modells reichen, die stillschweigend ausfallen

Sie können nicht klassifizieren, was Sie nie erkannt haben. Deshalb fließt das Geld in die Erkennung. Bei einem KI-System sind Verfügbarkeit und Fehlerraten die einfachen Signale und die am wenigsten nützlichen. Die Ausfälle, die für ein Betrugsmodell, eine Kreditentscheidungs-Engine oder einen KYC-Entity-Resolution-Dienst zählen, sind Einbrüche der Ergebnisqualität, die jede Infrastrukturmetrik unberührt lassen.

Wir verdrahten die Erkennung auf drei Ebenen und behandeln alle drei als vollwertige Vorfallquellen:

• Infrastruktur und Serving. Das Gewöhnliche: Latenz, Durchsatz, HTTP-Fehler, Timeouts am Inference-Endpunkt und bei seinen vorgelagerten Feature-Lookups. Ein Feature Store, der beginnt, veraltete Werte zurückzugeben, ist ein Vorfall, selbst wenn das Modell 200er liefert.
• Input- und Output-Verteilungen. Drift bei den eingehenden Feature-Vektoren und Drift bei der Score-Verteilung, die das Modell ausgibt. Ein plötzlicher Kollaps hin zu einer Klasse, ein wandernder Population Stability Index, ein Anstieg von Null-Features durch einen kaputten vorgelagerten Join. Das sind die Stolperdrähte für stille Verschlechterung.
• Proxys für die Entscheidungsqualität. Wo die Ground Truth verzögert eintrifft, beobachten Sie die Proxys, die Sie jetzt schon messen können: Alarmvolumen gegen das False-Positive-Budget, Straight-through-Processing-Rate, Manual-Override-Rate, den Anteil der Fälle, die in die menschliche Prüfung gehen. Wenn die Override-Rate hochschnellt, hat sich vorgelagert etwas verändert, auch wenn Sie es noch nicht benennen können.

Die Lineage-Ebene ist das, was ein Signal in einen Vorfall verwandelt, auf den Sie reagieren können. Wenn Drift auslöst, müssen Sie vom Score rückwärts zur genauen Feature-Version, zum Trainingsdaten-Snapshot und zur vorgelagerten Quelle laufen können, die sich verschoben hat. Ohne diese Lineage liest sich der Vorfallbericht wie “Modell wurde schlechter, Ursache unbekannt”, und das übersteht keine Aufsichtsfrage danach, was Sie geändert haben.

Die Klassifizierung ist die Entscheidung, die die Uhr startet

DORA verlangt nicht, dass Sie alles melden. Es verlangt, dass Sie anhand der Kriterien aus Artikel 18 und der Delegierten Verordnung der Kommission über die Klassifizierung schwerwiegender Vorfälle einstufen: betroffene Kunden und Transaktionen, Datenverluste, Ausfallzeiten von Diensten, geografische Ausbreitung, Reputationsschaden, wirtschaftliche Kosten. Überschreiten Sie die Schwellen, ist es ein schwerwiegender Vorfall mit Meldepflicht. Darunter kommt er in Ihr Register.

Für KI braucht diese Zuordnung eine Übersetzung, und diese Übersetzung live während eines Vorfalls vorzunehmen, ist zu spät. Entscheiden Sie sie im Voraus:

• Ordnen Sie jedes Modell der kritischen oder wichtigen Funktion zu, der es dient, und dem kundennahen Dienst, der ihm nachgelagert ist. Ein driftendes Sanktions-Screening-Modell berührt eine kritische Funktion; ein Marketing-Propensity-Modell in der Regel nicht. Die Klassifizierung folgt der Funktion, nicht der Technologie.
• Definieren Sie, was “betroffen” für ein verschlechtertes Modell bedeutet, nicht für ein totes. Wenn ein Scoring-Dienst sechs Stunden lang selbstsicher falsche Antworten liefert, sind die betroffenen Kunden alle, die in diesem Zeitfenster eine Entscheidung erhalten haben, ob der Endpunkt je einen Fehler zurückgegeben hat oder nicht.
• Legen Sie die Qualitätsschwellen fest, die eine Verschlechterung in einen Vorfall kippen lassen, bevor Sie in einem stecken. Eine False-Positive-Rate über X für länger als Y Minuten bei einem Überwachungsmodell ist ein Vorfall mit einem Schweregrad, festgehalten und mit der zweiten Verteidigungslinie abgestimmt.

Der Grund, diese Zahlen im Voraus festzulegen, ist die Uhr. Die Einstufung eines Vorfalls als schwerwiegend startet drei Fristen nach dem Melde-RTS: eine Erstmeldung innerhalb von vier Stunden nach dieser Einstufung und spätestens 24 Stunden nachdem Sie erstmals Kenntnis erlangt haben, ein Zwischenbericht innerhalb von 72 Stunden nach der Meldung und ein Abschlussbericht innerhalb eines Monats nach dem Zwischenbericht. Wenn Ihr Team den ersten Tag damit verbringt, zu diskutieren, ob eine verdoppelte Override-Rate “zählt”, verrutscht die Klassifizierung, und jede nachgelagerte Frist verrutscht mit ihr. Das ist eine Stunde Definitionsarbeit, die Sie in einem ruhigen Raum hätten erledigen können.

Der Meldeworkflow und der Audit-Trail darunter

Die drei DORA-Berichte bauen aufeinander auf. Der Vorfallsatz muss also von der Erkennung bis zur Ursachenanalyse sauber an Detail zunehmen. Wir bauen den Workflow so, dass dasselbe zugrunde liegende Ereignisprotokoll alle drei speist und jeder Eintrag mit Zeitstempel versehen und unveränderlich ist.

• Erstmeldung. Erkennungszeitpunkt, die betroffene Funktion, ein erster Schweregrad und das, was Sie wissen. Bei einem KI-Vorfall gehört dazu, welches Modell, welche Version und welches Signal ausgelöst hat, nicht nur “Dienst verschlechtert”.
• Zwischenbericht. Auswirkung quantifiziert gegen die Klassifizierungskriterien, die angewandte Eindämmung (Rückfall auf Regeln, Rollback des Modells auf die vorherige Version, Drosselung des Straight-through-Processing, um menschliche Prüfung zu erzwingen) und der aktuelle Status.
• Abschlussbericht. Ursache mit angehängter Lineage: die vorgelagerte Quelle, die sich verschoben hat, das Feature, das veraltet ist, das Retraining, das die Entscheidungsgrenze verschoben hat. Hier hören Drift-Erkennung und Model Monitoring auf, hübsche Dashboards zu sein, und werden zu den Belegen, die eine Aufsicht liest.

Zwei Dinge lassen das den Kontakt mit einem Prüfer überstehen. Erstens muss der Audit-Trail das Timing von Erkennung zu Klassifizierung zu Meldung zeigen, denn DORA interessiert sich ebenso dafür, ob Ihr Prozess funktioniert hat, wie dafür, was kaputtgegangen ist. Eine Lücke zwischen dem Zeitpunkt, an dem Drift die Schwelle überschritten hat, und dem Zeitpunkt, an dem ein Mensch sie eingestuft hat, ist für sich genommen eine Kontrollschwäche. Zweitens: Wenn die ausfallende Komponente bei einem Cloud-Anbieter oder einem Modellanbieter sitzt, bleibt die Verantwortung dennoch bei Ihnen. Ihr Monitoring und Ihre vertragliche Reichweite müssen diese Grenze also überschreiten. Ein Vorfall, den Sie im Stack Ihres Anbieters nicht sehen können, ist ein Vorfall, den Sie nicht rechtzeitig melden können.

Das Muster, das trägt, ist unspektakulär. Instrumentieren Sie die Inputs, Outputs und Entscheidungs-Proxys des Modells so sorgfältig wie seine Verfügbarkeit. Legen Sie die Klassifizierungsschwellen fest, solange nichts brennt. Halten Sie Lineage vor, damit die Ursachenanalyse eine Abfrage ist und kein archäologisches Projekt. Die Meldefristen sind dann eine Formalität obendrauf auf einem System, das es ohnehin schon wusste.