Nur jedes zehnte Unternehmen hat einen Prozess für KI-Vorfälle: die Notfallvorlage auf einer Seite

/01Was BSI und TÜV-Verband am 7. Oktober veröffentlicht haben

Ein eigener Notfallprozess für KI-Vorfälle ist im deutschen Mittelstand die Ausnahme: Nur 11 Prozent der Unternehmen, die KI nutzen oder planen, haben einen. Das ist der Kernbefund der „KI-Sicherheitsstudie 2026", die das Bundesamt für Sicherheit in der Informationstechnik und der TÜV-Verband am 7. Oktober 2026 gemeinsam vorgestellt haben. Die Pressemitteilung des BSI trägt die Überschrift „Nur jedes zehnte Unternehmen gegen KI-gestützte Angriffe gerüstet – jedes sechste Unternehmen berichtet von Vorfällen".

Die Studie ist eine Befragung, keine Messung. Laut Methodikseite des PDF hat forsa im Auftrag von BSI und TÜV-Verband zwischen dem 22. Juni und dem 31. Juli 2026 telefonisch (CATI) 505 Unternehmen befragt; die Pressemitteilung nennt Unternehmen ab 20 Beschäftigten. Am Telefon waren Verantwortliche für KI-Nutzung, IT-Sicherheit, IT-Leitung oder Geschäftsleitung. Der TÜV-Verband hat am 13. Oktober 2026 eine zweite Pressemitteilung nachgelegt, die sich auf die Fragen zu KI-Agenten konzentriert.

Die Empfehlung der Herausgeber ist ungewöhnlich konkret. Im Fazit des PDF steht unter der Überschrift „Notfallprozesse einüben": Bestehende IT-Sicherheits- und Notfallprozesse seien um KI-Szenarien wie Datenabflüsse, manipulierte Inhalte und ungewollte Agentenaktionen zu ergänzen. Dr. Dirk Stenkamp vom TÜV-Verband sagt in der Pressemitteilung dasselbe in einem Satz: Unternehmen sollten KI-bezogene Szenarien in ihre Sicherheits- und Notfallprozesse aufnehmen.

Dieser Artikel nimmt die Empfehlung beim Wort. Er ordnet die Zahlen ein, die für Betreiber eigener KI-Systeme zählen, trennt die zwei Arten von „KI-Vorfall", die in der Studie zusammenlaufen, und liefert eine Notfallvorlage auf einer Seite – mit Rollen, Abschaltbefehlen, Log-Sicherung und Meldewegen. Grundlagen zu KI-Risiken und Governance stehen im Bestandsartikel KI-Sicherheit und Risikomanagement; hier geht es um die erste Stunde nach dem Alarm.

/02Die Zahlen der KI-Sicherheitsstudie 2026 und wie sie gefragt wurden

Prozentwerte aus Befragungen taugen nur mit der Frage dazu. Die folgende Tabelle nennt deshalb je Wert den Wortlaut der Frage aus dem PDF und, soweit der Text es angibt, die Grundgesamtheit. Wo der Text die Basis nicht ausweist, steht das dabei.

Zwei Lesarten drängen sich auf, und beide sind falsch. Die erste: „17 Prozent hatten einen KI-Vorfall." Die Frage zielt auf Cyberangriffe und Betrugsversuche, bei denen KI eine Rolle gespielt hat – in neun von zehn Fällen hochrealistische Phishing-Mails. Über Angriffe auf das eigene Sprachmodell, auf eine RAG-Anwendung oder einen Agenten sagt der Wert nichts. Die zweite: „Wer keinen KI-Prozess hat, ist ungeschützt." 43 Prozent verlassen sich auf allgemeine IT-Sicherheitsprozesse; für den Phishing-Fall ist das oft ausreichend.

Der Wert, der Betreibern eigener Systeme zu denken geben sollte, ist ein anderer: 40 Prozent protokollieren oder überwachen die KI-Nutzung. Ohne Protokoll lässt sich nach einem Vorfall weder sagen, welcher Prompt welchen Werkzeugaufruf ausgelöst hat, noch, welche Daten in welcher Antwort standen. Ein Notfallprozess ohne Protokoll ist ein Formular ohne Inhalt. Stenkamp formuliert es vorsichtig: Was Unternehmen registriert hätten, „könnte deshalb nur die Spitze des Eisbergs sein".

/03Was als KI-Vorfall zählt: zwei Richtungen, vier Klassen

