Память ИИ-агента: как задать срок хранения, владельца и отзыв контекста

В понедельник агент помнит пятницу — и это уже решение о данных

В пятницу сервисная команда показала агента для разбора обращений. Он увидел переписку, карточку клиента и внутреннюю инструкцию, собрал черновик ответа и отметил, какие документы не хватает приложить. Чтобы не начинать каждый новый разговор с нуля, команда включила «память». В понедельник сотрудник открывает другое обращение и радуется: агент уже знает стиль ответа, помнит недавний спорный случай и быстро находит похожий договор.

Польза видна сразу. А вот вопрос обычно появляется позже: что именно агент теперь помнит, как долго и кто может это вернуть в следующий ответ? Слово «память» часто скрывает несколько разных объектов. Один живёт только пока идёт задача. Другой переживает сессию. Третий — фрагменты из базы знаний. Четвёртый — индекс для поиска. Пятый — кэш. Шестой — журнал событий. Если назвать всё одной настройкой, невозможно честно назначить срок, доступ и удаление.

В российском контексте это не только инженерная аккуратность. Статья 5 Федерального закона №152‑ФЗ требует обрабатывать персональные данные для конкретных, заранее определённых и законных целей; объём не должен быть избыточным, а идентифицируемое хранение не должно длиться дольше цели, если иной срок не установлен. Закон не описывает векторную БД и не сообщает, какой TTL поставить агенту. Но он не позволяет заменить цель словами «пусть будет полезно потом».

Мария здесь обычно задаёт приземлённый вопрос: если сотрудник закрыл обращение, что остаётся к следующему утру? Не «что ответит модель», а какие записи, индексы и копии всё ещё доступны. Если команда не может назвать их поимённо, будущая польза уже опережает управляемость.

Сначала назвать, что именно живёт после ответа

Техническая документация по агентным системам различает краткосрочную и долгосрочную память. Например, LangChain описывает краткосрочную память как состояние, ограниченное потоком или разговором, а долгосрочную — как записи, доступные между потоками в заданном namespace. Это не обязательная терминология для любой компании. Это удобное инженерное различение: область действия записи определяет, кто и когда может её прочитать.

Для паспорта памяти полезно развести минимум шесть классов.

1. Контекст задачи — история текущего обращения, промежуточный план, результаты инструментов и исключения. Ему часто нужен короткий срок: до завершения задачи, до истечения SLA или до ручного закрытия. Его задача — помочь не потерять ход работы, а не построить профиль человека.
2. Межсеансовая память — небольшой набор утверждённых фактов, которые нужны в новом потоке: например, язык общения или правило маршрутизации конкретной роли. Она опаснее обычной истории именно потому, что переживает разговор. Для неё нужны владелец, цель и отдельное правило пересмотра.
3. Источник знаний — документы, регламенты, записи CRM или другая система, из которой агент извлекает фрагменты. Это не «память модели» только потому, что модель увидела отрывок. У источника уже есть собственный владелец, доступ и правила хранения.
4. Индекс и эмбеддинги — производная структура, которая позволяет найти запись по смыслу. Она не нейтральна: по ней может проходить поиск и она может содержать содержательные признаки исходного материала. OWASP выделяет слабости векторов и эмбеддингов как самостоятельный риск для RAG-систем.
5. Кэш и очередь — временные копии, нужные ради скорости или асинхронной обработки. Они часто не попадают в первую диаграмму, зато переживают пользовательский интерфейс.
6. Журнал событий — доказательство того, что контекст создали, прочитали, изменили, заблокировали или удалили. Он не обязан повторять исходный текст. Его задача — сделать действие проверяемым.

Эти классы нельзя слить в одну таблицу «данные агента». Контекст задачи и журнал могут возникнуть в одном запросе, но отвечают на разные вопросы. Первый нужен, чтобы выполнить работу. Второй — чтобы позже проверить, кто и что сделал. Если хранить в журнале весь контекст «для удобства расследования», он превратится в ещё одну долгую память. Если не хранить журнал вообще, команда не докажет результат отзыва.

Четыре режима вместо одной кнопки «Memory»

Сравнение показывает важную альтернативу: полезная функция не всегда требует долгой памяти. Если агент отвечает на вопрос по действующему регламенту, безопаснее дать ему ограниченный поиск в источнике, чем записывать содержание документа в профиль пользователя. Если задача заканчивается после передачи черновика сотруднику, достаточно состояния потока. Межсеансовая память оправдана только там, где новый поток действительно потеряет необходимый факт и этот факт разрешено сохранять.

