Gedächtnis von KI-Agenten: Kontext, Präferenzen und dauerhafte Fakten trennen – und entscheiden, wann sie ablaufen

Sich erinnern heißt nicht, den Verlauf zu behalten

Ein Agent, der dieselbe Person oder dasselbe Team mehrfach unterstützt, braucht Kontinuität: Es kann sinnvoll sein, eine bevorzugte Sprache, das übliche Format einer Lieferung oder den Namen eines Projekts zu kennen. Werden jedoch alle Gespräche, abgerufenen Dokumente und Modellinferenzschlüsse zu wiederverwendbarem Gedächtnis, entsteht ein Governance-Problem. Das System kann irrelevante, veraltete, falsche, sensible oder nur in einer früheren Situation anwendbare Informationen abrufen.

Die Architekturfrage lautet nicht, ob ein Agent Gedächtnis besitzt, sondern welche konkrete Aussage er bewahrt, wer sie verwenden darf, zu welchem Zweck und wie lange. Der Satz „Der Kunde bevorzugt, Änderungen per E-Mail freizugeben“ kann eine erklärte Präferenz, eine Beobachtung aus einem einzigen Austausch oder eine aktuell geltende Betriebsregel sein. Diese Deutungen haben unterschiedlichen Wert und sollten weder gleich gespeichert noch gleich angewandt werden.

Auch persistentes Gedächtnis erhält keine Autorität, nur weil es gespeichert wurde. Eine Anweisung aus einem vergangenen Gespräch, einem importierten Dokument oder einem Abrufresultat bleibt Inhalt der Quelle, die sie geliefert hat. Sie darf keine Anweisungen höherer Autorität verdrängen und keine Handlungen ermöglichen, die der Agent im aktuellen Kontext nicht ausführen darf. Diese Trennung ist besonders wichtig, wenn abgerufener Inhalt nicht validiert wurde oder manipuliert sein könnte.

Für diesen Leitfaden ist die Unterscheidung zwischen Designfakten und Richtlinienentscheidungen hilfreich. Es ist eine operative Tatsache, dass ein System Datensätzen Erstellungs-, Prüf- oder Ablaufdaten zuweisen kann. Die Entscheidung, dass eine Präferenz nach neunzig Tagen abläuft, ist dagegen eine Organisationsrichtlinie: Sie muss durch Risiko, Veränderlichkeit des Datums und erwartete Erfahrung begründet sein und darf nicht als universelle Regel erscheinen.

Vier Objekte, die getrennt werden sollten

Das Wort „Gedächtnis“ vermischt häufig Komponenten mit sehr unterschiedlichen Lebenszyklen. Ihre Trennung reduziert unzulässige Abrufe und macht das Verhalten eines Agenten verständlicher. Der Sitzungs-Kontext enthält den unmittelbaren Austausch, der zur Interpretation der aktuellen Anfrage nötig ist. Er sollte auf die Sitzung begrenzt sein und nach ihrem Ende verschwinden oder unzugänglich werden, sofern ein Teil nicht bewusst in eine andere Kategorie überführt wird.

Der Aufgabenstatus repräsentiert den Fortschritt einer konkreten Arbeit: Kennung einer Anfrage, bereits verarbeitete Elemente, laufender Entwurf, Teilergebnis oder ausstehender Schritt. Er muss möglicherweise eine kurze Unterbrechung überdauern, ist deshalb aber weder eine Präferenz noch ein Fakt, der in zukünftigen Aufgaben verfügbar sein sollte. Die Dokumentation von Googles Ausführungswerkzeugen für Agenten liefert ein Beispiel für an eine Workflow-Sitzung gebundenen Zustand sowie explizite Bereinigung oder eine Lebensdauer nach Abschluss der Aufgabe oder des Gesprächs.

Erklärtes Gedächtnis ist Information, die eine Person oder ein Team für Kontinuität bereitgestellt hat, etwa bevorzugte Sprache, Zeitzone oder Namenskonvention. Es sollte die ursprüngliche Erklärung oder einen Verweis darauf sowie ihren Geltungsbereich bewahren. Eine für ein Projekt angegebene Einstellung muss nicht auf alle Projekte ausgeweitet werden; ebenso darf eine Präferenz eines Teammitglieds nicht der gesamten Organisation zugeschrieben werden.

