Die Maschine, die nicht vergessen kann

Eine Frau, die vor Jahren bei einer Beratungsstelle Hilfe suchte, meldet sich. Sie will, dass ihre Daten gelöscht werden – ihr gutes Recht nach der DSGVO. Die Sachbearbeiterin löscht die Akte im Dokumentenserver, bestätigt der Frau die Löschung, hakt den Vorgang ab. Und ist damit, ohne es zu wissen, möglicherweise im Unrecht. Denn die KI-Wissensdatenbank, in die diese Akte vor einem Jahr eingespeist wurde, hat die Daten vielleicht gar nicht wirklich vergessen. Sie hat nur ein Häkchen gesetzt.

Das klingt nach einem technischen Detail. Es ist der Punkt, an dem das Recht auf Löschung – eines der schärfsten Instrumente der DSGVO – auf die Funktionsweise dieser Systeme prallt und dabei ins Leere laufen kann. Dieser Teil erklärt, warum das so ist, und warum die bequeme Annahme „ein Löschbefehl löscht doch" gerade hier nicht trägt. Es ist der technisch anspruchsvollste Teil der Reihe – ich versuche, ihn ohne Fachchinesisch verständlich zu machen, und verspreche, dass am Ende eine Konstruktionsregel steht, die das Problem tatsächlich löst.

Warum das Recht auf Löschung hier zum Problem wird

Die DSGVO gibt Menschen in Artikel 17 das Recht, die Löschung ihrer Daten zu verlangen – das „Recht auf Vergessenwerden", über das vor Jahren so viel geredet wurde, als es noch um Google-Suchergebnisse ging. In einer normalen Datenbank ist die Umsetzung unspektakulär: Datensatz suchen, löschen, fertig. In einem KI-Wissenssystem ist es das nicht – aus einem Grund, der mit der Technik der Vektordatenbanken zu tun hat.

Erinnern wir uns an Teil 1: Jedes Textstück wird in eine lange Zahlenreihe übersetzt und in einer spezialisierten Datenbank abgelegt. Damit diese Datenbank blitzschnell die ähnlichsten Einträge findet, baut sie eine komplexe interne Landkarte aller Vektoren auf – ein Geflecht aus Verbindungen, in der Fachsprache ein „HNSW-Index". Dieses Geflecht bei jeder Löschung neu zu berechnen, ist rechenaufwändig und langsam. Deshalb gehen viele Systeme eine Abkürzung: Wird ein Eintrag „gelöscht", entfernen sie ihn nicht aus dem Geflecht, sondern setzen nur eine Markierung – „diesen bei Suchen überspringen". Für die Nutzerin sieht es aus wie gelöscht. In der Datenstruktur liegt er weiter, unsichtbar, aber vorhanden. Wie ein Track, den man im DJ-Set stummschaltet: Man hört ihn nicht mehr, aber er läuft mit.

Was hier wirklich passiert – keine Böswilligkeit, aber ein echtes Problem

Man könnte an dieser Stelle laut werden: „Die Konzerne löschen absichtlich nicht!" Die genauere Antwort ist unaufgeregter – und gerade deshalb ernster. Es ist keine böse Absicht, sondern eine Voreinstellung zugunsten der Geschwindigkeit. Aber die Folge ist real und inzwischen belegt.

Ein Forschungspapier mit dem sprechenden Titel „Ghost Vectors" hat 2026 gezeigt, dass sich solche nur markierten, „soft-gelöschten" Einträge aus der internen Struktur dieser Datenbanken rekonstruieren lassen. Die Daten sind also nicht bloß theoretisch noch da – sie sind wieder herauszuholen. Ich sage bewusst dazu: Es handelt sich um ein Preprint, also eine noch nicht abschließend begutachtete Arbeit, und sie untersucht eine bestimmte, wenn auch sehr verbreitete Bauart. Als endgültiger Beweis für „alles unlöschbar" taugt sie nicht. Als harter Hinweis, dass ein Löschbefehl in diesen Systemen nicht automatisch Löschung bedeutet, taugt sie sehr wohl. Und für eine Organisation, die einer Betroffenen die Löschung schriftlich bestätigt, ist genau das die entscheidende Information: Ein Häkchen ist keine Löschung. Echte Löschung verlangt, das Geflecht neu aufzubauen – das, was Techniker:innen „Reindexieren" nennen.

