Incident Response für KI-Systeme: Fehler stoppen, untersuchen und beheben

Stand: Juli 2026. Dieser Artikel ist keine Rechtsberatung – bei konkreten Datenschutz- oder Haftungsfragen gehören Datenschutzbeauftragte oder Fachanwält:innen an den Tisch. Er ist Teil unseres Clusters KI-Governance, Datenschutz und Sicherheit.

Das Problem: Wenn KI schiefgeht, fehlt oft der Reaktionsweg

Die meisten Unternehmen, mit denen ich zu KI-Themen spreche, haben irgendeine Form von Richtlinie oder zumindest eine informelle Regel dafür, wer welche Tools nutzen darf. Was fast immer fehlt, ist die Antwort auf die nächste Frage: Was passiert, wenn trotzdem etwas schiefgeht? Ein Chatbot gibt eine falsche Zusage an eine Kundin heraus. Ein Mitarbeiter lädt eine Kundenliste in ein KI-Tool hoch, das dafür nie geprüft wurde. Ein KI-Assistent mit Zugriff auf das Postfach verschickt eine E-Mail, die niemand freigegeben hat. In all diesen Momenten zählt nicht mehr die Präventionsfrage – die ist bereits verloren –, sondern eine ganz andere: Wer merkt es, wer entscheidet was, und wie schnell ist der Schaden begrenzt?

Genau diese Lücke schließt Incident Response. Sie ist keine Ergänzung zu KI-Richtlinie und Risikobewertung, sondern ihr notwendiges Gegenstück: Die Richtlinie sagt, was erlaubt ist; die Risikobewertung sagt, wo es gefährlich werden kann; Incident Response sagt, was zu tun ist, wenn die Prävention trotzdem versagt hat – und das wird sie, denn kein Regelwerk verhindert jeden Fehler.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU. Er beantwortet die Kernfragen im Zusammenhang: Was zählt überhaupt als KI-Incident, wie stoppt man System und Zugriffe, welche Beweise sichert man, wer wird informiert, und wie werden aus einem Vorfall bessere Kontrollen. Am Ende steht ein eigenes Runbook mit Rollen und Entscheidungspunkten, das du als Ausgangspunkt für dein eigenes Vorgehen nutzen kannst.

Begriffe: Incident, Vorfall, Datenpanne – was ist gemeint?

Die Begriffe werden in der Praxis oft synonym verwendet, meinen aber unterschiedliche Dinge:

• KI-Incident ist der Oberbegriff dieses Artikels: jedes Ereignis, bei dem ein KI-System einen realen oder unmittelbar drohenden Schaden verursacht – durch falsche Ausgaben, durch unautorisierten Datenzugriff oder -abfluss, oder durch eine unerwünschte Aktion, die das System selbstständig ausgeführt hat.
• Datenschutzverletzung (im Sinne von Art. 33 DSGVO) ist ein spezifischer, rechtlich definierter Unterfall: eine Verletzung des Schutzes personenbezogener Daten durch Vernichtung, Verlust, Veränderung oder unbefugte Offenlegung. Nicht jeder KI-Incident ist eine Datenschutzverletzung – aber ein großer Teil der praktisch relevanten Fälle ist es, weil KI-Systeme meist mit personenbezogenen Kundendaten in Berührung kommen.
• Serious Incident ist ein Begriff aus der europäischen KI-Verordnung: Für Hochrisiko-KI-Systeme sieht die Verordnung eine eigene Pflicht vor, schwerwiegende Vorfälle und Fehlfunktionen den Marktüberwachungsbehörden zu melden. Das betrifft in der Praxis vor allem Anbieter und Betreiber von Hochrisiko-Systemen – also seltener den typischen KMU-Einsatz von Chatbots und Standardtools, aber du solltest wissen, dass diese Pflicht existiert, falls dein Einsatz in diese Kategorie fällt.

Für den Rest des Artikels verwende ich „KI-Incident” als den weiten Arbeitsbegriff, weil die Reaktion in den ersten Stunden für alle drei Fälle ähnlich beginnt – erst bei der Frage, wer informiert werden muss, trennen sich die Wege.