Это особенно важно для персональных и служебных данных. OWASP в разделе о раскрытии чувствительной информации напоминает, что контекст приложения может включать ПДн, финансовые сведения, коммерческие данные, учётные данные и документы. Рекомендация не превращается в российскую норму автоматически. Но причинная связь переносима: чем больше источников и долговечных копий доступно агенту, тем больше мест, где нужно подтвердить необходимость и ограничить доступ.

Память факта, память опыта и память правила — это разные риски

Полезно не останавливаться на сроке. У записи есть ещё содержательная роль. Факт отвечает на вопрос «что известно о человеке, организации или задаче»: предпочитаемый канал связи, статус договора, роль сотрудника, номер заявки. Опыт хранит след того, что агент или человек уже сделали: последовательность проверки, исключение, неудачную попытку вызова инструмента. Правило говорит, как действовать: системная инструкция, шаблон маршрутизации, порог эскалации.

В технической терминологии эти различия нередко называют семантической, эпизодической и процедурной памятью. Документация LangChain приводит близкое деление и отдельно отмечает, что долгие записи могут жить в namespace. Для руководителя ИБ важнее не название, а последствия. Факт о пользователе может быть персональными данными. Опыт может содержать чувствительный фрагмент документа или переписки. Правило может включать внутреннюю технологическую информацию. У них не совпадают ни владелец, ни основание доступа, ни разумный момент пересмотра.

Например, агент службы поддержки запоминает: «сотрудник предпочитает письменное подтверждение». Это факт, который может быть полезен в следующем обращении, но ему нужны цель, источник и периодический пересмотр. Запись «в прошлый раз API вернул ошибку в 09:14» — опыт, который нужен скорее команде сопровождения и не обязательно должен попадать в пользовательский профиль. Инструкция «не отправлять наружу черновик без подтверждения» — правило, которое должно храниться и изменяться по процессу управления конфигурациями, а не выводиться из случайного диалога.

Смешивание делает невозможным честный отзыв. Если профиль пользователя, системное правило и отладочная трассировка лежат в одном документе «memory», удаление одного фрагмента либо оставит лишнее, либо повредит работу агента. Поэтому паспорт должен содержать не только класс данных, но и роль записи: факт, опыт, правило или временное состояние. Это не дополнительная классификация ради таблицы. Она подсказывает, в какой контур должна идти запись и кто вправе инициировать её изменение.

Цель, владелец и срок появляются до первой записи

Срок хранения — не поле конфигурации, которое ИБ заполняет после запуска. Он является следствием трёх вопросов.

Какова цель? «Улучшать ответы» не годится как рабочая цель: она не говорит, какие сведения нужны и когда задача закончена. Лучше: «сохранить состояние проверки одного обращения до его закрытия» или «хранить согласованное языковое предпочтение пользователя для последующих обращений». Первая цель привязана к событию завершения, вторая — к отдельному пересмотру.

Кто владелец? Владелец — не обязательно администратор базы и не обязательно разработчик агента. Владелец процесса подтверждает, зачем память нужна. Владелец данных определяет допустимый состав и доступ. Технический владелец реализует TTL, поиск и удаление. ИБ или контрольная функция проверяет, что модель не оставляет неучтённую копию. Когда эти роли не названы, техническая команда неизбежно принимает бизнес-решение о том, что хранить.

Что запускает прекращение? Это может быть закрытие задачи, отзыв согласия при наличии такого основания, изменение роли пользователя, уход сотрудника, окончание договора, истечение установленного срока или явная отмена пользователем. Статья 21 152‑ФЗ описывает обязанности оператора при неправомерной обработке, уточнении, блокировании и уничтожении данных. Из этого не следует, что каждый сервис обязан стирать весь бэкап мгновенно. Следует другое: «скрыть в интерфейсе» нельзя считать доказательством прекращения обработки.

Ниже — минимальный паспорт. Его не нужно превращать в новую бюрократическую систему. Достаточно заполнить его для каждого типа памяти до того, как агент начнёт делать запись.

У такого паспорта есть и экономический смысл. Длинная история не только расширяет риск, но и увеличивает объём поиска, стоимость контекста и вероятность того, что агент достанет устаревший факт. Техническая документация LangChain прямо отмечает, что длинные истории ухудшают работу модели, увеличивают задержку и стоимость; это аргумент за отбор и забывание, а не только за хранение «на всякий случай». Но стоимость не является правовым основанием для срока. Она лишь помогает увидеть, что минимизация обычно полезна и для эксплуатации.

