Чек‑лист: как проверить бота на соответствие 152‑ФЗ

В комментариях к предыдущему посту вы спрашивали про чек‑листы для самопроверки бота - подготовил практический вариант.

Если бот принимает заявки, телефоны, email, username, файлы, заказы, сообщения клиентов или передает данные в CRM/аналитику/ИИ - он почти наверняка работает с персональными данными.

Сохраняйте и проходите по пунктам 👇

1. 1️⃣ Что собирает бот

   • ☐ Есть список всех данных, которые получает бот: имя, телефон, email, Telegram ID, username, текст диалога, файлы, заказ, UTM‑метки.
   • ☐ Для каждого поля понятно, зачем оно нужно.
   • ☐ Бот не собирает данные «на всякий случай».
   • ☐ История переписки хранится только если она реально нужна для поддержки, сделки или качества сервиса.
   • ☐ Если бот принимает документы, медданные, данные детей, финансы или биометрию - проведена отдельная правовая оценка.

2. 2️⃣ Правовое основание

   • ☐ Понятно, на каком основании идет обработка: заявка, договор, согласие, законная обязанность.
   • ☐ Для маркетинговых рассылок есть отдельное согласие.
   • ☐ Согласие на рассылку не спрятано внутри согласия на обработку заявки.
   • ☐ Пользователь может отказаться от рассылки.
   • ☐ Факт согласия фиксируется: дата, время, ID пользователя, текст согласия, источник.

3. 3️⃣ Что видит пользователь

   • ☐ До отправки данных пользователь видит понятное уведомление.
   • ☐ Есть ссылка на Политику обработки персональных данных.
   • ☐ В политике указаны оператор, цели, категории данных, сроки хранения, получатели данных и права пользователя.
   • ☐ В политике отражены CRM, аналитика, рассылки, helpdesk, ИИ‑сервисы, если они используются.

   Нажимая «Отправить», вы соглашаетесь на обработку персональных данных в целях обработки заявки и связи с вами. Оператор: [компания]. Подробнее: [ссылка на политику].

4. 4️⃣ Локализация базы

   • ☐ Первичная база персональных данных граждан РФ находится в РФ.
   • ☐ Вы знаете, где физически хранятся база бота, CRM, логи, файлы, бэкапы и история чатов.
   • ☐ Зарубежная CRM или таблица не является единственным местом хранения клиентской базы.
   • ☐ Если данные уходят в зарубежный сервис, проверена трансграничная передача.
   • ☐ Резервные копии и логи тоже проверены на место хранения.

5. 5️⃣ CRM и подрядчики

   • ☐ Есть схема потока данных: бот → backend → БД → CRM → аналитика → ИИ.
   • ☐ В CRM передаются только нужные поля.
   • ☐ В CRM не уходит весь чат, если достаточно имени и телефона.
   • ☐ С CRM, интегратором или разработчиком оформлено поручение на обработку персональных данных.
   • ☐ В поручении указаны цели, данные, действия, меры защиты, сроки и порядок удаления.
   • ☐ Запрещены неучтенные выгрузки в Google Sheets, Notion, Airtable и личные таблицы менеджеров.

6. 6️⃣ Аналитика и реклама

   • ☐ В аналитику не передаются ФИО, телефон, email и полный текст сообщений.
   • ☐ События содержат минимум данных: источник, кампания, действие, обезличенный ID.
   • ☐ Cookie, пиксели, ретаргетинг и сквозная аналитика отдельно проверены.
   • ☐ Пользователь информирован о трекинге, если он используется.
   • ☐ Срок хранения аналитических событий ограничен.

   Плохо:

   lead_created: Иван, +7..., email

   Лучше:

   lead_created: source, campaign, anonymous_id

7. 7️⃣ ИИ‑сервисы

   • ☐ В ИИ не отправляется весь диалог без фильтрации.
   • ☐ Перед отправкой маскируются телефон, email, ФИО, адрес, документы.
   • ☐ Проверено, использует ли ИИ‑провайдер данные для обучения.
   • ☐ Включены no training / no retention, если доступны.
   • ☐ ИИ‑логи хранятся ограниченный срок.
   • ☐ В чувствительных сценариях ответ ИИ проверяет человек.
   • ☐ Зарубежный ИИ‑API проверен на трансграничную передачу.

8. 8️⃣ Доступы и безопасность

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

9. 9️⃣ Сроки хранения и удаление

   • ☐ Для каждого типа данных установлен срок хранения.
   • ☐ Отдельно определены сроки для лидов, чатов, логов, файлов, ИИ‑запросов и бэкапов.
   • ☐ Есть процесс удаления по истечении срока.
   • ☐ Есть процесс удаления или блокировки по запросу пользователя.
   • ☐ Удаление происходит не только в боте, но и в CRM, рассылках, аналитике, helpdesk и ИИ‑логах.
   • ☐ Результат удаления фиксируется.

10. 1️⃣0️⃣ Запросы и инциденты

    • ☐ Есть канал для обращений по персональным данным.
    • ☐ Назначен ответственный за такие запросы.
    • ☐ Понятно, как найти, уточнить, заблокировать или удалить данные.
    • ☐ Есть план действий при утечке или несанкционированном доступе.
    • ☐ Команда знает, кого уведомлять внутри компании.

Быстрая оценка

0–3 «нет» - базово все неплохо, нужен регулярный аудит.

4–7 «нет» - есть заметные риски, лучше доработать процессы.

8+ «нет» - бота не стоит масштабировать без юридической и ИБ‑проверки.

Главное правило:

цель → минимум данных → база в РФ → контролируемые интеграции → договоры → доступы → сроки хранения → удаление → аудит

Если хотите заказать бота, который изначально проектируется с учетом 152‑ФЗ, CRM, аналитики и ИИ‑интеграций - напишите мне в личные сообщения или оставьте заявку через моего бота‑помощника.

Разберем задачу, схему данных и подскажем, как сделать автоматизацию без хаоса в персональных данных.