KI Vorfall und Eskalation: Der Incident Prozess für den AI Act

Welche Ereignisse in das KI Runbook gehören

Der interne Incident Begriff sollte weiter sein als der gesetzliche schwerwiegende Vorfall. Erfasst werden Fehlfunktionen, falsche oder diskriminierende Ergebnisse, Grundrechtsbeeinträchtigungen, Sicherheitsereignisse, unerlaubte Nutzung, Beschwerden, Datenprobleme und Beinahe-Vorfälle. So kann die Organisation reagieren, bevor die Schwelle einer externen Meldepflicht erreicht ist. Mitarbeitende und externe Meldende benötigen einen leicht erreichbaren Kanal, der nicht voraussetzt, dass sie bereits die richtige rechtliche Kategorie kennen.

Artikel 3 Nummer 49 definiert den schwerwiegenden Vorfall für den AI Act. Diese Definition darf nicht mit internen Severity-Stufen gleichgesetzt werden. Ein intern kritischer Vorgang kann außerhalb dieser Definition liegen und dennoch nach Datenschutz-, NIS-, Produkt-, Verbraucher- oder Arbeitsrecht relevant sein. Umgekehrt darf eine technische Stufe niedrig erscheinen, obwohl Auswirkungen auf Gesundheit, Sicherheit oder Grundrechte eine sofortige juristische Bewertung verlangen. Triage und Rechtsprüfung laufen deshalb parallel.

• Fehler, Beschwerden, Missbrauch und Beinahe-Vorfälle über denselben Eingang erfassen.
• Interne Schweregrade von gesetzlichen Meldetatbeständen trennen.
• Personenwirkung und Grundrechtsrisiko neben technischer Auswirkung bewerten.

Quellen: [1] [2]

Triage in den ersten Stunden

Die Erstbewertung beantwortet wenige, entscheidende Fragen: Läuft das System noch? Sind Personen aktuell gefährdet oder benachteiligt? Wie groß ist die Reichweite? Kann die Auswirkung rückgängig gemacht werden? Welche Version, Daten und Schnittstellen sind betroffen? Gibt es Anzeichen für Manipulation oder unzulässige Nutzung? Ein Incident Lead bündelt Informationen, legt den vorläufigen Schweregrad fest und aktiviert Legal, Datenschutz, Security, Fachbereich und Management nach einer vorab definierten Eskalationsmatrix.

Unvollständige Informationen sind in der Frühphase normal. Das Runbook darf eine Sofortmaßnahme nicht davon abhängig machen, dass Ursache und Meldepflicht bereits abschließend feststehen. Annahmen, Unsicherheiten und nächste Prüfschritte werden mit Zeitstempel dokumentiert. Feste kurze interne Fristen schaffen Reserven für externe Meldezeiträume. Erreichbare Stellvertretungen und Kontaktdaten des Anbieters sind vor dem Vorfall zu pflegen; ein Postfach ohne Rufbereitschaft genügt bei zeitkritischen Anwendungen nicht.

• Incident Lead und fachübergreifendes Kernteam vorab bestimmen.
• Erstbewertung mit Zeitstempel, Annahmen und offenen Fragen dokumentieren.
• Interne Eskalationszeiten deutlich kürzer als mögliche Außenfristen setzen.

Quellen: [1] [2]

Eindämmung, Ersatzverfahren und Beweissicherung

Sofortmaßnahmen richten sich nach dem Risiko. Möglich sind Aussetzung, Einschränkung des Nutzerkreises, Deaktivierung einer Funktion, Sperre bestimmter Datenquellen oder Rückkehr zu einem menschlichen Ersatzprozess. Betroffene Entscheidungen werden angehalten oder überprüft, soweit dies praktisch und rechtlich geboten ist. Die Maßnahme sollte so weit gehen, wie der Schutz erfordert, aber nicht unkontrolliert weitere Schäden erzeugen. Zuständige Personen brauchen die technische Befugnis, einen Stopp tatsächlich umzusetzen.

Gleichzeitig wird Beweismaterial gesichert: System- und Modellversion, Konfiguration, relevante Eingaben und Ausgaben, automatisch erzeugte Logs, Zeitpunkte, Nutzeraktionen, Datenquellen und Lieferantenkommunikation. Die Sicherung muss Integrität, Datenschutz und Zugriffsschutz berücksichtigen. Produktivdaten werden nicht wahllos kopiert. Veränderungen am Systemzustand sind zu protokollieren, damit spätere Ursachenanalyse und Behördenkommunikation nachvollziehbar bleiben. Ein Beweissicherungsplan verhindert, dass automatische Löschfristen oder ein Anbieterupdate zentrale Informationen vernichten.

• Schutz von Personen vor wirtschaftlicher Kontinuität priorisieren.
• Einen getesteten manuellen oder sicheren Ersatzprozess bereithalten.
• Systemzustand und relevante Evidenz datenschutzgerecht und unverändert sichern.

Quellen: [1] [2]

Meldewege und Fristen nach Artikel 73

