Eine Notfallnummer ist noch keine Reaktion

Kurzfassung: Ein KI-Notfallkontakt schützt erst, wenn eine Meldung rechtzeitig eine wirksame Handlung auslöst. Unternehmen sollten die gesamte Kette mit ihren Anbietern üben: von der Erkennung über den bestätigten Empfang bis zur Begrenzung des Schadens.

Die Sicherheitsabteilung hat eine Telefonnummer. Der Anbieter hat ein Ticketsystem. Im Vertrag steht, dass Vorfälle unverzüglich gemeldet werden. Das wirkt ordentlich. Es beantwortet aber noch nicht die entscheidende Frage: Was ist im eigenen Betrieb bereits passiert, bevor auf der anderen Seite jemand handelt?

Für agentische KI ist diese Frage besonders konkret. Sobald ein System Geschäftsvorgänge auslösen darf, endet sein Fehler nicht unbedingt mit einer falschen Antwort auf dem Bildschirm. Es kann fehlerhafte Nachrichten weitergeben, Daten verändern oder weitere Werkzeuge aufrufen. Welche Schäden daraus entstehen und wie schnell, hängt vom jeweiligen Aufbau ab. Eine universelle KI-Notfallfrist lässt sich daraus nicht ableiten. Wohl aber eine Managementaufgabe: Die Reaktionskette muss zum tatsächlichen Handlungsspielraum des Systems passen.

Gemeldet heißt nicht begrenzt

Die im April 2025 veröffentlichte NIST-Leitlinie zur Behandlung von Cybervorfällen, SP 800-61 Revision 3, empfiehlt vorab vereinbarte Koordination mit betroffenen Parteien. Unter RS.CO-02 beschreibt sie Meldeverfahren, die festlegen, was an wen und zu welchen Zeitpunkten berichtet wird. Unter ID.IM-02 nennt sie Übungen mit Lieferanten und relevanten Dritten als Mittel zur Vorbereitung und Verbesserung.

Das ist eine Cybersecurity-Leitlinie, keine besondere Vorschrift für autonome KI und keine neue Nachricht aus dem Oktober 2026. Ihr Ansatz ist für KI-Anwendungen dennoch brauchbar: Eine Kontaktliste und ein vereinbartes Verfahren sind Voraussetzungen, nicht der Nachweis ihrer Wirksamkeit.

Zwischen einem auffälligen Ereignis und einer Schutzhandlung können mehrere Wartezeiten liegen. Ein Alarm muss erkannt und eingeordnet werden. Die richtige Stelle muss die Meldung erhalten. Dort braucht jemand genügend Informationen und die Befugnis, etwas zu ändern. Schließlich muss die vereinbarte Maßnahme tatsächlich im betroffenen System greifen.

Eine automatische Eingangsbestätigung belegt nur den Empfang im Ticketsystem. Sie belegt weder die Einschätzung des Vorfalls noch eine technische Sperre. Auch die Zusage „Wir haben eskaliert“ ist noch kein Nachweis, dass weitere schädliche Aktionen verhindert werden.

Die Uhr läuft über Unternehmensgrenzen

Ein hypothetischer Mittelständler lässt einen Serviceagenten Kundenfälle bearbeiten. Der Agent darf auf ein Ticketsystem zugreifen und vorbereitete Nachrichten versenden. Nach einer manipulierten Eingabe besteht der Verdacht, dass Kundendaten in eine falsche Antwort geraten sind. Der interne Betrieb kann den Nachrichtenversand sperren. Ob beim Modellanbieter zusätzliche Vorgänge laufen oder relevante Aufzeichnungen verfügbar sind, muss dagegen mit dessen Bereitschaft geklärt werden.

In diesem Fall sind zwei Reaktionen nötig, aber sie dürfen nicht verwechselt werden. Die lokale Sperre begrenzt weitere eigene Versendungen. Die externe Abstimmung soll Umfang, Ursache und gegebenenfalls weitere Maßnahmen klären. Wartet das Unternehmen mit einer verfügbaren lokalen Schutzhandlung auf die Antwort des Anbieters, verlängert es möglicherweise unnötig den Zeitraum, in dem weitere Vorgänge entstehen können.

