Datenschutz vs. KI: Der Löschfall, der Enterprise-KI entlarvt

Embedding ist eine numerische Repräsentation von Text oder anderen Inhalten. Sie hilft, semantisch ähnliche Inhalte zu finden. Ob ein Embedding datenschutzrechtlich relevant ist, hängt vom Kontext, vom Ausgangsmaterial, von Zusatzdaten und vom Rekonstruktions- oder Zuordnungsrisiko ab.

Vektordatenbank speichert Embeddings und Metadaten, damit ein System passende Chunks zu einer Nutzerfrage schnell wiederfinden kann.

Chunk ist ein Ausschnitt aus einem Dokument, etwa ein Abschnitt einer Policy, eines Tickets oder eines Vertrags. RAG-Systeme arbeiten selten mit ganzen Dokumenten, sondern mit vielen einzelnen Chunks.

Log ist eine technische Aufzeichnung, zum Beispiel über Anfrage, Antwort, genutzte Quellen, Latenz, Fehler oder Modellaufruf. Logs sind für Betrieb und Audit wichtig, brauchen aber klare Speicherfristen.

Retention beschreibt, wie lange Daten oder abgeleitete Artefakte gespeichert werden und wann sie gelöscht, anonymisiert oder archiviert werden.

Audit Trail ist die nachvollziehbare Spur eines Vorgangs: wer hat wann welche Verarbeitung ausgelöst, welche Daten wurden genutzt, welche Löschung wurde ausgeführt und wie wurde sie bestätigt?

Auftragsverarbeitung bezeichnet eine Verarbeitung personenbezogener Daten durch einen Dienstleister im Auftrag eines Verantwortlichen. In der DSGVO ist dafür insbesondere Art. 28 relevant.

Datenresidenz beschreibt, in welcher Region oder Umgebung Daten gespeichert und verarbeitet werden. Sie ersetzt kein Lösch- oder Auditkonzept, ist aber ein wichtiger Architekturparameter.

Ein Kunde verlangt die Löschung seiner Daten. Oder eine Bewerberin. Oder ein ehemaliger Mitarbeiter. In klassischen Anwendungen ist die erste Reaktion meist technisch greifbar: Datensatz suchen, Fremdschlüssel prüfen, CRM-Eintrag entfernen, Archivregeln beachten, Vorgang dokumentieren.

Bei Enterprise-KI beginnt an derselben Stelle eine unangenehmere Frage.

Wurde der Inhalt nur im Quellsystem gespeichert? Oder wurde er in Chunks zerlegt, in Embeddings überführt, in einer Vektordatenbank abgelegt, in Prompt- und Antwortverläufen protokolliert, für Monitoring genutzt, in Testsets kopiert, in Caches gehalten oder in einem Fine-Tuning-Prozess verwendet?

Die erste Antwort einer KI ist selten der härteste Compliance-Test. Härter ist die spätere Löschung. Kann das Unternehmen nachweisen, welche Artefakte aus den Daten entstanden sind, wo sie liegen, wie lange sie bleiben dürfen und wie sie wieder entfernt werden?

Das ist die zentrale These: Löschung ist der Lackmustest für Enterprise-KI. Wer Daten nicht nachvollziehbar entfernen kann, hatte sie nie wirklich unter Kontrolle.

Datenschutz und KI müssen dabei nicht als Kulturkampf erzählt werden. Die produktive Frage lautet nicht, ob Unternehmen KI verbieten oder blind einsetzen sollten. Die produktive Frage lautet: Ist die Architektur so gebaut, dass Datenflüsse, Speicherorte, abgeleitete Artefakte, Retention und Audit von Anfang an kontrollierbar sind?

Warum Löschung bei KI komplizierter ist

Klassische Fachanwendungen haben ebenfalls komplexe Datenmodelle. Kundendaten liegen nicht nur in einer Tabelle, sondern in CRM, ERP, Supportsystem, Rechnungsarchiv, Backups, E-Mail-Verkehr und Data Warehouse. Trotzdem ist die Denkweise meist relational: Es gibt definierte Entitäten, bekannte Schlüssel, dokumentierte Abhängigkeiten und etablierte Lösch- oder Sperrprozesse.

RAG- und KI-Architekturen fügen eine andere Art von Datenlebenszyklus hinzu. Inhalte werden nicht nur gespeichert, sondern transformiert. Ein Dokument wird gelesen, bereinigt, segmentiert, angereichert, eingebettet, gesucht, gerankt, in einen Modellkontext übergeben und in Antworten zusammengefasst. Jeder dieser Schritte kann technische Artefakte erzeugen.

