ИИ и персональные данные по 152‑ФЗ: почему нельзя вставлять CRM в случайный чат
Какие маркетинговые данные требуют проверки, чем псевдонимизация отличается от обезличивания и как оценить поставщика AI.
Фраза "ИИ и персональные данные 152 ФЗ" стала практической проблемой маркетинга. Сотрудник берёт выгрузку лидов, вставляет её в нейросеть и просит найти сегменты. Через минуту он получает аккуратную таблицу. Но компания может не знать, куда ушли данные, сколько они хранятся, кому доступны и было ли основание передавать их поставщику.
Запретить сотрудникам все AI-инструменты проще, чем разобраться, но такой запрет обычно обходят. Надёжнее разделить сценарии по данным, закрепить разрешённые инструменты и построить маршрут проверки. Эта статья объясняет рабочую логику, но не заменяет заключение юриста и специалиста по информационной безопасности для конкретной системы.
Начните не с нейросети, а с карты данных
Возьмите один сценарий, например анализ обращений поддержки. Запишите:
- какие поля используются;
- откуда они получены;
- для какой цели собирались;
- на каком основании обрабатываются;
- где хранятся;
- кто имеет доступ;
- какой поставщик получит данные;
- где происходит обработка;
- когда данные удаляются;
- какой результат возвращается.
Без этой карты невозможно оценить ни договор, ни локализацию, ни трансграничную передачу. Фраза "мы отправляем только текст" ничего не доказывает: в тексте обращения могут быть имя, телефон, номер заказа, адрес и сведения о здоровье.
Персональные данные — это не только паспорт
Закон определяет персональные данные широко: это информация, относящаяся к прямо или косвенно определённому физическому лицу. В маркетинговой работе сюда могут попадать:
- имя и контакты;
- идентификатор клиента;
- история покупок;
- запись звонка;
- текст обращения;
- IP-адрес и онлайн-идентификаторы в конкретном контексте;
- должность вместе с компанией и контактами;
- фотография;
- сведения о предпочтениях, если они связаны с человеком.
Отдельно существуют специальные категории и биометрические данные, для которых действуют дополнительные требования. Не пытайтесь решить классификацию по одному чек-листу из интернета. Если сценарий касается здоровья, национальности, политических взглядов, религии, интимной жизни или биометрии, подключайте профильных специалистов до пилота.
Псевдонимизация не всегда означает обезличивание
Замена имени на client_1842 уменьшает риск, но если компания сохраняет таблицу соответствия или может определить человека по остальным полям, данные могут оставаться персональными.
Пример: из выгрузки удалили имя, но оставили точную дату, небольшой город, должность и редкую покупку. Человека может определить сотрудник или внешний получатель, сопоставив сведения с другими источниками.
Для исследовательского пилота безопаснее использовать синтетические примеры. Если требуется реальная статистика, агрегируйте данные: категории обращений, частота темы, диапазон чека. Проверяйте, нужна ли модели каждая строка, или задачу можно решить внутри защищённого контура до обращения к AI.
Цель обработки не появляется после покупки сервиса
Закон № 152‑ФЗ устанавливает условия обработки в статье 6. Конкретное основание зависит от сценария: согласие, исполнение договора, обязанность по закону и другие предусмотренные случаи.
Нельзя рассуждать так: "у нас уже есть база клиентов, поэтому её можно использовать для любой аналитики". Сопоставьте новую операцию с целью, которую компания сообщила человеку и закрепила в документах. Если нейросеть строит профиль для рекламного воздействия, это отличается от краткого суммирования обращения для исполнения заявки.
Для прямых контактов с потенциальным потребителем средствами связи статья 15 предусматривает предварительное согласие. Оператор должен уметь доказать, что оно получено. AI не меняет это правило.
Поставщик AI может стать лицом, обрабатывающим данные по поручению
Если компания передаёт данные внешнему сервису, одной ссылки на его политику конфиденциальности может быть недостаточно. Часть 3 статьи 6 описывает содержание поручения обработки: перечень данных и операций, цели, конфиденциальность, меры защиты, документы по запросу и уведомление об инцидентах.
Перед договором выясните:
| Вопрос | Зачем он нужен |
|---|---|
| Кто является стороной договора? | определить получателя и юрисдикцию |
| Какие данные получает сервис? | ограничить объём поручения |
| Используются ли они для обучения? | понять дальнейшие цели |
| Сколько хранятся запросы и ответы? | настроить сроки и удаление |
| Есть ли субподрядчики? | увидеть полный маршрут |
| Где находятся базы и обработка? | проверить локализацию и передачу |
| Как сообщается об инциденте? | связать реакции сторон |
| Как подтвердить удаление? | завершить обработку |
Ответственность перед субъектом не исчезает после передачи подрядчику. Закон прямо сохраняет её за оператором.
Локализация и трансграничная передача — разные проверки
Часть 5 статьи 18 устанавливает требование при сборе персональных данных граждан России использовать для записи, систематизации, накопления, хранения, уточнения и извлечения базы данных на территории России, кроме предусмотренных законом исключений.
Трансграничная передача регулируется статьёй 12. До её начала оператор должен направить отдельное уведомление Роскомнадзору и выполнить предусмотренную законом оценку получателя. Порядок зависит от государства и обстоятельств передачи.
Наличие российской первичной базы не означает, что последующая отправка данных иностранному AI-сервису больше не требует анализа. И наоборот, сам доступ к иностранному сайту ещё не доказывает передачу персональных данных: нужно смотреть фактический запрос и архитектуру.
Публичные данные не становятся свободными для любых целей
Если человек разместил телефон на сайте или в социальной сети, это не даёт компании автоматического права собрать его, обогатить профиль и запустить рассылку. Доступность источника и законность дальнейшей обработки — разные вопросы.
Для маркетингового исследования можно анализировать публикации организаций, обезличенные агрегаты и открытые отраслевые материалы. Но массовый сбор профилей физических лиц, объединение источников и вывод чувствительных характеристик требуют отдельной оценки.
Не просите модель "найти все контакты руководителей и написать им персональные письма", пока не определены источник, основание и правила коммуникации. Техническая возможность скрейпинга не создаёт права на обработку.
Разделите сценарии на зелёные, жёлтые и красные
Пример внутренней классификации:
Зелёная зона
Публичные тексты компании, обезличенные брифы, черновики статей, синтетические данные, инструкции без секретов. Их можно обрабатывать в утверждённых сервисах по общим правилам.
Жёлтая зона
Внутренние документы, коммерческие условия, обезличенные обращения, агрегированная аналитика. Нужны разрешённый контур, ограниченные права и проверка владельца данных.
Красная зона
CRM-выгрузки, записи звонков, переписка с идентификаторами, паспортные сведения, данные о здоровье, биометрия, секреты доступа. Отправка во внешний сервис блокируется до отдельного решения юриста и безопасности.
Цвет не является юридической квалификацией. Это операционный предохранитель, который помогает сотруднику не принимать рискованное решение за пять секунд.
Промпт тоже нужно считать каналом утечки
Персональные данные попадают не только в основное поле запроса. Проверьте:
- имена файлов;
- URL и query-параметры;
- системные сообщения;
- журналы приложения;
- тексты ошибок;
- инструменты наблюдаемости;
- историю чата;
- вложения;
- кеши и резервные копии.
Удаление имени из документа не поможет, если файл называется жалоба_Иванова_паспорт.pdf. API-ключ нельзя помещать в промпт или клиентский код. Запросы и ответы должны логироваться так, чтобы журнал помогал расследованию, но не создавал вторую неконтролируемую базу.
Использование данных для обучения проверяется по продукту и тарифу
Не переносите условия корпоративного API на личный аккаунт или стороннюю оболочку. У одного поставщика могут различаться чат для физических лиц, бизнес-пространство, API и интеграция через партнёра.
OpenAI указывает, что данные бизнес-продуктов и API по умолчанию не используются для обучения, а GigaChat сообщает аналогичное для запросов и ответов API. Эти заявления важны, но не заменяют проверку договора, хранения, локализации и соответствия российскому праву.
Фиксируйте дату изучения условий и ссылку на документ. Поставщики меняют продукты, а старый скриншот не доказывает текущий маршрут данных.
Человеческая проверка нужна до запроса и после ответа
До отправки сотрудник проверяет допустимость набора данных. После получения результата он ищет:
- раскрытие исходных идентификаторов;
- восстановление удалённых сведений;
- необоснованные выводы о человеке;
- дискриминационные сегменты;
- ошибочное объединение клиентов;
- персональные данные в публичном материале.
Если модель суммирует обращения, итог может содержать редкую деталь, по которой автора легко узнать. Агрегированный отчёт тоже нужно читать перед распространением.
Редакционный контроль AI-контента разобран в статье с чек-листом перед публикацией.
Подготовьте сценарий инцидента до запуска
Команда должна знать, что делать, если в сервис отправили запрещённую выгрузку или ответ раскрыл данные. Минимальный сценарий:
- Остановить интеграцию и повторные запросы.
- Сохранить технические факты без расширения утечки.
- Уведомить ответственного за персональные данные и безопасность.
- Определить состав, объём, субъектов и получателей.
- Связаться с поставщиком по договорному каналу.
- Выполнить юридически необходимые действия и сроки.
- Исправить причину, а не только удалить один файл.
Не обещайте сотрудникам, что за своевременное сообщение обязательно накажут. Страх скрывает инциденты до момента, когда исправить их сложнее.
Как Система ограничивает работу с данными
«Система» разделяет типы контента и не применяет тяжёлый аудит статьи к короткому посту. Для данных принцип похож: публичные продуктовые факты можно использовать в редакционных сценариях, а клиентские сведения требуют отдельного разрешённого контура и правил.
Роли определяют, кто загружает источники, утверждает факты и публикует материал. Журнал сохраняет маршрут задачи. Перед передачей модели данные можно минимизировать, а рискованные категории блокировать до проверки.
Но платформа не выдаёт юридическое основание сама. Она не знает, как именно компания получила согласие, если это не отражено в системе, и не может признать набор обезличенным одним нажатием. Настройки реализуют решение оператора, юриста и безопасности; они не заменяют это решение.
Сравнить требования к поставщикам и тарифам поможет статья о выборе сервиса ИИ для маркетинга. Архитектурные компромиссы разобраны в материале о единой платформе и наборе сервисов.
Практический старт на одну неделю
Не начинайте с полной CRM. Выберите один публичный или синтетический сценарий. Назначьте владельца, опишите входные поля, используемый сервис, срок хранения и проверку результата.
Параллельно составьте реестр AI-инструментов, которыми сотрудники уже пользуются. В нём почти наверняка окажутся личные аккаунты, браузерные расширения и функции внутри привычных продуктов. Не закрывайте глаза на теневой контур.
После инвентаризации определите разрешённые сервисы и три зоны данных. Проведите обучение на реальных примерах: что можно отправить, что нужно очистить и когда следует остановиться. Такой процесс медленнее бездумного копирования CRM в чат, зато он переживает масштабирование и проверку.