Die Studie fragt nach „KI-bezogenen Sicherheitsvorfällen" und lässt offen, ob KI Werkzeug des Angreifers oder Ziel des Angriffs ist. Für einen Notfallprozess muss das getrennt werden, weil die Maßnahmen verschieden sind. In der Praxis haben sich vier Klassen bewährt.

• Klasse 1 – KI als Angriffswerkzeug: KI-Phishing, Deepfake-Anruf, automatisierte Schwachstellensuche gegen Ihre Systeme. Der bestehende IT-Notfallprozess greift; ergänzt wird nur die Rückbestätigung über einen zweiten Kanal. Das Handout der Allianz für Cyber-Sicherheit zur Studie empfiehlt dafür Rückruf über eine bekannte Nummer, ein vereinbartes Signalwort und das Vier-Augen-Prinzip bei Überweisungen.
• Klasse 2 – Datenabfluss über das KI-System: Eine Antwort enthält Daten, die der Fragende nicht sehen durfte; ein Agent schickt Inhalte an ein externes Ziel; eine Prompt Injection in einem Dokument bringt das Modell dazu, Inhalte der Wissensbasis preiszugeben (Vorbeugung im RAG: BSI-Basisschutz gegen Prompt Injection). Hier entscheidet die Uhr der Datenschutzmeldung.
• Klasse 3 – ungewollte Aktion: Ein Agent löscht, bucht, versendet oder ändert etwas ohne Auftrag – durch Fehlinterpretation, Halluzinationen oder eingeschleuste Anweisung. Die erste Maßnahme ist das Entziehen der Rechte, nicht die Ursachensuche.
• Klasse 4 – manipulierte oder kompromittierte Komponente: verändertes Modell, vergifteter Index in der Vektordatenbank, Schwachstelle im Inferenzserver, gestohlener Gateway-Schlüssel. Das ist ein klassischer Sicherheitsvorfall auf KI-Infrastruktur und wird wie einer behandelt: isolieren, sichern, analysieren.

Schweregrade ordnen die Klassen nach Wirkung, nicht nach Technik. Bewährt hat sich eine dreistufige Einteilung: S1 – personenbezogene oder vertrauliche Daten sind abgeflossen oder ein Agent hat eine irreversible Aktion ausgeführt; S2 – Verdacht ohne bestätigten Schaden, oder ein Schaden ist durch Freigaben aufgefangen worden; S3 – Fehlverhalten ohne Datenbezug, etwa ein gelungener Jailbreak ohne Zugriff auf interne Daten. S1 weckt die Geschäftsleitung, S3 wird am nächsten Werktag bearbeitet.

/04Die Notfallvorlage für KI-Vorfälle auf einer Seite

Die folgende Vorlage ist so geschrieben, dass sie ausgedruckt neben dem IT-Notfallplan hängen kann. Sie ersetzt ihn nicht, sie ergänzt ihn um die Schritte, die bei KI-Systemen anders sind. Die Namen in eckigen Klammern tragen Sie ein; die Befehle stehen in Abschnitt /05.

Drei Entscheidungen stecken in dieser Tabelle, die man vorher treffen muss, weil man sie im Ernstfall nicht mehr ruhig treffen kann. Erstens: Wer darf ein produktives KI-System ohne Rückfrage abschalten? Die Antwort sollte „die Technik, bei S1 immer" lauten – ein abgeschalteter Assistent kostet einen halben Arbeitstag, ein weiterlaufender Agent mit Datenabfluss kostet eine Meldung. Zweitens: Was ist der Rückfallbetrieb? Für einen internen Chat reicht „vorübergehend nicht verfügbar"; für einen Agenten in der Rechnungsprüfung braucht es den manuellen Ablauf von vorher. Drittens: Wer spricht mit Kunden, wenn eine Kundenanwendung betroffen ist?

Ehrlich: Die Minutenwerte sind unsere Empfehlung, kein Normwert. Weder der Grundschutz-Baustein DER.2.1 noch der BSI-Standard 200-4 noch NIST SP 800-61r3 schreiben Minuten vor; 200-4 leitet Zeiten aus der Business-Impact-Analyse ab, DER.2.1.A22 verlangt, die Zeit von Erstmeldung bis Bestätigung zu messen. Gesetzlich fest sind nur Meldefristen wie die 72 Stunden der DSGVO – und davon sollten nicht zwei für die Frage vergehen, wer zuständig ist.

/05Abschalten und Logs sichern: die Befehle für die erste halbe Stunde

Ein Eindämmungsschritt muss in einem Satz beschreibbar und in einer Minute ausführbar sein. Die folgenden Befehle setzen einen typischen On-Premise-Stack voraus: ein Gateway vor den Modellen, vLLM oder Ollama als Inferenzserver in Docker oder als systemd-Dienst, Agenten mit eigenen Dienstkonten. Passen Sie Namen und Pfade an und legen Sie die fertige Fassung neben die Vorlage.

