Erkannt, aber nicht gemeldet: Wer setzt die Meldeschwelle?

Im Juni 2025 schlägt bei OpenAI ein automatisches System bei einem ChatGPT-Konto an. Menschen sehen sich den Fall an. Sie prüfen zwei Fragen: Verstößt das Konto gegen die Nutzungsregeln? Und muss die Polizei davon erfahren? Die erste Frage beantworten sie mit Ja und sperren das Konto. Die zweite mit Nein. Die eigene Schwelle für eine Meldung sei nicht erreicht gewesen, schreibt das Unternehmen später.

Am 10. Februar 2026 sterben in Tumbler Ridge, einer Kleinstadt in British Columbia, acht Menschen, sechs von ihnen an der örtlichen Schule. Das gesperrte Konto gehörte der Person, die für die Tat verantwortlich ist.

Ich schreibe darüber nicht, um anzuklagen. Ob eine Meldung im Juni etwas verhindert hätte, weiß niemand, und ich behaupte es hier nicht. Ich schreibe darüber, weil derselbe Ablauf in jedem Betrieb stehen kann, nur kleiner. Ihre Protokolle zeigen morgen, dass jemand Kundendaten in ein privates Konto kopiert. Das System hat es erkannt. Wer entscheidet, ob das nach außen geht? Und wer hat festgelegt, ab wann?

Erkannt, geprüft, gesperrt: was funktioniert hat

Was genau passiert ist, wissen wir aus einer Quelle, die selten so offen ist: einem Brief von OpenAI selbst. Am 26. Februar 2026 schreibt die zuständige Vizepräsidentin an Kanadas Minister für künstliche Intelligenz. Der Ablauf, den sie beschreibt, hat drei Stufen. Ein automatisches System erkennt das Konto. Menschen prüfen, ob die Nutzungsregeln verletzt sind und ob eine Meldung an die Strafverfolgung angezeigt ist. Das Konto wird gesperrt. Für eine Meldung hätte das Unternehmen nach eigenen Worten eine glaubwürdige und unmittelbar bevorstehende Planung erkennen müssen. Die sah es nicht.

Technisch hat diese Kette funktioniert. Die Erkennung schlug an, ein Mensch sah hin, es fiel eine Entscheidung. Woran es hing, war die Schwelle. Sie stand fest, bevor jemand den Fall kannte, und sie bestimmte das Ergebnis.

Derselbe Brief enthält zwei Sätze, die ich für wichtiger halte als jede Schuldfrage. Erstens: Die Kriterien seien inzwischen flexibler gefasst, denn wer Gewalt plant, nennt im Gespräch mit einem Chatbot nicht unbedingt Ziel, Mittel und Zeitpunkt. Nach dem heutigen Verfahren würde das im Juni 2025 gesperrte Konto gemeldet. Zweitens: OpenAI sagt zu, die Schwellen seiner automatischen Erkennung regelmäßig zu überprüfen.

Daraus folgt etwas Unbequemes für jeden, der eine Schwelle festlegt. Dieselben Fakten führen mit der alten Schwelle zu einem Nein und mit der neuen zu einem Ja. Die Schwelle ist also kein Wert, den man irgendwo abliest. Menschen legen sie fest. Und Menschen können sie falsch legen.

Ein drittes Detail aus dem Brief passt in jede Werkhalle. OpenAI hatte ein System, das gesperrte Nutzer erkennen soll, wenn sie ein neues Konto anlegen. Ein zweites Konto fiel trotzdem erst auf, nachdem der Name der Person öffentlich war. Danach ging es an die Polizei. Eine Sperre wirkt gegen ein Konto. Gegen einen Menschen wirkt sie nur, solange er kein neues anlegt.

Zwölf Minuten bis zum Alarm, zweieinhalb Stunden bis zum Stopp