Abrufbares Wissen umfasst Aussagen aus identifizierten Quellen: eine geltende interne Richtlinie, den Status eines Dienstes oder eine Liste Verantwortlicher. Sein Design ähnelt weniger einem Nutzerprofil als einem Herkunftsdatensatz: Quelle, Version oder Abfragezeitpunkt, Verantwortlicher, Umfang und Aktualisierungsbedingungen. Die PROV-O-Ontologie des W3C bietet Konzepte zur Darstellung von Entitäten, Aktivitäten und Akteuren sowie von Beziehungen der Erzeugung, Ableitung und Ungültigmachung. Sie verpflichtet nicht zu einer bestimmten Datenbank, hilft jedoch, Nachvollziehbarkeit ausdrücklich zu machen.

Der Mindestdatensatz einer steuerbaren Erinnerung

Ein Datensatz muss nicht den vollständigen Gesprächstext speichern, um nützlich zu sein. In vielen Fällen genügen eine normalisierte Aussage und Metadaten. Statt eines ganzen Dialogs festzuhalten, könnte ein Datensatz beispielsweise aussagen, dass eine Person für einen bestimmten Arbeitsbereich Zusammenfassungen auf Spanisch gewählt hat. Weniger Inhalt beseitigt nicht alle Risiken, begrenzt aber die Exposition und erleichtert die Prüfung.

Mindestens sollte jedes Element eine stabile Kennung enthalten; Inhalt oder einen Verweis auf den Inhalt; Eigentümer oder die Person, der es zugeschrieben wird; erlaubten Zweck; Anwendungsbereich; Quelle und Erhebungsweg; Vertrauensniveau; Erstellungsdatum; Datum der letzten Prüfung; Ablaufregel; sowie Lösch- oder Einschränkungsstatus. Wird es aus anderen Daten abgeleitet, sollten auch seine Abhängigkeiten gespeichert werden. So lässt sich ermitteln, welche Erinnerungen überprüft werden müssen, wenn sich eine Quelle ändert oder eine Person Berichtigung verlangt.

Vertrauensniveau und Nutzungserlaubnis sollten getrennt werden. Eine von der Person unmittelbar erklärte Präferenz kann hohes Vertrauen dafür verdienen, was sie geäußert hat, aber nur einen engen Bereich haben. Automatisch aus einem Dokument extrahierte Daten können potenziell nützlich sein, jedoch menschliche Validierung oder die Abfrage einer Primärquelle benötigen, bevor sie eine Handlung auslösen. Vertrauen darf nicht zu einem undurchsichtigen Score werden, der die Herkunft ersetzt.

Für personenbezogene Daten formuliert die Datenschutz-Grundverordnung der Europäischen Union Grundsätze der Zweckbindung, Datenminimierung, Richtigkeit und Speicherbegrenzung sowie Rechte im Zusammenhang mit Berichtigung, Löschung und Einschränkung der Verarbeitung unter den anwendbaren Bedingungen. Ein Produkt, das in diesem Rahmen betrieben wird, muss diese Grundsätze in reale Prozesse übersetzen; ein Feld namens „TTL“ allein belegt keine rechtliche Konformität.

Was bestehen bleiben kann – und was verschwinden sollte

Über Persistenz sollte nach funktionaler Notwendigkeit und Risiko entschieden werden, nicht nach Speicherkomfort. Eine explizite Präferenz mit geringer Auswirkung kann fortbestehen, wenn sie einen klaren Eigentümer, einen konkreten Zweck und eine zugängliche Bearbeitungsmöglichkeit besitzt. Ein Aufgabenstatus wird üblicherweise nach Ende der Arbeit gelöscht. Ein veränderlicher externer Fakt wie Tarif, Richtlinie oder Dienstverfügbarkeit kann als Abrufhinweis bewahrt werden, sollte jedoch nicht als aktuelle Evidenz gelten, wenn eine relevante Entscheidung ansteht.