TTL полезен, но не заменяет событие и пересмотр

TTL — автоматическое истечение срока — хороший исполнитель решения, когда правило уже принято. Он умеет удалить запись через заданный период или сделать её недоступной. Но он не отвечает на три вопроса: почему срок именно такой, что делать при изменении роли и какие производные копии он охватывает. Если у профиля стоит 90 дней, а сотрудник сменил подразделение сегодня, технический счётчик не заменяет отзыв доступа по событию. Если индекс обновляется асинхронно, истечение в первичной БД не подтверждает, что поиск перестал возвращать фрагмент.

Практика поэтому использует два триггера. Первый — временной: запись пересматривается или истекает в установленную дату. Второй — событийный: закрытие задачи, смена роли, отзыв согласия в применимом сценарии, удаление исходного документа, прекращение договора, инцидент или ручное решение владельца. Для каждого триггера в паспорте нужен ожидаемый результат: только заблокировать выдачу, удалить первичную запись, поставить асинхронную задачу, изменить ключ шифрования или дождаться регламентного цикла резервной копии.

Именно здесь возникает граница между обещанием и доказательством. Фраза «данные удаляются через 30 дней» недостаточна, если неизвестно, от какой даты идёт отсчёт, что происходит при новой записи и как исключение отражается в журнале. Без этих деталей агент будет помнить либо дольше, чем ожидает владелец, либо непредсказуемо терять контекст посреди незавершённой задачи. Правило срока должно быть не просто числом, а проверяемым условием: «до закрытия обращения, но не более 14 дней после последнего обновления» или «до отзыва роли, затем блокировка retrieval немедленно и обработка копий по маршруту».

Доступ — до поиска, не после ответа

Ошибка часто выглядит так: команда разрешает агенту искать по широкому общему индексу, а затем пытается маскировать чувствительные слова в готовом ответе. Это поздняя граница. Если нерелевантный фрагмент уже извлечён и попал в контекст модели, произошло лишнее ознакомление системы с данными; к тому же фильтр ответа может пропустить смысловую или составную информацию.

Рабочий порядок другой:

1. пользователь и агентная операция получают проверяемую техническую идентичность;
2. retrieval-шлюз принимает запрос вместе с атрибутами роли, подразделения, типа задачи и контура;
3. политика отбирает допустимые источники и namespace до поиска;
4. поиск возвращает только разрешённые фрагменты;
5. журнал фиксирует запрос, класс источника и результат политики — без обязательного копирования всего содержания;
6. модель формирует ответ из уже допустимого набора.

Это не обещание, что ACL решит все риски. Неверная классификация или слишком широкая политика всё равно приведут к ошибке. Поэтому нужны сценарные проверки: может ли агент сотрудника подразделения А найти запись подразделения Б; возвращает ли поиск удалённую запись после истечения TTL; не остаётся ли старый фрагмент в кэше; что происходит при ошибке индекса.

Namespace не равен праву доступа

Многие хранилища позволяют разложить записи по namespace: пользователь, команда, проект, контур или тип памяти. Это нужная организационная граница. Она уменьшает вероятность случайно смешать записи разных потоков. Но один namespace сам по себе ещё не является политикой доступа. Если техническая идентичность агента имеет право искать во всех пространствах, логическое разделение останется только удобным именованием.

Поэтому для каждого namespace полезно определить пару: область записи и политика чтения. Первая отвечает, куда попадает новая память. Вторая — при каких атрибутах запрос может вернуть её модели. Атрибутами могут быть организация, подразделение, роль, конкретная задача, среда, тип данных и статус записи. Там, где такие атрибуты невозможно передать в retrieval-шлюз, безопаснее сузить функцию: оставить память только в одном потоке или отказаться от поиска по этому классу данных.

Это продолжает, а не повторяет матрицу полномочий. Права на инструмент отвечают, может ли агент изменить карточку. Права на память отвечают, может ли он увидеть прежний контекст перед тем, как вообще сформирует план. Если их спроектировать независимо, получается неприятная комбинация: агент не может отправить письмо, но может прочитать историю клиента, которой у текущего пользователя быть не должно. Ограничение действия после такой выдачи уже не исправляет лишний доступ.

