AI-порталAI-портал

Memory Deletion and Compliance в 2026: как забывать данные, а не только накапливать их

Memory deletion and compliance в 2026: TTL, explicit delete path, summary invalidation и почему память агента требует governance не меньше, чем сама модель.

Memory deletion and compliance в 2026 важны потому, что агентная память создаёт риск не только через хранение, но и через неправильное забывание. Даже если raw сообщения удалены, их summary, embeddings, derived preferences, cached prompts или cross-thread store items могут продолжать влиять на поведение системы. Поэтому delete path для agent memory должен отвечать не только на вопрос "удалили ли запись", но и на вопрос перестала ли система реально использовать этот факт.

Память агента — это не один блок текста. Она может жить в истории сообщений, summary, embeddings, long-term store и связанных артефактах. Поэтому delete path для такой памяти сложнее обычной кнопки удалить чат.
Самый опасный anti-pattern - удалить raw message, но оставить summary memory, cached context или cross-thread preference. Тогда система формально "забыла" данные, но фактически всё ещё принимает решения под их влиянием.

Короткая версия

Хороший memory deletion flow в 2026 обычно покрывает:

  1. Raw messages
  2. Summaries
  3. Cross-thread store items
  4. Embeddings / indexes
  5. Caches and derived artifacts

Что особенно важно

  • явный delete path, а не только TTL;
  • memory classes с разной retention политикой;
  • invalidation для summaries и derived facts;
  • observability, что deletion реально прошёл;
  • способность объяснить, какой state ещё остался и почему.
Без техники
Система удаляет сообщения из чата, но оставляет summary, embeddings и long-term preference store.
С техникой
Delete request проходит по всем слоям памяти: raw history, summaries, store items, indexes и caches. После этого память реально перестаёт влиять на future runs.
ПромптMemory deletion intuition
Почему удалить raw messages недостаточно для compliance-safe forget path?
Ответ модели

Потому что influence memory может жить ещё в summaries, store items, embeddings и cached context. Удаление текста не всегда означает удаление поведенческого эффекта.

1. Memory нужно делить по классам

Полезная базовая схема:

  • short-term conversation history;
  • summaries;
  • cross-thread memory store;
  • embeddings / retrieval artifacts;
  • cached assembled prompts;
  • reviewer or approval artifacts, если они связаны с memory.

Удаление и retention почти всегда разные для каждого класса.

2. Delete path важнее, чем просто TTL

TTL полезен как hygiene layer:

  • очищает старые данные;
  • не даёт памяти копиться бесконечно;
  • уменьшает compliance burden.

Но TTL не заменяет explicit deletion, если:

  • пользователь просит удалить данные сейчас;
  • memory ошибочная;
  • summary contaminated;
  • tenant offboarding требует cleanup.
TTL решает вопрос "когда память должна исчезнуть сама". Delete path решает вопрос "как остановить её влияние сейчас". Для compliance обычно нужны оба слоя.

3. Summary invalidation — самый недооценённый шаг

Даже если raw message удалён, summary может содержать:

  • персональные данные;
  • preferences;
  • sensitive facts;
  • outdated assumptions.

Поэтому при delete request полезно делать одно из трёх:

  • пересобирать summary без удалённых фактов;
  • инвалидировать summary полностью;
  • переводить thread в safe minimal state.

Без этого summary остаётся hidden memory leak.

4. Cross-thread stores и embeddings требуют отдельного внимания

Особенно если агент использует:

  • semantic search over memories;
  • user profile memory;
  • long-term preferences;
  • store items with TTL refresh on read.

Нужно понимать:

  • где они физически лежат;
  • как удаляются;
  • как проверяется, что они больше не участвуют в retrieval;
  • не осталось ли derived caches.

5. Delete verification должна быть наблюдаемой

Полезно логировать:

  • delete request id;
  • affected memory classes;
  • completion status;
  • retries or partial failures;
  • time-to-effective-forget.

Последняя метрика особенно важна: как быстро память перестала влиять на behavior.

6. Что особенно часто ломают команды

Delete raw only

Derived artifacts остаются.

TTL refresh hides old memory forever

Store item постоянно продлевается чтениями и не исчезает.

No summary rebuild

Hidden influence продолжает жить.

No deletion audit

Непонятно, какие классы памяти были очищены.

No tenant offboarding path

Memory cleanup для B2B клиента размазан по разным системам.

7. Какие метрики полезны

Минимальный memory-deletion dashboard обычно включает:

  • delete request success rate;
  • time-to-effective-forget;
  • percent of summaries invalidated or rebuilt;
  • stale memory item count;
  • failed cleanup across stores and indexes;
  • tenant offboarding completeness.

Плюсы

  • Delete path снижает privacy и compliance risk в agent memory
  • Summary invalidation закрывает скрытый behavioral leakage
  • TTL плюс explicit delete дают более зрелый governance слой
  • Observability for deletion делает forget path проверяемым

Минусы

  • Память часто распределена по нескольким storage layers
  • Не всегда просто доказать, что derived influence полностью исчез
  • Summary rebuild и index cleanup добавляют complexity
  • Слишком агрессивное удаление может ухудшать user experience

Пример delete checklist

1. Delete raw conversation items
2. Invalidate or rebuild summary
3. Remove cross-thread store items
4. Remove memory embeddings / search records
5. Purge cached prompt fragments
6. Emit deletion audit event

Пример TTL config idea

{
  "checkpointer": {
    "ttl": {
      "strategy": "delete",
      "default_ttl": 43200
    }
  },
  "store": {
    "ttl": {
      "default_ttl": 10080
    }
  }
}

Практический совет: для agent memory полезнее задавать вопрос не "где мы храним память?", а "где она ещё может продолжать влиять на ответ после удаления?". Именно второй вопрос обычно открывает скрытые compliance gaps.

Проверьте себя

1. Почему delete raw messages недостаточно?

2. Что особенно недооценивают в forget path?

3. Какой anti-pattern особенно вреден?

Источники

  1. OpenAI API Docs - Conversation state
  2. LangGraph Memory
  3. LangGraph TTL
  4. LangGraph Data storage and privacy
Предыдущая
MCP в 2026: roadmap, governance и production maturity
Следующая
OpenAI Agents SDK