Inferenzen verdienen eine eigene Kategorie. Dass das Modell abgeleitet hat, jemand bevorzuge kurze Mitteilungen, ist nicht gleichbedeutend damit, dass diese Person es erklärt hat. Entscheidet sich ein Produkt dafür, Inferenzen zu speichern, sollte es sie als solche kennzeichnen, ihren Bereich beschränken, eine kurze Überprüfungsfrist setzen und eine einfache Möglichkeit bieten, sie zu bestätigen, zu korrigieren oder zu verwerfen. In Szenarien mit hoher Auswirkung ist es vorsichtiger, Verhaltensinferenzen ohne explizite Produktentscheidung und Risikobewertung nicht in persistentes Gedächtnis zu überführen.

Sensible Daten verlangen eine strengere Bewertung als Darstellungsoptionen. Ihre Sensibilität hängt sowohl von der Art des Datums als auch von Kontext, Empfänger, Zweck und Rechtsordnung ab. Dieser Leitfaden ersetzt keine rechtliche oder sicherheitstechnische Analyse. Als Produktkriterium rechtfertigt das Vorliegen sensibler Daten nicht ihre Persistenz: Das Team muss einen konkreten Zweck, Zugangskontrollen, begrenzte Aufbewahrung und einen wirksamen Prozess für Änderungen oder Löschung nachweisen, wenn dies geboten ist.

Wichtig ist zudem, diese Klassifikation nicht hinter einem einzigen Etikett „Gedächtnis“ zu verbergen. Oberfläche und interne APIs sollten die Unterschiede abbilden: Ein Nutzer möchte möglicherweise eine Präferenz bearbeiten, eine pausierte Aufgabe abbrechen oder die Richtigkeit eines aus externer Quelle stammenden Fakts bestreiten. Das sind unterschiedliche Operationen und erfordern unterschiedliche Spuren.

Ablauf: Verfall, Überprüfung und Ereignisse

Ein Ablaufdatum beantwortet die Frage, wann ein Datum nicht mehr automatisch abgerufen werden darf. Eine verpflichtende Überprüfung beantwortet eine andere Frage: Wann es erneut geprüft werden muss, bevor es als gültig gilt. Beide können nebeneinander bestehen. Eine Formatpräferenz kann beispielsweise verfügbar bleiben, bis die Person sie ändert oder löscht; eine Betriebsrichtlinie kann dagegen weiter indexiert sein, aber vor ihrer Verwendung zur Genehmigung einer Handlung die Abfrage ihrer Quelle verlangen.

Ereignisbasierte Regeln ergänzen die Uhr. Ein Wechsel von Projekt, Rolle, Anbieter, Konto oder Dokumentversion kann zugeordnete Erinnerungen ungültig machen. Hängt eine Aussage von einer konkreten Quelle ab, sollte deren Aktualisierung oder Rücknahme eine Überprüfung ihrer Ableitungen auslösen. Die Modellierung von Ableitungen und Ungültigmachungen ermöglicht es, die betroffene Menge zu finden, statt abzuwarten, bis jedes Element einzeln abläuft.

Ablauf darf nicht mit sofortiger physischer Löschung verwechselt werden. Aus operativen oder regulatorischen Gründen kann es unterschiedliche Zustände geben, etwa „nicht abrufbar“, „Löschung ausstehend“ oder „unter einer spezifischen Richtlinie aufbewahrt“. Entscheidend für das Verhalten des Agenten ist, dass ein abgelaufenes oder eingeschränktes Element nicht stillschweigend wieder in den Antwortkontext gelangt. Die Implementierung muss dokumentieren, wer auf jeden Zustand zugreifen darf und zu welchem Zweck.

Konkrete Fristen lassen sich nicht aus einer allgemeinen technischen Quelle ableiten. Sie müssen aus Zweck, Datentyp, Risiko der Veraltung, anwendbaren Pflichten und operativen Bedürfnissen hervorgehen. Ein Team kann Aufbewahrungsklassen definieren, sollte jedoch ihre Auswirkungen messen: wie viele Erinnerungen ungenutzt ablaufen, wie viele korrigiert werden und wie viele Abrufe wegen fehlender Gültigkeit blockiert sind.

Konflikte: aktuelle Anweisungen, Präferenzen und Quellen

