> So entwirfst du das Gedächtnis von KI-Agenten: Kontext, Session, Langzeit, was du speicherst und nie speicherst, Retrieval, Compaction, Poisoning, DSGVO.
>
> Web page: https://balazscsorba.com/de/blog/ai-agent-memory-design · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/ai-agent-memory-design.md) · [Magyar](https://balazscsorba.com/hu/blog/ai-agent-memory-design.md)
> Author: Balázs Csorba · Published: 2026-10-02 · Keywords: AI agent memory design, long-term memory for AI agents, episodic semantic procedural memory LLM, agent memory architecture, ChatGPT memory vs Claude memory, Claude memory tool, AI memory poisoning, LLM context compaction, AI agent memory GDPR, short-term vs long-term memory agents

[Blog](https://balazscsorba.com/de/blog)/KI-Agenten

# Memory für KI-Agenten entwerfen: Ebenen, Schreibregeln, Poisoning und DSGVO

So entwirfst du das Gedächtnis von KI-Agenten: Kontext, Session, Langzeit, was du speicherst und nie speicherst, Retrieval, Compaction, Poisoning, DSGVO.

[Balázs Csorba](https://balazscsorba.com/de/about)·2\. Oktober 2026·13 Min. Lesezeit

-   AI agent memory
-   Context engineering
-   Memory poisoning
-   GDPR

![Diagramm: verschachtelte Gedächtnisebenen eines KI-Agenten, vom Arbeitskontext über den Session-Zustand bis zum episodischen und semantischen Langzeitgedächtnis.](https://balazscsorba.com/images/blog/ai-agent-memory-design/cover.webp?v=024d01c64a)

## Das Wichtigste in Kürze

-   Behandle Agenten-Memory als drei Ebenen mit unterschiedlicher Lebensdauer: Arbeitskontext (das Kontextfenster), Session-Zustand (eine Aufgabe oder ein Thread) und Langzeitgedächtnis (über Sessions hinweg). Jede Ebene braucht eigene Schreib- und Löschregeln.
-   Das Schwierige ist der Schreibpfad, nicht der Speicher. Entscheide, was merkenswert ist, aus welchen Quellen, mit Herkunft, Geltungsbereich und Ablaufdatum, und lass nie ungeprüft nicht vertrauenswürdige Inhalte ins Memory schreiben.
-   Memory ist eine Persistenzschicht für Prompt Injection: Ein vergifteter Eintrag kann jede spätere Session steuern, und auch Zusammenfassung und Compaction sind Schreibkanäle.
-   Für die DSGVO muss jede Erinnerung einer Person zuordenbar sein und sich samt abgeleiteter Kopien (Zusammenfassungen, Embeddings, Caches) löschen lassen. Ein Speicher, den du nur komplett zurücksetzen kannst, ist ein Compliance-Problem.
-   Die Produkte unterscheiden sich stark: ChatGPT und Claude lassen Nutzer Erinnerungen ansehen, bearbeiten und löschen, das Claude Memory Tool überlässt dir den Speicher, und bei OpenAI dots kannst du nur den ganzen Dot löschen.

Auf dieser Seite

1.  [Drei Ebenen: Arbeitskontext, Session, Langzeit](https://balazscsorba.com/#memory-tiers)
2.  [Episodisch, semantisch, prozedural: was du wirklich speicherst](https://balazscsorba.com/#memory-types)
3.  [Was du wann schreibst und was du nie speicherst](https://balazscsorba.com/#write-policy)
4.  [Erinnerungen abrufen, ohne den Kontext zu fluten](https://balazscsorba.com/#retrieval)
5.  [Compaction und Zusammenfassung: verlustbehaftet by Design](https://balazscsorba.com/#compaction)
6.  [Memory Poisoning: die Injection, die bleibt](https://balazscsorba.com/#memory-poisoning)
7.  [DSGVO: Auskunft, Löschung und das Problem abgeleiteter Daten](https://balazscsorba.com/#gdpr)
8.  [Wie aktuelle Produkte Memory lösen](https://balazscsorba.com/#products)
9.  [Eine Checkliste für das Memory-Design](https://balazscsorba.com/#checklist)
10.  [Meine Empfehlung](https://balazscsorba.com/#recommendation)
11.  [Quellen](https://balazscsorba.com/#sources)

Große Sprachmodelle sind zustandslos. Alles, woran sich ein Agent „erinnert", ist Text, den dein System wieder in den Prompt legt. Die spannenden Engineering-Fragen betreffen deshalb die Schleife um das Modell: was geschrieben wird, wo, von wem, wie es wiedergefunden und wie es entfernt wird. Memory ist auch der Punkt, an dem Agenten aufhören, eine Demo zu sein. Ein Coding-Agent, der dein Repository jeden Morgen neu lernt, oder ein Support-Agent, der zum dritten Mal dieselbe Frage stellt, ist ein Memory-Problem.

Memory ist außerdem eine Angriffsfläche und eine Datenschutz-Verpflichtung, was die meisten Tutorials auslassen. In diesem Artikel gehe ich durch die Ebenen, die ich verwende, die drei Gedächtnisarten, eine Schreibrichtlinie mit expliziter „Nie speichern"-Liste, Retrieval, Compaction, Poisoning und DSGVO, und vergleiche dann, wie ChatGPT, Claude und OpenAI dots es heute lösen. Er baut auf [der Funktionsweise der Agent-Schleife](https://balazscsorba.com/de/blog/agent-loop-explained) und auf dem Bedrohungsmodell aus [dem Artikel zur Lethal Trifecta](https://balazscsorba.com/de/blog/prompt-injection-lethal-trifecta-patterns) auf.

## Drei Ebenen: Arbeitskontext, Session, Langzeit

Ich trenne Memory gern nach Lebensdauer, weil sie entscheidet, wer schreiben darf, wie gelöscht wird und was es kostet. Die Forschung sieht das ähnlich. MemGPT hat das Problem wie ein Betriebssystem beschrieben: Es verwaltet verschiedene Gedächtnisebenen, um dem Modell einen erweiterten Kontext zu geben, und verschiebt Informationen zwischen schnellem und langsamem Speicher wie zwischen RAM und Festplatte.

Der Arbeitskontext ist das Fenster selbst. Es ist teuer und es degradiert: Anthropic beschreibt „Context Rot", also dass mit wachsender Tokenzahl im Kontextfenster die Fähigkeit des Modells sinkt, Informationen daraus genau abzurufen. Der Session-Zustand ist das, was du für eine Aufgabe oder einen Thread aufbewahrst, damit eine Unterbrechung den Fortschritt nicht zerstört, etwa eine Fortschrittsdatei oder eine Zusammenfassung. Das Langzeitgedächtnis überlebt Sessions und ist die einzige Ebene, auf der Datenschutz, Poisoning und Löschung dauerhafte Probleme werden.

Die Lebensdauer wächst von links nach rechts, und mit ihr die Kosten eines schlechten Eintrags. Nur das Gate zwischen Session und Langzeitgedächtnis entscheidet, was dauerhaft wird.

Für das Design folgt daraus: Der Arbeitskontext wird bei jedem Aufruf neu aufgebaut und darf so verrauscht sein, wie die Aufgabe es verlangt. Der Session-Zustand sollte klein, strukturiert und vom Harness verwaltet sein. Das Langzeitgedächtnis braucht ein Schreib-Gate, denn alles, was es passiert, behandelt der Agent später als sein eigenes Wissen.

## Episodisch, semantisch, prozedural: was du wirklich speicherst

Das CoALA-Paper von Sumers, Yao, Narasimhan und Griffiths ordnet Sprach-Agenten um ein Arbeitsgedächtnis und drei Langzeitarten aus der Kognitionswissenschaft: episodisch, semantisch und prozedural. Die Trennung ist praktisch, weil jede Art einen anderen Schreibauslöser, ein anderes Abrufmuster und einen anderen Fehlermodus hat.

Art

Enthält

Beispiel

Typische Form

Haupt-Fehlermodus

**Episodisch**

Konkrete frühere Erlebnisse

Am Dienstag scheiterte der Erstattungsprozess, weil die Bestellung schon versandt war

Zeitgestempeltes Ereignislog oder kurze Zusammenfassungen

Rauschen wächst unbegrenzt; alte Episoden führen in die Irre

**Semantisch**

Allgemeine Fakten und Präferenzen

Acme Corp bevorzugt Nachfassen per E-Mail

Key-Value-Fakten, Profildateien, Notizen

Veraltete oder falsche Fakten; Widersprüche nach Updates

**Prozedural**

Gelernte Handlungsweisen

In diesem Repo vor den Tests den Linter ausführen

Regeln, Playbooks, Prompt-Bausteine, Skills

Eine vergiftete oder veraltete Prozedur wird ausgeführt, nicht nur erinnert

Das Generative-Agents-Paper von Stanford und Google zeigt, warum episodisches Gedächtnis allein nicht reicht: Die Agenten speichern Erlebnisse in natürlicher Sprache und „synthesize those memories over time into higher-level reflections", so werden aus Ereignissen semantisches Wissen. Die Idee würde ich übernehmen, den Reflexionsschritt aber nachvollziehbar halten. Prozedurales Gedächtnis verdient das meiste Misstrauen, denn ein Memory, das ändert, wie der Agent handelt, ist näher an Code als an Daten. Wenn Agenten eigene Skills schreiben dürfen, behandle sie wie einen Pull Request (siehe [Coding-Agent-Skills](https://balazscsorba.com/de/blog/coding-agent-skills-workflow)).

## Was du wann schreibst und was du nie speicherst

Die meisten Memory-Systeme scheitern am Schreibpfad. Entweder schreibt der Agent alles (und das Retrieval ertrinkt im Rauschen) oder er schreibt nach Laune (und Wichtiges fehlt). Ich würde eine Schreibrichtlinie explizit definieren, statt sie allein dem Modell zu überlassen. Die Dokumentation des Claude Memory Tools weist in dieselbe Richtung: Du kannst steuern, was Claude schreibt, etwa indem du nur Informationen zu einem bestimmten Thema festhalten lässt, und du kannst eine Validierung ergänzen, die sensible Daten entfernt, bevor dein Handler eine Datei speichert.

Die Quellenprüfung ist das Sicherheits-Gate: Inhalte aus dem Web, aus Dokumenten oder Tool-Ergebnissen sind Indizien, nie eine Anweisung, sich etwas zu merken.

Schreibe zu wenigen klar definierten Zeitpunkten statt kontinuierlich: wenn der Nutzer eine stabile Präferenz oder Korrektur nennt, am Ende einer Aufgabe (Ergebnis, Entscheidungen, offene Fragen) und kurz bevor Kontext gelöscht oder verdichtet wird. Die Context-Editing-Dokumentation von Anthropic beschreibt Letzteres: Es arbeitet mit dem Memory Tool zusammen, damit Claude wichtige Informationen im Memory sichern kann, bevor Inhalte gelöscht werden. Jeder Eintrag sollte Owner, Quelle, Zeitstempel, Geltungsbereich (Nutzer, Projekt, Mandant) und ein Ablauf- oder Prüfdatum tragen.

Was ich nie speichern würde, egal was der Agent vorschlägt:

-   **Geheimnisse und Zugangsdaten.** API-Keys, Tokens und Passwörter gehören in einen Tresor. Anthropic merkt an, dass Claude sensible Informationen meist nicht in Memory-Dateien schreibt, empfiehlt für stärkere Garantien aber eine eigene Validierung. dots gehen weiter und sagen, ihr Kontext behalte keine Zugangsdaten, Bilder oder Screenshots.
-   **Kennungen und besondere Kategorien** wie amtliche Ausweisnummern, Kontonummern, Vorstrafen und Einwanderungsstatus. Claude schließt genau diese standardmäßig aus, und Gesundheit, Religion, Politik und Identität sind aus, solange der Nutzer nicht zustimmt.
-   **Rohe Tool-Ausgaben und Webinhalte.** Fasse geprüfte Fakten zusammen, speichere aber keine Seiten oder Dokumente wörtlich: Sie können Anweisungen enthalten, die dann im vertrauten Memory deines Agenten liegen.
-   **Schlüsse über Personen, die der Nutzer nicht von sich aus genannt hat**, und alles, womit der Nutzer nicht rechnet. Ist Überraschung wahrscheinlich, frag vorher.
-   **Personenbezogene Daten Dritter** (Kunden, Kollegen), sofern du keinen definierten Zweck und keine Rechtsgrundlage dafür hast.

## Erinnerungen abrufen, ohne den Kontext zu fluten

Memory, das man nicht findet, ist nur Speicher. Ich würde mit dem einfachsten Muster beginnen, das funktioniert, und erst Mechanik ergänzen, wenn Evals sie nötig machen. Anthropic nennt die zugrunde liegende Idee Just-in-Time-Retrieval: Statt alles vorab zu laden, hält der Agent leichtgewichtige Bezeichner wie Dateipfade und lädt Daten bei Bedarf. Das Memory Tool folgt dem, denn Claude sieht zuerst das Memory-Verzeichnis an und öffnet dann nur die relevanten Dateien.

-   **Erst eingrenzen, dann suchen.** Filtere zuerst nach Nutzer, Mandant und Projekt, dann ranke. Ein mandantenübergreifendes Memory-Leck ist eine Datenpanne, und ein harter Filter verhindert es viel zuverlässiger als ein Prompt.
-   **Mit einem kleinen Index beginnen.** Eine kurze Übersichtsdatei oder ein Profil, das immer geladen wird, plus Themendateien oder Datensätze, die bei Bedarf geholt werden, funktioniert bei einigen hundert Einträgen besser als eine Vektordatenbank.
-   **Hybride Suche bei wachsendem Volumen.** Kombiniere Schlüsselwort- und Embedding-Suche, rerank und gewichte Aktualität; die Mechanik ist dieselbe wie in [einer RAG-Pipeline](https://balazscsorba.com/de/blog/rag-pipeline-chunking-hybrid-search-reranking).
-   **Budget begrenzen.** Injiziere nur eine feste Zahl von Erinnerungen oder Tokens und zeige dem Agenten, woher jede stammt und wann sie geschrieben wurde.
-   **Memory als Daten kennzeichnen.** Liefere abgerufene Erinnerungen in einem klar abgegrenzten Block als Kontext zum Abwägen, nicht als Anweisungen. Das hilft, beseitigt das Poisoning-Risiko unten aber nicht.

Miss Retrieval wie jedes andere Feature: Baue eine kleine Menge von „Wäre die richtige Erinnerung gefunden worden?"-Fällen und verfolge Trefferquote und Quote falscher Erinnerungen über die Zeit (siehe [LLM-Evals für Produkt-Features](https://balazscsorba.com/de/blog/llm-evals-for-product-features)). Veralten ist auch ein Retrieval-Problem. Ändert sich ein Fakt, aktualisiere oder ersetze den alten Eintrag; hänge keinen Widerspruch an und hoffe, dass das Modell den neueren wählt.

## Compaction und Zusammenfassung: verlustbehaftet by Design

Compaction fasst eine Unterhaltung zusammen, die an ihre Grenze stößt, und startet mit der Zusammenfassung neu. Anthropic beschreibt das als Destillieren des Kontextfensters „in a high-fidelity manner" und nennt den zentralen Zielkonflikt: Zu aggressive Compaction riskiert, subtile, aber kritische Details zu verlieren. Außerdem beschreibt Anthropic strukturiertes Notieren, bei dem der Agent regelmäßig Notizen außerhalb des Kontextfensters ablegt und später wieder liest. Im Pokémon-Beispiel hielt Claude so präzise Zählstände über Tausende Spielschritte.

Die Claude-Dokumentation beschreibt die Arbeitsteilung gut: Context Editing löscht bestimmte Tool-Ergebnisse, Compaction fasst die ganze Unterhaltung serverseitig zusammen, und bei langlaufenden Agenten bewahrt Memory die Informationen, die eine Zusammenfassung überleben müssen. Das Löschen von Tool-Ergebnissen löst standardmäßig bei 100.000 Input-Tokens aus und behält die letzten drei Tool-Nutzungen, also sollten wichtige Entscheidungen vorher ins Memory geschrieben werden, statt hinterher aus einer Zusammenfassung rekonstruiert zu werden.

Das hat eine Sicherheitsfolge. Eine Zusammenfassung erzeugt ein Modell, das gerade nicht vertrauenswürdige Inhalte gelesen hat, und ihr Ergebnis wird gespeichert und als vertrauenswürdig behandelt. Compaction ist ein Schreibkanal und muss dieselben Gates passieren wie jeder andere Memory-Eintrag.

## Memory Poisoning: die Injection, die bleibt

Prompt Injection endet normalerweise mit der Session. Mit Memory nicht. 2024 zeigte der Forscher Johann Rehberger, dass ein manipuliertes Dokument ChatGPT dazu bringen kann, versteckte Anweisungen im Langzeitgedächtnis zu speichern, woraufhin Unterhaltungen in neuen Threads weiter an einen Angreifer-Server gesendet wurden. Im Oktober 2025 beschrieb Palo Alto Networks Unit 42 dieselbe Klasse gegen Amazon Bedrock Agents: Eine präparierte Webseite manipulierte den Zusammenfassungsschritt der Session, die eingeschleusten Anweisungen wurden gespeichert, und spätere Sessions leiteten still Nutzerdaten ab. Ihre zentrale Beobachtung: Memory-Inhalte werden in die System-Anweisungen der Orchestrierungs-Prompts eingefügt und oft höher priorisiert als die Nutzereingabe.

Ein Preprint von 2026 zu Memory Poisoning systematisiert das in vier Schreibkanäle: explizit per Anweisung ausgeführte Schreibvorgänge, vom System-Prompt getriebene Schreibvorgänge, durch Compaction getriebene Schreibvorgänge und Erfahrung-zu-Prozedur-Schreibvorgänge. Bei den zwei getesteten Agenten mit GPT-OSS-120B lag die durchschnittliche Angriffserfolgsrate bei 66,67 Prozent und 34,25 Prozent, und die vier untersuchten Prompt-Injection-Abwehrmaßnahmen ließen erhebliche Lücken. OWASP führt die Klasse inzwischen als ASI06, Memory and Context Poisoning. Die genauen Prozentwerte würde ich nicht als Prognose für dein System lesen, aber die Struktur des Problems ist klar: Je aggressiver ein Agent Memory liest und schreibt, desto größer die Angriffsfläche.

**Designregel**

Inhalte von außerhalb des Nutzers (Webseiten, E-Mails, Dokumente, Tool-Ergebnisse) dürfen nur als kurzer Fakt mit Quelle gemerkt werden, nie als Anweisung, Präferenz oder Prozedur. Wenn eine Erinnerung ändern würde, was der Agent tut, statt was er weiß, verlange einen Menschen oder eine separate Prüfung.

Konkret würde ich vier Kontrollen einsetzen: Schreibvorgänge nach Quelle gaten (die eigenen Nachrichten des Nutzers sind anders vertrauenswürdig als abgerufene Inhalte), jede Erinnerung mit Herkunft versehen, damit sie auditierbar und gesammelt entfernbar ist, prozedurales Memory wie Code reviewen und alle Lese- und Schreibzugriffe loggen, damit du hinterher „Warum hat der Agent das getan?" beantworten kannst. Den Agenten von ausgehenden Kanälen zu isolieren begrenzt den Schaden, wenn eine schlechte Erinnerung durchrutscht; die Muster aus [dem Artikel zur Lethal Trifecta](https://balazscsorba.com/de/blog/prompt-injection-lethal-trifecta-patterns) gelten unmittelbar.

## DSGVO: Auskunft, Löschung und das Problem abgeleiteter Daten

Sobald ein Langzeitgedächtnis personenbezogene Daten enthält, gelten dafür die Grundsätze aus Artikel 5 DSGVO. Daten müssen für festgelegte Zwecke erhoben und nicht unvereinbar weiterverarbeitet werden (Zweckbindung), angemessen, erheblich und auf das notwendige Maß beschränkt sein (Datenminimierung), sachlich richtig und aktuell sein, wobei unrichtige Daten unverzüglich gelöscht oder berichtigt werden, und nur so lange identifizierbar bleiben wie nötig (Speicherbegrenzung). Artikel 17 gibt Betroffenen das Recht auf Löschung, unter anderem wenn die Daten für den Zweck nicht mehr notwendig sind, die Einwilligung widerrufen wurde oder die Verarbeitung unrechtmäßig war. Ein Nutzer, der fragt „Was weißt du über mich, und bitte vergiss es", stellt eine normale Anfrage, die du bedienen können musst.

-   **Ordne jede Erinnerung einer Person zu.** Eine Nutzer- oder Betroffenen-ID an jedem Datensatz macht Auskunft und Löschung zu einer Abfrage statt zu einer Ermittlung. Auch Erinnerungen über Dritte brauchen eine Kennung.
-   **Lösche abgeleitete Kopien.** Zusammenfassungen, Embeddings, Suchindizes, Caches und Backups sind Kopien. Speichere in jeder Ableitung die ID der Quell-Erinnerung, damit das Löschen kaskadiert.
-   **Standardmäßig ablaufen lassen.** Speicherbegrenzung heißt Prüfdatum oder TTL an jedem Eintrag, und die Memory-Tool-Dokumentation nennt das Ablaufen lange ungenutzter Dateien als empfohlene Schutzmaßnahme.
-   **Anzeigen und Korrektur ermöglichen.** Richtigkeit ist ein Grundsatz, kein Feature. Eine sichtbare Memory-Ansicht mit Bearbeiten und Löschen ist der günstigste Weg dahin.
-   **Halte Logs frei von Memory-Inhalten** und behalte den Verarbeitungsort im Blick; zur Datenresidenz siehe [DSGVO und LLM-APIs](https://balazscsorba.com/de/blog/gdpr-llm-api-eu-data-residency).

Hier unterscheiden sich die Produkte am stärksten, wie der nächste Abschnitt zeigt. Das ist keine Rechtsberatung; kläre Rechtsgrundlage und Aufbewahrungsfristen mit deiner Datenschutzbeauftragten oder deinem Datenschutzbeauftragten. Die technische Anforderung ist aber eindeutig: Ein Memory, das du nicht pro Eintrag einsehen, korrigieren oder löschen kannst, ist schwer zu verteidigen.

## Wie aktuelle Produkte Memory lösen

Die folgenden Angaben stammen aus der Dokumentation der Anbieter (Stand 2. Oktober 2026) oder aus Quellen, die sie zitieren; die OpenAI-Hilfeseiten blockierten meinen automatisierten Zugriff, daher stütze ich mich bei ChatGPT und dots auf Suchauszüge der Hilfeartikel und auf einen Beitrag, der die dots-Dokumentation zitiert. Prüfe den aktuellen Wortlaut, bevor du dich auf ein Detail verlässt.

Aspekt

ChatGPT Memory

Claude Memory (claude.ai)

Claude Memory Tool (API)

OpenAI dots

**Was es ist**

Gespeicherte Erinnerungen plus Bezug auf den Chatverlauf

Kurze Themen aus Chats, pro Projekt

Dateioperationen, die Claude anfordert und deine App ausführt

Dot-eigene Notizen plus relevantes ChatGPT Memory

**Wo es liegt**

OpenAI

Anthropic

Deine Infrastruktur unter /memories

OpenAI, Notizen getrennt vom ChatGPT Memory

**Ansehen und bearbeiten**

Einstellungen, Personalisierung, Erinnerungen verwalten

Einstellungen, Memory: ansehen, bearbeiten, löschen

Was du baust

Einzelne Erinnerungen nicht einsehbar oder korrigierbar

**Löschen**

Einzeln oder alle; Chat löschen löscht die Erinnerung nicht

Einzeln, pausieren oder alles zurücksetzen

Dein Handler entscheidet (delete-Befehl, Ablauf)

Nur durch Löschen des Dots

**Sensible Daten**

In den lesbaren Seiten nicht behandelt

Schließt Ausweis-, Kontonummern, Vorstrafen und Einwanderungsdaten aus; Gesundheit, Religion, Politik per Opt-in

Du validierst; Claude lehnt meist ab

Kontext behält keine Zugangsdaten, Bilder oder Screenshots

**Ausschalter**

Ja

Pausieren, Inkognito-Chats

Du aktivierst das Tool nicht

Einstellungen ändern bestehende Notizen nicht zwingend

Drei Details fallen auf. ChatGPT führt ein Protokoll gelöschter gespeicherter Erinnerungen bis zu 30 Tage lang für Sicherheit und Debugging, und eine Erinnerung überlebt das Löschen des Chats, aus dem sie stammt. Claude begrenzt Memory pro Projekt, aktiviert es standardmäßig in den Plänen Free, Pro und Max und überlässt es bei Team und Enterprise den Owners. Bei dots sagt die Dokumentation, dass du einzelne Dot-Erinnerungen weder ansehen, korrigieren noch löschen kannst, dass das Trennen eines Plugins nicht löscht, was der Dot daraus gelernt hat, und dass alles, was der Dot dem ChatGPT Memory hinzugefügt hat, nach dem Löschen des Dots bestehen bleibt. Für einen persönlichen Assistenten mag das akzeptabel sein; für ein Unternehmen, das ihn mit Kundendaten verbindet, ist es zuerst eine DSGVO-Frage. Das größere Bild diskutiere ich in [der dots-Impact-Analyse](https://balazscsorba.com/de/blog/openai-dots-always-on-agents-impact).

## Eine Checkliste für das Memory-Design

In dieser Reihenfolge würde ich bei einem neuen Agenten vorgehen:

1.  Schreibe auf, welche Ebenen du brauchst. Viele Agenten brauchen nur Arbeitskontext plus eine Fortschrittsdatei pro Session.
2.  Wähle die Gedächtnisarten und gib jeder eine eigene Datensatzform und eigenen Ablauf.
3.  Definiere die Schreibrichtlinie: Auslöser, erlaubte Quellen und die „Nie speichern"-Liste. Setze Quellenprüfungen im Code um, nicht nur im Prompt.
4.  Versieh jeden Datensatz mit Owner, Quelle, Zeitstempel, Geltungsbereich und Ablauf.
5.  Grenze das Retrieval nach Mandant und Nutzer ein, bevor du rankst; begrenze die injizierten Tokens.
6.  Leite die Ausgabe von Compaction und Zusammenfassung durch dieselben Schreib-Gates.
7.  Reviewe prozedurales Memory wie Code; verlange Freigabe für Erinnerungen, die das Verhalten ändern.
8.  Gib Nutzern eine Ansicht mit Bearbeiten, Löschen und Pausieren; lass die Löschung auf abgeleitete Daten kaskadieren.
9.  Logge Lese- und Schreibzugriffe und teste vor dem Launch mit Poisoning-Fällen und Retrieval-Evals.

## Meine Empfehlung

Fang klein an: eine Fortschrittsdatei pro Session und ein kurzes, für Nutzer sichtbares Profil-Memory. Ergänze episodisches Langzeitgedächtnis erst, wenn du in deinen Evals zeigen kannst, dass es die Ergebnisse verbessert, und prozedurales Memory zuletzt und mit Review. Die Produkte zeigen, wohin der Markt geht, nämlich zu Agenten, die standardmäßig erinnern, aber auch die offenen Fragen: Kontrolle, Löschung und Vertrauen in das Erinnerte. Wenn du auf der API baust, ist das Memory Tool genau deshalb ein gutes Referenzdesign, weil es Speicher, Validierung und Löschung in deine Hände legt.

## Quellen

1.  [Anthropic docs: Memory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)
2.  [Anthropic docs: Context editing](https://platform.claude.com/docs/en/build-with-claude/context-editing)
3.  [Anthropic Engineering: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
4.  [Sumers et al.: Cognitive Architectures for Language Agents (CoALA)](https://arxiv.org/abs/2309.02427)
5.  [Packer et al.: MemGPT, Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)
6.  [Park et al.: Generative Agents, Interactive Simulacra of Human Behavior](https://arxiv.org/abs/2304.03442)
7.  [Unit 42: When AI Remembers Too Much, persistent behaviors in agents memory](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
8.  [From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents (preprint)](https://arxiv.org/html/2606.04329v1)
9.  [The Hacker News: ChatGPT macOS flaw could have enabled long-term spyware via memory function](https://thehackernews.com/2024/09/chatgpt-macos-flaw-couldve-enabled-long.html)
10.  [Vectorize: OWASP ASI06, Memory and Context Poisoning explained](https://vectorize.io/articles/owasp-asi06)
11.  [Claude Help Center: Use chat search and memory to build on previous context](https://support.claude.com/en/articles/11817273-use-claude-s-chat-search-and-memory-to-build-on-previous-context)
12.  [OpenAI Help Center: Memory in ChatGPT](https://help.openai.com/en/articles/8590148-memory-faq)
13.  [OpenAI Help Center: Dots privacy, security, and safety FAQs](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs)
14.  [Flavio Copes: A deep dive into OpenAI dots (quotes the dots documentation on memory)](https://flaviocopes.com/openai-dots/)
15.  [GDPR Article 5: Principles relating to processing of personal data](https://gdpr-info.eu/art-5-gdpr/)
16.  [GDPR Article 17: Right to erasure](https://gdpr-info.eu/art-17-gdpr/)

## Häufige Fragen

Was ist Memory bei einem KI-Agenten?

Alles, was ein Agent in einem späteren Schritt oder einer späteren Session nutzen kann und das nicht in den Modellgewichten steckt: das aktuelle Kontextfenster, Zustand für die laufende Aufgabe und ein persistenter Speicher wie Dateien oder eine Datenbank, den der Agent sessionübergreifend liest und schreibt. LLMs sind zustandslos, deshalb ist jede Form von Memory etwas, das dein System in den Prompt schreibt.

Was ist der Unterschied zwischen Kurzzeit- und Langzeitgedächtnis bei KI-Agenten?

Das Kurzzeitgedächtnis ist der Arbeitskontext der aktuellen Unterhaltung oder Aufgabe und verschwindet mit ihr oder wird verdichtet. Das Langzeitgedächtnis liegt außerhalb des Modells, überlebt Sessions und wird bei Bedarf abgerufen. Dazwischen liegt der Session-Zustand, etwa eine Fortschrittsdatei oder eine Thread-Zusammenfassung, der für die Dauer einer Arbeit existiert.

Was sind episodisches, semantisches und prozedurales Gedächtnis bei LLM-Agenten?

Das CoALA-Framework übernimmt diese Begriffe aus der Kognitionswissenschaft. Episodisches Gedächtnis speichert konkrete Erlebnisse (was in einer früheren Aufgabe passiert ist), semantisches Gedächtnis allgemeine Fakten (der Kunde bevorzugt E-Mail) und prozedurales Gedächtnis gelernte Fähigkeiten oder Handlungsweisen. Das Arbeitsgedächtnis ist der aktive Kontext darüber.

Was sollte ein KI-Agent nie im Memory speichern?

Geheimnisse und Zugangsdaten, amtliche Ausweisnummern und Kontonummern, besondere Kategorien personenbezogener Daten ohne klare Grundlage und Zweck, rohe Tool-Ausgaben und Webinhalte, die Anweisungen enthalten könnten, und alles, womit der Nutzer nicht rechnet. Claude schließt zum Beispiel standardmäßig amtliche Ausweisnummern, Kontonummern, Vorstrafen und Einwanderungsstatus aus.

Was ist Memory Poisoning bei KI?

Ein Angriff, bei dem feindliche Inhalte ins persistente Memory eines Agenten geschrieben werden und das Verhalten in späteren Sessions beeinflussen. OWASP führt ihn als ASI06, Memory and Context Poisoning, in den Top 10 für Agentic Applications. Anders als normale Prompt Injection endet er nicht mit der Session.

Ist Agenten-Memory mit der DSGVO vereinbar?

Ja, wenn du es dafür entwirfst. Memory mit personenbezogenen Daten muss Zweckbindung, Datenminimierung, Richtigkeit und Speicherbegrenzung (Artikel 5) einhalten, und du musst die Erinnerungen einer Person auf Anfrage finden und löschen können (Artikel 17). Dafür brauchst du Zuordnung pro Nutzer, Herkunftsangaben und ein Löschen, das auch Zusammenfassungen und Embeddings erreicht.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [OpenAI dots: Was Always-on-Agenten verändern werden, und was nicht](https://balazscsorba.com/de/blog/openai-dots-always-on-agents-impact)
-   [Human in the Loop bei KI-Agenten: wo Freigaben hingehören](https://balazscsorba.com/de/blog/human-in-the-loop-ai-agents)
-   [Multi-Agent-Systeme: wann sie einen Agenten schlagen und wann nicht](https://balazscsorba.com/de/blog/multi-agent-systems-when-worth-it)
-   [Voice Agents bauen: Realtime Speech-to-Speech oder STT, LLM und TTS?](https://balazscsorba.com/de/blog/voice-agents-realtime-latency)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)