AI-Agenten-Speicher: Langzeitkontext gemäß DSGVO erhalten

Ein Unternehmen, das einen AI-Assistenten für die B2B-Kundenbetreuung implementiert, kann 300–800 aktive Geschäftspartner in einer Systeminstanz haben. Wenn der Langzeitspeicher nicht pro Tenant isoliert ist, kann ein Agent, der einen Kunden aus der Medizinbranche betreut, Kontext aus Gesprächen mit einem Kunden aus dem Finanzsektor übernehmen. Das ist kein theoretisches Szenario: Eine falsche Filterkonfiguration in der Vektordatenbank führt in der Praxis zu solchen Datenlecks, bevor es jemand bemerkt.

Jeder produktiv eingesetzte Agent arbeitet mit mindestens drei Speicherebenen, die unterschiedliche Lebenszyklen und Anforderungen haben.

Session-Speicher ist der Kontext des aktuellen Gesprächsfensters (Context Window). Er existiert vom ersten bis zum letzten Kommunikationsschritt einer Session. Er wird nicht persistent gespeichert, es sei denn, du speicherst ihn explizit. Er enthält den gesamten Verlauf des aktuellen Gesprächs, die Systemanweisung sowie abgerufene Fragmente aus RAG. Seine Größe ist durch die Anzahl der Token begrenzt, die das Modell in einem Fenster verarbeiten kann, typischerweise 8.000–128.000 Token, abhängig vom Modell.

Vektorspeicher (Langzeitspeicher) besteht aus persistenten Embeddings von Gesprächshistorien, Kundendokumenten und Fakten, die der Agent zwischen den Sessions behalten soll. Er wird in einer Vektordatenbank (Qdrant, Weaviate, pgvector) gespeichert. Bei jeder neuen Anfrage wird durch semantische Suche relevante Fragmente aus dieser Ebene als Kontext für die Antwort abgerufen, nach dem Muster des RAG-Ansatzes.

Benutzer-/Tenant-Profil sind strukturierte Daten: Präferenzen, Rollen, Fallhistorie, erteilte Einwilligungen, Aufbewahrungsfristen. Sie werden in einer relationalen Datenbank (nicht in der Vektordatenbank) gespeichert, da präzise Abfragen, Aktualisierungen und kaskadierendes Löschen benötigt werden. Dieser Datensatz ist der Nachweis der Einwilligung und die Quelle der Wahrheit für das Recht auf Vergessenwerden.

Der häufigste Architekturfehler: Eine Vektordatenbank ohne Filterung nach Tenant-ID. Das sichere Muster sieht anders aus.

Jedes in die Vektordatenbank geschriebene Fragment erhält Metadaten tenant_id (und optional user_id). Bei jeder Abfrage enthält die Suche einen Filter where: { tenant_id: { eq: current_tenant } } als obligatorische Bedingung, bevor die Kosinus-Ähnlichkeit berechnet wird. Ohne diesen Filter kann das Embedding-Modell ein Fragment aus einem völlig anderen Kontext zurückgeben, wenn es semantisch ähnlich ist.

Zusätzliche Isolierungsebenen, die sich lohnen:

Namespace pro Tenant in der Vektordatenbank: Qdrant unterstützt Kollektionen oder Punkte mit Filtern pro Tenant. Die Speicherung von Daten verschiedener Kunden in separaten Kollektionen bietet eine stärkere Isolierung als die reine Metadatenfilterung, kostet aber mehr Ressourcen bei Hunderten von Tenants.

Session-Token als Kontextgrenze: Jede Session erhält eine eindeutige ID. In den Vektorspeicher geschriebene Fragmente der Historie enthalten session_id als Metadatum. Dadurch kannst du die gesamte Historie einer bestimmten Session löschen, ohne den Rest der Tenant-Daten zu berühren.

Guardrails am Ausgang: Bevor der Agent eine Antwort zurückgibt, prüft die Guardrails-Schicht, ob die Antwort keine personenbezogenen Daten (PII) eines anderen Kunden enthält. Das ist ein Sicherheitsnetz, nicht die erste Verteidigungslinie. Mehr zur Architektur mehrstufiger Agenten im Artikel über mehrstufige Agenten.

DSGVO Art. 17 gibt der betroffenen Person das Recht, die Löschung ihrer Daten zu verlangen. Im Kontext des Agentenspeichers bedeutet dies eine kaskadierende Operation auf mindestens vier Ressourcen.

Schritt 1: Profil löschen aus der relationalen Datenbank. Dies ist normalerweise eine einfache Operation DELETE WHERE user_id = X, erfordert jedoch zuvor das Sammeln aller mit diesem Benutzer verknüpften IDs.

Schritt 2: Embeddings löschen aus der Vektordatenbank. Qdrant ermöglicht das Löschen von Punkten nach Metadatenfilter: DELETE WHERE user_id = X AND tenant_id = Y. Bevor du dies tust, musst du eine Liste der mit diesem Benutzer verknüpften point_id haben, daher sollte die relationale Profildatenbank eine Zuordnung user_id → [point_id_1, point_id_2, ...] speichern.

Schritt 3: Logs löschen oder anonymisieren. Zu Audit-Zwecken gespeicherte Logs können Gesprächsinhalte enthalten. Optionen sind Pseudonymisierung (ersetze user_id durch einen nicht umkehrbaren Hash) oder vollständiges Löschen, wenn der Verarbeitungszweck eine längere Speicherung nicht rechtfertigt.

Schritt 4: Cache invalidieren. Wenn der semantische Cache Antworten enthält, die Daten dieses Benutzers beinhalten (selten, aber möglich bei personalisierten Antworten), lösche die zugehörigen Cache-Einträge.

