Персональные данные попадают в диалог с ботом всегда — независимо от того, спрашивает он их или нет. Достаточно того, что клиент пишет «это Ирина Петровна, заказ на Хабаровскую 14, перезвоните на 900…», и вся конструкция «у нас бот не собирает персональные данные» перестаёт существовать. Поэтому вопрос ставится не «есть ли у нас персональные данные», а «где они лежат, кто их видит и что из них уходит за периметр компании».
Хорошая новость в том, что большая часть требований закрывается архитектурой и делается один раз: маскирование перед отправкой в модель, ограниченный срок хранения журнала, разграничение доступа, обезличенный корпус для тестов. Плохая — в том, что оставшаяся часть закрывается только документами, и никакая настройка их не заменяет: согласие, поручение обработки подрядчику и провайдеру модели, политика обработки. Ниже разобрано, что к какой категории относится.
Оговорка о жанре. Мы инженерное бюро и разбираем тему со своей стороны: какие данные куда физически уходят, что настраивается технически и как сделать процедуру повторяемой. Формулировки согласия, состав политики и квалификацию конкретного случая обязан посмотреть юрист — мы прямо помечаем такие места по ходу текста. Модельный проект тот же, что и в остальных материалах раздела: клиентский агент на базе знаний из 150 страниц, поток около 6 000 обращений в месяц. Ставки: инженер 3 000 ₽/час, руководитель 2 500 ₽/час, методист базы знаний 900 ₽/час, оператор поддержки 700 ₽/час.
Что реально лежит в месячной выгрузке диалогов
Первое, что стоит сделать перед любым разговором о защите, — выгрузить месяц диалогов и посчитать, что там есть на самом деле. Обычно результат расходится с ожиданиями руководителя в два раза, причём в обе стороны: телефонов меньше, чем казалось, а сведений, которые клиент выдал сам, — заметно больше.
| Что встречается в диалоге | Диалогов из 6 000 | Доля | Откуда берётся |
|---|---|---|---|
| Номер заказа или договора | 4 700 | 78 % | Сценарий спрашивает сам — это главный ключ к клиенту |
| Имя или ФИО | 3 700 | 62 % | Клиент называет сам либо подставляется из профиля канала |
| Телефон | 2 600 | 43 % | Просят при передаче оператору и при уточнении доставки |
| Адрес доставки | 900 | 15 % | Тема доставки и переноса заказа |
| Фото или скан документа | 240 | 4 % | Клиент присылает сам, даже когда его об этом не просят |
| Сведения о здоровье, льготах, семье | 180 | 3 % | Обоснование возврата, отмены, переноса записи |
| Реквизиты карты | 60 | 1 % | Клиент отправляет по своей инициативе вопреки предупреждению |
Две нижние строки — самые неприятные. Их немного, но они переводят диалог в другую категорию чувствительности, и решение о том, что с ними делать, принимается не в момент инцидента, а заранее. Рабочее правило: всё, что клиент прислал сам сверх сценария, должно уметь удаляться из журнала одной операцией, а не поиском по базе руками.
Горизонтальная столбчатая диаграмма, семь полос, ось X — количество диалогов от 0 до 5 000, у каждой полосы подпись с числом и долей: «Номер заказа — 4 700 (78 %)», «Имя или ФИО — 3 700 (62 %)», «Телефон — 2 600 (43 %)», «Адрес — 900 (15 %)», «Фото документа — 240 (4 %)», «Здоровье, льготы, семья — 180 (3 %)», «Реквизиты карты — 60 (1 %)». Три нижние полосы выделены другой заливкой и подписаны сбоку «клиент прислал сам, сверх сценария». Общая подпись сверху: «месяц работы агента, 6 000 обращений». Чертёжный стиль, всё по-русски.
Требования 152-ФЗ, переведённые в устройство бота
Закон написан не про ботов, поэтому его требования приходится переводить на язык архитектуры. Полезнее всего разложить их в таблицу с третьей колонкой: закрывается это настройкой или бумагой. Настройку делает инженер за понятные часы, бумагу — юрист, и путать их дорого в обе стороны.
| Требование | Что это значит для агента на практике | Чем закрывается |
|---|---|---|
| Базы данных с персональными данными россиян размещены в России | И журнал диалогов, и векторное хранилище, и очередь сообщений физически в РФ — включая тестовый контур, про который забывают чаще всего | Архитектурой: выбор площадки и провайдера модели |
| Обработка на законном основании, с согласием там, где оно требуется | Текст согласия доступен из чата ссылкой, факт и время фиксируются в журнале вместе с версией текста | Документом плюс небольшой настройкой |
| Цели обработки определены и не расширяются молча | Диалог, собранный для обслуживания клиента, не уезжает автоматически в обучающую выборку и в маркетинговые рассылки | Архитектурой: разные хранилища под разные цели |
| Обработка подрядчиком — по поручению | Поручение оформляется и с интегратором, и с провайдером модели, если запросы уходят к нему; в нём перечень данных, действий и срок | Только документом |
| Срок хранения ограничен, данные уничтожаются | У журнала есть срок жизни и автоматическое удаление по расписанию, а не «храним всё на всякий случай» | Архитектурой |
| Права субъекта: доступ, уточнение, удаление | Поиск всех диалогов клиента по телефону или номеру заказа и удаление одной операцией, включая вложения и резервные копии | Архитектурой плюс регламентом |
| Трансграничная передача — по отдельным правилам | Запрос к зарубежной модели — это передача за границу, даже если её делает российский агрегатор от вашего имени | Архитектурой, а если решение принято — документами и уведомлением |
Боевой контур обычно собирают аккуратно, а тестовый разворачивают «на пару недель» и оставляют на годы: там боевая выгрузка диалогов, широкие доступы у половины команды и нулевое журналирование. Формально это такая же база персональных данных со всеми вытекающими требованиями. Правильный порядок — обезличенная копия для тестов и запрет на выгрузку боевого журнала на ноутбуки, и это ровно та работа, которую можно сделать один раз за 6–8 часов.
Зарубежная модель: почему это трансграничная передача
Когда агент отправляет запрос в модель, он отправляет не «обезличенный смысл вопроса», а текст диалога целиком — вместе с именем, номером заказа и всем, что клиент написал до этого. Если модель находится за пределами России, этот текст физически покидает страну, и обычная клиентская переписка становится трансграничной передачей персональных данных со всеми сопутствующими требованиями.
Российский или околороссийский сервис-посредник, который принимает оплату в рублях и переправляет ваши запросы в зарубежную модель. По состоянию на сентябрь 2026 года прямая оплата OpenAI и Anthropic из России невозможна, поэтому такие посредники распространены. Важно понимать конструкцию: договор у вас с посредником, данные уходят к провайдеру, договора с которым у вас нет, а перед клиентом за всю цепочку отвечаете вы. Подробнее маршрут запроса и его узлы разобраны в материале про приватность запросов к языковой модели.
Практический вывод простой: для клиентского контура берётся модель, размещённая в России. Это либо российская платформа — GigaChat, YandexGPT и их корпоративные версии, — либо открытая модель на своём сервере. Второй вариант снимает вопрос трансграничной передачи полностью, но у него своя экономика, и она сходится не у всех: расчёт порога есть в разборе локальной модели под 152-ФЗ. Зарубежные модели остаются пригодны для задач без персональных данных — например, для черновиков текстов, — и это стоит записать в политике прямым списком, а не оставлять на усмотрение сотрудника.
Карта связей. Слева узел «Клиент в мессенджере». Дальше «Прослойка компании» — крупный блок, внутри него три подписанных элемента: «поиск клиента по телефону», «маскирование ПД», «журнал диалогов, 90 дней». Из прослойки две стрелки вправо: верхняя — к узлу «Модель в России (GigaChat, YandexGPT, своя на сервере)» с подписью на стрелке «текст с масками», нижняя, штриховая и перечёркнутая, — к узлу «Зарубежная модель через агрегатора» с подписью «трансграничная передача». Вокруг всей левой части пунктирная рамка «контур в РФ». Внизу подпись: «маска ставится до отправки, снимается после ответа». Всё по-русски, чертёжный стиль.
Маскирование до отправки: что заменяется и чем это оплачивается
Маскирование — это подстановка меток вместо персональных данных перед отправкой текста в модель и обратная подстановка настоящих значений в готовый ответ. Модель видит «Здравствуйте, это [имя], мой заказ [номер]», формулирует ответ вокруг меток, а клиент получает нормальный текст с настоящим именем. Работает это не всегда одинаково хорошо, и честнее сразу сказать, где именно ломается.
| Что в диалоге | Заменяется | Что происходит с качеством ответа |
|---|---|---|
| Имя, отчество, фамилия | Да, на метку с восстановлением в ответе | Не меняется: имя нужно только в приветствии |
| Телефон, e-mail | Да, полностью | Не меняется: агент их не анализирует, а передаёт |
| Номер заказа и договора | Нет, но это внутренний идентификатор, а не данные о человеке | Ответ без номера теряет смысл — вместо маски ограничивают доступ |
| Адрес | Частично: дом и квартира скрываются, город остаётся | Слегка падает: расчёт срока доставки требует хотя бы города |
| Свободный текст жалобы | Только распознанные сущности | Здесь и живут пропуски: имя внутри цитаты маска не всегда ловит |
| Фото и сканы | Не отправляются в модель вообще | Такие диалоги сразу уходят человеку — это отдельное правило |
Месячная строка почти ничего не стоит именно потому, что не создаёт новой работы: те же 300 диалогов — это 5 % потока, которые и так читают в рамках выборочного контроля качества, просто к чек-листу добавляется один пункт. Как устроен сам контроль и почему сплошной просмотр перестаёт работать после 1 500 обращений — разбирали в материале про выборочный контроль диалогов.
Отдельно стоит решить, что делать с теми 240 диалогами в месяц, где клиент прислал фото или скан документа. Правило простое и не имеет исключений: вложения в модель не отправляются вообще. Такой диалог помечается и уходит человеку, файл сохраняется в отдельное хранилище с ограниченным доступом и своим сроком жизни, а в журнале остаётся ссылка, а не сам файл. Попытка «на всякий случай прогнать документ через распознавание» — самый частый способ получить паспортные данные там, где их быть не должно, и обнаружить это через год при разборе хранилища. Если распознавание документов действительно нужно процессу, это отдельный контур со своими требованиями, а не побочная функция клиентского бота.
Заменив имя меткой, вы не превратили диалог в обезличенные данные: у вас остаётся таблица соответствия, по которой всё восстанавливается за секунду, и номер заказа, который ведёт к конкретному человеку. Маскирование сокращает объём данных, уходящих третьей стороне, и это его единственная задача. Оно не отменяет ни согласия, ни поручения обработки, ни требований к сроку хранения — и подрядчик, который утверждает обратное, ошибается.
Журнал диалогов: срок, доступ, обезличивание, удаление
Журнал нужен обязательно: без него нельзя ни разобрать инцидент, ни измерить качество, ни доказать, что агент сказал именно то, что сказал. Но журнал с персональными данными — это база, которая живёт по правилам, и правила эти проще заложить сразу, чем вводить на втором году эксплуатации, когда там уже 150 000 диалогов.
- 1Горячий журнал — 90 дней
Полные диалоги с персональными данными, доступ у дежурного инженера и руководителя поддержки. Девяносто дней покрывают почти все разборы инцидентов и претензий: в модельном проекте на 6 000 обращений в месяц это около 18 000 диалогов в хранилище. Срок стоит согласовать с юристом под ваши цели обработки, а не копировать из статьи.
- 2Обезличенный корпус — дальше
После 90 дней диалог проходит обезличивание и переезжает в корпус для аналитики и тестов: имена, телефоны и адреса вычищаются, остаются формулировки вопросов и то, как агент отвечал. Именно этот корпус используют для регрессных наборов и для обучения новых сценариев, а не боевую выгрузку.
- 3Разграничение доступа
Оператор видит диалоги своей очереди, руководитель — все за период, аналитик — только обезличенный корпус, подрядчик — то, что записано в поручении, и не больше. Каждое обращение к журналу само пишется в отдельный лог: без этого невозможно ответить на вопрос, кто именно смотрел карточку клиента.
- 4Запрос на удаление — минуты, а не совещание
Поиск всех диалогов клиента по телефону и по номеру заказа, удаление вместе с вложениями и обновление резервных копий. Закон даёт на это короткий срок, измеряемый рабочими днями, поэтому процедура должна быть механической. При потоке 6 000 обращений в месяц таких запросов приходит немного — обычно 3–5, — но каждый из них при неготовой системе съедает день инженера.
- 5Уничтожение по расписанию
Удаление выполняется заданием по календарю и оставляет след: что удалено, сколько записей, когда. Ручное «мы почистили» не считается, потому что не проверяется. Заодно это единственный способ не обнаружить через два года, что резервные копии хранят всё с первого дня.
Горизонтальная лента времени с тремя зонами. Зона 1 «0–90 дней: горячий журнал» — подписи «полные диалоги, около 18 000 записей», «доступ: дежурный инженер, руководитель поддержки». Зона 2 «после 90 дней: обезличенный корпус» — подписи «имена, телефоны, адреса вычищены», «используется для тестов и регрессных наборов». Зона 3 «уничтожение по расписанию» — подпись «задание по календарю, остаётся след: что и когда удалено». Над лентой отдельная вертикальная стрелка в любую точку с подписью «запрос на удаление: 3–5 в месяц, выполняется за минуты». Чертёжный стиль, всё по-русски.
Документы: что подписывается и с кем
Это та часть, которую нельзя закрыть настройкой. Минимальный комплект для компании с клиентским агентом состоит из четырёх документов, и все четыре появляются не после запуска, а до первой выгрузки диалогов подрядчику.
- 1Согласие клиента там, где оно требуется под вашу цель обработки. В чате оно даётся ссылкой на текст, а факт, время и версия текста пишутся в журнал. Формулировку и саму необходимость согласия под конкретную цель определяет юрист.
- 2Поручение обработки подрядчику. Перечень данных, перечень действий, требования к защите, срок. Отдельная статья про то, как отличить рабочее поручение от пустышки, у нас есть — поручение обработки данных подрядчику.
- 3Поручение или эквивалентное условие с провайдером модели, если запросы уходят к нему. Здесь чаще всего выясняется, что договора нет вовсе — потому что доступ куплен через посредника.
- 4Политика обработки персональных данных, в которой упомянут сам факт использования ИИ-помощника в клиентских каналах и цели, ради которых он читает переписку. Это тот пункт, который проверяющий находит первым, потому что политика публична.
Сравнение в две колонки. Левая «Закрывается настройкой — 34 часа, 102 000 ₽»: размещение баз в России, маскирование перед отправкой в модель, срок жизни журнала 90 дней, разграничение доступа, удаление по запросу одной операцией, обезличенная копия для тестов. Правая «Закрывается только документом»: согласие клиента, поручение обработки подрядчику, поручение или условие с провайдером модели, политика обработки, внутренняя политика использования ИИ. Под правой колонкой подпись «работа юриста, до первой выгрузки данных». Под левой — «работа инженера, до запуска». Чертёжный стиль, всё по-русски.
Что изменилось с 1 сентября 2026 года
С 1 сентября 2026 года действуют требования к обработке персональных данных в системах с ИИ и к маркировке ИИ-контента. Подробный разбор изменений — в материале о том, что меняется в работе с ИИ с сентября. Для клиентского агента практический минимум добавляет к описанному выше три вещи.
- Собеседник представляется роботом в первом же сообщении. Помимо требований это снимает часть претензий: человек, который знает, что перед ним машина, осторожнее относится к её словам — и, что важно для этой темы, реже присылает лишние документы.
- Внутренняя политика использования ИИ на две-три страницы: какие сервисы разрешены, какие данные в них можно класть, кто отвечает за проверку результата. Состав документа мы разбирали в материале про политику использования ИИ в компании.
- Ответственность за то, что бот сказал клиенту, остаётся на компании, и персональные данные здесь не исключение. Это тема соседнего материала — кто отвечает за ошибку ИИ-агента; здесь важно только то, что утечка из журнала и выдуманная скидка разбираются одним и тем же порядком.
Когда весь этот контур избыточен
Полный набор нужен не каждому проекту, и в трёх ситуациях мы сами советуем остановиться на сокращённом варианте.
- Агент отвечает только на общие вопросы и не видит клиента. Нет поиска по CRM, нет номера заказа, диалог не связывается с человеком — тогда из всего описанного нужны только российская площадка и срок хранения журнала. Это 8–10 часов вместо 34.
- Внутренний бот по регламентам для сотрудников. Персональные данные там тоже есть, но это данные работников, а не клиентов, и они обычно уже покрыты кадровыми документами. Центр тяжести смещается к разграничению доступа: кто из сотрудников какие документы может достать через бота.
- Пилот на обезличенных данных. Если на первом этапе агент работает с выгруженным и вычищенным корпусом, а живых клиентов не видит, то маскирование и поручения появляются не в пилоте, а на границе выхода в эксплуатацию. Единственное, чего нельзя делать, — считать, что раз пилот прошёл без документов, то и боевой запуск пройдёт.
И общая рекомендация напоследок. Из всего перечисленного дороже всего обходится не построить контур, а перестроить его на работающей системе: маскирование, вписанное в уже готовые обработчики, обходится примерно вдвое дороже заложенного заранее, а разбор двухлетнего журнала без сроков хранения — это отдельный проект. Тридцать четыре часа на старте — заметно меньше, чем стоимость одного разговора с проверяющим о том, где именно лежат ваши данные.
Персональные данные в диалоге появляются сами. Управлять можно только тем, что уходит дальше и сколько живёт.
