Персональные данные в чат-боте: основания обработки, хранение и передача в AI

Имя, телефон, адрес доставки, ID в мессенджере и история обращений могут быть персональными данными. Бизнесу важно знать не только, что запрашивает бот, но и куда попадает сообщение: в CRM, журнал ошибок, резервную копию или внешний AI-сервис. Одна кнопка согласия не описывает весь этот путь.

Ниже — практический подход к проектированию такого процесса. Юридические источники проверены 28 сентября 2026 года; материал помогает подготовить требования к системе и вопросы юристу, но не заменяет индивидуальную юридическую консультацию.

Какие данные нужно учитывать

Персональными могут быть и данные без имени, если по ним можно установить конкретного человека. Например, ID пользователя, связанный с заказами, или текст обращения с адресом. Определение и основания обработки объясняет Уполномоченный Верховной Рады по правам человека.

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

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

Закон Украины, GDPR и законопроект №8153

Украинский закон и GDPR имеют собственные условия применения. Для украинского бизнеса базовым актом является Закон №2297-VI. GDPR может дополнительно применяться, в частности, к обработке в контексте деятельности учреждения в ЕС либо к предложению товаров или услуг людям в ЕС либо мониторингу их поведения там. Самого гражданства клиента или доступности бота из ЕС недостаточно для такого вывода. Критерии разъясняет EDPB в рекомендациях по статье 3 GDPR.

На дату проверки официальная карточка №8153 показывает подготовку ко второму чтению; принятие за основу состоялось 20 ноября 2024 года. Перед релизом проверьте статус повторно. Не закладывайте в договор дату вступления в силу, которая ещё не установлена.

Согласие, уведомление и цель обработки

Сначала определите законное основание для каждой цели; согласие — одно из возможных оснований. Законодательство предусматривает и другие основания, в частности связанные с исполнением сделки или законной обязанности. Кнопка «Согласен» сама по себе не делает любой сбор данных правомерным. Для GDPR смотрите объяснение Еврокомиссии о законных основаниях.

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

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

Семь решений для архитектуры бота

Юридические требования нужно превратить в проверяемые правила системы. Решения ниже — инженерные рекомендации; конкретный набор зависит от рисков и процессов компании.

1. Минимум полей. Запросите контакт для обратной связи, а детали заказа — только на соответствующем шаге. Каждое обязательное поле должно иметь объяснение.
2. Отдельные роли. Менеджер видит нужные ему обращения; выгрузка всей базы доступна только определённым сотрудникам. Проверьте доступ бывших работников.
3. Проверка доступа к документу. Владение номером или ID мессенджера не доказывает право читать любую запись CRM. Для чувствительных действий нужна проверка полномочий.
4. Контроль интеграций. Зафиксируйте разрешённые поля для каждого API. Не передавайте весь профиль там, где достаточно номера заявки.
5. Защищённые секреты. Храните ключи API отдельно от контента и пользовательских сообщений; ограничивайте права служебных учётных записей.
6. Журналы без лишнего содержимого. Для диагностики часто достаточно ID операции, времени и кода ошибки. Полный текст сообщения не должен автоматически попадать в каждый лог.
7. Управляемое удаление. Назначьте ответственного и проверьте, что команда удаления доходит до всех нужных систем, а не только убирает строку из админ-панели.

Маппинг полей и обработку ошибок стоит оформить вместе со схемой интеграции чат-бота с CRM. Распределение доступа к данным описано также в типовом порядке обработки Уполномоченного.

Сроки хранения и запросы пользователей

У всех данных бота нет одного универсального срока хранения. Согласуйте сроки с учётом цели, необходимости и законных обязанностей; для GDPR это отражено в принципе ограничения хранения.

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

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

Мессенджеры, хранилище и AI-провайдеры

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

Для документов лучше спроектировать авторизованный кабинет и минимальное уведомление в чате. Сами названия «Mini App» или «защищённая ссылка» ничего не гарантируют: проверьте авторизацию, срок действия ссылки и доступ другого пользователя.

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

Определите, хранит ли поставщик запросы, кто имеет доступ, используются ли они для обучения, как работает удаление и где происходит обработка. При международной передаче данных отдельно проверьте её правовые условия. Вопросы договоров с процессорами и передачи за пределы ЕС объясняет Еврокомиссия. Технические угрозы рассмотрены в материале о безопасности AI-чат-ботов.

Что проверить перед запуском

Проверку лучше проходить на тестовых данных вместе с владельцем процесса, техническим специалистом и юристом:

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

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

Вывод

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

Частые вопросы

Источники

• Закон Украины «О защите персональных данных» №2297-VI
• Уполномоченный: определения, основания обработки и права человека
• Официальная карточка законопроекта №8153
• EDPB: территориальная сфера применения GDPR
• Еврокомиссия: законные основания обработки
• Еврокомиссия: принципы GDPR
• Еврокомиссия: обязанности организаций
• Уполномоченный: типовой порядок обработки персональных данных