Artikel 73 adressiert Anbieter von Hochrisiko-Systemen und enthält für schwerwiegende Vorfälle differenzierte Höchstfristen. Grundsätzlich ist unverzüglich, spätestens binnen 15 Tagen nach Kenntnis durch Anbieter oder gegebenenfalls Betreiber zu melden. Bei einem weitverbreiteten Verstoß oder einer schweren und unumkehrbaren Störung kritischer Infrastruktur gilt grundsätzlich eine Höchstfrist von zwei Tagen; beim Tod einer Person grundsätzlich zehn Tage. Die jeweiligen zusätzlichen Voraussetzungen, insbesondere zur Kausalität oder zum Kausalitätsverdacht, sind gesondert zu prüfen. Kenntniszeitpunkt und Entwicklung der Bewertung müssen deshalb nachvollziehbar dokumentiert werden.

Eine Meldung darf nicht bis zur vollständigen Ursachenanalyse aufgeschoben werden, wenn die anwendbare Frist eine frühere Information verlangt. Prozess und Vorlage sollten Erstmeldung, Zwischenstand und Abschlussinformation ermöglichen. Zuständige Behörde und Kommunikationsweg sind vor jeder Meldung aktuell zu prüfen. Der Digital Omnibus hat Aufsichtskompetenzen für bestimmte, vom AI Office exklusiv beaufsichtigte Systeme neu geordnet; außerdem war die allgemeine österreichische Behördenzuweisung am Stichtag nicht abschließend umgesetzt. Zuständigkeiten dürfen daher nicht aus alten Kontaktlisten übernommen werden.

• Unverzüglichkeit sowie 2-, 10- und 15-Tage-Höchstfristen tatbestandsbezogen im Runbook abbilden.
• Kenntniszeitpunkt, Bewertung und behördliche Kommunikation lückenlos protokollieren.
• Zuständige Stelle unmittelbar vor einer Meldung anhand amtlicher Angaben prüfen.

Quellen: [2] [1]

Betreiber- und Anbieterprozess verbinden

Betreiber erkennen einen Vorfall häufig zuerst, während der Anbieter Ursachenanalyse und regulatorische Anbieterpflichten steuert. Artikel 26 bindet Betreiber in die Informationskette ein. Verträge müssen festlegen, welche Ereignisse unverzüglich gemeldet werden, welche technischen Daten bereitstehen, wie sichere Kommunikation erfolgt und wer bei Nichterreichbarkeit entscheidet. Die Organisation darf sich nicht darauf verlassen, dass ein Standard-Supportticket für einen zeitkritischen, folgenreichen Vorfall ausreicht.

Der Betreiber behält eigene Pflichten und Schutzmaßnahmen im Blick. Er muss gegebenenfalls die Nutzung aussetzen, Betroffene schützen und parallele Meldetatbestände prüfen, auch wenn der Anbieter noch untersucht. Umgekehrt benötigt der Anbieter Informationen aus dem realen Betrieb. Gemeinsame Übungen sollten Zeitzonen, Unterauftragnehmer, Sprachfragen und Wochenenden berücksichtigen. Ein Exit- oder Ersatzprozess ist besonders wichtig, wenn der Anbieter nicht reagiert, den Zugriff auf Logs verweigert oder ein kritisches Update nicht bereitstellen kann.

• Vertragliche Meldeauslöser, Kontaktstufen und Datenaustausch konkret definieren.
• Eigene Betreibermaßnahmen nicht von der abschließenden Anbieteranalyse abhängig machen.
• Nichterreichbarkeit und unzureichende Kooperation des Lieferanten im Runbook abbilden.

Quellen: [1] [2]

Nachbereitung, Wirksamkeitsprüfung und Re-Freigabe

Nach der Eindämmung folgt eine Ursachenanalyse, die technische, organisatorische und menschliche Faktoren einbezieht. Korrekturmaßnahmen erhalten Owner, Frist und Wirksamkeitskriterium. Das KI Inventar, Risikoregister, Kontrolldesign, Schulungsinhalt und Lieferantenbewertung werden aktualisiert. Eine Re-Freigabe setzt voraus, dass Ursachen ausreichend verstanden, Maßnahmen umgesetzt und verbleibende Risiken neu bewertet wurden. Die zuständige Freigabestelle entscheidet anhand des aktuellen Systemzustands und nicht aufgrund des früheren Beschlusses.

Die Hochrisiko-Vorfallpflichten gelten nach der Verordnung (EU) 2026/1744 für Anhang-III-Systeme grundsätzlich ab 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 grundsätzlich ab 2. August 2028. Bei Produkten nach Anhang I Abschnitt B ist wegen Artikel 2 Absatz 2 das sektorale Melderegime besonders zu prüfen. Ein Incident Prozess ist schon vorher sinnvoll und kann durch andere Rechtsgebiete bereits erforderlich sein. Übungen messen Erkennungszeit, Eindämmung, Informationsqualität und Entscheidungsfähigkeit. Ein abgeschlossenes Ticket belegt keine Wirksamkeit; entscheidend ist, ob Wiederholung verhindert oder schneller begrenzt wird. Der Prozess bietet keine Haftungs- oder Konformitätsgarantie.

• Ursache, Korrektur, Wirksamkeitskriterium und Restrisiko dokumentieren.
• Re-Freigabe durch die nach Governance zuständige Stelle verlangen.
• Runbook regelmäßig mit realistischen Lieferanten- und Personenszenarien üben.

Quellen: [2] [1]

Häufige Fragen