# --- 3a) Agent stoppen: Rechte entziehen, bevor Sie Ursachen suchen ---
# Dienstkonto des Agenten im Verzeichnisdienst sperren (Beispiel Samba/AD)
samba-tool user disable agent-rechnung
# API-Schlüssel des Agenten am Gateway sperren (Beispiel LiteLLM-Proxy)
curl -s -X POST http://gateway.intern:4000/key/block \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" -d '{"key": "sk-agent-rechnung"}'

# --- 3b) Route abschalten: Nutzer sehen eine Wartungsmeldung statt einer Antwort ---
# nginx vor dem Modell: location /v1/ { return 503; }  in die Notfall-Datei
sudo ln -sf /etc/nginx/notfall/ki-503.conf /etc/nginx/conf.d/ki-route.conf
sudo nginx -t && sudo systemctl reload nginx

# --- 3c) Modellserver anhalten, NICHT löschen ---
docker pause vllm              # friert Prozesse ein, Arbeitsspeicher bleibt erhalten
sudo systemctl stop ollama     # systemd-Dienst: Stopp, Daten bleiben auf der Platte

# --- 4) Beweise sichern, bevor rotiert oder neu gestartet wird ---
F=/srv/forensik/$(date +%F_%H%M)_ki-vorfall; sudo install -d -o "$USER" "$F"
docker logs --timestamps vllm          > "$F/vllm.log" 2>&1
docker inspect vllm                    > "$F/vllm-inspect.json"
sudo journalctl -u ollama --since "-48h" -o json > "$F/ollama.json"
sudo journalctl -u nginx  --since "-48h" -o json > "$F/nginx.json"
sudo cp -a /var/log/litellm /var/log/agenten "$F/" 2>/dev/null
nvidia-smi -q                          > "$F/gpu-zustand.txt"
(cd "$F" && sudo find . -type f ! -name SHA256SUMS -exec sha256sum {} + | sudo tee SHA256SUMS >/dev/null)
sudo chattr -R +i "$F"                 # schreibgeschützt bis zur Freigabe

Zwei Details entscheiden darüber, ob die Sicherung später etwas taugt. docker pause statt docker stop: Ein angehaltener Container behält Prozesse und Arbeitsspeicher, ein gestoppter verliert beides. Für die Frage, welche Anfragen noch in der Warteschlange lagen, ist das der Unterschied zwischen Befund und Vermutung. Und die Prüfsummen gehören in dieselbe Minute wie der Export – eine Datei, deren Hash erst am nächsten Tag gebildet wurde, beweist nur ihren Zustand am nächsten Tag.

Was gesichert wird, hängt davon ab, was protokolliert wurde – und hier liegt die eigentliche Arbeit vor dem Vorfall. Ein brauchbares Protokoll eines Sprachmodell-Stacks enthält je Anfrage: Zeitstempel, Nutzer oder Dienstkonto, Modell und Modellversion, den Systemprompt-Stand, die abgerufenen Dokumente bei RAG, jeden Werkzeugaufruf mit Parametern und Ergebnis, und die Antwort. Wie man das datensparsam baut, mit Pseudonymisierung und Zweckbindung, beschreibt der Bestandsartikel zu Vorfallmeldung und Audit-Log nach Artikel 73.

Der vierte Fall der Eindämmung ist der unangenehmste: der vergiftete Index. Wenn eine eingeschleuste Anweisung in einem Dokument steckt, das im Index liegt, hilft das Abschalten des Modells nur bis zum Neustart. Frieren Sie den Index ein (Schreibrechte entziehen, Snapshot ziehen), identifizieren Sie das Dokument über die Abrufprotokolle und entfernen Sie es aus der Quelle, nicht nur aus dem Index – sonst kommt es beim nächsten Einlesen zurück.

/06Meldewege und Fristen: DSGVO, AI Act, Versicherung

Ein KI-Vorfall löst nicht automatisch eine Meldepflicht aus. Er löst die Pflicht aus, zu prüfen, ob eine besteht – und diese Prüfung ist fristgebunden.

