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

Das Wichtigste in Kürze:

• Ein KI-Incident liegt vor, wenn ein KI-System realen Schaden verursacht oder androht.
• Erste Reaktion: Zugriffe sperren, Schaden stoppen, dann Beweise sichern statt aufräumen.
• Bei personenbezogenen Daten gilt die 72-Stunden-Meldefrist nach Artikel 33 DSGVO.
• Nach jedem Vorfall wird die Ursache in eine konkrete Kontrolländerung übersetzt.

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

Viele Unternehmen haben eine KI-Richtlinie. In den Gesprächen, die ich zu KI-Themen führe, gibt es fast immer zumindest eine informelle Regel, wer welche Tools nutzen darf. Was fast immer fehlt, ist die Antwort auf die nächste Frage: Was passiert, wenn trotzdem etwas schiefgeht?

Diese 3 Beispiele zeigen den Ernstfall.

• 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 die Präventionsfrage nicht mehr, die ist bereits verloren. Jetzt zählt 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 als KI-Incident zählt, wie man System und Zugriffe stoppt, welche Beweise man sichert und wer informiert wird. Dazu kommt, wie aus einem Vorfall bessere Kontrollen werden. Am Ende steht ein eigenes Runbook mit Rollen und Entscheidungspunkten als Ausgangspunkt für dein eigenes Vorgehen.

Begriffe: Was ist mit Incident, Vorfall, Datenpanne gemeint?

Die Begriffe werden oft synonym verwendet, meinen aber Verschiedenes.

• KI-Incident ist der Oberbegriff dieses Artikels: jedes Ereignis, bei dem ein KI-System realen oder unmittelbar drohenden Schaden verursacht, durch falsche Ausgaben, unautorisierten Datenabfluss oder eine selbstständig ausgeführte, unerwünschte Aktion.
• Datenschutzverletzung im Sinne von Artikel 33 DSGVO ist ein rechtlich definierter Unterfall: die Verletzung des Schutzes personenbezogener Daten durch Vernichtung, Verlust, Veränderung oder unbefugte Offenlegung.
• Serious Incident stammt aus der europäischen KI-Verordnung: Für Hochrisiko-KI-Systeme gilt eine eigene Pflicht, schwerwiegende Vorfälle und Fehlfunktionen den Marktüberwachungsbehörden zu melden.

Nicht jeder KI-Incident ist eine Datenschutzverletzung. Ein großer Teil der praktisch relevanten Fälle ist es aber, weil KI-Systeme meist mit personenbezogenen Kundendaten in Berührung kommen. Die Meldepflicht für Serious Incidents betrifft vor allem Anbieter und Betreiber von Hochrisiko-Systemen, also seltener den typischen KMU-Einsatz von Chatbots und Standardtools. Du solltest aber wissen, dass diese Pflicht existiert, falls dein Einsatz in diese Kategorie fällt.

Für den Rest des Artikels verwende ich „KI-Incident“ als weiten Arbeitsbegriff. Die Reaktion in den ersten Stunden beginnt für alle drei Fälle ähnlich. 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 vertrauliche Informationen offenlegt. Auch eine Aktion, die niemand freigegeben hat, gehört dazu. Aus meiner Projekterfahrung lassen sich die relevanten Fälle in 3 Kategorien ordnen. Das ist eine eigene Einordnung, keine amtliche Klassifikation. Sie deckt aber die allermeisten Fälle ab, die KMU tatsächlich betreffen.

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

Datenabfluss und Datenlecks: Personenbezogene Daten oder Geschäftsgeheimnisse gelangen in ein KI-Tool, das dafür nicht vorgesehen war. Typische Wege sind 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 mehrere Angriffsformen, bei denen über gezielt veränderte Eingaben (Evasion Attacks) oder manipulierte Trainingsdaten (Data Poisoning) Fehlverhalten oder Informationsabfluss erzwungen wird.

Unautorisierte Aktionen: KI-Systeme mit Werkzeugzugriff führen eine Handlung aus, die so nicht gewollt war, etwa eine verschickte E-Mail, ein geänderter Datensatz oder eine ausgelöste Bestellung. Das ist die Kategorie mit dem am schnellsten wachsenden Risiko. Immer mehr KI-Tools antworten nicht mehr nur, sie 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. Im Moment der Panik erfindet man sie nicht neu.

Wie stoppt man System und Zugriffe?

Die erste Handlung ist nicht die Analyse, sondern das Stoppen des Schadens. Diese 3 Schritte folgen in fester Reihenfolge.

