KI-Datenschutzvorfall: Was in den ersten 72 Stunden wirklich zählt

Ein vertraulicher Prompt, eine Kundenliste im falschen Workspace oder ein Dokument in einem nicht freigegebenen KI-Tool: In den ersten Stunden ist die wichtigste Frage nicht, ob eine Meldepflicht besteht. Entscheidend ist, weitere Auswirkungen zu begrenzen und belastbare Fakten zu sichern: Was wurde übertragen, über welchen Account, wohin, mit welchen Folgepfaden – und was lässt sich noch kontrollieren?

Technische Triage beginnt sofort. Datenschutz, Incident Management und gegebenenfalls Rechtsrat bewerten parallel die rechtlichen Folgen. Dabei gilt: Ein Upload ist nicht automatisch Modell-Training. Eine sichtbare Löschung ist nicht automatisch vollständige technische Entfernung. Und ein sichtbarer Chatverlauf ist nicht automatisch das vollständige Audit-Log.

Nicht spekulieren. Evidenz sichern.

Dieser Beitrag behandelt den konkreten Vorfall, der bereits passiert ist. Wie Unternehmen wiederkehrende Nutzung außerhalb freigegebener Wege reduzieren, behandelt Schatten-KI im Unternehmen.

Was in den ersten Stunden wirklich zählt

Die Qualität der ersten Reaktion hängt nicht an einer sofortigen rechtlichen Schlussfolgerung. Sie hängt daran, ob das Unternehmen die Lage stabilisiert und eine nachvollziehbare Faktenbasis aufbaut. Diese Basis brauchen technische Owner, Incident Management, Datenschutz und Legal jeweils für unterschiedliche Entscheidungen.

Technische Triage bei einem KI-Incident

1. 01

   Incident erkannt

   Welches Tool, welcher Account und welcher Zeitpunkt sind bislang bekannt?

   Erste Fakten und Owner festhalten

2. 02

   Containment

   Welche Uploads, Freigaben, Connectoren oder Automationen können noch weitere Daten bewegen?

   Aktive Datenpfade begrenzen

3. 03

   Evidenz

   Welche Logs, IDs, Zeitstempel und Einstellungen belegen den Ablauf?

   Nachvollziehbare Faktenbasis

4. 04

   Scope

   Welche Daten, Empfänger, Systeme und Mandanten sind tatsächlich betroffen?

   Technischer Incident Scope

5. 05

   Technische Folgen

   Gab es Sharing, Exporte, Indizes, Integrationen oder ausgelöste Aktionen?

   Side Effects geprüft

6. 06

   Eskalation

   Welche offenen Fakten, Owner und Entscheidungen müssen übergeben werden?

   Koordinierte nächste Schritte

Phase 1: Weitere Datenflüsse stabilisieren und begrenzen

Zuerst geht es um weitere Ausbreitung – nicht um eine allgemeine Bereinigung. Die konkreten Maßnahmen hängen vom Setup ab:

• Weitere Uploads oder Weitergaben im betroffenen Tool stoppen.
• Betroffenen Account, Workspace oder Tenant identifizieren und den aktuellen Zugriff prüfen.
• Öffentliche oder geteilte Links prüfen und, wenn erforderlich, deaktivieren.
• Aktive Connectoren, Plugins und API-Integrationen auf den betroffenen Datenpfad prüfen.
• Laufende Automationen oder Schreibpfade pausieren, wenn sie weitere Daten in andere Systeme übertragen oder Folgeaktionen auslösen können.
• Tokens, API-Keys oder Credentials nur rotieren oder widerrufen, wenn sie exponiert sind oder für weitere Ausführung auf dem betroffenen Pfad relevant bleiben.

Credential Rotation kann weitere Nutzung stoppen. Bereits übertragene Daten macht sie nicht rückgängig. Ebenso wichtig: Chats, Dateien, Logs oder Accounts nicht blind löschen, bevor die für den Incident nötige Evidenz gesichert ist.

Wenn intern kein klarer technischer Owner für diese Schritte verfügbar ist, kann die KI-Vorfall-Soforthilfe helfen, den Vorfall einzugrenzen, technische Fakten zu sichern und nächste Owner sowie Eskalationspfade festzulegen.

Phase 2: Evidenz sichern, ohne sensible Daten zu vervielfältigen

Die Incident-Dokumentation soll den Ablauf belegen, nicht den ursprünglichen Datenabfluss durch neue Kopien vergrößern. Sichern Sie – soweit im konkreten System verfügbar – einen kompakten Faktenkatalog:

