Fiktives, aber realitätsnahes Szenario vom 15. Juli 2026. Um 08:42 Uhr meldet das Ticketsystem eines Wiener Industriezulieferers ungewöhnlich viele Dateizugriffe durch einen KI-Assistenten. Zehn Minuten später findet der Serviceleiter drei Antwortentwürfe mit Informationen aus fremden Kundenakten. Die Geschäftsführerin fragt: „Sind Daten nach außen gelangt?“ Das Plattformteam sieht Modellaufrufe, die IT sieht API-Zugriffe, der Fachbereich sieht Vorgänge. Niemand kann die drei Sichten zu einer belastbaren Ereigniskette verbinden.
Das Szenario verdichtet typische Betriebsmuster. Es ist kein Kundenfall und behauptet kein Kundenergebnis. Der Vorfall begann nicht mit dem Alarm. Er begann dort, wo Identität, Datenzugriff, Prompt, Werkzeugrechte, Freigabe und Protokollierung ohne gemeinsamen Notfallweg produktiv gingen.
Die gefährliche Lücke: Der Notfallplan endet am Rand des KI-Systems
Ein klassischer Incident-Response-Plan kann ein Konto sperren, einen Rechner isolieren und eine Anwendung aus einem bekannten Stand wiederherstellen. Bei einem KI-Workflow liegen Modell, Retrieval, Werkzeuge, Identitäten und Freigaben oft in verschiedenen Systemen. Ein Geschäftsvorgang erzeugt mehrere Modellaufrufe, Tool-Aktionen und Übergaben.
Die entscheidende Frage lautet deshalb: Welche Identität hat mit welcher Modell- und Policy-Version auf welche Daten zugegriffen, welches Werkzeug ausgelöst und welches Ergebnis freigegeben? Ohne diese Kette wird Eindämmung zur Vermutung und Wiederanlauf zur Risikoübernahme ohne Nachweis.
Was Sie mit diesem Leitfaden aufbauen
Sie erhalten einen operativen Ablauf für die ersten 15 Minuten, die erste Stunde, vier Stunden und 24 Stunden, ergänzt um Beweispaket, Verantwortungsmatrix, Wiederanlauf-Gates, Krisenübung und 30/60/90-Tage-Plan. Der Beitrag vertieft unseren Überblick zum EU-Aktionsplan für Cybersicherheit und KI, ohne dessen allgemeine Einordnung zu wiederholen.
Vor dem Alarm: Was gilt überhaupt als KI-Sicherheitsvorfall?
Nicht jede schlechte Antwort ist ein Notfall. Umgekehrt darf ein ernstes Ereignis nicht als bloßes „Qualitätsproblem der KI“ verschwinden. Ein KI-Sicherheitsvorfall liegt betrieblich vor, wenn ein KI-gestütztes System vermutlich eine freigegebene Grenze überschritten hat und Vertraulichkeit, Integrität, Verfügbarkeit, rechtliche Position, finanzielle Befugnis, Sicherheit oder Kundenvertrauen wesentlich gefährden kann.
| Grenze | Beispiel | Erste Reaktion |
|---|---|---|
| Daten | Geschützte Daten gelangen in ein nicht freigegebenes Modell oder einen fremden Vorgang | Zugriff begrenzen, Beweise sichern, Betroffene und Empfänger bestimmen |
| Befugnis | Ein Agent versendet, bestellt oder ändert außerhalb seines Mandats | Token entziehen, Warteschlangen stoppen, Folgewirkungen prüfen |
| Integrität | Prompt Injection oder manipuliertes Retrieval beeinflusst eine Entscheidung | Quelle und Ergebnisse isolieren, auf sicheren Ersatzprozess wechseln |
| Verfügbarkeit | Retries oder Schleifen blockieren einen kritischen Prozess | Automatik stoppen, reduzierten oder manuellen Betrieb aktivieren |
| Nachweis | Eine folgenreiche Aktion lässt sich keiner Identität, Regel und Freigabe zuordnen | Vertrauen als ungeklärt behandeln und Rechte begrenzen |
Die ersten 15 Minuten: Ausbreitung stoppen, Spuren erhalten
Der Incident Commander eröffnet eine Vorgangsnummer und hält den Zeitpunkt der Kenntnis fest. Der Prozessverantwortliche stoppt neue Jobs und Retries. Identity- und Plattformverantwortliche entziehen gezielt Agenten-, Servicekonto- oder API-Rechte. Parallel werden Logs, Prompt- und Policy-Versionen, Retrieval-Quellen, Tool Calls, Freigaben und Warteschlangenstände unveränderbar gesichert.
Löschen Sie nicht vorschnell den Agenten oder ganze Chatverläufe. Rotieren Sie nicht pauschal alle Schlüssel, bevor die betroffene Kette gesichert ist. Ungezielte Maßnahmen können Beweise vernichten und einen zweiten Betriebsausfall erzeugen.
Minute 15 bis Stunde 1: Umfang klären und sicheren Betrieb herstellen
Erstellen Sie eine erste Ereigniskette: auslösende Person, Agentenidentität, Geschäftsvorgang, Modell und Version, Systemanweisung, abgerufene Daten, angeforderte und ausgeführte Werkzeuge, Ergebnis, Freigabe und Folgetransaktion. Kennzeichnen Sie jede Lücke. „Nicht im Dashboard sichtbar“ bedeutet nicht „nicht passiert“.
Bestimmen Sie zugleich einen sicheren Betriebsmodus. Der Service-Assistent arbeitet nur noch als Entwurf. Der Einkaufsagent verliert Schreibrechte. Kritische Vorgänge gehen in eine manuelle Warteschlange. Ziel ist die Betriebsfähigkeit auf bekanntem Risikoniveau, nicht die schnellstmögliche Rückkehr jeder Automatisierung.
Stunde 1 bis 4: Auswirkungen, Meldewege und Verantwortung entscheiden
Fachbereich, IT-Sicherheit, Datenschutz beziehungsweise Recht, Kommunikation und Geschäftsleitung benötigen ein gemeinsames Lagebild: bestätigte Fakten, begründete Annahmen, offene Fragen, mögliche Betroffene, vertragliche Pflichten und regulatorische Meldewege.
Für erfasste Unternehmen und erhebliche Sicherheitsvorfälle beschreibt die NIS2-Übersicht der Europäischen Kommission eine Frühwarnung innerhalb von 24 Stunden nach Kenntnis, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Diese Frist gilt nicht pauschal für jedes KMU und jeden KI-Fehler. Maßgeblich sind Anwendungsbereich, Erheblichkeit, nationale Umsetzung sowie qualifizierte rechtliche Prüfung.
Stunde 4 bis 24: Eine belastbare Managemententscheidung vorbereiten
Nach 24 Stunden braucht die Geschäftsleitung keinen perfekten Forensikbericht, aber ein entscheidungsfähiges Paket: betroffener Geschäftsservice, bestätigte und plausible Auswirkungen, Stand der Eindämmung, Daten- und Befugnisgrenzen, möglicherweise Betroffene, rechtliche Bewertung, Kapazität des Ersatzbetriebs, Beweislücken, nächster Lagebericht und freigabeberechtigte Person.
Die richtige Entscheidung kann lauten, manuell weiterzuarbeiten oder nur lesenden Zugriff wiederherzustellen. Eine schnelle, aber unklare Freigabe ist keine Resilienz. Belastbarer ist: „Der bekannte Pfad ist eingedämmt; diese Nachweise liegen vor; Schreibrechte kehren erst zurück, wenn die drei offenen Spuren geklärt sind.“
Das KI-Beweispaket: neun Bausteine für eine belastbare Rekonstruktion
- Chronologie: Alarme, Kenntnis, Maßnahmen, Entscheidungen und Übergaben.
- Identitätskette: Nutzer, Agent, Servicekonto, delegierte Rechte und wirksame Berechtigungen.
- Modellakte: Anbieter, Modell/Version, Region, Konfiguration und Request IDs.
- Anweisungen: System Prompt, Workflow-, Routing- und Sicherheitsregeln mit Version.
- Kontext: Dokumente, Retrieval-Treffer, Speicher, Verlauf und Datenklasse.
- Werkzeugspur: angeforderte und ausgeführte Calls, Parameter, Ergebnisse, Retries und Transaktions-IDs.
- Ergebnis und Freigabe: Output, Evaluation, Prüfer, Entscheidung und Veröffentlichung.
- Änderungen: Deployments, Anbieter-, Konfigurations- und Credential-Änderungen.
- Auswirkungsregister: Systeme, Datensätze, Empfänger, Verpflichtungen, Kosten und Bereinigung.
Originale werden zugriffsgeschützt und integritätsgesichert; Analysen arbeiten mit Kopien. Alle Artefakte tragen Vorgangsnummer und abgestimmte Zeitbasis. Datenschutz bleibt auch im Krisenmodus gültig: Sichern Sie das Erforderliche, nicht wahllos alles.
Verantwortungsmatrix: vier Entscheidungen brauchen klare Eigentümer
| Entscheidung | Accountable | Operativ verantwortlich | Nachweis |
|---|---|---|---|
| Vorfall erklären und einstufen | Incident Commander | Security und Prozessverantwortlicher | Auslöser, Kenntniszeit, bekannte Wirkung |
| Befugnisse eindämmen | Business Service Owner | Identity-, Plattform- und Workflow-Team | Wirksamer Rechteentzug und Queue-Stand |
| Extern melden | Recht/Datenschutz | Recht, Security, Kommunikation | Sachverhalt, Geltungsbereich, Unsicherheit, Frist |
| Wiederanlauf freigeben | Business Service Owner | Betrieb und Technik | Kontrolländerung, Tests, Monitoring, Rollback |
Wiederanlauf-Gates: Ein verstummter Alarm beweist keine Sicherheit
- Scope: Identitäten, Daten, Tools, Queues und Folgesysteme sind eingegrenzt.
- Nachweis: kritische Spuren sind gesichert, zeitlich abgestimmt und verknüpft.
- Kontrolle: die versagte Grenze wurde konkret verändert, nicht nur zurückgesetzt.
- Test: Normal-, Angriffs- und Fehlerpfade bestehen in isolierter Umgebung.
- Betrieb: Ersatzprozess, Monitoring, Rufbereitschaft und Rollback sind arbeitsfähig.
- Freigabe: eine namentlich verantwortliche Person akzeptiert Rest-Risiko und Umfang.
Stellen Sie stufenweise wieder her: beobachten, lesen, entwerfen, menschlich freigeben, begrenzt automatisieren. Der Leitfaden zu KI-Agenten-Gateway und Kontrollschicht zeigt die technischen Stopppunkte; hier geht es um den nachweisbaren Entscheidungsprozess.
Eine 60-minütige Krisenübung für den Mittelstand
Nehmen Sie einen echten Prozess mit fiktiven Daten. Start: Ein Agent hat nach Zugriff auf ein gesperrtes Dokument drei Lieferanten angeschrieben. Nach 15 Minuten erfahren die Teams, dass ein delegiertes Token weiterverwendet wurde. Nach 30 Minuten fragt ein Lieferant nach möglichem Datenabfluss. Nach 45 Minuten meldet der Plattformanbieter eine Konfigurationsänderung.
Messen Sie Zeit bis Incident Commander, wirksamem Rechteentzug, Ersatzbetrieb, erster Ereigniskette, Meldeentscheidung und Wiederanlauf-Verantwortlichem. Eine gute Übung erzeugt offene Punkte; sie soll Lücken finden und nicht Harmonie simulieren.
30/60/90-Tage-Fahrplan: Aus dem Dokument wird Betriebsfähigkeit
Tag 1-30: erfassen und zuordnen
- Drei folgenreiche KI-Workflows auswählen.
- Auslöser, Schweregrad, Service Owner, Incident Commander und Ersatzbetrieb definieren.
- Identitäten, Modelle, Daten, Tools, Freigaben, Anbieter und Kontakte abbilden.
- Prüfen, ob die neun Nachweise über eine Vorgangsnummer auffindbar sind.
Tag 31-60: instrumentieren und üben
- Korrelations-IDs und Versionsstände durch Modell, Retrieval, Tools und Freigaben führen.
- Stopppunkte implementieren und den wirksamen Rechteentzug testen.
- Krisenübung mit Betrieb, Security, Recht/Datenschutz und Leitung durchführen.
- Die drei größten Verzögerungen für Eindämmung und Entscheidung beseitigen.
Tag 61-90: Wiederanlauf und Governance festigen
- Stufenweise Wiederanlauf-Gates, Rollback und manuellen Betrieb testen.
- Aufbewahrung, Zugriff und Integrität der Beweise festlegen.
- Anbieterverträge zu Logs, Incident Notice, Region, Support und Exit prüfen.
- Time-to-Contain, Spurenvollständigkeit, Ersatzkapazität und Maßnahmenstau berichten.
Was offizielle Quellen belegen und was daraus abgeleitet wurde
Der EU Action Plan on Cybersecurity and Artificial Intelligence vom 7. Juli 2026 verbindet sicheren KI-Einsatz mit Cyberresilienz. ENISA beschreibt im Juli 2026 den Zeitdruck durch KI-gestützte Angriffe sowie die Rolle von Logging, Monitoring, Runtime Guards, Zugriffskontrolle und Incident Response. Die NIS2 Technical Implementation Guidance liefert praktische Nachweisbeispiele für die erfassten Sektoren.
NIST SP 800-61r3 verankert Incident Response in Governance, Identifikation, Schutz, Erkennung, Reaktion und Wiederherstellung. Das NIST GenAI Profile empfiehlt verantwortete und geübte Incident-Pläne für Drittanbieter-KI. Zeitachse, Beweispaket, Matrix und Gates dieses Artikels sind Ali Najafzadehs betriebliche Synthese für DACH-Teams und keine wörtlichen Vorgaben dieser Quellen.
Rezept: Die einseitige KI-Notfallkarte
Auslösen bei: [Daten-, Befugnis-, Integritäts-, Verfügbarkeits- oder Nachweisgrenze]. Führen: [Rolle]. Stoppen: [Agent, Token, Tool, Queue, Retry]. Sichern: [neun Nachweise]. Ersatzbetrieb: [manuell/lesend/Entwurf]. Bewerten: [Wirkung, Betroffene, Meldewege]. Nächstes Update: [Zeit]. Wiederanlauf nur bei: [sechs Gates]. Freigabe: [Name/Rolle].
FAQ
Was ist ein KI-Incident-Response-Plan?
Ein verantworteter und geübter Ablauf zur Erkennung, Eindämmung, Untersuchung, Kommunikation und Wiederherstellung bei Vorfällen mit Modellen, Prompts, Daten, Tools, Agenten, Freigaben und Folgetransaktionen.
Was muss in den ersten 15 Minuten passieren?
Vorgang eröffnen, neue Jobs und Retries stoppen, betroffene Befugnisse entziehen, flüchtige Spuren sichern, Incident Commander benennen und einen sicheren Ersatzbetrieb aktivieren.
Muss jeder KI-Vorfall innerhalb von 24 Stunden gemeldet werden?
Nein. Die NIS2-Frühwarnung betrifft erfasste Unternehmen und erhebliche Sicherheitsvorfälle. Geltungsbereich, nationale Umsetzung, Verträge und andere Rechtsregime müssen qualifiziert geprüft werden.
Welche Nachweise sind unverzichtbar?
Chronologie, Identitäten und Rechte, Modell und Konfiguration, Prompt- und Policy-Versionen, Kontext, Tool Calls, Ergebnisse und Freigaben, Änderungen sowie Auswirkungsregister.
Wann darf ein KI-Workflow wieder anlaufen?
Stufenweise, nachdem Scope und Nachweis genügen, die Ursache kontrolliert wurde, Angriffs- und Fehlerpfade getestet sind, Monitoring und Rollback bereitstehen und der Business Owner das Restrisiko freigibt.
Nächster Schritt: Einen echten Workflow testen, bevor der Alarm kommt
Bringen Sie einen folgenreichen KI-Workflow mit Anbietern, Identitäten, Datenquellen, Tools, Freigaben und vorhandenen Logs in einen fokussierten Termin. Als AI Systems Architect prüft Ali Najafzadeh den Entscheidungsweg der ersten Stunde, die Beweiskontinuität, den Ersatzbetrieb und die Wiederanlauf-Gates und übersetzt die Lücken in einen 90-Tage-Plan. AI Systems Review vereinbaren.
Continue Reading
