Vertrauliche Daten in einer KI-Ausgabe entdeckt: Was zuerst geklärt werden muss

Wenn eine KI-Ausgabe vertrauliche Informationen enthält, muss zuerst die weitere Verbreitung begrenzt und der Vorfall intern gemeldet werden. Danach wird geklärt, welche Daten betroffen sind, woher sie stammen und wer tatsächlich Zugriff hatte. Eine auffällige Antwort allein beweist weder einen Angriff noch einen Abfluss an andere Kunden. Sie ist aber ein konkreter Anlass, den Vorgang nachvollziehbar zu untersuchen.

Dieser Artikel beschreibt einen vorgeschlagenen betrieblichen Erstablauf. Er ersetzt keine bestehende Notfallanweisung und keine rechtliche Einzelfallprüfung. Die zuständige Incident-Response-Funktion und die Datenschutzverantwortlichen müssen den konkreten Fall bewerten. Die Beispiele sind fiktiv; es wird kein realer Vorfall berichtet. Quellenstand: 24. Oktober 2026.

Die erste Aufgabe ist eine sichere Übergabe des Verdachts

Ein Mitarbeiter entdeckt in einer Antwort einen vertraulichen Vertragswert. Er darf den Inhalt nicht zur Diskussion in einen grossen Teamchat kopieren. Auch ein Screenshot kann den betroffenen Empfängerkreis vergrössern. Die erste interne Meldung enthält deshalb nur die nötigen Hinweise: welches System, welcher Vorgang, wann entdeckt und welche Art von Information auffällt.

Nutze den vorgesehenen geschützten Meldeweg. Wenn es einen Incident-Prozess gibt, hat dieser Vorrang vor dem hier beschriebenen Raster. Fehlt ein solcher Weg, muss die zuständige IT- oder Sicherheitsverantwortung ihn benennen. Eine Meldung an die Teamleitung allein reicht organisatorisch nicht aus, wenn dort niemand den technischen Zugriff begrenzen oder eine Datenschutzprüfung auslösen kann.

Verändere den betroffenen Ablauf nicht unkoordiniert. Pausiere eine weitere Weitergabe innerhalb deiner Berechtigung und melde den Status. Lösche nicht spontan alle Verläufe, Konten oder Dateien. Das kann relevante Nachweise vernichten und andere Abläufe beeinträchtigen. Die zuständige Einsatzleitung muss Eindämmung und Beweissicherung zusammen planen.

Vertraulichkeit und personenbezogene Daten sind zwei verschiedene Fragen

Eine interne Preisliste kann vertraulich sein, ohne sich auf eine natürliche Person zu beziehen. Eine Kundennotiz kann gleichzeitig vertrauliche Geschäftsangaben und personenbezogene Informationen enthalten. Die Untersuchung muss beide Aspekte berücksichtigen. Nicht jeder Vertraulichkeitsvorfall ist automatisch eine meldepflichtige Datenschutzverletzung.

Die Europäische Kommission erläutert den Begriff personenbezogener Daten. Massgeblich ist, ob Informationen eine identifizierte oder identifizierbare natürliche Person betreffen. Pseudonymisierung beseitigt diesen Bezug nicht automatisch. Im Vorfallprotokoll muss daher die Datenart beschrieben werden; das pauschale Feld "sensible Daten: ja" reicht zur Einordnung nicht.

Auch ein Geheimnis ohne Personenbezug verlangt einen passenden Reaktionsweg. Vertragsbedingungen, Zugangsdaten oder interne technische Informationen können andere Schäden auslösen. Die rechtliche Prüfung muss mögliche Pflichten aus dem konkreten Verhältnis einordnen. Die technische Untersuchung darf nicht warten, bis jede dieser Fragen abschliessend beantwortet ist.

Trenne Beobachtung, Vermutung und gesicherten Befund

Eine brauchbare Erstmeldung lautet: "Die Antwort zu Vorgang A enthält einen Wert, der in der zugänglichen Produktquelle nicht steht. Der Wert ähnelt einem internen Vertragswert. Herkunft noch ungeklärt." Sie behauptet nicht: "Das Modell hat unsere Daten an alle Nutzer weitergegeben." Diese zweite Aussage braucht andere Nachweise.

Diese Trennung verhindert zwei Fehler: eine unbewiesene Entwarnung und eine unbewiesene Eskalation. Ein unbekannter Empfängerkreis bleibt unbekannt. Er ist nicht automatisch leer. Der Artikel KI-Fehler als Vorfallbericht erfassen ergänzt die Struktur für technische und fachliche Ereignisse.

Untersuche mehrere mögliche Entstehungswege

