Логирование диалогов с ИИ: что хранить и что нельзя

MAATRIX

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

Зачем вообще логировать диалоги

Три причины, и они разного веса.

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

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

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

Дальше — конкретика: что из этого следует хранить, а что нет.

Что разумно хранить

Список короче, чем кажется на первый взгляд, но каждый пункт закрывает одну из трёх причин выше.

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

{
  "session_id": "a3f9c1e2-...",
  "turn": 4,
  "role": "user",
  "text": "Можно вернуть деньги за подписку, если не пользовался месяц?",
  "ts": "2026-08-20T11:42:03Z"
}

и следом — ответ ассистента тем же форматом с "role": "assistant".

Метаданные о контексте ответа. Это то, что превращает лог из простого чата в лог, по которому можно провести расследование:

• версия модели, которая генерировала ответ (gpt-4.1-mini-2026-04, claude-sonnet-4-20260514 и т.п.) — модели меняются, и через полгода вы должны точно знать, какая версия дала конкретный ответ;
• список источников, которые были подтянуты в контекст, если у ассистента есть RAG — не полный текст документов (об этом ниже), а идентификаторы: doc_id, номер версии документа, дата последнего обновления источника;
• системный промпт или его хеш на момент ответа — если промпты меняются часто, полезно хранить хотя бы контрольную сумму, чтобы можно было сопоставить с историей изменений промптов в репозитории;
• температура и другие параметры генерации, если они варьируются между сценариями.

Пример строки метаданных рядом с ответом:

{
  "session_id": "a3f9c1e2-...",
  "turn": 5,
  "role": "assistant",
  "text": "Да, возврат возможен в течение 14 дней с момента оплаты...",
  "model": "claude-sonnet-4-20260514",
  "prompt_hash": "sha256:7e2a...",
  "sources": [{"doc_id": "policy_returns_v3", "updated_at": "2026-06-01"}],
  "ts": "2026-08-20T11:42:07Z"
}

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

Таблица: что писать в лог, а что — только ссылкой

Что представляет неоправданный риск

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

Избыточные персональные данные, случайно попавшие в диалог. Пользователь спрашивает про возврат денег и по ходу упоминает, что он сейчас на больничном с депрессией, или диктует номер карты, потому что решил, что боту так проще проверить платёж. Это не имеет отношения к сути обращения — «можно ли вернуть деньги» — и хранить это в логе годами означает копить данные, утечка которых причинит пользователю реальный вред, при нулевой пользе для отладки или разбора инцидента. Если техническая возможность позволяет, такие фрагменты стоит маскировать до записи в лог: номера карт, паспортные данные, медицинские подробности — под регулярное выражение или классификатор PII, заменяющий их на [REDACTED] перед сохранением.

Полные копии чувствительных документов, переданных в контекст. Если ассистенту для ответа передали содержимое договора, медицинской карты или внутреннего регламента компании, соблазн — сохранить в логе весь этот текст «на всякий случай, вдруг пригодится для разбора». Не нужно: для разбора инцидента достаточно знать факт использования источника (doc_id, версия, дата) — сам документ и так лежит в исходном хранилище, откуда его в любой момент можно поднять с привязкой к нужной версии. Дублирование полного содержимого в каждом логе диалога, где документ был использован, размножает копии чувствительных данных без какой-либо дополнительной пользы, зато с дополнительной поверхностью для утечки — тем более если у логов более слабый контроль доступа, чем у исходного хранилища документов. Общий принцип того, как ассистент вообще становится каналом утечки, разобран в статье про утечку данных через ИИ-ассистента — накопление лишних копий в логах работает ровно по тому же механизму: чем больше мест, где лежит чувствительное содержимое, тем выше суммарный риск, даже если каждое отдельное место защищено вроде бы неплохо.

Итог этого раздела прост: логировать разговор — да, логировать всё, что через ассистента прошло, включая содержимое любых переданных документов — нет. Разница между «что было сказано» и «что было передано целиком» и есть граница разумного хранения.

Как определить разумный срок хранения

Логи диалогов с ИИ — не исключение из общего принципа: хранить нужно ровно столько, сколько данные реально нужны для целей, ради которых их собирали, а не «бессрочно на всякий случай». Бессрочное хранение не даёт дополнительной пользы сверх какого-то разумного окна, зато линейно увеличивает объём накопленных чувствительных данных и, соответственно, ущерб при возможной утечке.

Практический ориентир:

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

Статья про то, что хранить в логах по закону и сколько времени написана про технические логи серверов, но принцип соразмерности переносится без изменений: срок хранения должен быть обоснован конкретной целью, а не выбран «с запасом», потому что диск не жалко. На практике удобно сразу настроить автоматическое удаление логов диалогов старше установленного срока — например, через cron-задачу или встроенный TTL хранилища, а не полагаться на то, что кто-то вспомнит почистить логи вручную:

# пример: удаление логов диалогов старше 90 дней
find /var/log/ai-assistant/dialogs/ -name "*.jsonl" -mtime +90 -delete

Если логи лежат в базе данных, а не в файлах, тот же принцип реализуется через партиционирование по дате и регулярную задачу дропа старых партиций — так удаление не требует построчного сканирования и не создаёт нагрузку на боевую БД.

Анонимизация и маскирование там, где это возможно

Не все данные в логе одинаково нужны в исходном виде. Там, где сам факт события важнее конкретного значения, стоит маскировать:

• заменять явные идентификаторы пользователя (email, телефон) на внутренний user_id, а таблицу соответствия user_id → контактные данные хранить отдельно, с более узким доступом;
• применять regex- или классификатор-фильтр на потенциальный PII перед записью лога — номера карт, паспортов, адресов — заменяя найденное на плейсхолдер;
• для голосовых ассистентов — не хранить аудиозапись целиком, если достаточно транскрипта: аудио несёт дополнительную биометрическую информацию (тембр, эмоциональное состояние), которая для целей отладки ответов ассистента, как правило, не нужна.

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

Ограничение доступа к логам диалогов

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

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

На уровне инфраструктуры это можно закрыть ролевой моделью в самой СУБД или хранилище логов (отдельная роль с SELECT только на анонимизированное представление, а не на исходную таблицу) плюс отдельным сервисным аккаунтом для пайплайна аналитики, у которого нет прав на чтение персональных полей вообще.

Частые вопросы