Personenbezogene Daten in KI-Systemen: Löschen, Anonymisieren, Zugriff regeln

Wo personenbezogene Daten in einem KI-System liegen

Ein KI-System, das mit eigenen Dokumenten antwortet, besteht aus mehreren Bausteinen. Die Datenschutzkonferenz (DSK), das gemeinsame Gremium der deutschen Datenschutzaufsichtsbehörden, beschreibt den typischen Aufbau in ihrer Orientierungshilfe zu RAG-Systemen vom Oktober 2025: Dokumente werden in kurze Textabschnitte zerlegt, sogenannte Chunks. Ein Embedding-Modell wandelt jeden Chunk in einen Zahlenvektor um, und beides wird gemeinsam in einer Vektordatenbank gespeichert. Kommt eine Frage, sucht das System die passenden Abschnitte und gibt sie dem Sprachmodell mit.

Für den Datenschutz heißt das: Personenbezogene Daten liegen nicht an einer Stelle, sondern an mehreren.

Zwei Stellen werden oft übersehen. Erstens Protokolle: Viele Systeme schreiben Fragen und Antworten zur Fehlersuche in Logdateien und bewahren sie dort oft länger auf als den eigentlichen Chatverlauf. Zweitens Backups: Ein gelöschtes Dokument kann in Sicherungen noch Wochen später vorhanden sein. Beide gehören in Ihr Verzeichnis der Verarbeitungstätigkeiten und in Ihr Löschkonzept.

Ein Sonderfall sind die Modellgewichte. Solange Sie ein Sprachmodell nur nutzen, es nicht mit eigenen Daten nachtrainieren und ein externer Anbieter Ihre Eingaben nicht zum Training verwendet, gelangen Ihre Dokumente nicht in das Modell. Wer dagegen mit personenbezogenen Daten feinabstimmt, schreibt sie unter Umständen in das Modell ein, wo sie sich kaum gezielt entfernen lassen. Mehr dazu im Beitrag KI mit eigenen Daten trainieren. Was die DSK insgesamt verlangt, fasst der Ratgeber zur DSK-Orientierungshilfe KI zusammen.

Kurz gesagtSieben mögliche Orte. Vier lassen sich gezielt löschen, Protokolle und Backups brauchen eigene Fristen, das Modell ist nur bei Fine-Tuning betroffen.

Was die DSGVO-Rechte im KI-System bedeuten

Die DSGVO kennt keine Sonderregeln für KI. Die bekannten Rechte und Pflichten gelten, und sie müssen an jedem Speicherort umsetzbar sein. Die DSK hält in ihrer RAG-Orientierungshilfe fest: Für Eingaben und Ausgaben, die Referenzdokumente und die Vektordatenbank stehen Betroffenen die Rechte aus Art. 15 ff. DSGVO zu, und Transparenz, Auskunft, Berichtigung und Löschung lassen sich dafür in der Regel umsetzen (Abschnitt 3.7). Den vollständigen Prüfpfad beschreibt der Ratgeber DSGVO-konforme KI.

Für die Antwort an die betroffene Person gilt Art. 12 Abs. 3 DSGVO: unverzüglich, spätestens innerhalb eines Monats. Bei komplexen oder zahlreichen Anträgen kann die Frist um zwei weitere Monate verlängert werden; darüber informieren Sie die Person innerhalb des ersten Monats und nennen die Gründe. Legen Sie deshalb vorab fest, wie Sie alle Speicherorte nach einer Person durchsuchen. Eine Volltextsuche über Dokumente, Verlauf und Logs ist dafür meist der direkte Weg; die Vektoren allein eignen sich weniger, weil sie Bedeutung abbilden und nicht exakte Namen.

Anders sieht es im Sprachmodell aus. Die DSK nennt die Umsetzung von Betroffenenrechten in KI-Modellen, insbesondere großen Sprachmodellen, „weitgehend ungelöst“. Auch die Einordnung der Modelle selbst ist zwischen Aufsichtsbehörden nicht einheitlich. Der Hamburgische Datenschutzbeauftragte vertrat im Juli 2024, vor der EDSA-Stellungnahme, in einem als Debattenimpuls bezeichneten Diskussionspapier die These, im Sprachmodell selbst würden keine personenbezogenen Daten gespeichert; Betroffenenrechte bezögen sich jedenfalls auf Input und Output. Das Papier betrifft nur das Modell, nicht Vektorindex oder Dokumente eines RAG-Systems. Der Europäische Datenschutzausschuss (EDSA) hielt im Dezember 2024 fest, dass mit personenbezogenen Daten trainierte KI-Modelle nicht in allen Fällen als anonym gelten können (Stellungnahme 28/2024, Rn. 34).

