KI im Notfallplan: Wer handelt im Ernstfall?

Eine täuschend echte E-Mail, ein gefälschter Anruf oder eine auffällige Aktion einer KI-Anwendung: Im Ernstfall hilft kein allgemeiner Hinweis auf „die IT“. Es muss klar sein, wer den Vorgang entgegennimmt, Schäden begrenzt und über die nächsten Schritte entscheidet. Die im Oktober veröffentlichte KI-Sicherheitsstudie von BSI und TÜV-Verband liefert dafür einen konkreten Anlass, bestehende Abläufe zu überprüfen.

Was die Studie tatsächlich über Vorfallprozesse sagt

Laut der KI-Sicherheitsstudie 2026 haben 11 Prozent der Unternehmen mit bestehender oder geplanter KI-Nutzung spezielle Prozesse für KI-bezogene Sicherheitsvorfälle. Weitere 43 Prozent greifen auf allgemeine IT-Sicherheitsprozesse zurück, bislang ohne spezielle KI-Regeln. 25 Prozent nennen dafür bisher keine Regelungen. Die Untersuchung wurde am 7. Oktober veröffentlicht; die Fachberichterstattung vom 28. Oktober greift die Ergebnisse erneut auf.

Wichtig ist der Gegenstand der Frage: Der Studienbericht, Seite 47, behandelt an dieser Stelle die Reaktion auf Cyberangriffe oder Betrugsversuche, bei denen Täter KI einsetzen. Die Zahl ist kein Nachweis, dass alle übrigen Unternehmen ungeschützt sind oder dass dort jeder Notfallablauf fehlt. Ebenso lässt sich daraus nicht unmittelbar ableiten, wie gut Unternehmen Störungen ihrer eigenen KI-Anwendungen beherrschen.

Die gesamte forsa-Befragung umfasst 505 Unternehmen ab 20 Mitarbeitenden in Deutschland. Befragt wurden Verantwortliche für KI, IT-Sicherheit, IT-Leitung oder Geschäftsleitungen zwischen dem 22. Juni und dem 31. Juli 2026. Die Prozentwerte sind Selbstauskünfte, keine Ergebnisse technischer Sicherheitsprüfungen.

Zwei Arten von KI-Bezug unterscheiden

Für die eigene Organisation lohnt es sich, zwei Perspektiven getrennt durchzugehen. Erstens: Angreifer nutzen KI, etwa für glaubwürdige Phishing-Nachrichten oder gefälschte Stimmen. Der Notfallablauf muss dafür nicht vollständig neu erfunden werden. Aber Rückrufverfahren, Zahlungsfreigaben und interne Meldungen sollten auch dann funktionieren, wenn Sprache und Auftreten überzeugend wirken.

Zweitens: Die eigene KI-Anwendung ist am Vorfall beteiligt, etwa weil ein angeschlossener Dienst ungewöhnliche Aktionen ausführt oder vertrauliche Inhalte in einer Ausgabe erscheinen. Das ist ein anderes Szenario mit anderen Eingriffsmöglichkeiten. Wer darf Zugriffe sperren, eine Verbindung trennen oder die Anwendung vorübergehend deaktivieren? Welche betrieblichen Abläufe hängen daran? Diese Fragen sollten vorab mit den technisch und fachlich Verantwortlichen geklärt werden.

Für KI-Agenten nennt OWASP unter anderem begrenzte Werkzeugrechte, menschliche Kontrolle risikoreicher Aktionen und nachvollziehbare Protokollierung. Das sind technische Schutzprinzipien. Ein betrieblicher Reaktionsablauf ergänzt sie um Zuständigkeiten und Entscheidungen; er ersetzt sie nicht.

Fünf Entscheidungen im bestehenden Ablauf ergänzen

Die folgende Übersicht ist eine organisatorische Arbeitshilfe, keine neue gesetzliche oder normative Pflichtliste. Prüfen Sie sie zunächst an einer tatsächlich genutzten Anwendung oder einem konkreten Betrugsszenario.

Ein Beispiel: Ein vermeintlicher Anruf der Geschäftsleitung verlangt eine ungewöhnliche Zahlung. Der erste sinnvolle Schritt kann darin bestehen, die Zahlung auszusetzen und die Anweisung über einen bereits bekannten, unabhängigen Kontaktweg zu prüfen. Dafür muss niemand zuerst beweisen, dass die Stimme KI-generiert war. Das weitere Vorgehen richtet sich nach dem Sachverhalt und dem bestehenden Sicherheitsprozess.

Auch bei einer auffälligen KI-Anwendung ist pauschales Ausschalten nicht immer die richtige Sofortmaßnahme. Eingriffe müssen Schäden begrenzen und zugleich wichtige Nachweise sowie betriebliche Abhängigkeiten berücksichtigen. Solche Entscheidungen gehören in die Hände der zuständigen Personen, nicht in eine allgemeine Chatbot-Anweisung.

Den Ablauf proben, statt einen weiteren Ordner anzulegen

Eine kurze Besprechungsübung macht Lücken oft verständlicher als ein zusätzlicher Richtlinientext. Verwenden Sie ausschließlich fiktive oder geeignete Testdaten, keine echten Geheimnisse. Ein mögliches Szenario: Ein externer Dienstleister meldet, dass eine angebliche interne Anweisung von einer unbekannten Adresse kam und ungewöhnliche Daten anfordert.

Lassen Sie die Beteiligten erklären, was sie konkret tun würden. Wo liegt der Meldeweg? Wer kann den betroffenen Vorgang stoppen? Welche Person kann Protokolle bereitstellen? Wer spricht mit dem Dienstleister? Dokumentieren Sie dabei ungeklärte Zuständigkeiten und fehlende Zugriffe, nicht nur die Teilnahme an der Übung.

Leiten Sie daraus wenige umsetzbare Verbesserungen mit Verantwortlichen und Termin ab. Eine aktualisierte Kontaktliste, ein verlässlicher Rückrufweg oder ein getesteter Zugriff auf Protokolle kann hilfreicher sein als eine weitere abstrakte Regel. Prüfen Sie anschließend am selben Szenario, ob die Änderung tatsächlich funktioniert.

Fazit

KI-bezogene Vorfälle brauchen handlungsfähige Menschen, klare Eingriffsmöglichkeiten und einen nachvollziehbaren Ablauf. Entscheidend ist, welche vorhandenen Sicherheitsprozesse weiterhelfen und welche Ergänzungen das konkrete Szenario benötigt. Aus einer niedrigen Quote spezieller KI-Prozesse folgt weder eine pauschale Schutzlosigkeit noch die Notwendigkeit eines vollständig neuen Parallel-Systems.

Die Risiko- und Maßnahmenplanung ist ein sinnvoller Ort, erkannte Lücken mit Zuständigkeiten und Verbesserungen zu verbinden. IMScollect unterstützt die organisatorische Dokumentation von Risiken, Maßnahmen und Verantwortlichkeiten. Technische Erkennung, Zugriffssperren oder das Abschalten externer KI-Anwendungen ersetzt die Software damit nicht. Wie sich die organisatorische Nachverfolgung für Ihren konkreten Fall abbilden lässt, kann eine Demo mit Ihrem eigenen Ablauf zeigen.