• Tool oder Anbieter sowie Produkt, Tarif und Account-Typ,
• Workspace oder Tenant,
• Benutzer, Identität und Rollen,
• Zeitpunkt der Eingabe, des Uploads, Sharings und der Entdeckung,
• Dateien, Prompts oder Inputs als Referenz – etwa Dateiname, ID, Hash oder Zeitstempel statt vollständigem Inhalt,
• Sharing, Freigaben, Links und bekannte Empfänger,
• Admin-, Audit-, Identity- und Access-Logs,
• Connectoren, Plugins, API-Zugriffe und zugehörige Konfiguration,
• beobachtete Folgeaktionen oder Schreibvorgänge,
• sichtbare Retention- und Delete-Einstellungen,
• relevante Anbieterinformationen, Support-Tickets und Exportmöglichkeiten.

Wo möglich, sind IDs, Log-Referenzen, Hashes, Dateinamen und Zeitstempel besser als vollständige sensible Inhalte in Screenshots, Tickets oder neuen Dokumenten. Wenn ein Screenshot notwendig ist, sollte er nur die Information enthalten, die den Ablauf belegt.

Phase 3: Scope bestimmen

Die technische Scope-Frage lautet nicht „Wie schlimm ist es?“, sondern: Welche Systeme, Daten und Zugänge sind nachweisbar betroffen – und welche Punkte sind noch offen?

Daten

Klären Sie, ob personenbezogene Daten, besondere Kategorien, Kunden- oder Mitarbeiterdaten, Geschäftsgeheimnisse, interne Dokumente oder Secrets und Credentials enthalten waren. Eine Datei kann mehrere dieser Kategorien zugleich enthalten.

Umfang

Unterscheiden Sie einzelnen Text, ein Dokument, mehrere Dateien sowie Datensätze, Personen oder Mandanten. Halten Sie fest, was konkret bekannt ist und was nur vermutet wird.

Account und Empfänger

War ein privater Consumer-Account, ein verwalteter Business- oder Enterprise-Workspace oder ein geteilter Zugang beteiligt? Gab es öffentliche Links, externe Empfänger oder weitere Personen mit Zugriff?

Systeme

Erfassen Sie Quellsysteme, Downstream-Systeme und aktive Integrationen. Entscheidend ist nicht nur, wo die Daten herkamen, sondern auch, ob sie über Connectoren, APIs oder Automationen weitere Systemgrenzen passieren konnten.

Diese Einordnung simuliert keine juristische Risikobewertung. Sie definiert den technischen Incident Scope und macht fehlende Fakten sichtbar.

Phase 4: Technische Folgen außerhalb des Chatfensters prüfen

Ein KI-Incident kann Side Effects außerhalb des sichtbaren Chatverlaufs haben. Das bedeutet nicht, dass sie in jedem Setup entstehen. Es bedeutet: Sie müssen im konkreten Setup geprüft werden.

• Wurde Inhalt nur eingegeben oder hochgeladen – oder zusätzlich geteilt?
• Existieren aktive oder frühere Links, Exporte oder Freigaben?
• Waren Connectoren, Plugins oder APIs aktiv?
• Wurden Daten in externe Systeme geschrieben, etwa Tickets, Nachrichten, Datensätze oder Dateien?
• Haben Automationen, Agents oder Tool Calls Folgeaktionen ausgelöst?
• Könnten Embeddings, Indizes oder Caches entstanden sein, und gibt es dafür Evidenz oder Konfigurationsdaten?
• Welche Exporte, Audit-Daten oder weiteren Protokolle sind verfügbar?

Der sichtbare Chat ist deshalb nur ein möglicher Einstiegspunkt. Für die technische Einordnung zählen auch Identity-Daten, Admin- und Audit-Logs, Integrationskonfigurationen und nachweisbare Zustandsänderungen in angebundenen Systemen.

Phase 5: Anbieter- und Account-Maßnahmen gezielt auslösen

Erst wenn Tool, Account und Datenpfad eingegrenzt sind, lassen sich Maßnahmen zielgerichtet auslösen. Prüfen und dokumentieren Sie, was im konkreten Produkt tatsächlich verfügbar ist:

• sichtbare Delete-Funktionen und deren Ergebnis,
• Retention Controls und dokumentierte Aufbewahrungsregeln,
• Admin Controls, Workspace Policies und Rollen,
• Widerruf von Connectoren sowie API- oder Token-Zugriffen,
• Audit- oder Account-Exporte,
• Support Request mit den gesicherten Referenzen,
• gegebenenfalls dokumentierte Data Controls des Anbieters.