Immerhin gibt es hier eine praktische gute Nachricht, die ich der Fairness halber nenne: Manche Datenbanken – etwa die weit verbreitete Postgres-Erweiterung „pgvector" – erlauben echtes Löschen mit anschließendem Neuaufbau des Index. Die Wahl der Datenbank ist damit keine reine Technikfrage für die IT-Abteilung, sondern eine Datenschutzentscheidung, die auf den Tisch der Leitung gehört. Wer Löschbarkeit von Anfang an mitdenkt, erspart sich das Problem, das die Frau aus dem Eingangsbeispiel aufwirft. Wer es nicht tut, baut sich eine Zeitbombe ein, die erst hochgeht, wenn die erste Löschanfrage kommt – und die kommt garantiert.

Die zweite Hürde: Was, wenn die Maschine sich „erinnert"?

Es gibt eine noch grundsätzlichere Ebene. Bisher ging es um die Datenbank mit den Textstücken. Aber verändert man das Sprachmodell selbst mit den eigenen Daten – im Fachjargon „Feintuning" –, sitzt der Personenbezug plötzlich in den Modellgewichten, und die kann man nicht einfach „löschen" wie einen Datenbankeintrag. Man müsste, überspitzt gesagt, dem Modell einen Teil seiner Erinnerung herausoperieren – und das ist mit heutiger Technik praktisch nicht zuverlässig möglich.

Hier kommt die europäische Aufsicht erneut ins Spiel, mit derselben Stellungnahme, die schon Teil 1 grundierte. Der Europäische Datenschutzausschuss hat Ende 2024 festgehalten, dass ein aus personenbezogenen Daten entwickeltes Modell nicht automatisch anonym ist – und dass die Organisation nachweisen muss, dass sich weder direkt noch über geschickte Abfragen personenbezogene Daten herausholen lassen. Diese Hürde ist hoch. Forschung zu sogenannten Membership-Inference-Angriffen zeigt, dass sich unter Umständen feststellen lässt, ob die Daten einer bestimmten Person im Training waren. Ein feingetuntes Modell kann sich also, bildlich gesprochen, an Menschen „erinnern" – und dieses Erinnern ist praktisch nicht rückgängig zu machen.

Daraus folgt eine klare, fast beruhigende Konstruktionsregel: Für NGOs mit sensiblen Daten ist RAG dem Feintuning vorzuziehen, gerade weil RAG löschbar bleibt. In einem RAG-System kann man ein Textstück und seinen Vektor entfernen, sofern die Datenbank es sauber tut. Aus einem Modellgewicht bekommt man die Person nicht wieder heraus. Was nach einem technischen Nachteil klingt – RAG „merkt sich" nichts dauerhaft im Modell, es schlägt jedes Mal neu nach –, ist datenschutzrechtlich der entscheidende Vorteil. Manchmal ist die scheinbar primitivere Lösung die klügere.

Die anderen Rechte, die im Alltag untergehen

Das Recht auf Löschung ist nur das prominenteste. Daneben stehen das Recht auf Auskunft und auf Berichtigung – und beide setzen etwas voraus, das viele Systeme gar nicht mitbringen. Wer Auskunft geben will, welche Daten einer Person im System stecken, muss überhaupt wissen, welches Textstück zu wem gehört. Das verlangt saubere Metadaten – eine Zuordnung von Chunk zu Person. Viele schnell zusammengebaute Systeme haben die nicht; sie könnten auf eine Auskunftsanfrage schlicht nicht antworten, weil sie selbst nicht wissen, wer in ihrem Bauch steckt. Und wer eine falsche Information berichtigen soll, kann das im Textkorpus tun – im feingetunten Modell praktisch nicht. Wieder dasselbe Muster: Das schnell hingestellte System schuldet Antworten, die es nicht geben kann.

Hier zeigt sich der Konflikt in seiner konkretesten Form – Kontrolle gegen Bequemlichkeit. Das bequeme System – schnell aufgesetzt, mit Soft-Delete, ohne Metadaten, vielleicht feingetunt, am besten noch über eine US-API – ist das, das die Betroffenenrechte reihenweise nicht einlösen kann. Das kontrollierte System kostet mehr Sorgfalt im Bau und gibt diese Sorgfalt dafür an die Menschen zurück, um die es geht. Daran hängt mehr als eine technische Feinheit: die Frage, ob man das Versprechen hält, das man einer schutzsuchenden Person mit der Aufnahme ihrer Geschichte gegeben hat.

