mem0 selbst betreiben: Gedächtnis für KI-Agenten, ohne Datenschutzlücke

Constantin Budin, Azure- und Microsoft-Berater bei Pexon Consulting | 11 Min. Lesezeit | 22.09.2026

TL;DR: mem0 in fünf Sätzen

mem0 gibt KI-Agenten ein Langzeitgedächtnis über einzelne Gespräche hinaus. Es läuft als Bibliothek oder als eigener Server mit Oberfläche, Schlüsseln je Nutzer und Protokoll. Als Bibliothek speichert es in Qdrant, als Server in Postgres mit pgvector. Die Voreinstellungen zeigen auf OpenAI, für ein EU-Setup hängt man Modell und Einbettungen um. Der eigentliche Aufwand ist nicht das Erinnern, sondern das Vergessen.

Das Problem: Der Assistent fragt jedes Mal dasselbe

Der Satz fällt in fast jedem Pilotprojekt nach zwei Wochen: „Warum muss ich dem Ding jedes Mal erklären, wie wir arbeiten?“ Der Vertriebsmitarbeiter erklärt zum fünften Mal, dass Angebote ohne Preisliste rausgehen. Die Entwicklerin erklärt zum fünften Mal, dass das Projekt kein npm nutzt.

Der Reflex ist, alles in den Systemprompt zu schreiben. Das funktioniert, bis der Prompt 3.000 Wörter hat, für jeden gleich ist und bei jedem einzelnen Aufruf mitbezahlt wird. Der zweite Reflex ist, das ganze Gespräch mitzuschicken. Dann steigen die Kosten mit der Länge, und die Qualität sinkt trotzdem, weil das Modell im Rauschen sucht. Warum lange Kontexte schaden, steht im Beitrag zum Context Engineering.

Eine Gedächtnisschicht macht etwas anderes: Sie merkt sich wenige, verdichtete Aussagen und holt nur die passenden zurück.

Was mem0 macht

mem0 setzt zwischen Gespräch und Modell zwei Vorgänge:

Wichtig ist der erste Punkt: Gespeichert wird nicht das Protokoll, sondern eine verdichtete Aussage wie „arbeitet im Vertrieb Nord, will Angebote ohne Preisliste“. Das ist der Unterschied zu einem RAG-Index über Chatverläufe, und es ist zugleich der Grund, warum das Thema datenschutzrechtlich heikel ist: Diese Aussagen sind Profilbildung.

Schritt 1: Betriebsform wählen

Zwei Wege, mit unterschiedlichen Folgen:

• Als Bibliothek. Installation im eigenen Dienst, Speicher standardmäßig in einem lokalen Qdrant. Schnell für einen Prototyp, aber jede Anwendung baut ihre eigene Insel.
• Als eigener Server. Läuft per Docker, bringt Oberfläche, Schlüssel je Nutzer und ein Protokoll der Anfragen mit, und speichert in Postgres mit pgvector.

Für Unternehmen ist der Server fast immer die richtige Wahl, und zwar wegen der drei Dinge, die er mitbringt: Zugriffsschlüssel je Anwendung, Protokoll und eine Datenbank, die Sie ohnehin sichern. Wenn pgvector ohnehin im Haus ist, entfällt ein zweiter Datenspeicher.

Schritt 2: Die Voreinstellungen umhängen

Hier liegt die Falle. Im Auslieferungszustand nutzt mem0 ein OpenAI-Modell für das Verdichten und OpenAI-Einbettungen. Das heißt: Genau die Sätze, die etwas über Ihre Mitarbeiter aussagen, gehen an einen amerikanischen Anbieter, bevor sie in Ihrer Datenbank landen.

Für ein souveränes Setup zeigen beide Einstellungen auf Ihr eigenes Gateway:

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "claude-sonnet-5",
            "openai_base_url": "https://gateway.intern.example.com/v1",
            "api_key": "sk-team-agenten",
        },
    },
    "embedder": {
        "provider": "openai",
        "config": {
            "model": "bge-m3",
            "openai_base_url": "https://gateway.intern.example.com/v1",
        },
    },
    "vector_store": {"provider": "pgvector", "config": {"collection_name": "memories"}},
}

Der Anbieter heißt weiterhin openai, weil das die Schnittstelle beschreibt, nicht den Empfänger. Dahinter steht Ihr LiteLLM-Gateway, das auf Claude über Bedrock in der EU oder auf ein lokales Modell zeigt. Damit gilt für das Gedächtnis dieselbe Regel wie für alles andere: eine Stelle, an der Modelle, Grenzen und Protokolle festgelegt sind.

Prüfen Sie nach dem Umhängen im Gateway-Protokoll, dass tatsächlich Anfragen ankommen. Wer das nicht kontrolliert, entdeckt Monate später, dass eine Standardeinstellung irgendwo überlebt hat.

Schritt 3: Trennung je Nutzer, von Anfang an

Erinnerungen ohne klare Zuordnung sind das teuerste Versäumnis in diesem Thema. Jede Erinnerung braucht eine Kennung, meist den Nutzer, manchmal zusätzlich ein Projekt oder einen Mandanten.

Drei Fehler, die wir regelmäßig sehen:

