Чат-бот на базе языковой модели собирает имена, телефоны и запросы клиентов — это персональные данные, и работа с ними попадает под 152-ФЗ. Закон требует согласия человека, хранения данных на серверах в России и понятной цели сбора. Разберём по шагам, что бизнес обязан сделать перед запуском бота, какие данные стоит передавать модели, а какие держать под замком. Текст носит ознакомительный характер, итоговую проверку доверьте юристу.
Что требует закон
152-ФЗ обязывает бизнес получить согласие клиента на обработку данных, хранить эти данные на серверах в России, объявить цель сбора и обеспечить их защиту. Чат-бот собирает имя, телефон и запрос — значит, это полноценный оператор персональных данных. Перед запуском нужны согласие в боте, политика обработки и понимание, какие данные уходят в языковую модель.
Когда клиент пишет боту имя и телефон, чтобы записаться на услугу, бизнес становится оператором персональных данных по 152-ФЗ. Это статус с обязанностями: получить согласие, объяснить цель сбора, защитить данные и хранить их там, где требует закон. Многие запускают бота, забыв про эту часть, и узнают о требованиях уже после жалобы клиента или проверки.
Закон выделяет несколько ключевых обязанностей оператора. Первое — согласие: человек должен ясно подтвердить, что согласен на обработку своих данных для конкретной цели. Второе — локализация: первичный сбор и хранение данных россиян идёт на серверах внутри страны. Третье — цель и объём: вы собираете только то, что нужно для услуги, и используете данные строго по объявленной цели. Четвёртое — защита: данные под паролем, доступ ограничен.
Отдельный слой появляется, когда бот работает на языковой модели. Текст клиента уходит на обработку, и важно понимать, где физически находится сервер модели и что с данными происходит дальше. Зарубежная модель без корректного доступа и без хранения в России создаёт прямой риск по локализации. Поэтому выбор модели — это вопрос удобства, а часть юридической архитектуры бота.
- Согласие клиента на обработку данных для конкретной цели
- Политика обработки персональных данных, доступная клиенту
- Хранение данных россиян на серверах внутри страны
- Защита данных: ограниченный доступ, пароли, журнал действий
Перед запуском
Подготовка идёт от документов и архитектуры, а от самого бота. Сначала вы решаете, какие данные собираете и зачем, где они хранятся и какая модель их обрабатывает. Только потом запускаете бота клиентам. Обратный порядок — сперва бот, потом документы — оставляет бизнес без правовой опоры и под риском штрафа.
- Опишите, какие данные собирает бот и для какой конкретной цели
- Подготовьте политику обработки данных и текст согласия, проверьте их у юриста
- Встройте в бота шаг согласия: клиент подтверждает обработку до отправки данных
- Выберите модель и хранилище так, чтобы данные россиян оставались внутри страны
- Ограничьте доступ к данным: пароли, роли, журнал, минимум собранных полей
- Проверьте маршрут данных: куда уходит текст клиента и где он оседает
Подготовьте политику обработки данных и текст согласия вместе с юристом, встройте шаг согласия в бота. Это база, без которой остальное теряет смысл. Клиент видит понятный текст, подтверждает обработку, и только после этого бот принимает его имя и телефон.
Что отдавать модели
Главное правило простое: модели уходит минимум данных, нужный для ответа. Для типового вопроса про адрес и часы работы личные данные клиента вообще лишние. Для записи на услугу боту достаточно имени и телефона, и эти поля стоит обрабатывать с особой осторожностью. Чем меньше чувствительных данных проходит через модель, тем ниже риск и проще защита.
| Тип данных | Можно ли отдавать модели | Как защитить |
|---|---|---|
| Вопрос про услугу, часы, адрес | Да, личные данные тут лишние | Обезличенный запрос без имени и телефона |
| Имя и телефон для записи | С осторожностью, по минимуму | Модель внутри страны, хранение в России, согласие |
| История заказов клиента | Только при явной необходимости | Доступ по ролям, корректный доступ к модели |
| Паспорт, медданные, платежи | Лучше держать вне модели | Отдельное защищённое хранилище, согласие на особые данные |
Особые категории — здоровье, биометрия, иногда платёжные реквизиты — требуют отдельного согласия и усиленной защиты. Такие данные через языковую модель лучше вообще пропускать: бот собирает их в защищённое хранилище, а модель работает с обезличенным запросом. Для клиники, банка или страховой это критично, и здесь часто выбирают локальную модель внутри контура компании.
Российский бизнес выбирает между отечественной моделью с хранением в стране и зарубежной через корректный доступ. Отечественные решения снимают часть вопросов по локализации сразу. Зарубежная модель требует отдельной проработки: где сервер, как оформлен доступ, что с трансграничной передачей. Конкретная схема зависит от типа данных и отрасли — это тема, которую мы разбираем на разборе процессов вместе с юристом.
Риски и штрафы
Нарушение 152-ФЗ грозит оборотными штрафами, которые для бизнеса ощутимы, а при утечке данных суммы растут. Точные размеры и составы меняются, поэтому актуальные цифры уточняйте у юриста и в действующей редакции закона. Важнее другое: штраф — это лишь часть риска. Утечка данных клиентов бьёт по репутации сильнее любой суммы, и вернуть доверие тяжело.
Текст согласия, политика обработки, оценка трансграничной передачи и работа с особыми категориями данных — это зона юриста. Технику бота и маршрут данных настраивает внедренец, правовую рамку держит специалист по праву. Этот текст помогает понять картину, заменяет он консультацию по вашей конкретной ситуации.
Модель добавляет свой риск поверх юридического. Она ошибается уверенно и способна выдать клиенту чужие данные, если бот спроектирован небрежно и тянет в ответ лишнее из базы. Это свойство языковых моделей называют галлюцинациями. Защита здесь техническая: модель видит только данные текущего клиента, доступ к чужим записям закрыт на уровне архитектуры, а на уровне просьбы в промпте.
- Запуск бота без согласия и политики обработки данных
- Хранение данных россиян на зарубежных серверах без локализации
- Передача особых категорий данных в зарубежную модель без проработки
- Архитектура, где модель видит данные всех клиентов сразу
Главная защита — собрать правовую и техническую рамку до запуска, а после. Юрист готовит документы и оценивает передачу данных, внедренец строит бота так, что модель получает минимум и только по текущему клиенту. Когда обе части на месте, бот приносит пользу без юридического хвоста. Полезно раз в квартал пересматривать схему: меняются и закон, и модели, и набор собираемых данных.
Куда двигаться
Правильный порядок такой: сначала вы определяете цель и объём данных, готовите согласие и политику с юристом, выбираете модель и хранилище под требования локализации, и только потом запускаете бота клиентам. Так бизнес получает пользу от автоматизации и остаётся в правовом поле. Это занимает время на старте, зато снимает риск штрафа и утечки.
Заодно компания выстраивает культуру работы с данными. Сотрудники понимают, что собирать, что отдавать модели, а что держать под замком. Этот навык остаётся с бизнесом: когда вы добавляете новый бот или новую услугу, схема уже понятна и переносится без долгой проработки с нуля.
Сложность здесь на стыке права и техники. Юрист видит требования закона, внедренец видит архитектуру бота, и важно свести две картины в одну рабочую схему. Самый частый провал — бизнес запускает бота быстро, собирает данные без согласия и хранит их где попало, а узнаёт о требованиях после жалобы. На разборе процессов мы вместе с юристом смотрим на вашу схему и выстраиваем её безопасно.