Ein häufiger Konflikt entsteht, wenn eine gespeicherte Präferenz der gegenwärtigen Anfrage widerspricht. Die einfachste Betriebsregel lautet: Die aktuelle Anfrage der Person hat innerhalb der Autorisierungs- und Sicherheitsgrenzen des Systems Vorrang vor einer früheren Präferenz. Wollte jemand zuvor kurze Antworten, fordert nun aber eine ausführliche Analyse, sollte der Agent die aktuelle Anfrage erfüllen und gegebenenfalls eine Aktualisierung der Präferenz anbieten, statt sie stillschweigend zu ändern.

Die Hierarchie von Anweisungen ist unabhängig vom Gedächtnis. Die Modellspezifikation von OpenAI beschreibt Autoritätsebenen für Anweisungen und stellt klar, dass nicht vertrauenswürdiger Inhalt keine Autorität erhält, weil er in bereitgestellten oder abgerufenen Daten erscheint. Daher kann eine im erklärten Gedächtnis gespeicherte oder aus einem Dokument übernommene Anweisung keine Regeln höherer Autorität aufheben. Das Design muss den Ursprung jeder Anweisung bewahren und verhindern, dass der Abruf sie als Systembefehl darstellt.

Weichen zwei Wissensquellen voneinander ab, sollte der Agent den Widerspruch nicht durch eine erfundene Synthese lösen. Er muss erkennen, dass ein Konflikt besteht, nach definierter Richtlinie eine primäre oder aktuellere Quelle bevorzugen oder menschliches Eingreifen verlangen, falls die Entscheidung relevante Folgen hat. Der Gedächtnisdatensatz sollte die fraglichen Elemente markieren, damit sie nicht als gesicherte Fakten erneut verwendet werden.

Korrektur hat zwei Dimensionen. Die Korrektur des Primärdatensatzes verhindert, dass die Daten in neuen Abrufen erscheinen. Die Korrektur seiner Ableitungen verhindert, dass sie je nach Architektur in Zusammenfassungen, Indizes, Caches, Bewertungen oder Trainingsdaten für die Suche fortbestehen. Ein Berichtigungs- oder Löschprozess, der nur eine sichtbare Tabelle aktualisiert, die Daten aber in den Indizes belässt, welche den Agenten speisen, erfüllt das operative Ziel nicht, ihre Wiederverwendung zu verhindern.

Vor einer externen Handlung erneut validieren

Gedächtnis kann beim Formulieren einer Antwort helfen, genügt aber nicht immer für eine externe Handlung. Wenn ein Agent Informationen versenden, einen Datensatz ändern, eine Transaktion starten, Berechtigungen ändern oder eine Entscheidung mit Auswirkungen treffen soll, muss er die Gültigkeit der Daten bewerten, die diese Handlung bedingen. Je höher die Auswirkung und je veränderlicher die Quelle, desto höher sollte die Anforderung an Abfrage oder Bestätigung sein.

Evidenz für Gültigkeit ist keine allgemeine Behauptung, der Datensatz habe „hohes Vertrauen“. Sie kann eine aktuelle Abfrage der autorisierten Primärquelle, eine ausdrückliche Bestätigung durch die zuständige Person oder ein signiertes Datum sein, das nach den Regeln der Domäne noch gültig ist. Das System sollte festhalten, welche Prüfung wann gegen welche Quelle erfolgte und welche Entscheidung sie erlaubte. Kann es nicht prüfen, muss es sich enthalten, den Umfang der Handlung reduzieren oder um Bestätigung bitten.

Das OWASP Gen AI Security Project benennt Risiken im Zusammenhang mit Gedächtnis- und Kontextvergiftung in agentischen Anwendungen. Aus Designsicht verstärkt dies die Notwendigkeit, abgerufenen Inhalt von autorisierten Anweisungen zu trennen, Herkunft zu erfassen und zu beobachten, welche Erinnerungen eine Handlung beeinflusst haben. Ein semantischer Filter allein garantiert weder die Zuverlässigkeit einer Erinnerung noch ihre Angemessenheit für das aktuelle Ziel.