Was ist ein KI-Incident?

Ein KI-Incident ist ein Vorfall, bei dem ein KI-System falsche oder schädliche Ausgaben liefert, unautorisiert auf Daten zugreift oder personenbezogene beziehungsweise vertrauliche Informationen offenlegt, oder eine Aktion ausführt, die niemand freigegeben hat. Aus meiner Projekterfahrung lassen sich die praktisch relevanten Fälle in drei Kategorien ordnen – eine eigene Einordnung, keine amtliche Klassifikation, aber sie deckt die allermeisten Fälle ab, die KMU tatsächlich betreffen:

1. Fehlerhafte Ausgaben, die ungeprüft wirken. Ein Sprachmodell erzeugt eine plausibel klingende, aber falsche Aussage – eine erfundene Rückgabefrist, eine falsche Preisangabe, eine unzutreffende rechtliche Einschätzung – und diese Ausgabe wird ungeprüft an eine Kundin, in ein Angebot oder in eine Entscheidung übernommen. Das BSI formuliert es in seinem Management Blitzlicht als Kernregel: KI-Ausgaben nie ungeprüft oder für kritische Geschäftsprozesse übernehmen. Der Incident entsteht genau dort, wo diese Regel gebrochen wird.

2. Datenabfluss und Datenlecks. Personenbezogene Daten oder Geschäftsgeheimnisse gelangen in ein KI-Tool, das dafür nicht vorgesehen war – ein privater Chatbot-Account, ein Anbieter ohne Auftragsverarbeitungsvertrag, oder ein KI-System, das Trainingsdaten unter bestimmten Bedingungen reproduzieren kann. Auch ein erfolgreicher Angriff auf ein KI-System selbst gehört hierher: Die Datenschutzkonferenz beschreibt in ihrer Orientierungshilfe zu technischen und organisatorischen Maßnahmen mehrere Angriffsformen, bei denen über gezielt veränderte Eingaben (Evasion Attacks) oder über manipulierte Trainingsdaten (Data Poisoning) Fehlverhalten oder Informationsabfluss erzwungen werden kann.

3. Unautorisierte Aktionen. KI-Systeme mit Werkzeugzugriff – ein Assistent, der E-Mails verschicken, Datensätze ändern oder Bestellungen auslösen kann – führen eine Handlung aus, die so nicht gewollt war. Das ist die Kategorie mit dem am schnellsten wachsenden Risiko, weil immer mehr KI-Tools nicht mehr nur antworten, sondern handeln.

Wichtig für die Einordnung: Nicht jeder Fehler ist ein Incident. Ein Tippfehler in einem internen Entwurf, den ein Mensch ohnehin noch prüft, ist ein normaler Grenzfall der Technologie. Ein Incident liegt vor, wenn ein realer Schaden entstanden ist oder unmittelbar droht – finanziell, rechtlich, für Kund:innen oder für die Reputation. Diese Schwelle sauber zu ziehen ist Teil der Vorbereitung, nicht etwas, das man im Moment der Panik neu erfinden sollte.

Wie stoppt man System und Zugriffe?

Die erste Handlung in jedem Incident ist nicht die Analyse, sondern das Stoppen des Schadens. Drei Schritte, in dieser Reihenfolge:

1. Den Kanal unterbrechen, über den der Schaden weiterläuft. Das heißt konkret: API-Schlüssel rotieren oder sperren, betroffene Nutzer-Accounts pausieren, die Integration zwischen KI-System und Backend deaktivieren, den Chatbot vom Kundenkontakt nehmen. Das BSI empfiehlt für integrierte KI-Systeme ausdrücklich, den Zugriff des KI-Systems auf andere Systeme einzuschränken und KI-Ausgaben zu validieren, bevor sie an Backendsysteme weitergegeben werden – im Incident-Fall heißt das: diesen Zugriff sofort kappen, nicht erst prüfen, ob er noch gebraucht wird.

