Kannst du jemanden wirklich aus einer RAG-Pipeline löschen?

Ein Auskunftsersuchen einer betroffenen Person kommt herein. Du löschst das Quelldokument und schließt das Ticket. Die Person ist noch an vier weiteren Stellen vorhanden, und eine davon erreichst du nicht.

Der Monat beginnt, wenn die E-Mail eintrifft

Artikel 12(3) gibt dir einen Monat, um auf ein Auskunftsersuchen zu antworten, verlängerbar um zwei weitere Monate, wenn die Anfrage komplex ist. Artikel 15 sagt, du musst der Person mitteilen, was du über sie speicherst. Artikel 17 sagt, dass du es unter bestimmten Umständen löschen musst.

Nichts davon wurde mit Retrieval-Augmented Generation im Hinterkopf geschrieben, und nichts davon kümmert sich darum.

Der Workflow, den die meisten Organisationen haben, ist der, den sie 2018 gebaut haben. Die Dateifreigaben durchsuchen, das Mailarchiv durchsuchen, exportieren, was man findet, löschen, was infrage kommt, den Brief schreiben. Bequem war das nie, aber es war lösbar, weil es eine Kopie der Wahrheit gab und die Kopien der Kopien wenigstens in Dateisystemen lagen, die man aufzählen konnte.

Dann hat jemand eine RAG-Pipeline an dieselben Freigaben angeschlossen. Die Anzahl der Stellen, an denen eine Person existiert, ging von eins auf fünf, und nur drei davon stehen in irgendeiner Löschprozedur.

Die fünf Stellen, und welche du erreichen kannst

1. Die Quelldokumente. Der Lebenslauf, der E-Mail-Thread, der Vertrag, das Support-Ticket. Das behandelt dein bestehender Prozess, und er behandelt es einigermaßen gut. Lösbar.

2. Der Vektorindex. Der wird vergessen, und das ist kein kleines Versehen.

Wenn du ein Dokument aufnimmst, zerlegst du es in Chunks und bettest jeden Chunk als Vektor ein. Dieser Vektor ist kein Verweis auf das Dokument — er ist eine verlustbehaftete, aber semantisch treue Darstellung des Texts selbst, die in einem separaten Datenspeicher mit eigenem Lebenszyklus liegt. Löschst du die Quelldatei, bleibt der Vektor bestehen, weiterhin munter abrufbar, weil in einer naiven Ingestion-Pipeline nichts die Löschung rückwärts propagiert.

Man nimmt an, ein Vektor sei anonym, weil er eine Liste von Fließkommazahlen ist. Ist er nicht. Embedding-Inversion ist ein aktives Forschungsfeld und funktioniert gut genug, um erhebliche Teile des Quelltexts allein aus dem Vektor zu rekonstruieren. Behandle Embeddings von personenbezogenen Daten als personenbezogene Daten, denn bei jeder ehrlichen Lesart von Artikel 4(1) sind sie genau das.

Lösbar, aber nur, wenn du dafür gebaut hast. Du brauchst stabile Dokument-IDs, die als Metadaten in den Vektorspeicher übernommen werden, und einen Löschpfad, der von der Quelle bis zum Index reicht. Das nachträglich in eine Pipeline einzubauen, die als Proof of Concept aufgesetzt wurde, ist wirklich unangenehm, und die meisten produktiven RAG-Deployments von heute wurden als Proof of Concept aufgesetzt.

3. Konversationsprotokolle. Jeder Prompt und jede Antwort, aufbewahrt zum Debugging, zur Evaluierung und zur Missbrauchserkennung. Wenn ein Mitarbeiter den Assistenten nach einem Kunden gefragt und eine synthetisierte Antwort mit dessen Angaben bekommen hat, stecken die personenbezogenen Daten des Kunden jetzt in einem Logspeicher, den dein Prozess für Auskunftsersuchen mit ziemlicher Sicherheit noch nie durchsucht hat.

Lösbar, und meist geht es nur darum, einzugestehen, dass der Logspeicher existiert, und ihm eine Aufbewahrungsregel zu geben.

4. Caches, Backups, Replikate. Prompt-Caches, Retrieval-Caches, der nächtliche Snapshot der Vektordatenbank, das Lesereplikat. Das Primärsystem zu löschen und die Kopien zu lassen, ist keine Löschung. Es ist Löschung an der einen Stelle, an der man zufällig nachgesehen hat.

Mit Aufwand lösbar, und hier würde ich den Aufwand konzentrieren, weil das der Fehler ist, der sich einer Aufsichtsbehörde am leichtesten zeigen und am schwersten wegerklären lässt.