Datenschutz. Sind personenbezogene Daten betroffen – eine Antwort mit Personaldaten an den falschen Empfänger, ein Agent, der Kundendaten an ein externes Ziel schickt –, greift Art. 33 DSGVO: Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem der Verantwortliche Kenntnis erlangt hat, es sei denn, ein Risiko für die Betroffenen ist unwahrscheinlich. Für nicht-öffentliche Stellen in Bayern ist das Bayerische Landesamt für Datenschutzaufsicht zuständig; es bietet ein Online-Formular, das ausdrücklich auch eine vorläufige Meldung mit Risikoschätzung und eine spätere Folgemeldung erlaubt. Das ist für KI-Vorfälle wichtig, weil die Frage „welche Daten standen in welchen Antworten?" selten in 72 Stunden abschließend beantwortet ist.

AI Act. Der AI Act kennt eine Meldepflicht für schwerwiegende Vorfälle. Nach Art. 73 meldet der Anbieter spätestens 15 Tage nach Kenntnis, bei einem Todesfall binnen 10 Tagen, bei weitverbreitetem Verstoß oder schwerer Störung kritischer Infrastruktur binnen 2 Tagen; ein unvollständiger Erstbericht ist zulässig. Betreiber informieren nach Art. 26 Abs. 5 unverzüglich zuerst den Anbieter. Die Pflicht hängt an Hochrisiko-KI-Systemen, und deren Pflichten gelten nach dem Digital Omnibus erst ab dem 2. Dezember 2027 (Anhang III, etwa Beschäftigung und Bildung) beziehungsweise dem 2. August 2028 (Anhang I, in regulierte Produkte eingebettete Systeme). Ein interner Wissensassistent oder ein Agent in der Rechnungsprüfung ist in aller Regel kein Hochrisiko-System. Wer ein Bewerber-Screening mit KI betreibt, sollte die Meldekette trotzdem jetzt bauen; Inhalte und Audit-Log stehen im Artikel zur Vorfallmeldung nach Artikel 73.

Verträge und Versicherung. Auftragsverarbeitungsverträge verpflichten Auftragsverarbeiter, Datenschutzverletzungen an den Verantwortlichen zu melden; Kundenverträge enthalten oft eigene, kürzere Fristen. Cyberversicherungen verlangen in den Obliegenheiten meist eine unverzügliche Anzeige. Welche Frist für Sie gilt, steht in Ihren Verträgen, nicht in diesem Artikel. Tragen Sie sie in Schritt 5 der Vorlage ein, mit Rufnummer.

Freiwillig, aber nützlich: Über das Melde- und Informationsportal des BSI können Unternehmen Sicherheitsvorfälle auch ohne Meldepflicht melden, ohne Registrierung und auf Wunsch anonym. Für einen Angriff auf ein Agentensystem, der vielleicht andere Häuser genauso trifft, ist das kein Formalismus.

/07Grenzen der Studie und der Vorlage

Ehrlich: Die Studie misst Wahrnehmung, nicht Wirklichkeit. 4 Prozent bestätigte Vorfälle und 11 Prozent Verdachtsfälle sind Selbstauskünfte von Befragten, die am Telefon antworten. Ein Unternehmen ohne Protokollierung kann einen Datenabfluss über einen Assistenten gar nicht bemerken und berichtet folglich keinen. Für Ihre Planung heißt das: Die 17 Prozent sind keine Obergrenze und keine Eintrittswahrscheinlichkeit.

Die Studie sagt auch wenig über Häuser, die KI selbst betreiben. Die Fragen zu Schutzmaßnahmen unterscheiden nicht zwischen einem Cloud-Assistenten im Abonnement und einem On-Premise-Stack mit eigenen Agenten. Für den ersten Fall liegt die Eindämmung beim Anbieter, und Ihr Prozess besteht im Wesentlichen aus Konto sperren, Anbieter anrufen und Meldung prüfen. Die Befehle aus Abschnitt /05 helfen dann nicht.

Die Vorlage hat ebenfalls Grenzen. Sie ersetzt keine Forensik: Wer einen kompromittierten Inferenzserver vermutet, braucht jemanden, der Container-Images und Modelldateien gegen bekannte Stände vergleicht und Speicherabbilder lesen kann. Sie ersetzt keine Rechtsberatung: Ob eine Meldung nötig ist, entscheidet am Ende der Verantwortliche mit seinem Datenschutzbeauftragten. Und sie ist überflüssig, wenn KI im Haus nur aus Textvorschlägen in einer Büroanwendung besteht, ohne Zugriff auf interne Daten – dann genügt ein Absatz im bestehenden IT-Notfallplan.

/08Entscheidung: welcher Notfallprozess zu welchem Haus passt

Die Frage ist nicht „KI-Notfallprozess ja oder nein", sondern wie viel davon. Die Antwort hängt weniger an der Zahl der Beschäftigten als an dem, was die KI darf.

