Отзыв согласия на обработку данных в продукте с LLM

Что меняется после отзыва согласия

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

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

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

На согласии обычно держатся такие действия:

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

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

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

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

Какие функции отключают сразу

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

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

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

Команды часто забывают про побочные потоки данных. После отзыва нельзя:

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

Это касается и внешних подрядчиков, и внутренних пайплайнов. Если запрос идет через единый LLM-шлюз, проверять нужно не только основной вызов модели, но и все боковые отправки: трассировку, A/B-тесты, разметку, ручной разбор саппортом. Именно там данные нередко продолжают жить еще недели после того, как в интерфейсе уже все выключено.

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

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

Что команда может оставить

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

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

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

На практике обычно оставляют следующее:

• факт отзыва и служебные метки по нему;
• журнал действий для споров и внутренних проверок;
• антифрод-сигналы отдельно от пользовательского контента;
• срок хранения для каждой категории;
• доступ только для тех ролей, кому это действительно нужно.

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

В системах с LLM это особенно заметно. Если команда использует API-шлюз вроде RU LLM, можно сохранить технический audit trail по запросу и факт применения маскирования PII, но не держать исходный текст диалога дольше, чем требует задача. Такой подход проще объяснить с точки зрения 152-ФЗ и он заметно снижает риск: при проверке у вас есть след действий системы, а лишних персональных данных в логах нет.

Как отделить сервис от контроля

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

Проверяйте основание по каждой функции

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

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

Храните только то, что можете объяснить

Хорошая проверка простая: сможете ли вы объяснить юристу, инженеру и службе безопасности, зачем после отзыва хранится каждый атрибут. Если ответ расплывчатый, атрибут лучше убрать. Для 152-ФЗ это особенно важно, потому что LLM быстро собирает лишние персональные данные прямо в переписке.

Полезно держать одну короткую таблицу и обновлять ее при каждом релизе:

Если инфраструктура уже умеет маскировать PII и писать audit trail по каждому запросу, провести границу проще. В RU LLM такие метки и маскирование встроены в поток запроса, поэтому команда может оставить факт действия и причину проверки, а не весь текст диалога.

Порядок действий

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

Обычно процесс выглядит так:

1. Сначала проверьте, кто подал запрос. Сверьте аккаунт, почту, номер договора, историю входа и канал обращения. Если запрос пришел с нового адреса или через саппорт без авторизации, запросите подтверждение личности.
2. Затем соберите карту данных по человеку. Ищите не только запись в основной базе, но и память чата, историю сессий, логи запросов к модели, prompt cache, очереди задач, аналитические выгрузки, резервные копии и тестовые стенды.
3. Сразу поставьте статус отзыва в профиле или в отдельном реестре. После этого продукт должен прекратить персонализацию, маркетинговые сценарии, фоновую переиндексацию, повторную отправку данных в модель и любые джобы, которые создают новые копии.
4. Отдельно проверьте обучающие и оценочные наборы. Если диалоги пользователя попадали в датасеты по согласию, уберите эти записи из следующих прогонов и из рабочих выборок. Если данные уже вошли в модель и вы не можете откатить это сразу, зафиксируйте ограничение и не используйте новые данные этого человека.
5. В конце оформите запись о результате. Укажите, что вы отключили сразу, что сохранили, где это лежит, кто принял решение и на каком основании.

Если у вас LLM идет через отдельный API-шлюз, проверьте и этот слой. Там часто остаются технические логи, маскированные поля, audit trails и признаки злоупотребления. Для аудита и антифрода их можно хранить дальше, но только в минимальном объеме и с понятным сроком.

Пример: чат-ассистент в личном кабинете

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка перед релизом

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

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

Минимальная проверка перед релизом включает пять точек:

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

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

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

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

Что сделать заранее

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

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

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

• Для памяти чата ставят статус "off" и чистят данные по правилам продукта.
• Для аналитики оставляют только анонимные события или полностью останавливают сбор.
• Для обучения моделей и ручного разбора качества запрещают использовать данные этого пользователя.
• Для антифрода и аудита хранят только утвержденный минимум и сразу задают срок удаления.

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

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

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