1. Alles in einen Topf. Ein gemeinsames Gedächtnis für das ganze Team klingt effizient. Dann erfährt die Praktikantin aus einer Antwort, was der Geschäftsführer letzte Woche gefragt hat.
2. Kennung aus der Sitzung statt aus der Anmeldung. Wenn die Kennung aus dem Frontend kommt, kann sie manipuliert werden. Sie gehört aus dem Anmeldetoken.
3. Keine Trennung nach Mandant. In Kanzleien und Beratungen ist das kein Komfort, sondern Pflicht.

Schritt 4: Das Löschkonzept, bevor es produktiv geht

Ein Gedächtnis ist eine Sammlung personenbezogener Aussagen. Damit gelten Auskunft, Berichtigung und Löschung. Das ist kein Randthema, sondern der Teil, der über die Freigabe entscheidet. Vier Punkte gehören geklärt, bevor der erste Nutzer dazukommt:

Was das im Betrieb kostet

Eine grobe Rechnung hilft gegen Überraschungen. Jeder Gesprächsabschluss löst einen zusätzlichen Modellaufruf zum Verdichten aus, jede Antwort eine Suche in der Datenbank. Bei 100 Mitarbeitenden mit je zehn Gesprächen am Tag sind das 1.000 zusätzliche kleine Aufrufe täglich. Mit einem günstigen Modell für das Verdichten bleibt das im zweistelligen Eurobereich je Monat, mit einem großen Modell wird daraus schnell das Zehnfache.

Die Gegenrechnung ist der eingesparte Kontext: Wer heute 3.000 Wörter Systemprompt bei jedem Aufruf mitschickt, zahlt diese Tokens bei jeder einzelnen Frage. Deshalb gehört vor die Einführung eine kurze Messung beider Seiten, nicht nur die Annahme, dass Gedächtnis billiger ist.

Was ein Gedächtnis nicht löst

• Falsches bleibt falsch, nur länger. Wenn der Agent eine falsche Annahme verdichtet, wiederholt er sie monatelang. Es braucht einen Weg, eine Erinnerung zu korrigieren, und zwar für den Nutzer selbst.
• Es ersetzt keine Wissensbasis. Ein Gedächtnis merkt sich, wie jemand arbeitet. Was in der Verfahrensanweisung steht, gehört in RAG. Wer beides vermischt, bekommt Antworten, die sich auf Erinnerungen statt auf Dokumente stützen.
• Es kostet bei jedem Aufruf. Verdichten ist ein zusätzlicher Modellaufruf. Das ist meist günstiger als ein langes Kontextfenster, aber nicht kostenlos. Rechnen Sie es vorher durch.
• Qualität lässt sich messen. Bevor Sie Gedächtnis flächendeckend einschalten, nehmen Sie zwanzig typische Aufgaben, einmal mit und einmal ohne. Wenn kein Unterschied sichtbar ist, war das Problem woanders.

Häufig gestellte Fragen

Was ist mem0?

mem0 ist eine offene Gedächtnisschicht für KI-Anwendungen. Sie leitet aus Gesprächen verdichtete Aussagen ab, speichert sie und holt vor der nächsten Antwort die passenden zurück. Betrieben wird sie als Bibliothek oder als eigener Server.

Kann ich mem0 selbst hosten?

Ja. Die Fassung zum Selbstbetreiben läuft per Docker mit Oberfläche, Schlüsseln je Nutzer und Protokoll, und speichert in Postgres mit pgvector. Als Bibliothek nutzt sie standardmäßig ein lokales Qdrant.

Schickt mem0 Daten an OpenAI?

In den Voreinstellungen ja, weil Modell und Einbettungen dort zeigen. Für ein EU-Setup stellt man beide auf das eigene Gateway um, etwa auf Claude über Amazon Bedrock oder ein lokales Modell. Prüfen Sie im Gateway-Protokoll, ob die Umstellung greift.

Was ist der Unterschied zwischen Gedächtnis und RAG?

RAG holt Wissen aus Dokumenten, das für alle gilt. Ein Gedächtnis merkt sich Aussagen über eine Person oder einen Vorgang. Beides gehört getrennt, sonst begründet der Assistent fachliche Antworten mit Erinnerungen.

Welche Datenschutzpflichten kommen mit einem Gedächtnis?

Es speichert personenbezogene Aussagen, damit gelten Auskunft, Berichtigung und Löschung. Nötig sind Fristen je Art, ein Löschlauf je Nutzerkennung inklusive der Einbettungen, eine Auskunftsfunktion und ein Eintrag im Verarbeitungsverzeichnis.

Nächster Schritt

Wenn Ihre Agenten sich erinnern sollen, ohne dass daraus eine unkontrollierte Personensammlung wird, gehört die Gedächtnisschicht in dieselbe Architektur wie Gateway und Wissensbasis. Wir bauen sie mit Trennung je Nutzer, Löschkonzept und Messung.

Verwandte Themen

Quellen: mem0-Dokumentation zur Fassung zum Selbstbetreiben (Bibliothek und Server, Qdrant beziehungsweise Postgres mit pgvector, Voreinstellungen für Modell und Einbettungen). Stand 22.09.2026.