Datenpannen mit KI-Bezug: Einen belastbaren Incident-Prozess aufsetzen

Ein KI-Assistent zeigt einem Nutzer die Daten eines anderen Kunden. Ein Protokoll mit Prompts und Antworten, das eigentlich intern bleiben sollte, war über einen ungeschützten Link erreichbar. In solchen Momenten zählt jede Stunde, und wer erst dann klärt, wer zuständig ist und was zu tun wäre, verliert genau die Zeit, die später fehlt.

Datenpannen mit KI-Bezug folgen denselben Grundregeln wie klassische Datenschutzverletzungen, haben aber eigene Vorfallsarten und eigene Erkennungsprobleme. Ein belastbarer Incident-Prozess nimmt beides ernst: Er kennt die typischen KI-Szenarien, und er steht, bevor der erste Vorfall passiert. Dieser Artikel beschreibt, wie ein solcher Prozess aufgebaut wird, in Grundzügen und ohne den Anspruch, Rechtsberatung zu ersetzen.

KI-spezifische Vorfallsarten erkennen

Wer nur an gestohlene Datenbanken denkt, übersieht die Vorfälle, die im KI-Betrieb tatsächlich auftreten. Typische Muster:

• Kontextvermischung: Das System spielt einem Nutzer Daten aus, die zu einem anderen Nutzer, Mandanten oder Kunden gehören, etwa durch fehlerhafte Trennung im Retrieval oder im Sitzungsmanagement.
• Offene Protokolle: Prompt-Logs, Konversationsverläufe oder Debug-Ausgaben mit personenbezogenen Inhalten sind ungeschützt zugänglich, intern für zu viele Personen oder extern für jedermann.
• Preisgabe über Ausgaben: Das Modell gibt personenbezogene Daten aus angebundenen Quellen an Empfänger weiter, die sie nicht sehen dürften, weil Berechtigungen der Quellsysteme nicht in die KI-Schicht übernommen wurden.
• Schatten-Nutzung: Mitarbeitende laden personenbezogene Daten in nicht freigegebene Dienste, oft in guter Absicht und ohne Bewusstsein für die Folgen.
• Vorfall beim Anbieter: Der eingesetzte Dienst meldet selbst eine Verletzung, und das eigene Unternehmen muss als Verantwortlicher reagieren.

Auffällig ist: Kaum eines dieser Muster löst einen klassischen Sicherheitsalarm aus. Erkannt werden sie meist von Menschen, von einem irritierten Nutzer, einem aufmerksamen Mitarbeiter, einem Hinweis von außen. Deshalb braucht der Prozess einen einfachen, bekannten Meldeweg für Menschen, nicht nur technisches Monitoring.

Schweregrad und Meldepflicht in Grundzügen einschätzen

Nicht jede Panne ist meldepflichtig, aber jede gehört bewertet und dokumentiert. Der Maßstab der Bewertung ist das Risiko für die betroffenen Personen: Welche Datenarten sind betroffen, wie viele Personen, wer hatte Zugriff, und welche Folgen sind für die Betroffenen realistisch denkbar. Ein intern falsch zugestelltes Dokument mit Namen und Firmenadresse wiegt anders als offen zugängliche Gesundheitsinformationen.

Zwei Dinge sollte jedes Unternehmen verinnerlicht haben. Erstens: Die gesetzliche Frist für eine Meldung an die Aufsichtsbehörde, in Österreich die Datenschutzbehörde, ist knapp bemessen, sie wird in Stunden und wenigen Tagen gedacht, nicht in Wochen. Die Bewertung muss also schnell beginnen, auch wenn noch nicht alle Fakten vorliegen, und darf gestaffelt nachgereicht werden. Zweitens: Auch die Entscheidung, nicht zu melden, gehört mit Begründung dokumentiert. Bei erhöhtem Risiko kann zusätzlich die Information der Betroffenen selbst erforderlich sein. Für die Grenzfälle gilt: früh die Datenschutzbeauftragte, den Datenschutzbeauftragten oder externe Beratung einbinden, nicht erst, wenn die Frist fast abgelaufen ist.

Zuständigkeiten und Eskalationswege vorab festlegen

Im Ernstfall dürfen nur noch Fakten offen sein, nicht Zuständigkeiten. Der Prozess legt vorab fest: Wo gehen Meldungen ein, am besten eine zentrale, allen bekannte Adresse. Wer nimmt die Erstbewertung vor und stuft den Schweregrad ein. Wer entscheidet über die Meldung an die Behörde und über die Information der Betroffenen. Wer kommuniziert intern, wer gegenüber Kunden, wer gegenüber dem Anbieter. Und wer vertritt wen bei Abwesenheit.

Bei KI-Diensten kommt eine Besonderheit hinzu: Der Anbieter ist Teil des Prozesses. Die Auftragsverarbeitungsvereinbarung verpflichtet ihn üblicherweise, Verletzungen unverzüglich zu melden und bei der Aufklärung zu unterstützen. Damit das im Ernstfall funktioniert, gehören die Meldewege des Anbieters, die Ansprechstellen und die zugesagten Reaktionszeiten in die eigene Prozessdokumentation, und zwar pro eingesetztem Dienst. Wer im Vorfall erst die Support-Adresse suchen muss, hat den Prozess nicht fertig aufgesetzt.

Aus jedem Vorfall strukturiert lernen

Ein Vorfall ist erst abgeschlossen, wenn er ausgewertet ist. Bewährt hat sich eine kurze Nachbetrachtung ohne Schuldzuweisung: eine Zeitleiste von der Entstehung über die Entdeckung bis zur Behebung, die ehrliche Frage, warum die Panne möglich war und warum sie so lange unentdeckt blieb, und daraus abgeleitete Maßnahmen mit Verantwortlichen und Terminen. Maßnahmen ohne Termin und Namen sind gute Vorsätze, keine Verbesserung.

Zwei Ergänzungen machen den Unterschied. Erstens zählen auch Beinahe-Vorfälle: Eine Kontextvermischung, die zufällig nur Testdaten betraf, ist eine kostenlose Lektion über eine echte Schwachstelle. Zweitens sollte der Prozess geübt werden, bevor er gebraucht wird. Ein Trockenlauf mit einem fiktiven KI-Szenario, etwa einem offen zugänglichen Prompt-Log, deckt in zwei Stunden mehr Lücken auf als jede Dokumentenprüfung: fehlende Kontakte, unklare Entscheidungswege, Werkzeuge, auf die im Ernstfall niemand Zugriff hätte.

Fazit

Datenpannen mit KI-Bezug sind keine Frage des Ob, sondern des Wann, und sie werden selten von Alarmen entdeckt, sondern von Menschen. Ein belastbarer Prozess besteht deshalb aus vier Bausteinen: die KI-typischen Vorfallsarten kennen und melden können, den Schweregrad schnell und dokumentiert bewerten, Zuständigkeiten samt Anbieter-Meldewegen vorab festlegen und jeden Vorfall in konkrete Verbesserungen übersetzen. Der Aufwand für das Aufsetzen ist überschaubar. Im Ernstfall entscheidet er darüber, ob ein Unternehmen handelt oder improvisiert.