Kurz gesagtAuskunft, Berichtigung und Löschung lassen sich für Dokumente, Index, Verlauf und Logs in der Regel umsetzen, im Modell selbst kaum.

Pseudonym, anonym, Embedding: wo die Grenze liegt

Zwei Begriffe werden oft verwechselt. Pseudonymisierte Daten lassen sich ohne zusätzliche Informationen keiner Person mehr zuordnen, mit diesen Informationen aber schon (Art. 4 Nr. 5 DSGVO). Für Sie als Verantwortlichen, der die Zuordnung herstellen kann, bleiben sie personenbezogene Daten. Anonym sind Informationen erst, wenn sich die Person mit den Mitteln, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, nicht mehr identifizieren lässt (Erwägungsgrund 26). Nur dann gilt die DSGVO nicht.

Embeddings wirken auf den ersten Blick anonym: Aus einem Satz wird eine Liste aus Hunderten bis Tausenden Zahlen. Die Forschung zeigt aber, dass sich der Text daraus oft zurückgewinnen lässt. Morris und Kollegen von der Cornell University konnten mit ihrem Verfahren Vec2Text 92 % von Texteingaben mit 32 Tokens exakt aus ihren Embeddings rekonstruieren. Aus eingebetteten klinischen Notizen gewannen sie 89 % der vollständigen Namen zurück. Schon 2020 hatten Song und Raghunathan aus verbreiteten Satz-Embeddings 50 bis 70 % der Wörter zurückgewonnen.

Diese Ergebnisse entstanden unter Laborbedingungen: Die Angreifer hatten Zugriff auf die Vektoren und konnten das Embedding-Modell beliebig oft abfragen. Hinzu kommt, dass in vielen Vektordatenbanken neben jedem Vektor auch der Textabschnitt selbst liegt, so beschreibt es auch die DSK. Der EDSA betont zudem mit Blick auf KI-Modelle, dass sich Informationen auch dann auf eine Person beziehen können, wenn sie nur maschinenlesbar kodiert sind (Stellungnahme 28/2024, Rn. 37); das lässt sich auf Embeddings übertragen.

Für die Praxis heißt das: Behandeln Sie den Vektorindex mit demselben Schutzbedarf wie die Dokumente, aus denen er entstanden ist. Er braucht eine Rechtsgrundlage (DSK, Abschnitt 3.6), ein Zugriffskonzept und ein Löschkonzept. Datensparsamkeit lohnt sich trotzdem: Laut DSK sind personenbezogene Daten schon bei der Aufbereitung zu entfernen oder zu anonymisieren, soweit sie nicht erforderlich sind (Abschnitt 3.1). Wo sie gebraucht werden, senkt Pseudonymisierung das Risiko; Art. 32 DSGVO nennt sie ausdrücklich als Schutzmaßnahme.

Kurz gesagtEmbeddings sind keine Anonymisierung. Pseudonymisieren senkt das Risiko, der Personenbezug bleibt.

Löschen, das alle Speicherorte erreicht

Ein Löschantrag nach Art. 17 DSGVO ist erst vollständig umgesetzt, wenn die Daten aus allen aktiven Speicherorten entfernt sind und für Backups ein dokumentiertes Vorgehen greift. In einem RAG-System ist das gut machbar: Laut DSK sind Einträge in der Vektordatenbank „direkt adressierbar und damit auch personenbezogene Daten gezielt löschbar“ (Abschnitt 3.5). Damit das zuverlässig klappt, muss die Löschung durchgreifen, vom Quelldokument bis zum Backup.

Bei angebundenen Quellen kommt es auf den Abgleich an: Wird ein Dokument im Quellsystem gelöscht, muss die nächste Synchronisation es auch aus dem Index entfernen. Prüfen Sie das mit einem Testdokument, bevor Sie produktiv gehen, und halten Sie das Ergebnis fest.

Backups regelt die DSGVO nicht ausdrücklich. Einzelne Datensätze werden in der Praxis selten aus Sicherungen herausgelöscht. Verbreitet ist, Backups mit fester Rotation zu überschreiben, sie gegen Zugriff zu schützen und dafür zu sorgen, dass gelöschte Daten nach einer Wiederherstellung nicht wieder auftauchen, etwa indem Löschungen nach dem Restore erneut angewendet werden. Halten Sie dieses Vorgehen in Ihrem Löschkonzept fest. Gesetzliche Aufbewahrungspflichten können einer Löschung entgegenstehen (Art. 17 Abs. 3 lit. b DSGVO); dann schränken Sie die Verarbeitung auf den Aufbewahrungszweck ein und nehmen die Daten aus der KI-Nutzung heraus.