5. Modellgewichte. Wenn du auf personenbezogenen Daten feinabgestimmt hast — etwa ein LoRA-Adapter über zehn Jahre Support-Tickets —, ist die Person jetzt so über Parameter verteilt, dass niemand sie lokalisieren oder herausschneiden kann.

Nicht lösbar. Es gibt keine Löschoperation. Maschinelles Verlernen ist ein aktives Forschungsfeld, die veröffentlichten Verfahren sind approximativ, und keines davon gibt dir eine Zusicherung, die du einer Aufsichtsbehörde schriftlich geben möchtest.

Der EDSA hat sich die angrenzende Frage in Stellungnahme 28/2024 angesehen und niemandem eine pauschale Ausnahme erteilt. Ob ein Modell als anonym gelten kann, ist eine Einzelfallbewertung, und sie hängt davon ab, ob sich personenbezogene Daten extrahieren lassen oder eine betroffene Person herausgegriffen werden kann — was angesichts dessen, was Membership-Inference- und Extraktionsangriffe zeigen, keine sichere Standardannahme ist.

Die praktische Konsequenz ist unverblümt: keine Feinabstimmung auf personenbezogenen Daten. Nicht weil es verboten wäre, sondern weil du damit eine Verpflichtung schaffst, die du mit keinem Mechanismus erfüllen kannst. Halte personenbezogene Daten in der Retrieval-Schicht, wo Löschung ein technisches Problem ist und kein ungelöstes Forschungsproblem. RAG ist die konforme Architektur fast aus Versehen, vorausgesetzt, du hast den Löschpfad verdrahtet.

Was Artikel 15 verlangt und jeder vergisst

Die Löschhälfte bekommt die ganze Aufmerksamkeit. Die Auskunftshälfte ist still und heimlich schwerer.

Ein Auskunftsersuchen verlangt von dir, anzugeben, welche personenbezogenen Daten du über die Person speicherst und woher sie stammen. Wenn deine Pipeline eine Reihe von SharePoint-Sites aufgenommen hat, weil sauberes Scoping drei Wochen gedauert hätte, kannst du diese Frage nicht beantworten. Nicht "es dauert eine Weile, zu antworten" — du kannst es strukturell nicht, weil du nie wusstest, was hineingelangt ist.

Das ist derselbe Fehler wie bei Artikel 5(2), nur dass er durch eine andere Tür kommt und mit einer namentlich genannten Person verknüpft ist.

Eine Prozedur schreiben, die einer Prüfung standhält

Die Version, die trägt, ist kürzer und ehrlicher als die Version, die die meisten Organisationen haben:

• Zähle die Speicher auf. Quellsysteme, Vektorindex, Konversationsprotokolle, Caches, Backups. Benannt, mit Eigentümer, mit jeweils einer Aufbewahrungsregel. Steht es nicht auf der Liste, wird es nicht durchsucht.

• Propagiere per ID, nicht per Namen. Löschung breitet sich von einer stabilen Dokument-ID aus. Ein Abgleich anhand des Namens einer Person über fünf Systeme hinweg scheitert an Rechtschreibung, an Eheschließungen und an der Tatsache, dass mehrere Menschen denselben Namen haben.

• Protokolliere die Löschung, nicht die Daten. Kennung, Grund, Genehmiger, Zeitstempel pro Speicher. Genug, um den Vorgang zu belegen, ohne aufzubewahren, was du gelöscht hast.

• Gib an, was du nicht gelöscht hast, und warum. Daten unter einer gesetzlichen Aufbewahrungspflicht, und — falls du feinabgestimmt hast, bevor du es besser wusstest — das Modell. Aufsichtsbehörden reagieren deutlich besser auf eine dokumentierte Einschränkung als auf eine entdeckte.

• Führe es erneut aus. Eine Löschung, die einmal gelingt und durch die nächste Pipeline-Änderung stillschweigend außer Kraft gesetzt wird, ist schlimmer als keine Löschung, weil du ein Zertifikat hast, das das Gegenteil behauptet.

Die Abkürzung

Jeder Punkt oben wird leichter, je weniger du aufgenommen hast.

Die Organisationen, die das gut hinbekommen, sind nicht die mit dem ausgefeiltesten Lösch-Tooling. Es sind die, die ihre unstrukturierten Daten zuerst klassifiziert haben, gelöscht haben, was keinen rechtmäßigen Zweck hatte, und erst dann eine Retrieval-Pipeline auf das gerichtet haben, was übrig blieb.

Sie beantworten Auskunftsersuchen anhand eines Korpus, das sie beschreiben können. Alle anderen beantworten sie anhand eines Korpus, von dem sie hoffen, dass sie es beschreiben können.

Wenn du wissen willst, was tatsächlich in deinen unstrukturierten Daten steckt, bieten wir eine kostenlose Überprüfung an.

Pass auf dich auf da draußen.

/A