Löschen in einer KI-Plattform: die fünf Orte, an denen Daten liegen

TL;DR

Ein Löschersuchen trifft nicht eine Datenbank, sondern fünf: Quellsystem, Vektorindex, Chatverläufe, Aufrufprotokolle und Zwischenspeicher. Wer nur das Quellsystem bereinigt, hat die Daten weiterhin im Index — und beantwortet weiter Fragen daraus. Das Konzept muss deshalb vor der ersten Indexierung stehen.

Warum das bei KI-Systemen anders liegt

Bei einer klassischen Fachanwendung ist Löschen ein Vorgang: Datensatz weg, fertig.

Bei einer KI-Plattform vervielfältigen sich die Daten während des normalen Betriebs. Ein Dokument aus einer Personalakte wird geparst, in Abschnitte zerlegt, jeder Abschnitt eingebettet und im Index abgelegt, samt Klartext in der Nutzlast. Wird es in einer Anfrage abgerufen, landet es im Chatverlauf und im Aufrufprotokoll. Möglicherweise auch im Zwischenspeicher des Gateways.

Aus einem Dokument sind fünf Kopien geworden, an fünf Orten mit fünf verschiedenen Lebensdauern.

Die fünf Orte

1. Quellsystem. SharePoint, Netzlaufwerk, Fachanwendung. Hier greift Ihr bestehendes Löschkonzept — sofern es eines gibt.

2. Vektorindex. Enthält Einbettungen und in der Regel den Klartext des Abschnitts in der Nutzlast. Das ist der Ort, der am häufigsten übersehen wird, weil er als "technischer Index" wahrgenommen wird und nicht als Datenspeicher.

Zur häufig gestellten Frage, ob eine Einbettung personenbezogen ist: Sie ist aus dem Text abgeleitet und lässt Rückschlüsse zu. Die Diskussion ist fachlich nicht abschließend geführt — praktisch ist sie irrelevant, weil der Klartext ohnehin danebensteht. Entfernen Sie den Punkt vollständig.

3. Chatverläufe. Die Oberfläche speichert Gespräche, damit Nutzer sie wiederfinden. Darin stehen Fragen und Antworten im Klartext — einschließlich abgerufener Personendaten.

4. Aufrufprotokolle. Die Nachverfolgung enthält Prompt, abgerufene Abschnitte und Antwort. Der vollständigste Datensatz von allen. Die Einordnung dazu steht im Beitrag zur LLM-Nachverfolgung.

5. Zwischenspeicher. Wenn Sie Antwort-Caching aktiviert haben, liegen dort vollständige Antworten. Mit einer Lebensdauer, die jemand einmal gesetzt hat.

Der Ablauf, der funktioniert

Der Schlüssel ist eine Kennung, die sich über alle fünf Orte verfolgen lässt. Ohne sie ist ein Löschersuchen eine Suche im Heuhaufen.

def entfernen(dokument_id: str) -> dict:
    """Entfernt ein Dokument aus allen abgeleiteten Speichern."""
    ergebnis = {}

    # 2. Vektorindex — über die Dokumentkennung in der Nutzlast
    ergebnis["index"] = qdrant.delete(
        collection_name="dokumente",
        points_selector=models.FilterSelector(filter=models.Filter(must=[
            models.FieldCondition(key="dokument_id",
                                  match=models.MatchValue(value=dokument_id))
        ])),
    )

    # 3. + 4. Chatverläufe und Protokolle, in denen das Dokument
    #          als Quelle vermerkt ist
    ergebnis["verlaeufe"] = db.execute(
        "DELETE FROM chat_quellen WHERE dokument_id = %s", (dokument_id,))
    ergebnis["protokolle"] = db.execute(
        "DELETE FROM trace_quellen WHERE dokument_id = %s", (dokument_id,))

    # 5. Zwischenspeicher vollständig leeren — gezielt geht nicht,
    #    weil der Schlüssel aus dem Prompt gebildet wird
    ergebnis["cache"] = redis.flushdb()

    # 1. Zustandstabelle, damit die Ingestion es nicht erneut aufnimmt
    db.execute("UPDATE ingestion_status SET is_deleted = true "
               "WHERE dokument_id = %s", (dokument_id,))
    return ergebnis

Zwei Punkte, die daraus folgen und vor der Indexierung entschieden werden müssen:

Die Dokumentkennung muss überall mitgeführt werden. In der Nutzlast des Vektorpunkts, im Chatverlauf als Quellenangabe, im Aufrufprotokoll. Wenn Sie das nachträglich einführen wollen, müssen Sie neu indexieren.

Der letzte Schritt in der Zustandstabelle ist entscheidend. Ohne ihn holt der nächste Ingestion-Lauf das Dokument aus der Quelle zurück, falls es dort noch liegt — und Sie haben nichts entfernt, sondern nur verzögert.