• Nur Assistenz, keine internen Daten (Textentwürfe, Übersetzungen, Recherche): Klasse 1 im bestehenden IT-Notfallplan ergänzen, Rückbestätigung bei Zahlungen einführen, fertig. Ein eigener Prozess wäre Aufwand ohne Gegenwert.
• Assistent mit Zugriff auf interne Dokumente (RAG, Wissensdatenbank): Klassen 2 und 4 aufnehmen, Protokollierung je Anfrage einschalten, Abschaltweg für die Route festlegen. Das ist die Gruppe, in die die meisten Mittelständler mit eigenem System gehören.
• Agenten mit Schreibrechten (Buchung, Versand, Ticketänderung, Werkzeugaufrufe über MCP): alle vier Klassen, die vollständige Vorlage, Sperrbefehle getestet, kritische Aktionen nur nach Freigabe. Die 5 Prozent, die laut Studie Agenten nutzen, gehören hierher – und die 8 Prozent, die es planen, sollten den Prozess vor dem ersten Produktivlauf haben, nicht danach.

Für ein Haus mit 40 Arbeitsplätzen und einem internen Assistenten ist das ein halber Tag: Vorlage ausfüllen, Protokoll einschalten, Abschaltung einmal üben. Mit Agenten in Buchhaltung und Kundendienst wird es ein Projekt, weil Sperrbefehle, Dienstkonten und Rückfallabläufe mit jedem Agenten mitwachsen.

/09Probelauf: die Vorlage in 60 Minuten testen

Ein Notfallprozess, der nie geübt wurde, ist eine Annahme. Die Studie empfiehlt ausdrücklich, Notfallprozesse einzuüben; für KI-Vorfälle reicht dafür eine Stunde im Besprechungsraum, ohne Produktionssystem.

1. Szenario vorlesen (5 Minuten). Beispiel: „Eine Sachbearbeiterin meldet, dass der Assistent ihr auf die Frage nach einem Lieferanten die Gehaltsliste der Abteilung gezeigt hat." Oder: „Der Rechnungsagent hat über Nacht 14 Zahlungen freigegeben, die über dem Limit liegen."
2. Einstufen (10 Minuten). Klasse, Schweregrad, wer wird geweckt. Notieren Sie, wie lange die Runde braucht, um sich zu einigen.
3. Eindämmen am Testsystem (15 Minuten). Die Technik führt die Sperr- und Abschaltbefehle tatsächlich aus – am Testsystem oder einer Kopie. Hier zeigt sich, ob der Gateway-Schlüssel wirklich gesperrt ist und ob jemand das Passwort für den Verzeichnisdienst hat.
4. Beweise sichern (10 Minuten). Export, Prüfsummen, Ablage. Prüfen: Enthält das Protokoll den Prompt, die abgerufenen Dokumente, die Werkzeugaufrufe? Wenn nicht, ist das der wichtigste Befund des Probelaufs.
5. Meldung entwerfen (15 Minuten). Der Datenschutzbeauftragte füllt die Felder einer vorläufigen Meldung mit dem, was nach 45 Minuten bekannt ist. Lücken notieren.
6. Auswerten (5 Minuten). Drei Dinge, die nicht funktioniert haben, mit Verantwortlichem und Datum.

In der Praxis scheitert der erste Probelauf fast nie an der Technik, sondern an Kleinigkeiten: das Dienstkonto des Agenten ist ein persönliches Konto eines Entwicklers, das Gateway hat keinen Sperrbefehl, nur einen Löschbefehl, das Protokoll enthält die Antwort, aber nicht die abgerufenen Dokumente. Jede dieser Lücken ist im Probelauf eine Notiz und im Ernstfall eine verlorene Stunde. Ergänzen Sie das Szenario einmal im Jahr um einen Angriff aus dem Red-Teaming Ihres Systems – etwa eine eingeschleuste Anweisung in einem Dokument, die die Guardrails umgeht.

Wenn Sie den Betrieb auslagern, gehört der Probelauf in den Vertrag: Wer sperrt, in welcher Zeit, mit welchem Nachweis. Für die von HostSpezial betriebenen Systeme gilt eine Reaktionszeit bei kritischen Störungen von 15 Minuten ab Service-Klasse Business; Ihre Vorlage sollte die Rufnummer und die Störungsklasse enthalten, nicht nur den Firmennamen. Dass ein Agentenfehler auch ohne Angreifer teuer wird, zeigt der Bestandsartikel über Agentenausfälle mit Produktionsschäden; die Disziplin dahinter heißt LLMOps, und der Notfallprozess ist ihr unangenehmster, aber wichtigster Teil.