Jede ernsthafte Compliance-Architektur braucht einen Plan für den Tag, an dem etwas schiefgeht. Der EU AI Act verankert das in Art. 73: Anbieter von Hochrisiko-KI-Systemen müssen schwerwiegende Vorfälle den zuständigen Marktaufsichtsbehörden melden. Diese Pflicht ist das KI-Pendant zur Datenpannen-Meldung der DSGVO — und wie dort entscheidet die Vorbereitung darüber, ob eine Organisation im Ernstfall innerhalb der Frist reagieren kann oder in Hektik verfällt.
Was ein schwerwiegender Vorfall ist
Der AI Act definiert einen schwerwiegenden Vorfall als ein Ereignis, das direkt oder indirekt zu einem der folgenden Ergebnisse führt: dem Tod oder einer schweren Gesundheitsschädigung einer Person; einer schweren und irreversiblen Störung der Verwaltung oder des Betriebs kritischer Infrastruktur; einem Verstoss gegen Grundrechte schützende Unionsvorschriften; oder einem schweren Sach- oder Umweltschaden. Die Schwelle liegt also hoch — es geht nicht um jeden Bug, sondern um Ereignisse mit erheblicher realer Wirkung. Genau deshalb ist die Vorab-Definition wichtig: Ihr Team muss im Moment des Vorfalls schnell entscheiden können, ob die Meldeschwelle erreicht ist.
Die Fristen
Die Meldung erfolgt unverzüglich, nachdem der Anbieter einen Kausalzusammenhang zwischen dem KI-System und dem Vorfall oder dessen vernünftige Wahrscheinlichkeit festgestellt hat. Der AI Act nennt gestaffelte Höchstfristen: Im Regelfall spätestens 15 Tage nach Kenntnisnahme. Bei einem weitverbreiteten Verstoss oder einer schweren Störung kritischer Infrastruktur verkürzt sich die Frist auf zwei Tage. Führt der Vorfall zum Tod einer Person, ist unverzüglich, spätestens aber zehn Tage nach Feststellung des Zusammenhangs zu melden. Eine erste Meldung darf unvollständig sein und durch eine vollständige nachgereicht werden — aber die Erstmeldung muss fristgerecht raus.
Warum Logging die Voraussetzung ist
Eine Vorfallmeldung verlangt, dass Sie den Hergang rekonstruieren können: Was hat das System getan, auf welcher Datengrundlage, wer hat es überwacht? Ohne die nach Art. 12 vorgeschriebenen Logs ist das unmöglich. Incident Reporting und Logging sind deshalb zwei Seiten derselben Medaille — wer das eine ernst nimmt, muss das andere beherrschen. Eine häufige Schwäche in unseren Mandaten: vorhandenes Logging, das im Vorfall nicht schnell genug auswertbar ist, weil niemand definiert hat, wie man aus den Rohdaten eine Vorfallchronik erstellt.
Der Reporting-Prozess
Ein belastbarer Prozess hat fünf Elemente. Erstens, eine klare Definition der Meldeschwelle, an der jede betroffene Person den Ernst eines Ereignisses einschätzen kann. Zweitens, ein Eskalationsweg mit benannten Verantwortlichen und Stellvertretern — ein Vorfall passiert nicht nach Kalender. Drittens, eine Vorfall-Vorlage, die die meldepflichtigen Angaben strukturiert erfasst, damit niemand unter Zeitdruck überlegen muss, was hineingehört. Viertens, ein definierter Kanal zur zuständigen Behörde mit hinterlegten Kontaktdaten. Fünftens, eine Nachbereitung: Ursachenanalyse, Korrekturmassnahme und Aktualisierung des Risikomanagements, denn der AI Act verlangt, dass Sie aus Vorfällen lernen.
Die Schnittstelle zu anderen Meldepflichten
Ein Vorfall kann gleichzeitig mehrere Meldepflichten auslösen. Sind personenbezogene Daten betroffen, greift parallel die 72-Stunden-Meldung der DSGVO. Bei kritischer Infrastruktur kommen sektorale Pflichten und gegebenenfalls NIS2 hinzu. Bauen Sie Ihren Prozess deshalb so, dass er im Vorfall alle einschlägigen Pflichten parallel adressiert, statt sie nacheinander zu entdecken. Eine einzige Vorfall-Triage, die fragt «Welche Meldepflichten löst dieses Ereignis aus?», verhindert, dass Sie eine Frist übersehen, während Sie sich auf eine andere konzentrieren.
Was zu tun ist
Setzen Sie den Incident-Reporting-Prozess auf, bevor Sie ihn brauchen — das ist der gesamte Punkt. Definieren Sie die Meldeschwelle anhand der vier Vorfallkategorien, benennen Sie Verantwortliche, erstellen Sie die Vorfall-Vorlage und verproben Sie den Prozess einmal in einer Übung. Verknüpfen Sie ihn mit Ihrem Logging, damit die Rekonstruktion im Ernstfall in Minuten statt Tagen gelingt, und mit Ihren übrigen Meldepflichten, damit nichts durchrutscht. Ein einmal aufgesetzter und geübter Prozess kostet wenig im Unterhalt und entscheidet im Ernstfall über die Differenz zwischen kontrollierter Reaktion und Fristversäumnis.
Was Betreiber zusätzlich beachten
Auch wenn die primäre Meldepflicht beim Anbieter liegt, sind Betreiber nicht aussen vor. Stellt ein Betreiber einen schwerwiegenden Vorfall fest, muss er unverzüglich zunächst den Anbieter und gegebenenfalls die zuständige Behörde informieren. In der Praxis bedeutet das: Anbieter und Betreiber brauchen einen abgestimmten Meldeweg, in dem klar ist, wer wen in welcher Reihenfolge informiert. Gerade bei zugekauften KI-Systemen ist dieser Kommunikationspfad oft ungeklärt — und genau dann tritt der Vorfall ein. Regeln Sie ihn vertraglich, bevor Sie ihn brauchen.
Behandeln Sie schliesslich jeden gemeldeten Vorfall als Lerngelegenheit, nicht nur als Pflichtübung. Der AI Act verzahnt das Incident Reporting eng mit dem Risikomanagement nach Art. 9: Erkenntnisse aus Vorfällen fliessen zurück in die Risikobewertung und führen zu Korrekturmassnahmen. Ein Vorfall, der gemeldet, aber nicht zur Verbesserung des Systems genutzt wird, erfüllt den Buchstaben der Pflicht, verfehlt aber ihren Sinn. Schliessen Sie die Schleife von der Meldung über die Ursachenanalyse zur konkreten Anpassung — und dokumentieren Sie diese Anpassung.
Ein letzter organisatorischer Hinweis: Bestimmen Sie vorab, wer im Ernstfall sprechfähig ist. Ein schwerwiegender Vorfall erzeugt nicht nur eine Meldepflicht, sondern oft auch Anfragen von Kunden, Partnern und unter Umständen der Öffentlichkeit. Wer hier ohne abgestimmte Sprachregelung agiert, riskiert widersprüchliche Aussagen, die die rechtliche Lage verkomplizieren. Legen Sie fest, wer intern koordiniert, wer mit der Behörde kommuniziert und wer nach aussen spricht — diese drei Rollen sollten klar getrennt und vorab benannt sein, damit im Vorfall niemand improvisieren muss.