Im Modell ist Löschen deutlich schwieriger. Die DSK schreibt, ungeachtet der Vorteile eines RAG-Systems blieben „die Probleme bei der Datenlöschung im Sprachmodell bestehen“ (Abschnitt 3.5). In ihrer Orientierungshilfe zu technischen und organisatorischen Maßnahmen vom Juni 2025 hält sie fest, dass Filter als Übergangslösung einzusetzen sind, „an sich“ aber keine Löschung darstellen (S. 23).

Kurz gesagtLöschen heißt: Quelle, Index, Verlauf, Protokolle und Backups. Testen Sie den Weg einmal, bevor Sie live gehen.

Zugriff, Aufbewahrung und sparsame Protokolle

Wer welche Inhalte über die KI finden darf, entscheidet sich nicht im Sprachmodell. Die DSK weist darauf hin, dass sich im Sprachmodell selbst nicht steuern lässt, wer worauf zugreifen darf. Im RAG-Teil greifen dagegen bewährte Maßnahmen wie Mandantentrennung und ein Rechte- und Rollenkonzept für Bereiche der Vektordatenbank und die Referenzdokumente (Abschnitt 3.3). Praktisch heißt das: Trennen Sie Inhalte nach Zweck, etwa Personalunterlagen in ein eigenes Projekt mit kleinem Nutzerkreis und Handbücher in ein offenes.

Prüfen Sie außerdem, ob Berechtigungen aus dem Quellsystem übernommen werden. Nicht jedes System übernimmt die Rechte einzelner Dokumente aus Laufwerken, Wikis und Ticketsystemen. Wenn nicht, legen Sie nur Inhalte in ein gemeinsames Projekt, die alle Mitglieder sehen dürfen. Die DSK verlangt, bei jeder neuen Datenquelle eines RAG-Systems zu prüfen, ob alle Nutzenden auch auf die neuen Daten zugreifen dürfen (Orientierungshilfe zu technischen und organisatorischen Maßnahmen, S. 24).

Speicherbegrenzung (Art. 5 Abs. 1 lit. e DSGVO) und datenschutzfreundliche Voreinstellungen (Art. 25 Abs. 2 DSGVO) sprechen für kurze Fristen. Die DSK nennt als Beispiel für Beschäftigten-Accounts, Eingaben nicht für Training zu nutzen und keine Eingabe-Historie über die Sitzung hinaus zu speichern (Orientierungshilfe KI und Datenschutz, Mai 2024, Rn. 43). Ob Ihr Einsatz zusätzlich eine Datenschutz-Folgenabschätzung braucht, klären Sie am besten früh.

Bei Protokollen hilft eine einfache Regel. Für Sicherheit (Art. 32 DSGVO) und Fehlersuche sind Logs sinnvoll, aber nicht unbedingt mit dem Wortlaut jeder Frage. Protokollieren Sie Metadaten wie Zeitpunkt, Nutzer, Projekt und Quelle, und speichern Sie Inhalte nur, wenn es dafür einen Zweck gibt, mit eigener, kurzer Frist.

Kurz gesagtZugriff steuern Sie über Projekte und Rollen, nicht über das Modell. Kurze Fristen und sparsame Logs gehören in die Grundeinstellung.

Personenbezogene Daten in RAGSuite

RAGSuite ist eine RAG Engine: Mit Ihren Daten trainiert RAGSuite kein Modell. Dokumente, Textabschnitte und Embeddings liegen im Suchindex, wo Sie sie verwalten und löschen. Die kostenlose Community Edition (Apache-2.0) bietet automatische Löschung mit Löschbelegen, Zwei-Faktor-Anmeldung, ein Audit-Log der letzten 15 Tage und einen einfachen Abfrageverlauf. Sie läuft auf Ihrem eigenen Server, auch offline, und sendet keine Telemetrie.

Für Organisationen mit mehreren Teams bietet Enterprise Rollen und Projektzugriffe, Single Sign-on, die vollständige Audit-Historie mit Export sowie Aufbewahrungsrichtlinien und Legal Hold. Wichtig für Ihr Zugriffskonzept: RAGSuite übernimmt die Berechtigungen einzelner Dokumente aus den Quellsystemen nicht; Sie trennen Inhalte über Projekte und steuern in Enterprise, welche Teams auf welches Projekt zugreifen. Mehr zu den Datenschutzfunktionen zeigt die Seite KI-Datenschutz, und wie Daten durch das System fließen, erklärt der Ratgeber RAG-Pipeline.

Kurz gesagtIn RAGSuite liegen Ihre Daten in Index, Verlauf und Protokollen, nicht im Modell. Trennung über Projekte; Aufbewahrungsrichtlinien und Legal Hold in Enterprise.