Was Sie über Fristen festlegen sollten

Löschen auf Anforderung ist der eine Fall. Der wichtigere ist die regelmäßige Bereinigung, weil sie das Volumen dessen begrenzt, was ein Ersuchen überhaupt trifft.

Diese Fristen sind Vorschläge, keine Rechtsberatung — Aufbewahrungspflichten aus anderen Vorschriften können abweichen, etwa im Finanz- oder Gesundheitswesen. Wichtig ist, dass sie technisch durchgesetzt werden und nicht als Absichtserklärung im Konzept stehen.

Die schärfste Frist ist die, die Sie am günstigsten bekommen: Was gar nicht erst indexiert wird, muss auch nicht entfernt werden. Klären Sie vor der Indexierung, welche Quellen personenbezogene Daten enthalten, und lassen Sie diejenigen draußen, deren Nutzen den Aufwand nicht rechtfertigt. Personalakten in einem Wissenssystem für die Produktion sind ein Beispiel dafür.

Der Fall, der schwierig bleibt

Auskunftsersuchen nach Artikel 15. Eine betroffene Person will wissen, welche Daten über sie verarbeitet werden.

Bei einer Fachanwendung ist das eine Abfrage. Bei einer KI-Plattform müssten Sie die Chatverläufe und Protokolle durchsuchen — nach einem Namen, der irgendwo in einem Prompt oder einer Antwort vorkommt.

Das ist technisch machbar über eine Volltextsuche und praktisch unangenehm, weil Namen mehrdeutig sind. Der beste Umgang damit ist Vermeidung: Wenn personenbezogene Daten vor dem Modellaufruf maskiert werden, stehen in Protokoll und Verlauf Platzhalter statt Klarnamen. Wie das eingerichtet wird, steht im Beitrag zur Guardrail-Kette im Gateway.

Das ist der stärkste Grund für Maskierung — stärker als der Schutz vor dem Modellanbieter, der bei lokalem Betrieb ohnehin entfällt.

Häufig gestellte Fragen

Reicht es, ein Dokument im Quellsystem zu entfernen?

Nein. Die abgeleiteten Kopien im Vektorindex, in Chatverläufen und Aufrufprotokollen bleiben bestehen, und das System beantwortet weiterhin Fragen daraus. Ein Löschvorgang muss alle Speicherorte erfassen — und die Zustandstabelle der Ingestion aktualisieren, damit der nächste Lauf das Dokument nicht erneut aufnimmt.

Sind Einbettungen personenbezogene Daten?

Sie sind aus dem Ausgangstext abgeleitet und lassen Rückschlüsse zu; die fachliche Diskussion dazu ist nicht abschließend geführt. Praktisch ist die Frage nachrangig, weil im Vektorindex neben der Einbettung fast immer der Klartext des Abschnitts in der Nutzlast steht. Entfernen Sie den Datenpunkt deshalb vollständig statt nur den Text.

Welche Aufbewahrungsfristen sind für Chatverläufe angemessen?

90 Tage sind ein praktikabler Ausgangswert für Verläufe, 30 Tage für vollständige Aufrufprotokolle und 24 Monate für aggregierte Kennzahlen ohne Personenbezug. Branchenspezifische Aufbewahrungspflichten können abweichen. Entscheidend ist, dass die Fristen automatisiert durchgesetzt werden und nicht nur im Konzept stehen.

Wie beantworte ich ein Auskunftsersuchen bei einer KI-Plattform?

Über eine Volltextsuche in Chatverläufen und Protokollen nach dem Namen der betroffenen Person — technisch machbar, praktisch mühsam wegen mehrdeutiger Namen. Deutlich einfacher wird es, wenn personenbezogene Daten vor dem Modellaufruf maskiert werden: Dann stehen in Verlauf und Protokoll Platzhalter statt Klarnamen.

Muss ich einen Antwort-Zwischenspeicher mit bereinigen?

Ja, und in der Regel vollständig statt gezielt, weil der Cache-Schlüssel aus dem Prompt gebildet wird und keinen Bezug zur Dokumentkennung trägt. Praktikabler ist eine kurze Lebensdauer von wenigen Stunden — dann ist der Zwischenspeicher bei jedem Vorgang ohnehin fast leer und der Punkt entschärft sich.

Der nächste Schritt

Prüfen Sie eine Sache an Ihrem laufenden System: Entfernen Sie ein Testdokument im Quellsystem und fragen Sie einen Tag später nach seinem Inhalt. Kommt eine Antwort, haben Sie kein Löschkonzept, sondern eine Absichtserklärung. Beim Aufbau unterstützen wir gern.