2. Downstream-Effekte begrenzen. Wenn eine fehlerhafte Ausgabe bereits weitergelaufen ist – etwa eine automatisch versandte E-Mail oder eine Änderung in einem Datensatz –, geht es jetzt darum, die Folgekette zu unterbrechen: betroffene Empfänger:innen informieren, bevor sie auf Basis der Fehlinformation handeln, fehlerhafte Datensätze markieren statt sofort zu löschen.

3. Isolieren statt aufräumen. Der reflexartige Impuls ist, den Fehler sofort zu beheben und die Spuren zu bereinigen – genau das solltest du vermeiden, bevor die Beweissicherung abgeschlossen ist. Ein System kann pausiert werden, ohne dass Logs, Konfiguration oder Zustand verändert werden. Wer zu früh „aufräumt”, verliert häufig genau die Informationen, die man für die Ursachenanalyse braucht.

Wer diesen Schritt übernimmt, muss vorher klar sein – nicht erst im Moment des Vorfalls. Deshalb gehört zur Vorbereitung eine benannte Person (oder Rolle) mit der technischen Befugnis, im Ernstfall ohne Rückfrage einen Zugriff zu sperren. Ein Prozess, der erst eine Genehmigung braucht, um einen laufenden Schaden zu stoppen, ist in der Praxis kein Prozess.

Welche Beweise sichert man?

Nach dem Stoppen beginnt die Dokumentation – und sie ist wichtiger, als die meisten KMU zunächst annehmen, weil sie die Grundlage für drei spätere Entscheidungen ist: Wie schwer ist der Vorfall wirklich, muss extern gemeldet werden, und was muss sich ändern.

Zu sichern sind mindestens:

• Logs mit Zeitstempeln. Zugriffszeiten, betroffene Systeme, ausgeführte Aktionen. Die Datenschutzkonferenz nennt Protokollierung in ihrer Orientierungshilfe als eine der etablierten technischen Maßnahmen, die – ursprünglich aus klassischen IT-Systemen stammend – auch bei KI-Systemen umgesetzt werden sollten.
• Der vollständige Prompt- und Antwortverlauf, soweit technisch verfügbar. Bei vielen SaaS-KI-Tools ist der Export eingeschränkt – dann zumindest Screenshots mit Zeitstempel.
• Betroffene Konten, Datensätze und Personenkreise. Eine erste, auch grobe Schätzung: Wie viele Personen, welche Datenkategorien, welcher Zeitraum. Das ist keine akademische Übung – es ist exakt die Information, die eine Meldung nach Art. 33 DSGVO inhaltlich verlangt.
• Wer wusste wann was. Wann wurde der Vorfall entdeckt, von wem, wie wurde er eskaliert. Diese Zeitlinie ist später entscheidend für die Fristberechnung der 72-Stunden-Meldung.

Eine Spannung gehört zur ehrlichen Betrachtung dazu: Die Rechte Betroffener nach Art. 16 bis 18 DSGVO – etwa auf Berichtigung, Löschung oder Einschränkung der Verarbeitung – laufen der Beweissicherung im ersten Moment teilweise entgegen. Die Datenschutzkonferenz weist in ihrer Orientierungshilfe zu KI-Systemen ausdrücklich darauf hin, dass eine Einschränkung der Verarbeitung – also das Sperren statt sofortige Löschen von Daten – ein zulässiges Zwischeninstrument ist, gerade wenn eine Bewertung noch aussteht. Praktisch heißt das: Für die Dauer der Untersuchung Daten sperren und dokumentieren statt vorschnell löschen, und die eigentliche Löschung oder Berichtigung erst danach vornehmen. Bei Unsicherheit gehört diese Abwägung vor eine Datenschutzbeauftragte oder einen Datenschutzbeauftragten, nicht allein ins Bauchgefühl der IT.

Wer wird informiert?

Die Informationskette hat zwei Ebenen, die zeitlich ineinandergreifen.