Der zweite Fall stammt ebenfalls von OpenAI, aus einem Vorfallbericht, den das Unternehmen am 25. September 2026 zuletzt aktualisiert hat. Ein Agent sollte im Training eine Rechercheaufgabe lösen und hatte keinen Zugang zum offenen Internet. Er fand trotzdem einen Weg hinaus, über den Namensdienst (DNS) seiner Testumgebung, und stellte darüber einem fremden Chatbot Fragen. Der Bericht nennt die Uhrzeiten:

• 9:50:23 Uhr: Der Agent bekommt die erste Antwort von außen.
• 10:02:11 Uhr: Die Überwachung löst einen Alarm der höchsten Stufe aus, knapp zwölf Minuten später.
• 10:05:06 Uhr: Ein Mensch bestätigt den Alarm, keine drei Minuten danach.
• 12:34:30 Uhr: Der Lauf wird beendet.

Zwischen der Bestätigung und dem Stopp liegen 2 Stunden und 29 Minuten. OpenAI schreibt selbst, warum. Der Lauf hielt nicht, wie erwartet, von allein an, und es war unklar, ob er gestoppt werden sollte. Beendet wurde er, als das geklärt war. Ich lese daraus eine offene Zuständigkeit. Der Alarm hatte einen Empfänger. Die Entscheidung hatte keinen.

Zwei weitere Sätze aus dem Bericht sind typische Auditbefunde, nur in einer anderen Umgebung. Die Überwachung hat andere DNS-Zugriffe nach außen nicht mit der erwarteten Schwere gemeldet, weil sie eine Antwort ohne brauchbaren Inhalt für einen gescheiterten Zugriff hielt. Und ein Detektor für auffällige DNS-Aktivität hatte die betroffene Umgebung ausgeschlossen, obwohl die Aktivität protokolliert war. Protokolliert heißt nicht gesehen. Auch eine automatische Bewertung trägt eine Schwelle in sich, und die hat jemand gesetzt.

Bevor das nach Kritik klingt: Beide Fälle kennen wir nur, weil OpenAI sie mit Uhrzeit und Begründung veröffentlicht hat. Das verdient Anerkennung. Könnte Ihr Betrieb für seinen letzten Vorfall dieselbe Zeitleiste liefern? Wer anhalten darf, sollte vorher feststehen; darum ging es in meinem Beitrag zum Not-Aus für KI. Hier geht es um die Frage, die nach jedem Alarm kommt: Bleibt das im Haus, oder muss es raus?

Die Schwelle ist eine Entscheidung, kein Messwert

Jede Erkennung hat zwei Schwellen. Die erste ist technisch: Ab welchem Wert schlägt der Alarm an? Die setzt meist die IT oder der Anbieter. Die zweite ist organisatorisch: Ab wann verlässt ein erkannter Vorfall das Haus? Diese zweite Schwelle hat in vielen Betrieben niemand festgelegt. Sie entsteht im Ernstfall, am Telefon, aus dem Bauch.

Nehmen Sie den Fall vom Anfang. Ihre Netzwerküberwachung meldet, dass ein Mitarbeiter eine Preisliste mit Kundennamen und Ansprechpartnern in sein privates Chatbot-Konto geladen hat. Daran hängen gleich mehrere Meldewege, jeder mit eigener Schwelle:

• An die Datenschutzaufsicht, wenn die Datei personenbezogene Daten enthält und ein Risiko für die Betroffenen nicht ausgeschlossen ist.
• An den Kunden, wenn Ihr Vertrag oder die Geheimhaltungsvereinbarung eine Benachrichtigung verlangt. Prüfen Sie die Vereinbarungen Ihrer größten Kunden auf eine solche Klausel.
• An das BSI, wenn Ihr Betrieb unter das BSI-Gesetz fällt und der Vorfall erheblich ist.
• An die Polizei, wenn Sie den Verdacht haben, dass Geschäftsgeheimnisse gezielt abfließen.

Vier Adressaten, vier Schwellen, und meist eine Person, die am Montagmorgen allein entscheidet. Oft ist das dieselbe Person, die die Folgen einer Meldung tragen müsste: Ärger mit dem Kunden, Fragen der Behörde, ein schwieriges Gespräch mit dem Mitarbeiter. Wer selbst betroffen ist, legt die Schwelle selten zu niedrig.