Umgekehrt kann es nicht so tun, als kontrolliere es sämtliche Wirkungen selbst. Ein eigener Stopp beendet nicht automatisch jeden bereits ausgelösten Vorgang in fremden Systemen. Die Abhängigkeiten müssen deshalb vorher bekannt sein: Was lässt sich lokal unterbinden, was verlangt eine Handlung des Dienstleisters, und welche Auswirkungen sind bereits unumkehrbar?

Diese Unterscheidung verändert die Beschaffung. Ein Notfallkontakt sollte nicht nur namentlich benannt sein. Geklärt werden müssen Erreichbarkeit, Ersatzweg, benötigte Informationen und die Handlungsmöglichkeiten der erreichbaren Stelle. Wer lediglich an einen allgemeinen Supportkanal melden kann, sollte diesen nicht als sofort verfügbare technische Eingriffsmöglichkeit kalkulieren.

Eine Übung braucht ein sichtbares Ende

Für einen ersten Test genügt ein enges, vereinbartes Szenario mit ungefährlichen Testdaten. Das Unternehmen und sein Anbieter spielen einen konkreten Vorfall durch. Der Zweck ist nicht, möglichst dramatische Angriffe zu simulieren, sondern die Übergaben zu prüfen.

Als eigene Managementableitung aus der NIST-Leitlinie bietet sich an, mindestens vier Zeitpunkte festzuhalten:

• Wann wird das relevante Ereignis für den Betrieb erkennbar?
• Wann erreicht eine ausreichende Meldung die zuständige externe Stelle?
• Wann bestätigt eine handlungsfähige Person die Übernahme?
• Wann ist die vereinbarte Schutzwirkung nachgewiesen?

Der letzte Punkt entscheidet. Eine Sperre lässt sich etwa daran prüfen, dass ein weiterer ungefährlicher Testvorgang nicht mehr ausgeführt wird. Ein Gesprächsprotokoll allein reicht dafür nicht. Bei anderen Maßnahmen braucht es einen anderen passenden Nachweis.

Die gemessene Zeitkette wird anschließend mit dem Szenario verglichen. Könnten bis zur wirksamen Begrenzung bereits weitere schädliche Vorgänge entstehen? Gibt es eine lokale Zwischenmaßnahme? Welcher Ersatzkontakt übernimmt, wenn die erste Stelle nicht reagiert? Solche Fragen ergeben ein brauchbares Zeitbudget. Es ist eine organisations- und szenariospezifische Festlegung, keine von NIST vorgegebene Minutenfrist.

Eine Übung zu Bürozeiten sagt außerdem wenig über einen Vorfall am Wochenende aus, wenn dann andere Zuständigkeiten gelten. Nicht jeder Test muss unter ungünstigsten Bedingungen stattfinden. Aber sein Ergebnis darf nur für die Bedingungen gelten, die tatsächlich geprüft wurden.

Die Konsequenz gehört zurück in den Auftrag

Scheitert die Übung an einer unvollständigen Meldung, braucht das Unternehmen ein besseres Meldeschema. Fehlt der erreichbaren Stelle das Eingriffsrecht, muss die Zuständigkeit geändert werden. Dauert die externe Reaktion länger als vertretbar, kommen lokale Begrenzungen, ein kleinerer autonomer Handlungsspielraum oder ein anderer Bereitschaftsservice in Betracht.

Nicht jede Anwendung benötigt denselben Aufwand. Ein interner Entwurfsassistent ohne Schreib- oder Versandrechte hat andere Folgen als ein Agent, der Kundenprozesse selbstständig verändert. Geschäftsführung und Fachbereich sollten daher zuerst die kritischen Handlungen bestimmen. Informationssicherheit und Betrieb können daraus das passende Übungsszenario entwickeln; Einkauf und Anbieter klären die zugesagte Unterstützung.

Die Meldekette ersetzt dabei weder gesetzliche Berichtspflichten noch den eigenen Pausenplan. Sie ergänzt ihn um einen anderen Prüfgegenstand: die rechtzeitige Zusammenarbeit zwischen Organisationen. Interner Stopp, externe Abstimmung und spätere Untersuchung können unterschiedliche Verantwortliche und unterschiedliche Zeitmaßstäbe haben.

Wer KI-Notfallkommunikation ernst nimmt, bestellt deshalb nicht bloß einen Kontakt. Er klärt, welche Handlung dieser Kontakt auslösen kann, und prüft die gesamte Strecke dorthin. Eine Nummer im Handbuch ist schnell ergänzt. Belastbar wird sie erst, wenn aus der Meldung rechtzeitig Schutz entsteht.