Wie eine Löschanfrage richtig abläuft – und warum das nicht trivial ist

Damit das nicht abstrakt bleibt, einmal konkret durchgespielt. Die Frau aus dem Eingangsbeispiel meldet sich. Ein System, das sein Handwerk versteht, macht dann Folgendes: Es findet über die Metadaten alle Chunks und Vektoren, die zu ihrer Akte gehören – das setzt voraus, dass diese Zuordnung beim Einspeisen überhaupt angelegt wurde. Es löscht sie nicht per Flag, sondern echt, und baut den betroffenen Teil des Index neu auf. Es prüft, ob Kopien in Backups, Caches oder Protokolldateien liegen, und behandelt die genauso. Und es dokumentiert den Vorgang, damit die Organisation belegen kann, dass gelöscht wurde – nicht nur behauptet.

Das klingt nach viel, und es ist viel – aber es ist der Unterschied zwischen einer ehrlichen und einer scheinheiligen Löschbestätigung. Wer ein Managed-System nutzt, verlässt sich für diese ganze Kette auf den Anbieter: Man muss vertraglich und technisch wissen, ob und wie schnell er wirklich löscht, statt es zu hoffen. „Wir haben da einen Löschbutton" ist keine Antwort auf die Frage, was hinter dem Button passiert. Ein sauberes Löschkonzept – welche Daten wie lange bleiben, wann sie automatisch verfallen, wie eine Anfrage bearbeitet wird – gehört deshalb in die Dokumentation, bevor das erste Dokument eingespeist wird, nicht als Feuerwehr danach.

Ein Wort noch zur vielbeschworenen Anonymisierung als Ausweg. Der Gedanke ist verführerisch: Wenn die Daten anonym sind, entfällt das Löschproblem, denn ohne Personenbezug keine DSGVO. Nur reicht es dafür nicht, ein paar Namen zu schwärzen. Solange sich eine Person aus dem Kontext wieder erschließen lässt – und bei detaillierten Fallgeschichten lässt sie das fast immer –, ist das Ergebnis rechtlich nur pseudonymisiert, das Löschproblem bleibt. Echte Anonymisierung, die vor Gericht hält, ist bei reichhaltigen Falltexten die Ausnahme, nicht die bequeme Abkürzung.

Kann das System vergessen? Ja – wenn man es dafür baut

Die ehrliche Antwort auf die Titelfrage lautet also nicht „nein", sondern „nur, wenn man es von Anfang an so konstruiert". Ein NGO-Wissenssystem kann das Recht auf Vergessen einlösen, wenn drei Dinge zusammenkommen: eine Datenbank, die wirklich löscht und ihren Index neu aufbaut; der Verzicht auf Feintuning mit Personendaten, damit nichts im Modell hängen bleibt; und eine saubere Zuordnung, wer wo im System steckt, damit Auskunft und Berichtigung überhaupt möglich sind. Das ist kein Hexenwerk, aber es ist eine bewusste Entscheidung gegen den schnellsten Weg – und für den, der die Rechte der Betroffenen ernst nimmt.

Damit haben wir die drei materiellen Ebenen beisammen: die Daten, die hineingehen; die Server, auf denen sie liegen; das Gedächtnis, das sie behalten oder loslassen. Was fehlt, ist die Ebene darüber – die Regeln. Wann ist so ein System überhaupt zulässig, wer muss vorher eine Folgenabschätzung machen, was sagt das neue KI-Gesetz der EU, und welche Empfehlung lässt sich am Ende ehrlich geben, ohne eine kleine NGO zu überfordern oder eine große in falscher Sicherheit zu wiegen? Das ist Teil 4 und der Schluss: Souveränität gibt es nicht im Abo – mit einer Bilanz, die auch der eigenen Seite widerspricht, und mit einem Ausblick, der über die einzelne Organisation hinausreicht.

Dieser Text ist Orientierung, kein Rechtsrat – bei der konkreten Umsetzung braucht es datenschutzrechtliche Beratung. Zeitlich instabile Angaben – Stand des Data Privacy Framework, AI-Act-Fristen, Anbieterlage, Stand der offenen Modelle – sind auf dem Stand Juli 2026 und sollten vor Weiterverwendung geprüft werden. Zur vollständigen Quellenbasis: siehe die Übersicht der Reihe.