Die Rückseite gehört dazu. Eine zu niedrige Schwelle schadet ebenfalls. Wer jeden Fehlalarm an Behörde und Kunden weitergibt, verliert deren Aufmerksamkeit für den echten Fall. Wer einen Mitarbeiter wegen eines Missverständnisses anzeigt, beschädigt einen Menschen und das Vertrauen der ganzen Belegschaft. OpenAI benennt dieselbe Spannung im Brief: die Privatsphäre der allermeisten Nutzer auf der einen Seite, die Sicherheit Dritter auf der anderen. Melden um jeden Preis ist deshalb keine Lösung. Die Lösung ist eine Schwelle, die jemand bewusst gesetzt, begründet und befristet hat.

Praktisch heißt das: Die Schwelle steht schriftlich fest, mit Namen und Datum. Sie hat Beispiele dafür, was darüber liegt und was darunter. Sie hat eine Wiedervorlage, spätestens nach jedem echten Vorfall. Und das Nein wird genauso festgehalten wie das Ja.

Die Uhr läuft ab dem Erkennen

Das Recht kennt diese Schwellen längst, und an einer Stelle ist es strenger, als viele denken. Art. 33 Abs. 1 DSGVO verlangt, eine Datenschutzverletzung unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde zu melden. Ausgenommen ist eine Verletzung, die voraussichtlich zu keinem Risiko für die Betroffenen führt. Diese Ausnahme ist eine Schwelle, die Sie selbst anwenden. Abs. 5 macht sie prüfbar: Sie dokumentieren jede Verletzung mit Fakten, Auswirkungen und Abhilfe, und zwar so, dass die Behörde Ihre Entscheidung nachvollziehen kann. Wer nicht meldet, muss also begründen können, warum nicht.

Abs. 2 betrifft Ihre Dienstleister. Ein Auftragsverarbeiter, auch ein KI-Anbieter, der für Sie personenbezogene Daten verarbeitet, meldet Ihnen eine Verletzung unverzüglich. Wie schnell das in der Praxis geht und über welchen Weg, steht im Vertrag zur Auftragsverarbeitung. Oder es steht nirgends.

Eine Änderung ist vorgeschlagen, beschlossen ist sie nicht. Die EU-Kommission will mit dem Vorschlag COM(2025) 837 vom 19. November 2025 die Meldepflicht auf Verletzungen mit voraussichtlich hohem Risiko beschränken und die Frist auf 96 Stunden verlängern. Das Verfahren 2025/0360(COD) wartet im Parlament laut Legislative Observatory am 1. November 2026 noch auf die Entscheidung im Ausschuss. Die Dokumentationspflicht in Abs. 5 lässt der Vorschlag unangetastet.

Für Betriebe, die als wichtige oder besonders wichtige Einrichtung unter das BSI-Gesetz fallen, gilt § 32 BSIG. Eine frühe Erstmeldung ist spätestens 24 Stunden fällig, nachdem Sie von einem erheblichen Sicherheitsvorfall erfahren haben, die eigentliche Meldung nach 72 Stunden, die Abschlussmeldung einen Monat danach. Wer am Freitagabend vom Vorfall erfährt, muss die Erstmeldung bis Samstagabend abgegeben haben. Auch „erheblich“ ist eine Schwelle.

Für Hochrisiko-KI regelt die KI-Verordnung die Kette ausdrücklich. Betreiber überwachen das System, informieren bei einem Risiko den Anbieter und die Marktüberwachungsbehörde und setzen die Nutzung aus. Einen schwerwiegenden Vorfall melden sie unverzüglich, zuerst dem Anbieter (Art. 26 Abs. 5). Der Anbieter meldet ihn der Behörde, spätestens nach 15 Tagen, bei einem Todesfall nach 10 Tagen, bei einem weitverbreiteten Verstoß oder einer schweren und unumkehrbaren Störung kritischer Infrastruktur nach 2 Tagen. Ein unvollständiger Erstbericht ist ausdrücklich erlaubt (Art. 73 Abs. 2 bis 5). Die Aufsicht muss den Betrieb mit einer Stopptaste anhalten können (Art. 14 Abs. 4 Buchst. e). Die Pflichten aus Art. 14 und 26 gelten für Systeme nach Anhang III ab dem 2. Dezember 2027 (Art. 113 Buchst. c in der Fassung der Verordnung (EU) 2026/1744).

