Политика удаления промптов и ответов по типам задач

Почему один срок хранения не работает

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

Если поставить один срок на все, команда быстро упрется в крайности. Короткий срок мешает разбору инцидентов и споров с пользователями. Длинный срок тянет за собой лишние персональные данные, лишние копии в логах и больше ручного контроля.

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

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

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

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

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

Что именно вы храните

Проблемы начинаются не с удаления, а с учета. Во многих командах все называют "логами", хотя внутри лежат разные данные с разным риском. Пока вы не разделите их заранее, политика удаления промптов и ответов останется только в документе.

Обычно в системе есть как минимум четыре слоя: текст промпта, ответ модели, вложения и служебные метаданные. К вложениям относятся PDF, сканы, таблицы, изображения и фрагменты документов. К метаданным - время запроса, модель, токены, стоимость, request ID, теги маршрутизации и коды ошибок.

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

Отдельно пометьте поля с персональными данными и поля после маскирования. Это не одно и то же. Если номер телефона скрыт в логах как "+7***", исходное значение все еще может жить во вложении, в резервной копии или в экспортном CSV. Для 152-ФЗ и хранения данных это принципиальная разница: нужно точно знать, где лежит исходник, где маска, а где только технический след запроса.

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

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

Если вы работаете через RU LLM, часть служебных данных уже отделена на уровне запроса: есть маскирование PII, журналы аудита, а логи и бэкапы хранятся в РФ. Но внутреннюю карту хранения это не отменяет. Иначе вы удалите промпт из одного места, а через месяц найдете тот же текст в старом экспорте отдела аналитики.

Поддержка: храните до конца разбора случая

В поддержке полный текст диалога нужен не всегда, но во время разбора без него трудно. Оператору надо видеть, что клиент уже пробовал, какую ошибку получил, что ответил бот и где разговор свернул не туда. Если удалить переписку слишком рано, команда начнет заново задавать одни и те же вопросы, а клиенту придется повторять детали.

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

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

Персональные данные лучше маскировать еще до записи в лог. Не "почистим потом", а сразу. Телефон, почту, номер договора, паспортные поля, адрес и свободный текст с PII стоит скрывать на входе. Так риск ниже и у оператора, и у тех, кто потом смотрит журналы.

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

Если компания уже использует RU LLM, маскирование PII и аудит-трейлы можно добавить в каждый запрос без переписывания клиентского кода: команды просто меняют base_url на api.rullm.com и продолжают работать со своими SDK и промптами. Это удобно, но срок хранения все равно нужно описать отдельно внутри процесса поддержки.

Аналитика: оставляйте цифры, а не сырой текст

Для аналитики почти никогда не нужен полный текст каждого запроса и ответа. Команде важно понять другое: о чем спрашивают пользователи, где модель ошибается и какой процент ответов действительно помогает.

Если хранить сырой текст месяцами "на всякий случай", база быстро превращается в склад лишних данных. Риск растет, а пользы мало. Для задач аналитики лучше сначала выделить признаки и метрики, а исходные запросы удалить раньше.

Чаще всего достаточно темы запроса или класса задачи, типа ошибки, доли успешных ответов по сценарию, времени ответа, числа токенов и стоимости. Такой набор дает рабочую картину без лишнего доступа к чувствительному содержимому. Для 152-ФЗ и хранения данных это обычно более разумный путь: вы не собираете в хранилище больше персональных данных, чем нужно.

Сырые запросы и ответы иногда все же нужны, но только для разбора сбоев. Здесь лучше держать небольшую выборку и короткий срок. Например, 0,5-1% проблемных диалогов на 7-14 дней часто достаточно, чтобы понять, почему модель спутала поля в анкете или неверно поняла формулировку в отчете.

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

Если вы строите такую схему через шлюз вроде RU LLM, ее удобно заложить сразу в контур логирования: служебные шаблоны и пользовательские данные не смешиваются, а маскирование PII и журналы аудита уже встроены в запросы. Аналитикам проще работать, а команде, которая отвечает за хранение логов ИИ, проще доказывать, что лишний текст не лежит без причины.

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

Обработка документов: привяжите срок к процессу

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

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

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

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