Ein Löschfall berührt deshalb nicht nur die Quelle. Er berührt die Pipeline.

flowchart LR
    A["Quelle<br/>CRM, DMS, SharePoint, Tickets"] --> B["Ingestion<br/>Connector, Parser, Normalisierung"]
    B --> C["Chunking<br/>Abschnitte, Metadaten, Kontext"]
    C --> D["Embeddings<br/>Vektoren + IDs"]
    D --> E["Retrieval<br/>Vektordatenbank, Filter, Reranking"]
    E --> F["Modellaufruf<br/>Prompt, Kontext, Antwort"]
    F --> G["Betrieb<br/>Logs, Monitoring, Caches"]
    G --> H["Retention<br/>Löschung, Sperrung, Audit"]

Das Diagramm zeigt den Architekturpunkt: Löschung ist kein einzelner Support-Klick am Ende. Sie muss durch dieselben Schichten laufen, durch die Daten vorher gewandert sind.

Die DSGVO formuliert unter anderem Grundsätze wie Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Art. 17 behandelt das Recht auf Löschung. Art. 25 fordert Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Für Enterprise-KI ist das keine juristische Fußnote, sondern ein technisches Designproblem: Systeme müssen so gebaut werden, dass sie Löschung und Nachweisbarkeit überhaupt leisten können.

Welche Artefakte Enterprise-KI erzeugt

Ein ernst gemeinter Löschprozess beginnt mit einer Inventur. Nicht im Sinne einer statischen Excel-Liste, sondern als lebendes Verzeichnis der Datenartefakte, die eine KI-Architektur erzeugt.

Typische Artefakte sind:

Diese Liste ist nicht in jedem System identisch. Genau deshalb muss sie pro Architektur konkretisiert werden. Ein Unternehmen kann nur löschen, was es kennt. Und es kann nur nachweisen, was es vorher instrumentiert hat.

Embeddings kontrollieren, ohne falsche Absolutheiten

Embeddings werden in Datenschutzdiskussionen oft zu grob behandelt. Die eine Seite tut so, als seien Embeddings immer harmlose Zahlen. Die andere Seite behauptet, Embeddings seien immer personenbezogene Daten. Beides ist zu einfach.

Ein Embedding ist zunächst ein abgeleitetes technisches Artefakt. Ob es personenbezogen oder datenschutzrechtlich relevant ist, hängt vom Kontext ab: Welcher Inhalt wurde eingebettet? Gibt es Metadaten, IDs oder Quellverweise? Kann das Embedding einer Person, einem Kunden oder einem Vorgang zugeordnet werden? Wie stark ist das Rekonstruktions-, Inferenz- oder Zuordnungsrisiko? Wer hat Zugriff auf Vektorraum, Metadaten und Suchfunktion?

Für die Architektur reicht deshalb eine vorsichtige, aber klare Regel: Embeddings und Vektordatenbankeinträge gehören in das Lösch- und Retention-Konzept.

Das bedeutet praktisch:

• Jeder Vektor braucht eine stabile Verbindung zur Quelle, zum Chunk und zur Version.
• Metadaten müssen anzeigen, aus welchem Tenant, Projekt, Dokument und Verarbeitungslauf ein Eintrag stammt.
• Re-Indexing darf alte Vektoren nicht still neben neuen Vektoren liegen lassen.
• Löschung muss Vektoren, Chunk-Texte, Metadaten und Graph- oder Suchindizes gemeinsam adressieren.
• Backup-, Snapshot- und Restore-Regeln müssen erklären, wann gelöschte Vektoren endgültig aus wiederherstellbaren Ständen verschwinden.

Eine Vektordatenbank ist damit nicht nur Performance-Infrastruktur. Sie ist ein Teil des Datenschutz- und Auditmodells.

Logs, Monitoring und Antwortverläufe

Viele KI-Projekte unterschätzen Logs. In der Pilotphase wirken sie harmlos: Man will sehen, welche Fragen gestellt werden, welche Antworten schlecht waren, welche Quellen fehlten und wo die Latenz hoch ist. Ohne Logging lässt sich ein RAG-System kaum betreiben.

Aber Logs sind nicht neutral. Sie können personenbezogene Daten enthalten, selbst wenn die Wissensbasis sauber modelliert ist. Ein Nutzer kann Namen, Kundennummern, Gesundheitsdaten, Vertragsdetails oder interne Vorfälle in eine Frage schreiben. Eine Antwort kann Teile davon wiedergeben. Ein Retrieval-Trace kann zeigen, welche Dokumente und Chunks zu einer Person gefunden wurden.