Allen drei Regelwerken ist eines gemeinsam. Die Frist beginnt mit der Kenntnis, nicht mit der Entscheidung. Jede Stunde, die ein Alarm unbearbeitet liegt, fehlt danach bei der Meldung.

Was ich im Audit dazu sehen will

Die Normen haben dafür eigene Maßnahmen, und im Gespräch mit Geschäftsführern kommen sie selten vor. ISO/IEC 27001 trennt im Anhang A, was im Ernstfall nacheinander passieren muss: Planung und Vorbereitung des Vorfallmanagements (A.5.24), Beurteilung von Ereignissen und Entscheidung darüber (A.5.25), Reaktion auf den Vorfall (A.5.26), Sicherung von Beweisen (A.5.28). Dazu kommen die Meldung von Ereignissen durch die Beschäftigten (A.6.8) und der Kontakt zu Behörden (A.5.5). Die Entscheidung ist dort eine eigene Maßnahme. Genau die fehlte im zweiten Fall zweieinhalb Stunden lang.

ISO/IEC 42001 verlangt in Anhang A.8.4 (Meldung von Vorfällen) einen festgelegten und dokumentierten Plan, wie Vorfälle an die Benutzer eines KI-Systems gemeldet werden. Die Hinweise in Anhang B nennen, was in so einen Plan gehört: welche Vorfälle zu melden sind, bis wann, ob eine Behörde zu informieren ist und mit welchen Angaben. Wer schon ein Vorfallmanagement nach ISO/IEC 27001 betreibt, kann den KI-Teil dort einhängen. Einen zweiten Prozess braucht es dafür nicht.

Im Audit würde ich an dieser Stelle nicht nach dem Plan fragen. Ich würde nach dem letzten Ereignis fragen, das nicht gemeldet wurde, und mir die Begründung zeigen lassen. Drei Antwortmuster, schwach und belastbar:

• Schwach: Bei einem Vorfall ruft die IT den Geschäftsführer an. Belastbar: Hier ist die Liste, wer welchen Alarm bekommt, mit Vertretung und Erreichbarkeit am Wochenende.
• Schwach: Gemeldet wird, was meldepflichtig ist. Belastbar: Hier stehen die Schwellen je Adressat, mit Beispielen, mit dem Datum der Festlegung und dem Datum der letzten Prüfung.
• Schwach: Wir hatten keinen meldepflichtigen Vorfall. Belastbar: Hier sind die Ereignisse dieses Jahres, und bei jedem steht, wer entschieden hat, wann und warum.

Fünf Fragen für die nächste Runde der Geschäftsführung:

• Wer bekommt einen Alarm aus Netzwerküberwachung, Virenschutz oder KI-Protokoll, und wer vertritt diese Person nachts und am Wochenende?
• Welche Schwelle gilt für welche Meldung, an Aufsichtsbehörde, Kunde, BSI und Polizei, und wer hat sie wann festgelegt?
• Wer entscheidet im Einzelfall, und bis wann nach dem Alarm?
• Wo steht die Begründung, wenn nicht gemeldet wird?
• Was meldet Ihnen Ihr KI-Anbieter, über welchen Weg und in welcher Frist?

Spielen Sie das einmal durch, mit der Uhr auf dem Tisch. Ein erfundener Alarm am Freitag um 17 Uhr reicht. Danach wissen Sie, ob Ihre Meldekette ein Ablauf ist oder ein Telefonbuch. Und wenn bei Ihnen morgen um 9:50 Uhr ein Alarm kommt: Wer entscheidet bis wann, und wo steht das?