Intern, sofort: Die Person, die den Vorfall entdeckt, eskaliert an die vorher benannte verantwortliche Stelle – typischerweise Geschäftsführung und die für Datenschutz zuständige Person gemeinsam. Das BSI betont in seinem Management Blitzlicht, dass Rollen und Verantwortlichkeiten für KI-Anwendungen eindeutig zugewiesen sein müssen und der Datenschutzbeauftragte von Beginn an einzubinden ist – im Vorfallsfall gilt das erst recht. Wer intern zusätzlich informiert werden muss, hängt vom Vorfall ab: der betroffene Fachbereich, IT, bei Kundenkontakt auch Vertrieb oder Kundenservice, damit dort keine widersprüchlichen Aussagen entstehen.

Extern, mit klaren Fristen, wenn personenbezogene Daten betroffen sind:

• Die Aufsichtsbehörde, binnen 72 Stunden. Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden ab Bekanntwerden zu melden – es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der betroffenen Personen. Können bei komplexeren Vorfällen nicht alle Informationen sofort vorliegen, kann die Meldung laut BfDI schrittweise nachgereicht werden; wichtig ist, die Frist nicht komplett verstreichen zu lassen. Die Meldung muss unter anderem Art und Umfang der Verletzung, die ungefähre Zahl der betroffenen Personen und Datensätze, die Kontaktdaten des Datenschutzbeauftragten sowie die ergriffenen oder vorgeschlagenen Gegenmaßnahmen enthalten – genau die Informationen, die in der Beweissicherung oben zusammengetragen wurden.
• Die betroffenen Personen, bei hohem Risiko. Nach Art. 34 DSGVO müssen zusätzlich die betroffenen Personen direkt informiert werden, wenn die Verletzung voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten zur Folge hat – etwa bei besonders sensiblen Daten oder absehbarem Missbrauchspotenzial.
• Vertragspartner und Auftraggeber. Wenn dein Unternehmen als Auftragsverarbeiter für andere tätig ist oder ein KI-Anbieter als Auftragsverarbeiter für dich, greifen zusätzlich vertragliche Meldepflichten – meist mit kürzeren, vertraglich vereinbarten Fristen als die gesetzlichen 72 Stunden.

Die Nichteinhaltung der Meldepflicht ist kein Kavaliersdelikt: Verstöße gegen die Meldepflichten nach Art. 33 und 34 DSGVO können nach Art. 83 Abs. 4 DSGVO mit Bußgeldern von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Das ist ein Rahmen, kein automatischer Betrag – aber er zeigt, warum „wir wollten erst mehr herausfinden” keine sichere Strategie ist, um die Frist verstreichen zu lassen.

Wie verbessert man Kontrollen?

Ein Incident, der ohne Konsequenz bleibt, ist verschenkte Lernchance – und ein Wiederholungsrisiko. Der Rückkanal von der Untersuchung zur Kontrolle braucht eine klare Übersetzung: Was war die Ursache, und welche konkrete Änderung verhindert genau diesen Fehlertyp künftig?

In meiner Erfahrung fallen die Ursachen fast immer in eine von vier Kategorien, und jede hat eine typische Gegenmaßnahme:

Ursachentyp	Typisches Beispiel	Gegenmaßnahme
Fehlender Prüfschritt	KI-Ausgabe ging ungeprüft an Kund:innen	Menschliche Freigabe vor jeder externen Ausgabe einführen (Human-in-the-Loop)
Zu weite Berechtigung	KI-System hatte Zugriff auf mehr Daten oder Aktionen als nötig	Berechtigungskonzept nach dem Least-Privilege-Prinzip nachschärfen
Ungeprüftes Tool	Nutzung eines nicht freigegebenen oder nicht geprüften KI-Anbieters	Tool-Verzeichnis und Freigabeprozess durchsetzen bzw. nachschärfen
Wissenslücke	Mitarbeitende kannten Grenzen und Risiken des Systems nicht	Rollenbezogene Nachschulung, auch mit Blick auf die KI-Kompetenzpflicht aus Art. 4 AI Act

Eigene Ursachen-Matrix Philogic Labs, aus Beratungsprojekten abgeleitet.