NIST schlägt in seinem Rahmen für KI-Risikomanagement Aktivitäten für Governance, Mapping, Messung und Management vor, einschließlich Monitoring und Dokumentation während des Betriebs. Auf Gedächtnis angewandt spricht dies dafür, fehlgeschlagene Abrufe, veraltete Erinnerungen und wiederholte Korrekturen als messbare Risikosignale zu behandeln, nicht nur als isolierte Qualitätsvorfälle.

Produktkontrollen und operative Tests

Eine Gedächtnisansicht ist nicht nur eine Konfigurationsseite. Sie sollte verständlich machen, welche Daten der Agent nutzt, und mindestens erklärte Präferenzen, abrufbare Fakten, Inferenzen und Aufgabenstatus unterscheiden, soweit diese für die Person sichtbar sind. Für jedes Element umfasst eine nützliche Darstellung verständlichen Inhalt, Quelle oder Erhebungsweg, Bereich, letzte Überprüfung, Ablaufdatum sowie gegebenenfalls Optionen für Bearbeitung, Einschränkung oder Löschung.

Das Nutzungsprotokoll ist die technische Ergänzung dieser Ansicht. Bei einer problematischen Antwort muss das Team rekonstruieren können, welche Elemente abgerufen, welche verworfen, welche die Entscheidung beeinflusst und ob sie erneut validiert wurden. Nicht alle internen Daten müssen allen Betreibern zugänglich gemacht werden: Auch die Protokolle selbst benötigen Zugangskontrollen, Datenminimierung und Aufbewahrungsfristen. Nachvollziehbarkeit soll Untersuchungen unterstützen, ohne selbst zu einem unbegrenzten Gedächtnis zu werden.

Tests müssen mehr als korrekten Abruf abdecken. Schließen Sie Fälle ein, in denen eine alte Erinnerung der aktuellen Anfrage widerspricht; eine Quelle geändert wurde; eine Inferenz falsch ist; eine Präferenz zu einem anderen Projekt gehört; oder ein gelöschtes Element in einer Zusammenfassung oder einem Cache auftaucht. Für externe Handlungen sollte geprüft werden, dass fehlende aktuelle Evidenz die Handlung blockiert oder eine angemessene Bestätigung verlangt.

Messen Sie die Raten abgelaufener oder bereichsfremder Erinnerungsabrufe, erkannter und ungelöster Konflikte, Berichtigungen, abgeschlossener Löschungen, Blockierungen wegen fehlender erneuter Validierung sowie Handlungen, die von Gedächtnis abhingen. Diese Metriken beweisen nicht allein, dass das System sicher oder konform ist, zeigen aber, wo Gedächtnis zu einer Quelle fehlerhafter Entscheidungen wird.

Checkliste für die Bereitstellung

Vor der Aktivierung persistenten Gedächtnisses sollte das Team überprüfbar beantworten können: welche Datenklassen es speichert; wer ihr Eigentümer ist; welcher Zweck jede Klasse rechtfertigt; wie die Quelle identifiziert wird; wann sie abläuft; welche Ereignisse sie ungültig machen; wer sie sehen oder ändern darf; und was in Indizes, Caches und Zusammenfassungen geschieht, wenn sie berichtigt oder gelöscht wird.

Die Architektur muss nicht alle Risiken durch Automatisierung lösen. In manchen Domänen besteht die richtige Antwort darin, Gedächtnis auf Präferenzen mit geringer Auswirkung zu beschränken, sensible Fakten außerhalb der Agentenpersistenz zu halten oder für Änderungen mit hoher Auswirkung menschliche Prüfung zu verlangen. Operative Kontinuität hängt nicht davon ab, mehr zu erinnern, sondern nur das zu erinnern, was gesteuert werden kann.

Zur Erweiterung des Rahmens sollte diese Praxis mit den Learn-Inhalten zum Design von Agenten, mit Sicherheit für operative Risiken und mit dem Glossar verbunden werden, um Begriffe wie Herkunft, Aufbewahrung, Bereich und erneute Validierung abzustimmen. Ein gemeinsames Vokabular verhindert, dass Produkt, Engineering, Daten und Sicherheit mit „Gedächtnis“ unvereinbare Mechanismen meinen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.