Deshalb gehören Logs in ein eigenes Retention-Modell:

• Welche Logs enthalten Rohprompts oder Antworttexte?
• Welche Logs enthalten nur technische Metriken?
• Welche IDs erlauben eine Rückführung auf Nutzer, Dokumente oder Betroffene?
• Welche Daten werden für Debugging gebraucht und welche nur für Aggregatmetriken?
• Wie lange werden Chatverläufe gespeichert?
• Wer darf Support- oder Fehlerdaten einsehen?
• Wie werden Logs bei einem Löschfall gefunden, gelöscht, anonymisiert oder gesperrt?

Ein gutes Monitoring trennt fachliche Inhalte von Betriebsmetriken, wo immer das möglich ist. Es speichert nicht automatisch alles, nur weil es technisch bequem wäre. Und es behandelt Prompt-/Antwortverläufe als eigene Datenklasse, nicht als unsichtbare Nebenwirkung.

Trainingsnutzung und Fine-Tuning

Der Satz "Ihre Daten werden nicht zum Training genutzt" ist wichtig, aber zu unpräzise. Unternehmen sollten genauer unterscheiden:

1. Werden Eingaben oder Dokumente zum allgemeinen Modelltraining genutzt?
2. Werden sie für Fine-Tuning eines kundenspezifischen Modells genutzt?
3. Werden sie für Evaluation, Regressionstests oder Prompt-Optimierung kopiert?
4. Werden sie für manuelles Review, Support oder Fehleranalyse bereitgestellt?
5. Werden abgeleitete Beispiele in Testsets, Benchmarks oder Monitoring-Reports übernommen?

Jede dieser Nutzungen hat andere Löschfolgen. Wenn Daten nie für Training oder Fine-Tuning verwendet werden, vereinfacht das den Löschfall erheblich. Es ersetzt aber nicht die Löschung in Index, Logs, Chatverlauf, Monitoring und Caches.

Wenn Fine-Tuning oder kundenspezifische Modellanpassung vorgesehen ist, braucht die Architektur eine noch schärfere Grenze. Trainingsdaten, Trainingsläufe, Modellartefakte, Evaluationssets und Modellversionen müssen dokumentiert werden. Sonst wird der Löschfall schwer beweisbar: Welche Modellversion hat welche Daten gesehen? Kann eine Version außer Betrieb genommen werden? Gibt es Rollback-Pfade? Wurden Beispiele in spätere Testsets übernommen?

Viele Enterprise-RAG-Anwendungen kommen ohne Fine-Tuning auf vertraulichen Inhalten aus. Sie halten Wissen im kontrollierten Retrieval-System und geben nur den jeweils erlaubten Kontext an das Modell. Das kann datenschutzarchitektonisch attraktiv sein, weil Löschung stärker auf Datenhaltung, Index und Logs konzentriert bleibt. Eine Garantie ist es nicht. Auch Retrieval erzeugt Artefakte.

Nachweisbarkeit: Löschung als Audit-Prozess

Der Löschfall ist nicht abgeschlossen, wenn ein Button "delete" erfolgreich zurückgibt. Er ist abgeschlossen, wenn der Prozess nachvollziehbar ausgeführt, begrenzt und dokumentiert wurde.

Ein auditierbarer Löschprozess für Enterprise-KI braucht mindestens fünf Bausteine:

1. Identifikation: Welche Person, welcher Kunde, welcher Vorgang oder welche Datenklasse ist betroffen?
2. Abbildung: Welche Quellen, Chunks, Embeddings, Logs, Verläufe, Caches und Testdaten verweisen darauf?
3. Ausführung: Welche Artefakte werden gelöscht, welche gesperrt, welche aufgrund rechtlicher Pflichten aufbewahrt?
4. Propagation: Welche Indizes, Graphen, Caches, Replicas, Backups und Suchräume werden aktualisiert?
5. Nachweis: Welche technischen Protokolle, Prüfsummen, Job-Ergebnisse und Freigaben belegen den Vorgang?