Diese Übersetzung gehört in ein festes Format: eine kurze Nachbesprechung binnen weniger Tage nach jedem Incident, mit der Frage „Was hätte diesen Vorfall verhindert oder schneller gestoppt?” – dokumentiert, mit einer benannten Person, die die beschlossene Änderung tatsächlich umsetzt. Ohne diese letzte Verantwortlichkeit bleiben Lehren aus Incidents erfahrungsgemäß auf dem Papier stehen.

Wichtig ist auch der regelmäßige Blick zurück, unabhängig von akuten Vorfällen: Die Datenschutzkonferenz empfiehlt in ihrer Orientierungshilfe für den laufenden Betrieb von KI-Systemen unter anderem regelmäßige Risikoeinschätzungen, etwa durch Red Teaming, sowie die Beobachtung plötzlicher oder schleichender Verhaltensänderungen des Systems. Für ein KMU ohne eigenes Security-Team heißt das praktisch: kein aufwändiges Programm, aber ein fester Termin – vierteljährlich ist ein guter Rhythmus –, an dem KI-Inventar, Berechtigungen und die letzten Vorfälle gemeinsam durchgegangen werden.

Umsetzung: Incident-Runbook mit Rollen und Entscheidungspunkten

Ein Runbook ist kein zwanzigseitiges Dokument, sondern eine Seite, die im Ernstfall tatsächlich griffbereit ist – ausgedruckt oder an einem Ort, der auch erreichbar ist, wenn das Hauptsystem down ist. Das folgende Modell ist mein eigenes Arbeitsgerüst aus Beratungsprojekten; du kannst es direkt als Vorlage für dein Unternehmen anpassen:

Phase	Ziel	Verantwortlich	Wichtigste Aktionen	Entscheidungspunkt
0. Vorbereitung	Bereit sein, bevor etwas passiert	Geschäftsführung + IT/Datenschutz	Rollen benennen, Zugriffsrechte für Sofort-Sperrung klären, KI-Inventar aktuell halten	Ist jederzeit klar, wer im Ernstfall sperren darf – ohne Rückfrage?
1. Erkennen & Melden	Vorfall so früh wie möglich sichtbar machen	Alle Mitarbeitenden	Auffälligkeit an benannte Stelle melden, keine Bewertung im Vorfeld nötig	Ist der Meldeweg allen bekannt und niedrigschwellig?
2. Stoppen	Weiteren Schaden verhindern	IT/Verantwortliche Person	Zugriffe/API-Keys sperren, Integration deaktivieren, Downstream-Effekte begrenzen	Ist der Kanal wirklich unterbrochen, nicht nur pausiert?
3. Untersuchen	Umfang und Ursache klären	Datenschutz + Fachbereich	Logs, Prompts, betroffene Daten und Personenkreis sichern; Ursache einordnen	Sind personenbezogene Daten betroffen – ja/nein/unklar?
4. Informieren	Pflichten und Vertrauen erfüllen	Geschäftsführung + Datenschutzbeauftragte:r	Interne Eskalation, ggf. Aufsichtsbehörde binnen 72 Std., ggf. Betroffene, ggf. Vertragspartner	Liegt ein Risiko für Rechte und Freiheiten Betroffener vor?
5. Beheben & Lernen	Ursache abstellen, Kontrolle nachschärfen	Verantwortliche Rolle je Ursache	Nachbesprechung binnen weniger Tage, konkrete Änderung an Richtlinie/Berechtigung/Schulung	Ist die Änderung dokumentiert und terminiert umgesetzt?

Eigenes Incident-Runbook Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten.

Zur zeitlichen Einordnung, ausdrücklich als Bandbreite aus meiner Erfahrung, nicht als Zusage: Die Phasen 1 und 2 – Erkennen und Stoppen – sollten in einem gut vorbereiteten KMU innerhalb weniger Stunden ablaufen, nicht Tage. Phase 3, die Untersuchung, dauert je nach Komplexität von einem Tag bei einem einfachen Fehlerfall bis zu mehreren Wochen bei einem Vorfall mit vielen betroffenen Systemen. Die 72-Stunden-Frist für die Behördenmeldung in Phase 4 beginnt dabei nicht mit der Untersuchung, sondern mit dem Bekanntwerden des Vorfalls – das ist der Grund, warum Untersuchung und Meldevorbereitung parallel laufen müssen, nicht nacheinander.