Beginne mit dem ursprünglichen Auftrag. Vielleicht enthielt der Prompt bereits den vertraulichen Wert. Vielleicht wurde eine Datei angehängt, deren weitere Seiten nicht bemerkt wurden. Vielleicht erhielt ein Konnektor Zugriff auf einen zu breiten Ordner. Auch ein gemeinsam genutzter Chatverlauf oder eine fehlerhafte Zuordnung in der Anwendung kommt als Ursache infrage. Das sind Untersuchungshypothesen, keine Feststellungen.

Prüfe danach die Ausgabewege. Wurde der Text nur einer berechtigten Person angezeigt? Wurde er automatisch in ein anderes System geschrieben? Gibt es einen öffentlichen Freigabelink? Hat eine Benachrichtigung den Inhalt per E-Mail übertragen? Für die Schadensbegrenzung ist dieser Weg oft unmittelbarer relevant als eine spekulative Erklärung über das Modelltraining.

Ein Sprachmodell kann zudem falsche personenbezogene Angaben erzeugen. Auch solche Inhalte verlangen eine Prüfung, insbesondere wenn sie einer realen Person zugeordnet und weiterverarbeitet werden. Die Übereinstimmung eines Namens allein beweist keine Herkunft aus einer geheimen Quelle. Umgekehrt darf ein bestätigter unberechtigter Zugriff nicht mit dem Hinweis auf mögliche Halluzinationen abgetan werden.

Sichere nur die nötigen Nachweise

Ich empfehle, Vorgangskennung, Zeitstempel mit Zeitzone, betroffene Anwendung, sichtbare Ausgabe und relevante Konfiguration nachvollziehbar zu sichern. Das genaue Vorgehen muss der bestehende Sicherheitsprozess bestimmen. Der Zugriff auf diese Nachweise gehört auf einen begrenzten Personenkreis. Der Vorfallbericht selbst darf nicht zum zweiten unkontrollierten Speicherort werden.

Die Publikation NIST SP 800-61 Revision 3 ordnet Erkennung, Reaktion und Wiederherstellung in das Cybersecurity-Risikomanagement ein. Das Dokument ist eine fachliche Orientierung aus April 2025 und keine Aussage über deutsche Meldepflichten. Der hier vorgeschlagene Erstablauf ist eine eigene, auf kleine KI-Arbeitsabläufe zugeschnittene Umsetzungsidee.

Notiere bei jeder Sicherung, wer sie erstellt hat und was sie zeigt. Eine Datei mit Datum im Namen beweist noch nicht den tatsächlichen Entstehungszeitpunkt des ursprünglichen Ereignisses. Trenne deshalb Ereigniszeit, Entdeckungszeit und Sicherungszeit. Wenn eine Uhr falsch eingestellt war oder eine Zeitzone fehlt, bleibt diese Unsicherheit im Bericht erhalten.

Prüfe Meldepflichten sofort und parallel zur Technik

Die EDSA-Leitlinien 9/2022, Version 2.0 erläutern die Meldung von Verletzungen personenbezogener Daten. Artikel 33 DSGVO verlangt eine Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, ausser ein Risiko für Rechte und Freiheiten natürlicher Personen ist voraussichtlich ausgeschlossen. Eine verspätete Meldung benötigt eine Begründung.

Die Leitlinien verknüpfen das Bekanntwerden mit einem hinreichenden Grad an Gewissheit über einen Sicherheitsvorfall, der personenbezogene Daten beeinträchtigt hat. Es ist nicht nötig, vor jeder Meldung bereits die komplette technische Ursache zu kennen. Fehlende Informationen lassen sich unter den beschriebenen Voraussetzungen schrittweise ergänzen. Bei voraussichtlich hohem Risiko kommt zusätzlich die Benachrichtigung betroffener Personen nach Artikel 34 in Betracht, einschliesslich der dort geregelten Ausnahmen.

Die rechtliche Bewertung muss die zuständige Stelle übernehmen. Dokumentiere auch die begründete Entscheidung, keine Meldung vorzunehmen. Die 72 Stunden sind kein frei verfügbares Wartefenster. Die Untersuchung und Risikobewertung müssen sofort beginnen; eine interne Kalenderfrist ersetzt keine rechtliche Beurteilung.

Für Unternehmen richtet sich die zuständige Aufsicht nach dem konkreten Fall. Die Berliner Datenschutzaufsicht bietet beispielsweise ein Meldeverfahren. Dieser Link erklärt einen behördlichen Zugang, legt aber nicht automatisch die Zuständigkeit für jedes Unternehmen fest. Vertrauliche Vorfalldaten gehören ausschliesslich in den tatsächlich zuständigen und freigegebenen Meldekanal.

Fiktiver Fall: Der Assistent findet mehr als geplant