Финальные реквизиты живут по правилам процесса, а не по сроку технического лога. Если запись о выплате должна храниться пять лет, ее и нужно хранить пять лет. Но это не значит, что промпт, полный ответ модели и скан приложения должны лежать столько же.

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

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

Как выбрать срок хранения для каждой задачи

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

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

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

Дальше лучше назначить не абстрактный срок, а событие удаления. Это работает надежнее, чем формула вроде "храним 90 дней на всякий случай". Для чата поддержки таким событием будет закрытие тикета и окончание окна для апелляции. Для отчета - выпуск финальной версии и проверка цифр. Для анкеты или файла - конец проверки, онбординга или согласования.

Потом проверьте, где данные остаются после удаления. Команды часто чистят основную таблицу и забывают про логи, трассировку, кэш и бэкапы. Если у вас есть OpenAI-совместимый шлюз вроде RU LLM, смотрите на всю цепочку: приложение, прокси, журналы аудита и резервные копии в РФ. Иначе на бумаге срок есть, а по факту данные лежат дольше.

Для каждого сценария нужен владелец. Обычно это не абстрактная "безопасность", а конкретная роль: руководитель поддержки, владелец аналитической системы, продуктовый менеджер или DPO. Рядом стоит поставить дату пересмотра. Раз в квартал или после изменения процесса этого обычно достаточно.

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

Пример для банка: чат поддержки, отчеты и анкеты

В банке три похожих на вид запроса дают совсем разный след в хранении данных. Если назначить для них один срок, команда либо держит лишнее, либо удаляет данные слишком рано и ломает процесс.

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

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

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

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

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

Где команды ошибаются чаще всего

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

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

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

Отдельная проблема - логи вне основной системы. Если запрос идет через API-шлюз, прокси и внешнего провайдера моделей, срок жизни данных нужно проверять на каждом слое. Иначе у вас одна политика на бумаге и совсем другая в реальном пути запроса.

Часто слабое место вскрывает простой вопрос внутреннего аудита: когда именно вы удалили запись и чем это подтверждается? Если система не показывает дату, тип удаленных данных и источник события, доказать соблюдение политики почти невозможно. Запись "удалено" без следа операции никого не убедит.

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

У банка это выглядит очень буднично. Команда убрала диалог клиента из CRM, но тот же текст остался в логах шлюза и в ночном бэкапе. Через месяц приходит запрос от комплаенса, а показать полное удаление уже нельзя.

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

Быстрая проверка перед запуском

Перед запуском полезно проверить не только модель и качество ответов, но и путь данных после каждого запроса. Проблемы обычно начинаются не в генерации текста, а в логах, отладке и ручных разборах, где промпты лежат дольше, чем кто-то планировал.

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

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

Где обычно всплывает ошибка

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

Еще одна типичная ошибка - хранить полный текст "на всякий случай". На старте это кажется удобным, но потом временный режим становится постоянным. Если без текста можно обойтись, лучше сохранить сам факт запроса, тип задачи, время, модель, стоимость и итоговый статус. Для многих команд этого хватает, чтобы считать расходы, искать сбои и проходить аудит.

Что делать дальше

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

Хороший первый шаг - выбрать один сценарий, а не весь контур LLM сразу. Опишите путь данных от запроса до логов, бэкапов и выгрузок, назначьте срок хранения и точное событие удаления, затем закрепите, кто проверяет удаление и где это видно.

Начинать лучше с тестовых данных. Возьмите один чат поддержки или один пакет анкет, прогоните его через весь путь и проверьте, где текст остается жить после обработки. Часто команда удаляет запись в приложении, но забывает про системные логи, экспорт в BI, тикеты в help desk и резервные копии. Тогда правило на бумаге есть, а удаление данных по типам задач по факту не работает.

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

Если команде нужен пилот внутри РФ, проще брать среду, где эти требования не нужно собирать по частям. RU LLM дает единый OpenAI-совместимый эндпоинт, хранит логи и бэкапы на серверах в РФ и уже включает маскирование PII и журналы аудита на уровне запросов. Для пилота это удобно: можно сменить base_url, не менять SDK и быстро проверить, как ваша матрица сроков работает в реальном процессе.

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