„Gelöscht“ im UI ist kein automatischer Beweis für vollständige technische Entfernung. Umgekehrt ist eine offene Frage zur Anbieter-Verarbeitung kein Grund für Spekulation. Dokumentieren Sie die verfügbaren Fakten, die konkrete Anfrage an den Anbieter und dessen belastbare Antwort.

Vorläufig klassifizieren, nicht spekulieren

Eine kompakte Klassifikation ersetzt keinen Score und keine automatische Meldeentscheidung. Sie hilft, Priorität, Owner und offene Fragen sichtbar zu machen:

• Datenart,
• Umfang,
• Zugänglichkeit,
• Empfänger,
• bekannte Persistenz oder Retention,
• Secrets oder Credentials,
• ausgelöste Systemaktionen,
• Reversibility: Was lässt sich nachweisbar stoppen, widerrufen oder entfernen – und was noch nicht?

Das Ergebnis darf „unklar“ sein. Gerade dann ist es wertvoll, weil es zeigt, welche Evidenz als Nächstes fehlt und wer sie beschaffen kann.

Was Sie jetzt nicht tun sollten

• Nicht über Modell-Training oder interne Anbieterprozesse spekulieren.
• Nicht Chats, Dateien oder Logs blind löschen, bevor notwendige Evidenz gesichert ist.
• Keine Beweise durch hektische Änderungen oder unkoordinierte Admin-Aktionen überschreiben.
• Nicht automatisch jeden Incident als meldepflichtig deklarieren.
• Nicht nur Passwörter ändern, wenn das eigentliche Problem eine bereits erfolgte Datenweitergabe ist.
• Nicht allein auf den sichtbaren Chatverlauf vertrauen.
• Keine Schuldzuweisung an Mitarbeitende, bevor Ablauf, Tooling und Kontrolllücken verstanden sind.

72 Stunden: rechtliche Frist, keine technische Wartezeit

Die 72-Stunden-Regel betrifft nicht jeden KI-Vorfall, sondern eine nach Art. 33 DSGVO gegebenenfalls erforderliche Meldung einer Verletzung des Schutzes personenbezogener Daten an die zuständige Aufsichtsbehörde. Ob diese Voraussetzung erfüllt ist, muss anhand des konkreten Vorfalls fachlich bewertet werden.

72 Stunden sind keine Schonfrist für technische Analyse. Containment und Evidenzsicherung beginnen sofort – auch dann, wenn Art, Umfang und rechtliche Folgen des Vorfalls noch offen sind. Datenschutz und fachkundiger Rechtsrat bewerten Fristen sowie mögliche Melde- und Informationspflichten. Dieser Artikel trifft keine abschließende Meldeentscheidung, sondern liefert die technische Faktenbasis.

Übergabe an Datenschutz, Incident Management und Rechtsrat

Technische, organisatorische und rechtliche Arbeit laufen parallel, aber mit unterschiedlichen Aufgaben:

Technische Triage liefert

• Fakten, Scope und offene technische Fragen,
• Logs, Evidenz und eine nachvollziehbare Timeline,
• aktive Datenpfade, Containment-Status und mögliche Side Effects.

Datenschutz und Legal bewerten

• rechtliche Einordnung,
• mögliche Melde- oder Informationspflichten,
• Kommunikation und weitere rechtliche Dokumentation.

Incident Management koordiniert

• Owner und Maßnahmen,
• Eskalation und Entscheidungszeitpunkte,
• Timeline und Kommunikation zwischen den beteiligten Teams.

Die technische Übergabe ist dann gut, wenn sie nicht auf Vermutungen beruht: Was ist belegt, was wurde begrenzt, was ist noch aktiv und welche Information fehlt noch?

Nach dem Vorfall: vom Einzelfall zum kontrollierten AI-Arbeitsweg

Ein konkreter Incident ist nicht automatisch ein Governance-Programm. Zeigt er jedoch wiederkehrende Nutzung außerhalb freigegebener Wege, ist Schatten-KI im Unternehmen der nächste Schritt: ein strukturelles Adoption- und Angebotsproblem, nicht die Rückschau auf diesen einzelnen Vorfall.

Müssen Daten-, Kontroll- oder Betriebsgrenzen langfristig neu entschieden werden, vertieft DSGVO-konforme KI die Architekturfrage. Fehlende Incident Paths, Observability oder Runbooks können wiederum ein Anlass für die KI-Architektur-Checkliste für Unternehmen sein.

Die KI-Vorfall-Soforthilfe bleibt der direkte Pfad, wenn der konkrete Vorfall jetzt technisch eingegrenzt, dokumentiert und in klare nächste Schritte überführt werden muss.