Ein Serviceassistent soll freigegebene Anleitungen durchsuchen. In einer Antwort erscheint eine Kundenkontaktnotiz. Die zuständige Person pausiert den betroffenen Abrufweg und meldet den Verdacht geschützt an die IT. Die Untersuchung stellt in diesem fiktiven Szenario fest, dass ein übergeordneter Ordner statt des vorgesehenen Unterordners verbunden wurde.

Die technische Ursache allein beantwortet noch nicht, wer die Notiz gesehen hat. Das Team prüft deshalb Konten, Sitzungen und mögliche Weitergaben im betroffenen Zeitraum. Die Aussage "Der Ordner ist jetzt richtig eingestellt" reicht als Abschluss nicht. Bereits erzeugte Ausgaben oder exportierte Dateien können unabhängig vom korrigierten Konnektor bestehen bleiben.

Ein zweiter Prüfschritt betrifft die Berechtigungen an der Quelle. Selbst bei richtigem Ordner muss der Assistent die vorgesehene Zugriffstrennung einhalten. Die Wiederaufnahme verlangt deshalb einen Test mit berechtigten und nicht berechtigten Testkonten. Der Test verwendet geeignete Prüfdaten und erzeugt keine zusätzliche Offenlegung realer Kundendaten.

Die interne Kommunikation trennt drei Zustände: Verbreitung begrenzt, Ursache korrigiert und Wiederaufnahme freigegeben. Diese Zustände können zu unterschiedlichen Zeitpunkten erreicht sein. Das ist präziser als die einzige Meldung "Problem behoben".

Kopierbare Erstaufnahme

Diese Vorlage dient dem internen, geschützten Meldeweg. Sie enthält keine bereits gesicherten Fakten. Trage bei fehlenden Informationen "offen" ein und vermeide vollständige vertrauliche Inhalte im allgemeinen Tickettext.

Ergänze später eine Chronologie. Jede neue Erkenntnis erhält einen Zeitpunkt und einen Nachweis. Korrigiere falsche Annahmen nachvollziehbar, statt die ursprüngliche Meldung still umzuschreiben. So bleibt sichtbar, auf welchem Wissensstand eine Entscheidung beruhte. Für die Vorbereitung eines solchen Prozesses hilft Schatten-KI durch sichere Arbeitsabläufe ersetzen.

Kommunikation braucht überprüfte Aussagen

Eine schnelle interne Nachricht darf knapp sein: betroffener Ablauf, vorläufige Einschränkung, zuständiger Kontakt und nächster Informationspunkt. Sie muss nicht die vollständige Untersuchung vorwegnehmen. Unbestätigte Angaben zur Zahl betroffener Personen oder zur Ursache gehören nicht als gesicherte Fakten in die Meldung.

Auch gegenüber dem Anbieter braucht es eine kontrollierte Übergabe. Übermittle nur die für die Untersuchung notwendigen Angaben über einen vereinbarten Kanal. Frage konkret nach dem betroffenen Zeitraum, relevanten Zugriffswegen und verfügbaren Nachweisen. Eine allgemeine Antwort "Unsere Systeme sind sicher" klärt den eigenen Vorgang nicht.

Eine Behauptung "Es gab keinen Datenabfluss" braucht eine belastbare Reichweite. Wenn nur ein bestimmter Exportweg geprüft wurde, muss die Aussage auf diesen Weg begrenzt bleiben. Die Prüfung von KI-Ergebnissen gilt auch für die Texte, mit denen ein Unternehmen über einen KI-Vorfall informiert.

Freigabe zur Wiederaufnahme ist ein eigener Schritt

Vor der Wiederaufnahme muss die verantwortliche Stelle die behobene Ursache, verbleibende Risiken und bestandene Tests kennen. Prüfe auch, ob bereits erzeugte Ausgaben bereinigt oder Zugriffe entzogen werden müssen. Eine technische Korrektur macht frühere Offenlegungen nicht rückwirkend ungeschehen.

Lege fest, welcher Test genau die frühere Fehlerursache abdeckt. Bei einem zu weit gefassten Datenzugriff sind Gegenproben mit getrennten Berechtigungen wichtiger als eine neue allgemeine Produktvorführung. Bei einem fehlerhaften Versandweg muss zusätzlich das Verhalten bei Abbruch und Wiederholung geprüft werden.

Der Abschlussbericht enthält den tatsächlichen Umfang der Untersuchung und die noch offenen Punkte. Er benennt Verantwortliche für verbleibende Massnahmen. Ein Vorfall ist damit nicht einfach eine schlechte KI-Antwort, sondern ein bearbeiteter Vorgang mit begrenzter Verbreitung, nachvollziehbarer Prüfung und dokumentierter Entscheidung über den weiteren Betrieb.