flowchart TB
    A["Löschanfrage<br/>Betroffene Person / Kunde / Fachbereich"] --> B["Identity & Scope Resolution<br/>IDs, Quellen, Datenklassen"]
    B --> C["Artifact Mapping<br/>Dokumente, Chunks, Embeddings,<br/>Logs, Verläufe, Caches"]
    C --> D{"Aufbewahrungspflicht<br/>oder Ausnahme?"}
    D -- "Ja" --> E["Sperrung / Einschränkung<br/>mit Begründung"]
    D -- "Nein" --> F["Löschjob<br/>Quelle, Index, Vektoren, Metadaten"]
    F --> G["Cache- und Index-Invalidierung"]
    E --> H["Audit Trail<br/>Status, Zeit, Systeme, Belege"]
    G --> H
    H --> I["Nachweis für Datenschutz,<br/>Revision oder Kundenkommunikation"]

Diese Sicht hilft auch bei der Systemauswahl. Ein Anbieter oder internes Plattformteam sollte nicht nur zeigen, dass die KI gute Antworten erzeugt. Es sollte zeigen, wie ein einzelnes Dokument, ein Kunde oder ein personenbezogener Vorgang wieder aus der Architektur entfernt wird.

Nachweisbarkeit ist für Enterprise-KI genauso wichtig wie Antwortqualität. Ohne sie wird ein System zwar produktiv, aber nicht belastbar.

Datenresidenz und Betriebsmodell

On-Premise, EU-Cloud und Hybrid sind keine simple Rangliste von "gut" nach "schlecht". Die passende Architektur folgt Schutzbedarf, Datenklassen, Betriebsverantwortung, Integrationsrealität, Löschbarkeit und Audit-Anforderungen.

Eine EU-Cloud kann für viele Anwendungsfälle sinnvoll sein, wenn Auftragsverarbeitung, Subprozessoren, Datenresidenz, Zugriff, Logging, Löschung und Betriebsprozesse sauber geregelt sind. On-Premise kann für besonders sensible Datenräume mehr technische Kontrolle geben, bringt aber auch mehr Verantwortung für Betrieb, Patching, Monitoring, Backups, Incident Response und Nachweise. Hybrid-Modelle können Datenklassen trennen: sensible Quellen bleiben intern, weniger kritische Wissensbestände laufen in einer kontrollierten Cloud-Umgebung.

Entscheidend ist nicht das Etikett, sondern die Durchsetzbarkeit:

On-Premise ist also nicht automatisch DSGVO-konform. EU-Cloud ist nicht automatisch ausreichend. Hybrid ist nicht automatisch sicherer. Jedes Modell muss an denselben Fragen gemessen werden: Welche Daten entstehen, wo liegen sie, wer verarbeitet sie, wie lange bleiben sie, wie werden sie gelöscht und wie wird das belegt?

Die Architektur hinter kontrollierbarer Löschung

Aus dem Löschfall lassen sich konkrete Architekturprinzipien ableiten.

Erstens braucht jedes Artefakt Provenance. Ein Chunk, ein Embedding oder eine Graph-Beziehung sollte wissen, aus welcher Quelle, welcher Dokumentversion und welchem Verarbeitungslauf es stammt. Ohne Provenance wird Löschung zur Volltextsuche im Nebel.

Zweitens müssen IDs stabil und durchgängig sein. Wenn ein CRM-Kontakt in Dokumenten, Tickets und Chatverläufen auftaucht, braucht das System eine Möglichkeit, diesen Zusammenhang kontrolliert zu finden. Das bedeutet nicht, alle Daten in einen zentralen Topf zu kippen. Es bedeutet, referenzierbare Grenzen und Zuordnungen zu schaffen.

Drittens gehören Retention-Regeln in die Pipeline. Es reicht nicht, Daten nachträglich in einem Archivskript aufzuräumen. Ingestion, Indexierung, Chatverlauf, Logging und Evaluation sollten von Anfang an wissen, welche Datenklasse welche Speicherfrist hat.

Viertens braucht Löschung Idempotenz und Wiederholbarkeit. Ein Löschjob muss mehrfach laufen können, ohne Schaden anzurichten. Er muss Teilerfolge, Fehler und Wiederholungen dokumentieren. Gerade verteilte KI-Architekturen brauchen robuste Jobs, nicht manuelle Einzelaktionen.

Fünftens sollte Retrieval nicht mehr Kontext speichern als notwendig. Je weniger Rohdaten in Logs, Caches und Testsets landen, desto kleiner wird der spätere Löschradius.