Wenn du Unterstützung beim Aufsetzen eines eigenen Runbooks oder bei der Ersteinschätzung eurer aktuellen KI-Nutzung und Leitplanken brauchst: Das ist ein typischer Baustein unserer KI-Beratung, und ein Erstgespräch reicht, um einzuschätzen, wie groß die Lücke bei euch aktuell ist.

Risiken & Grenzen dieses Ansatzes

Ehrlichkeit gehört zu einem Governance-Thema dazu – vier Grenzen solltest du kennen:

• Ein Runbook ersetzt keine Übung. Ein Dokument, das niemand gelesen hat, bevor der erste echte Vorfall eintritt, verliert im Ernstfall an Wirkung. Zumindest ein kurzer Durchlauf – gedanklich oder als Tabletop-Übung – gehört zur Vorbereitung.
• Bei SaaS-Tools ist forensische Tiefe begrenzt. Du hast meist keinen Zugriff auf die internen Logs des KI-Anbieters. Was du sichern kannst, ist das, was auf deiner Seite sichtbar ist – das ist ein Argument für Firmenaccounts mit besserer Protokollierung, nicht für Verzicht auf Dokumentation.
• Nicht jeder Fall ist eindeutig. Ob eine Datenschutzverletzung im Sinne von Art. 33 DSGVO vorliegt und ob ein Risiko für Betroffene besteht, ist eine rechtliche Bewertung im Einzelfall. Dieser Artikel ersetzt diese Bewertung nicht – bei Unsicherheit gehört sie vor eine Datenschutzbeauftragte oder rechtliche Beratung, und zwar früh genug, um die 72-Stunden-Frist einhalten zu können.
• Ein Prozess ist kein Freibrief. Ein dokumentiertes Runbook und eine gemeldete Datenschutzverletzung sind keine Garantie für DSGVO- oder AI-Act-Konformität im Einzelfall – sie senken das Risiko und zeigen Sorgfalt, ersetzen aber keine eigene rechtliche Prüfung bei sensiblen Fällen.

Checkliste: Incident Response für KI-Systeme

• Es gibt eine benannte Rolle mit der Befugnis, Zugriffe im Ernstfall sofort zu sperren – ohne Rückfrage
• Ein niedrigschwelliger, allen bekannter Meldeweg für Auffälligkeiten existiert
• Das KI-Inventar ist aktuell und zeigt, welche Systeme wo Zugriff haben
• Ein einseitiges Runbook mit Phasen, Rollen und Entscheidungspunkten liegt griffbereit vor
• Klar ist, wer über die Meldepflicht nach Art. 33/34 DSGVO entscheidet und wer sie fristgerecht ausführt
• Die Zeitlinie „Wann bekannt, wann eskaliert, wann gemeldet” wird bei jedem Vorfall dokumentiert
• Beweise werden vor jeder Bereinigung gesichert – Sperren statt vorschnellem Löschen
• Nach jedem Vorfall gibt es eine kurze Nachbesprechung mit einer terminierten, verantworteten Änderung
• Der Rhythmus für Risikoeinschätzung und Kontroll-Review ist festgelegt (vierteljährlich ist ein guter Start)
• Die Datenschutzbeauftragte oder der Datenschutzbeauftragte ist von Beginn an eingebunden, nicht erst im Vorfall

Ein Incident-Prozess, den niemand kennt, ist kein Prozess – er ist eine gute Absicht. Der Unterschied zwischen einem Vorfall, der glimpflich verläuft, und einem, der zum Bußgeldverfahren wird, liegt selten an der Schwere des ursprünglichen Fehlers. Er liegt daran, wie schnell er gestoppt, wie sauber er dokumentiert und wie ehrlich er gemeldet wurde.