Frist für die Umsetzung: 30 Kalendertage ab Anfrage. Automatisiere den gesamten Prozess und führe ein Log der Anfrageumsetzung als Nachweis der Rechenschaftspflicht (DSGVO Art. 5 Abs. 2). Muster zur Anonymisierung von PII vor der Verarbeitung durch das Modell beschreiben wir im Artikel über Anonymisierung von PII.

Die Aufbewahrung von Daten im Agentenspeicher ist nicht nur eine Frage der Speicherdauer. Es ist eine Entscheidung darüber, wie lange der Agent Kontext „erinnert“ und wie sich dies auf die Antwortqualität im Vergleich zum Risiko der Speicherung überflüssiger Daten auswirkt.

Praktischer Ansatz: Teile den Vektorspeicher in Segmente mit unterschiedlichen TTLs auf. Historie des aktuellen Kundenprojekts: TTL 6–12 Monate oder bis zum Projektabschluss. Allgemeine Kommunikationspräferenzen: TTL 24 Monate. Sensible Daten (z. B. Finanzdetails): TTL 3–6 Monate oder nach der ersten Verwendung.

Die Aufbewahrungspolitik dokumentierst du in der DPIA. Wenn dein Agent Daten systematisch in großem Umfang verarbeitet (z. B. Tausende von Kunden bedient), ist die DPIA vor dem Start verpflichtend. Sie enthält eine Beschreibung des Verarbeitungszwecks, der Datenkategorien, der Aufbewahrungsfristen und der angewandten Sicherheitsmaßnahmen.

Ein bewährtes Muster für die Aufbewahrung in Unternehmensimplementierungen: Jedes Fragment in der Vektordatenbank hat ein Feld expires_at (Timestamp). Ein täglicher Datenbankjob löscht abgelaufene Fragmente und aktualisiert die Zuordnung point_id im Benutzerprofil. Für die unternehmensweite Wissensdatenbank (nicht personalisiert) ist die Aufbewahrung unbegrenzt, aber jede Aktualisierung eines Dokuments löst eine Reindexierung aus. Muster für das Wissensmanagement in RAG beschreiben wir im Artikel über unternehmensweites GPT auf Wissensbasis.

Wenn Kundendaten besonders sensibel sind (Gesundheitsdaten, Finanzdaten, Geschäftsgeheimnisse), eliminiert das Self-Hosting des gesamten Agentenspeicher-Stacks das Risiko der Datenübertragung in ein Drittland. Das Embedding-Modell (z. B. BGE-M3), die Vektordatenbank (Qdrant) und das LLM-Modell (Ollama) können auf der eigenen Infrastruktur betrieben werden. Die gesamte Lösung bleibt unter der von der DSGVO geforderten Data-Residency. Detaillierte Muster für Self-Hosting von LLMs unter DSGVO-Aspekten beschreiben wir im Artikel über Multi-Agenten-Systeme im Unternehmen.

Vektordatenbanken wie Qdrant ermöglichen das Löschen von Punkten nach Metadatenfilter. Speichere die Zuordnung user_id → [point_id] in einer relationalen Datenbank. Bei einer Löschanfrage: Hole die Liste der point_id aus dem Profil, führe DELETE points WHERE id IN (...) in der Vektordatenbank aus, lösche das Profil aus der SQL-Datenbank und anonymisiere die Logs. Der gesamte Prozess sollte automatisiert und als Nachweis der Rechenschaftspflicht protokolliert werden.

Erste Effekte sind nach 20–50 gespeicherten Fragmenten pro Benutzer sichtbar, typischerweise nach 3–5 Arbeitssessions. Ab 100+ Fragmenten beginnt der Agent, Kontext aus früheren Projekten treffsicher abzurufen. Die Qualität hängt mehr von der Genauigkeit des Chunkings und der Speicherpolitik (was gespeichert wird) ab als von der Datenmenge.

Ja, das ist aus zwei Gründen eine gute Praxis. Erstens belegen Zusammenfassungen weniger Token im Kontextfenster, sodass der Agent schneller arbeitet. Zweitens kannst du personenbezogene Daten aus der Zusammenfassung entfernen, bevor sie gespeichert wird, was die Aufbewahrung vereinfacht und den Umfang der DPIA reduziert. Nachteil: Verlust an Präzision bei spezifischen Fakten, die der Agent genau erinnern sollte.

Der Filter tenant_id in der Vektordatenbank ist obligatorisch und muss die erste Bedingung der Abfrage sein, bevor die semantische Ähnlichkeit berechnet wird. Die semantische Ähnlichkeit von Embeddings allein reicht nicht als Isolierung aus. Zusätzlich kann die Guardrails-Schicht am Ausgang prüfen, ob die Antwort keine Identifikatoren eines anderen Tenants enthält (Firmennamen, Vertragsnummern).

Beide Ansätze funktionieren produktiv. pgvector in PostgreSQL (Erweiterung) ist eine gute Lösung bei weniger als 1–2 Millionen Vektoren und einem Traffic unter einigen hundert Abfragen pro Minute. Bei größeren Volumina bieten dedizierte Datenbanken (Qdrant, Weaviate) besseres Metadatenmanagement, mehrdimensionale Filterung und Optimierungen für ANN (Approximate Nearest Neighbor). Der Vorteil von pgvector ist ein einziges Datenbanksystem für sowohl Benutzerprofile als auch Embeddings, was das kaskadierende Löschen bei der Umsetzung des Rechts auf Vergessenwerden vereinfacht.