Персональные данные в голосовом роботе

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

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

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

Правовая рамка

В 152-ФЗ обезличивание описывается как действия, после которых без дополнительной информации невозможно определить принадлежность персональных данных конкретному субъекту.

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

С 1 сентября 2025 года применяются новые требования и методы обезличивания, утвержденные приказом Роскомнадзора от 19.06.2025 № 140.

Какие методы применимы к роботу

Подход Как используется в голосовом роботе
Введение идентификаторов Персональные значения заменяются токенами: номер_договора, ФИО, адрес_подключения, баланс. Код хранит соответствие и восстанавливает значение только на этапе формирования ответа абоненту.
Изменение состава или семантики Абсолютные даты заменяются относительными, суммы могут искажаться контролируемым способом, а лишние атрибуты вообще не передаются в модель.
Декомпозиция Исходные данные, токены, журнал диалога и технические признаки хранятся раздельно. Модель получает только подготовленный безопасный контекст.
Защитные проверки в коде Критические действия не выполняются “по решению LLM”. Например, обещанный платеж, смена статуса услуги или расчет сложной суммы должны проходить через программный guard.

Пример: финансовая карточка абонента без передачи лишних данных в LLM

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

Как токены превращаются в ответ абоненту

Модель формирует ответ с токенами, а код перед синтезом аудио заменяет их на реальные значения внутри защищенного контура провайдера.

Деньги и ограничения
Поле Что делать Комментарий
баланс / доступная сумма Токен Передавать как “баланс”; код восстанавливает значение при генерации аудио.
сумма для включения Токен Передавать как “сумма_для_включения”; код подставляет реальное значение.
есть финансовое ограничение Признак Не требует обезличивания, если передается как булевый признак.
есть задолженность Признак Не требует обезличивания, если передается как булевый признак.
сумма задолженности Токен Передавать как “сумма_задолженности”.
Тариф
Поле Что делать Комментарий
название тарифа Без обезличивания Обычно не является персональными данными само по себе.
стоимость в месяц Без обезличивания Справочное значение тарифа.
стоимость на следующий месяц Без обезличивания Справочное значение тарифа.
справочник повышения тарифов Без обезличивания Общая справочная логика.
Платежи и операции
Поле Что делать Комментарий
банк платежа Токен Передавать как “банк_платежа”; при необходимости код восстанавливает значение.
дата платежа Относительная дата Абсолютную дату заменить на “сегодня”, “вчера”, “3 дня назад” и т.п.
сумма платежа Искажение значения Можно добавлять случайное смещение и корректировать ответ кодом после получения ответа LLM.
дата начисления Относительная дата Абсолютную дату заменить относительной.
сумма начисления Искажение значения Искажать контролируемо и корректировать кодом.
Обещанный платеж
Поле Что делать Комментарий
можно предложить Признак Не требует обезличивания.
доступная сумма Токен Передавать как “доступная_сумма”.
срок обещанного платежа Без обезличивания Обычно это правило продукта, а не данные конкретного человека.
уже использовался Признак Не требует обезличивания.
дата уже использованного Относительная дата Абсолютную дату заменить относительной.
сумма уже использованного Токен Передавать как “сумма_уже_использованного”.
Договор и клиент
Поле Что делать Комментарий
номер договора Токен Передавать как “номер_договора”.
логин личного кабинета Токен Передавать как “логин_личного_кабинета”.
пароль личного кабинета Не передавать в LLM Лучше вообще исключать из контекста модели; восстановление только внутри защищенного кода, если сценарий это допускает.
имя или организация Токен Передавать как “ФИО” или “название_организации”.
тип клиента Признак Физическое/юридическое лицо обычно можно передавать как категорию.
адрес подключения Токен Передавать как “адрес_подключения”; полный адрес не отдавать модели.
статус договора Признак Можно передавать как категорию статуса без идентифицирующих деталей.
Контакты и блокировки
Поле Что делать Комментарий
контакты провайдера Без обезличивания Общедоступные контакты провайдера.
добровольная блокировка активна Признак Не требует обезличивания.
причина блокировки Признак Передавать категорию причины без лишних деталей.
признак KTV-only Признак Не требует обезличивания; важен для запрета неуместных действий, например обещанного платежа для КТВ-only.

Сложные случаи закрывает код

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

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

  • расчет суммы к оплате за несколько месяцев;
  • прогноз, хватит ли текущего баланса до следующего списания;
  • расчет при смене тарифа внутри периода, о котором говорит абонент;
  • ответы, где нужно учитывать историю предыдущих обращений;
  • оформление обещанного платежа, смена статуса услуги и другие действия, которые должны проходить через программные проверки.
Набор таких обработчиков обычно быстро выявляется при просмотре транскриптов звонков “абонент – робот”. В реальных проектах сразу видно, где достаточно токенов, а где нужен отдельный расчет или защитный guard.

Какие вопросы можно закрывать с токенами

При корректной реализации токены позволяют закрывать большую долю типовых финансовых запросов без передачи персональных данных во внешнюю LLM:

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

Не все, что важно для закрытия звонков роботом, является персональными данными

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

Эта информация обычно не является персональными данными, но она во многом определяет качество клиентского опыта. Если робот не знает об аварии, он начинает вести абонента по стандартной диагностике: проверить кабель, роутер, питание, настройки. Формально сценарий работает, но для абонента он выглядит как “тупой робот”.

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

Вывод

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

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

Источники и нормативная база

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