Erstens: 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 zum Backend deaktivieren, den Chatbot vom Kundenkontakt nehmen. Das BSI empfiehlt für integrierte KI-Systeme, den Zugriff auf andere Systeme einzuschränken und Ausgaben vor der Weitergabe an Backendsysteme zu validieren. Im Incident-Fall heißt das: diesen Zugriff sofort kappen, nicht erst prüfen, ob er noch gebraucht wird.

Zweitens: Downstream-Effekte begrenzen. Ist eine fehlerhafte Ausgabe bereits weitergelaufen, etwa als versandte E-Mail oder geänderter Datensatz, geht es um die Folgekette. Betroffene Empfänger:innen werden informiert, bevor sie auf Basis der Fehlinformation handeln. Fehlerhafte Datensätze werden markiert statt sofort gelöscht.

Drittens: 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 für die Ursachenanalyse.

Wer diesen Schritt übernimmt, muss vorher klar sein, nicht erst im Moment des Vorfalls. Zur Vorbereitung gehört deshalb 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. Sie ist wichtiger, als die meisten KMU annehmen. Sie ist die Grundlage für 3 spätere Entscheidungen: Wie schwer ist der Vorfall, muss extern gemeldet werden, und was muss sich ändern. Zu sichern ist mindestens Folgendes.

• Logs mit Zeitstempeln: Zugriffszeiten, betroffene Systeme, ausgeführte Aktionen.
• Der vollständige Prompt- und Antwortverlauf, soweit technisch verfügbar, bei eingeschränktem Export vieler SaaS-Tools zumindest Screenshots mit Zeitstempel.
• Betroffene Konten, Datensätze und Personenkreise: eine erste grobe Schätzung, wie viele Personen, welche Datenkategorien, welcher Zeitraum.
• Wer wusste wann was: Wann wurde der Vorfall entdeckt, von wem, wie eskaliert?

Die Protokollierung nennt die Datenschutzkonferenz in ihrer Orientierungshilfe als etablierte technische Maßnahme, die auch bei KI-Systemen umgesetzt werden sollte. Die Schätzung der Betroffenen ist keine akademische Übung, sondern exakt die Information, die eine Meldung nach Artikel 33 DSGVO inhaltlich verlangt. Und die 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 Artikel 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 darauf hin, dass eine Einschränkung der Verarbeitung, also Sperren statt sofortiges Löschen, ein zulässiges Zwischeninstrument ist, solange eine Bewertung aussteht. Praktisch heißt das: für die Dauer der Untersuchung Daten sperren und dokumentieren, die eigentliche Löschung oder Berichtigung folgt danach. Bei Unsicherheit gehört diese Abwägung vor Datenschutzbeauftragte, nicht allein ins Bauchgefühl der IT.

Wer wird informiert?

Die Informationskette hat 2 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, 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. Je nach Vorfall kommen Fachbereich, IT und bei Kundenkontakt auch Vertrieb oder Kundenservice dazu, damit keine widersprüchlichen Aussagen entstehen.

Extern gelten klare Fristen, sobald personenbezogene Daten betroffen sind.

• Die Aufsichtsbehörde, binnen 72 Stunden: Artikel 33 DSGVO verlangt die Meldung unverzüglich und möglichst binnen 72 Stunden ab Bekanntwerden. Die Ausnahme: Die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der Betroffenen.
• Die betroffenen Personen, bei hohem Risiko: Artikel 34 DSGVO verlangt ihre direkte Information, wenn voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten besteht, etwa bei sensiblen Daten.
• Vertragspartner und Auftraggeber: Bei Auftragsverarbeitung greifen zusätzlich vertragliche Meldepflichten, meist mit kürzeren Fristen als die gesetzlichen 72 Stunden.

Bei komplexeren Vorfällen kann die Meldung laut BfDI schrittweise nachgereicht werden, wenn nicht alle Informationen sofort vorliegen. Wichtig ist, die Frist nicht komplett verstreichen zu lassen. Die Meldung enthält unter anderem Art und Umfang der Verletzung, die ungefähre Zahl der Betroffenen und Datensätze, die Kontaktdaten des Datenschutzbeauftragten und die ergriffenen Gegenmaßnahmen. Genau diese Informationen liefert die Beweissicherung oben.

Die Nichteinhaltung der Meldepflicht ist kein Kavaliersdelikt. Verstöße gegen die Meldepflichten der Artikel 33 und 34 DSGVO fallen unter Artikel 83 Absatz 4 DSGVO. Der Rahmen reicht bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Das ist ein Rahmen, kein automatischer Betrag. Er zeigt aber, warum „wir wollten erst mehr herausfinden“ keine sichere Strategie ist.

Wie verbessert man Kontrollen?