Для проверяемости нужны отрицательные тесты. Создайте две записи с похожими словами, но разными атрибутами владельца. Попробуйте найти их из разрешённого и неразрешённого namespace. Затем отзовите одну запись и повторите поиск из всех путей, которые реально использует агент: прямой retrieval, фоновая суммаризация, кэшированный ответ, инструмент внутренней базы знаний. Результатом теста должно быть не «кажется, не нашёл», а конкретный код или запись в журнале о разрешении либо отказе.

Связь с опубликованным разбором НТА о доступах ИИ-ассистентов прямая, но темы не дублируются. Там матрица отвечает на вопрос, какое действие агент вообще может выполнять. Здесь — что остаётся доступным после действия и как эта доступность прекращается. Общий сервисный токен опасен в обеих задачах, но память добавляет новый объект контроля: производную копию контекста.

Отзыв — это маршрут, а не кнопка

Самое неудобное место в любой схеме — удаление. В интерфейсе запись можно скрыть одним действием. В архитектуре она могла успеть попасть в первичную БД, очередь асинхронной обработки, векторный индекс, кэш ответа, трассировку и резервную копию. Поэтому «удалили карточку» — это начало проверки, а не её конец.

Маршрут отзыва стоит проектировать как последовательность с наблюдаемыми результатами.

1. Найти корневой идентификатор. У записи должен быть стабильный идентификатор, который связывает первичный объект, индекс и журнал. Нельзя опираться только на текст запроса: он может повториться или уже измениться.
2. Остановить новую выдачу. Сначала политика или статус записи блокирует retrieval. Это уменьшает окно, в котором память ещё возвращается, пока фоновые задачи очищают копии.
3. Обработать первичную запись и производные. Удаление или недоступность выполняются в первичном хранилище, индексе, кэше и очереди согласно их контрактам. Для каждого компонента фиксируется результат, а не просто запуск задачи.
4. Учесть восстановление. Если копия попала в резерв, в паспорте должен быть указан режим: исключение из будущих восстановлений, криптографическое прекращение доступа или очистка при регламентном цикле. Нельзя обещать физическое стирание резервной копии быстрее, чем позволяет её доказуемый процесс.
5. Записать итог в журнал. Журнал хранит метаданные события: что отозвано, кто инициировал, какие компоненты обработаны, где есть отложенный регламентный шаг и как проверить результат. Сам журнал тоже классифицируют: он не должен тайно повторять полный контекст.

Приказ Роскомнадзора №179 устанавливает требования к подтверждению уничтожения персональных данных. Для автоматизированной обработки в предусмотренных случаях важна выгрузка из журнала регистрации событий. Это не повод подменить архитектуру одной выгрузкой. Это ясный сигнал: при уничтожении недостаточно намерения; нужен артефакт, который подтверждает выполненное действие. Для агентной памяти разумно применить тот же инженерный принцип шире — фиксировать результат по каждому компоненту маршрута, не выдавая это за универсальное требование приказа к любому логу.

Здесь помогает опыт соседней темы — обезличивания тестовых данных. Скрыть прямой идентификатор недостаточно, если осталась практическая связь к человеку. Аналогично удалить основную карточку недостаточно, если агент всё ещё находит связанный фрагмент по индексу. В обоих случаях вопрос не в красивом слове «удалено», а в маршруте к исходному объекту.

Что именно должно остаться в журнале

Журналирование легко превратить в противоположность минимизации: записывать полный prompt, ответ модели и все извлечённые документы «на случай расследования». Такой лог сам становится самым удобным долговечным хранилищем контекста. Он может оказаться доступнее первичных систем и пережить правила удаления, ради которых процесс вообще строился.

Поэтому журналу нужен собственный паспорт. Обычно для расследования достаточно метаданных: идентификатор записи или хэш, класс памяти, инициатор, техническая идентичность, операция, время, результат политики, идентификаторы обработанных компонентов и ссылка на согласованный инцидент или запрос. Полный текст стоит сохранять только если есть отдельная цель, владелец, срок и ограниченный доступ. Если без текста расследование невозможно, это нужно проговорить как компромисс, а не оставить скрытой настройкой трассировки.

Приказ №179 важен не перечнем полей для любой системы, а самой дисциплиной подтверждения: при автоматизированной обработке в его сфере подтверждение уничтожения связано с журналом регистрации событий. Для агентной архитектуры это означает простой контрольный вопрос: можно ли по журналу показать, что маршрут отзыва был запущен, какие компоненты подтвердили результат и где есть предусмотренное отложенное действие? Если нельзя, команда знает о намерении удалить, но не знает о результате.