flowchart LR
    A["Datenklasse<br/>z.B. Kunde, HR, Vertrag"] --> B["Policy<br/>Retention, Zugriff, Region"]
    B --> C["Ingestion-Regeln<br/>Minimierung, Metadaten, IDs"]
    C --> D["Index-Regeln<br/>Chunks, Vektoren, Provenance"]
    D --> E["Runtime-Regeln<br/>Kontext, Logs, Caches"]
    E --> F["Lösch- und Audit-Regeln<br/>Jobs, Nachweise, Exceptions"]

Das ist der Unterschied zwischen "wir haben eine KI angebunden" und "wir betreiben eine kontrollierbare Enterprise-KI-Plattform".

Berechtigungen bleiben wichtig, sind aber nicht der ganze Datenschutz

Berechtigungen sind ein wichtiger Teil der Architektur. Ein RAG-System darf Nutzern nur Kontext geben, den sie im jeweiligen Tenant, Projekt und Quellsystem sehen dürfen. Sonst kann die KI Daten offenlegen, die im Ursprungssystem korrekt geschützt waren.

Für den Löschfall ist Zugriffskontrolle aber nur ein Ausschnitt. Auch korrekt berechtigte Daten müssen später gelöscht, gesperrt oder aus abgeleiteten Artefakten entfernt werden können. Umgekehrt macht ein perfektes Rollenmodell keine Embedding-, Log- oder Retention-Strategie überflüssig.

Der eigene Zugriffskontrolle-Artikel vertieft dieses Thema separat. Hier reicht die Abgrenzung: Datenschutzfähige Enterprise-KI braucht beides, aber der Löschfall prüft den gesamten Datenlebenszyklus, nicht nur die Frage, wer einen Chunk sehen darf.

Was Enterprise-Teams früh klären sollten

Vor dem produktiven Rollout lohnt sich eine konkrete Lösch- und Retention-Checkliste:

• Welche Datenklassen dürfen überhaupt in die KI-Pipeline?
• Welche Quellen werden indexiert, und wer ist fachlich verantwortlich?
• Welche Artefakte entstehen pro Quelle: normalisierte Kopie, Chunk, Embedding, Metadaten, Graph, Log, Verlauf, Cache?
• Welche Artefakte enthalten Rohdaten, welche nur Referenzen oder technische Metriken?
• Welche Retention gilt für Chatverläufe, Prompts, Antworten, Retrieval-Traces und Observability-Daten?
• Werden Eingaben, Antworten oder Dokumente für Training, Fine-Tuning, Evaluation oder Support genutzt?
• Wie wird eine Löschanfrage auf Quell-IDs, Chunk-IDs, Vektor-IDs und Log-IDs abgebildet?
• Wie werden Re-Indexing, Cache-Invalidierung und Backup-Retention gesteuert?
• Welche Nachweise erzeugt das System automatisch?
• Welche Grenzen bleiben organisatorisch oder rechtlich zu klären?

Diese Fragen sind nicht nur für Datenschutzbeauftragte relevant. Sie gehören in Architektur-Reviews, Anbieterbewertungen, Data-Platform-Design und Betriebsdokumentation.

Fazit: Datenschutzfähige KI beginnt mit Architektur

Der Löschfall entlarvt Enterprise-KI, weil er den Blick von der Oberfläche wegzieht. Eine Demo kann gute Antworten zeigen. Ein Pilot kann produktiv wirken. Ein Chat kann freundlich formulieren. Aber erst die Löschung zeigt, ob das Unternehmen seine Datenflüsse wirklich verstanden hat.

Wer Daten aus Quellen in Chunks, Embeddings, Logs, Monitoring und Antworten überführt, muss diese Artefakte als Teil des Datenlebenszyklus behandeln. Nicht irgendwann, wenn die erste Anfrage einer betroffenen Person kommt, sondern beim Design der Plattform.

Datenschutz ist in Enterprise-KI deshalb kein Verbotsschild. Er ist ein Architekturprinzip: Daten minimieren, Datenflüsse kennen, abgeleitete Artefakte kontrollieren, Retention festlegen, Löschung automatisieren und Nachweise erzeugen.

Die TensorFive RAG API und T5.Chat sind für solche kontrollierbaren Enterprise-RAG-Szenarien gedacht: mit Quellenbezug, mandanten- und projektbezogener Trennung, permission-aware Retrieval, EU-Cloud-, On-Premise- und Hybrid-Optionen sowie Audit-orientierter Architektur. Der sinnvolle nächste Schritt ist kein pauschales Compliance-Versprechen, sondern ein technisches Architekturgespräch: Welche Datenflüsse entstehen in Ihrem Use Case, und wie wird der Löschfall dort konkret beherrschbar?