Ein Incident ohne Konsequenz 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 4 Kategorien.

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

Eigene Ursachen-Matrix Philogic Labs, aus Beratungsprojekten abgeleitet.

Diese Übersetzung gehört in ein festes Format. Bewährt hat sich eine kurze Nachbesprechung binnen weniger Tage mit der Frage: „Was hätte diesen Vorfall verhindert oder schneller gestoppt?“ Dokumentiert wird mit einer benannten Person, die die beschlossene Änderung tatsächlich umsetzt. Ohne diese letzte Verantwortlichkeit bleiben Lehren aus Incidents auf dem Papier stehen.

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

Umsetzung: Incident-Runbook mit Rollen und Entscheidungspunkten

Ein Runbook ist kein zwanzigseitiges Dokument. Es ist eine Seite, die im Ernstfall griffbereit ist, ausgedruckt oder an einem Ort, der auch erreichbar bleibt, 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 0, Vorbereitung (Geschäftsführung plus IT/Datenschutz): Rollen benennen, Zugriffsrechte für die Sofort-Sperrung klären, das KI-Inventar aktuell halten. Entscheidungspunkt: Ist jederzeit klar, wer im Ernstfall ohne Rückfrage sperren darf?

• Phase 1, Erkennen und Melden (alle Mitarbeitenden): Auffälligkeiten an die benannte Stelle melden, ohne Bewertung im Vorfeld. Entscheidungspunkt: Ist der Meldeweg allen bekannt und niedrigschwellig?

• Phase 2, Stoppen (IT beziehungsweise verantwortliche Person): Zugriffe und API-Keys sperren, Integrationen deaktivieren, Downstream-Effekte begrenzen. Entscheidungspunkt: Ist der Kanal wirklich unterbrochen, nicht nur pausiert?

• Phase 3, Untersuchen (Datenschutz plus Fachbereich): Logs, Prompts, betroffene Daten und Personenkreis sichern, Ursache einordnen. Entscheidungspunkt: Sind personenbezogene Daten betroffen, ja, nein oder unklar?

• Phase 4, Informieren (Geschäftsführung plus Datenschutzbeauftragte:r): interne Eskalation, gegebenenfalls Aufsichtsbehörde binnen 72 Stunden, gegebenenfalls Betroffene und Vertragspartner. Entscheidungspunkt: Liegt ein Risiko für Rechte und Freiheiten Betroffener vor?

• Phase 5, Beheben und Lernen (verantwortliche Rolle je Ursache): Nachbesprechung binnen weniger Tage, konkrete Änderung an Richtlinie, Berechtigung oder Schulung. Entscheidungspunkt: 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 sollten in einem gut vorbereiteten KMU innerhalb weniger Stunden ablaufen, nicht Tage. Phase 3 dauert je nach Komplexität von einem Tag bei einem einfachen Fehlerfall bis zu mehreren Wochen bei vielen betroffenen Systemen. Die 72-Stunden-Frist beginnt nicht mit der Untersuchung, sondern mit dem Bekanntwerden des Vorfalls. Deshalb müssen Untersuchung und Meldevorbereitung parallel laufen, nicht nacheinander.

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

Risiken & Grenzen dieses Ansatzes

Diese 4 Grenzen solltest du kennen.

• Ein Runbook ersetzt keine Übung: Ein Dokument, das niemand vor dem ersten echten Vorfall gelesen hat, verliert im Ernstfall an Wirkung. Mindestens ein gedanklicher Durchlauf oder eine Tabletop-Übung gehört zur Vorbereitung.
• Bei SaaS-Tools ist forensische Tiefe begrenzt: Du siehst nur, was auf deiner Seite anfällt, nicht die internen Logs des Anbieters, ein Argument für Firmenaccounts mit besserer Protokollierung.
• Nicht jeder Fall ist eindeutig: Ob eine Datenschutzverletzung nach Artikel 33 DSGVO vorliegt, ist eine rechtliche Bewertung im Einzelfall, die früh genug vor Datenschutzbeauftragte oder rechtliche Beratung gehört.
• Ein Prozess ist kein Freibrief: Runbook und Meldung senken das Risiko und zeigen Sorgfalt, ersetzen aber keine eigene rechtliche Prüfung bei sensiblen Fällen.

Checkliste: Incident Response für KI-Systeme

Diese 10 Punkte machen dich handlungsfähig.

• Es gibt eine benannte Rolle mit der Befugnis, Zugriffe im Ernstfall sofort und ohne Rückfrage zu sperren.

• 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 Artikel 33 und 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 geht vor 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.

• Datenschutzbeauftragte sind von Beginn an eingebunden, nicht erst im Vorfall.

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