Наконец, журнал должен быть читаем тем, кто проверяет процесс, но не доступен модели как обычная база знаний. Агенту не нужно извлекать из него старые обращения ради ответа пользователю. Иначе ретроспективное доказательство превращается в новый неограниченный источник контекста.

Когда память не надо сохранять

Есть соблазн решить проблему сложным lifecycle management. Иногда правильнее отказаться от памяти.

Не сохраняйте запись между сессиями, если агент может заново получить актуальный факт из разрешённого источника. Не переносите в долгую память текст договора, если достаточно хранить идентификатор и каждый раз проверять доступ к первоисточнику. Не используйте общий пользовательский профиль для временного исключения в одной задаче. Не оставляйте «обучающие примеры» из рабочих обращений без отдельного решения о составе, доступе и сроке.

Если пилот только проверяет полезность сценария, начните с нулевой или потоковой памяти. Это не шаг назад. Это способ отделить пользу от ранней архитектурной привычки. NIST AI RMF полезен здесь как метод управления: сначала определить контекст, роли и меру риска, затем выбрать управляемую меру. Он не заменяет российское право и не говорит, какой продукт покупать. Но он дисциплинирует порядок: не «сначала включим всё», а «сначала назовём, что контролируем».

Три сценария выбора

Сценарий 1: помощник по одному обращению. Агент читает текущую заявку, готовит черновик и передаёт его сотруднику. После закрытия заявки задача не продолжается. Здесь разумный старт — память потока с событием закрытия. Межсеансовый профиль не добавляет необходимой пользы, поэтому его не создают. Проверка проста: после закрытия поиск по идентификатору заявки не возвращает рабочий контекст, а журнал фиксирует завершение.

Сценарий 2: помощник с устойчивой настройкой пользователя. Пользователь явно подтвердил, что агент может сохранять предпочитаемый формат отчёта. Это не даёт права хранить всю переписку, документы или историю решений. В паспорте создаётся один узкий факт, владелец процесса подтверждает необходимость, задана дата пересмотра, а пользовательский namespace не доступен другим сотрудникам. При смене роли или отзыве настройки запускается маршрут отзыва именно этой записи.

Сценарий 3: агент ищет по внутренней базе знаний. Долгой памяти пользователя может не быть вообще. Агент каждый раз получает фрагменты из действующей базы по политике доступа. В таком сценарии главный контроль — ACL перед retrieval, актуальность источника и обработка индекса при удалении документа. Он сложнее технически, но часто честнее: компания не дублирует знания в профиль только ради удобства модели.

Эти сценарии нельзя оценить одной шкалой «больше памяти — умнее агент». У первого меньше остаточный след. У второго есть ограниченная межсеансовая польза. У третьего важнее управляемый источник и поиск. Выбор зависит от конкретного результата процесса, а не от названия продукта.

Перед запуском полезно зафиксировать и отрицательное решение: какие данные агент не будет сохранять. Это могут быть полные тексты документов, реквизиты, разовые эмоциональные оценки, вложения, системные секреты, токены и результаты инструментов, которые нужны только до следующего шага. Такой список даёт команде понятный критерий для ревью: новая функция памяти не проходит молча вместе с очередной интеграцией. Она либо попадает в существующий паспорт, либо получает новый владелец, цель, срок и маршрут отзыва.

Матрица проверки перед запуском

Перед расширением памяти возьмите один агентный сценарий и отметьте строки ниже. Если в строке нельзя назвать владельца, срок или маршрут отзыва, это не повод придумать значение. Это повод оставить память выключенной или ограничить её потоком, пока решение не появится.

Тест понедельником

В ближайший рабочий день выберите один закрытый поток агента. Не открывайте новую платформу и не переписывайте весь RAG. Просто пройдите по паспорту: что было записано, кто это может найти после закрытия, какой срок назначен, где лежит индекс, что останется в кэше и какая запись подтвердит отзыв. Если на один из вопросов можно ответить только «наверное, в базе», память ещё не стала управляемой частью процесса.

Полезный агент не обязан помнить всё. Ему нужно помнить ровно то, что требуется для следующего разрешённого действия, и уметь доказуемо забыть остальное. Тогда память перестаёт быть эффектом демонстрации и становится обычным, проверяемым элементом корпоративной системы.

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.