AI и персональные данные: 6 проверок до загрузки клиентской базы

Коротко: перед первым запросом к нейросети нужно проверить цель обработки, состав данных, договорный контур, маршрут, техническую защиту и журналирование. Маскирование снижает риск передачи прямых идентификаторов внешней модели, но не делает процесс автоматически соответствующим 152-ФЗ. Ниже — практический маршрут для бизнеса без юридической магии.

Обложка: шесть проверок перед отправкой персональных данных в AI

Можно не «вообще», а только в конкретном, заранее описанном процессе. Нужно понимать, какие данные попадают в запрос, для какой цели они используются, на каком основании обрабатываются, кто участвует в цепочке и какие меры защиты действительно включены.

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

Этот материал — не индивидуальное юридическое заключение. Это технический и организационный чек-лист, который помогает подготовить предметный разговор владельцу процесса, юристу и специалисту по информационной безопасности.

С 30 мая 2025 года ответственность за нарушения при работе с персональными данными стала заметно строже. Федеральный закон № 420-ФЗ изменил КоАП РФ и ввёл отдельные составы, связанные в том числе с неуведомлением об утечке и неправомерной передачей данных.

КонсультантПлюс разъясняет, что для повторной утечки в предусмотренных законом случаях возможен оборотный штраф от 1% до 3% годовой выручки, а верхний предел составляет 500 млн рублей. Это не означает, что любой запрос к AI автоматически ведёт к такому штрафу. Но цена неописанного маршрута данных теперь точно не равна цене нескольких тысяч токенов.

Официальный текст поправок опубликован на портале правовой информации. Актуальная редакция 152-ФЗ на дату статьи — 4 сентября 2026 года — сохраняет обязанности самого оператора: определить цель и основание, принять организационные и технические меры, контролировать обработку и оформить поручение, когда данные обрабатывает другое лицо.

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

Главная идея проста: выбирать нужно не только модель. Вы выбираете весь путь запроса — от исходного файла до ответа и журнала событий.

Начните с работы, которую должен закончить сотрудник, а не с желания «подключить AI». Например: классифицировать причины обращений, подготовить черновик ответа или извлечь из договора фиксированный набор полей.

Плохая постановка звучит так: «загрузим всю базу и посмотрим, что найдёт модель». Хорошая — так: «определим тему обращения и срочность, используя только текст последнего сообщения без ФИО, телефона и истории покупок».

Статья 18.1 закона № 152-ФЗ требует, чтобы локальные документы определяли для каждой цели категории данных, субъектов, способы и сроки обработки и хранения. Поэтому одна узкая задача — не бюрократия, а способ не протащить в модель всё, что случайно лежит рядом.

Минимизация начинается до автоматического детектора. Если модели не нужен номер договора, телефон, адрес доставки или полное имя, эти поля лучше не включать в запрос вообще.

Практический порядок:

Это важно потому, что псевдонимизация не равна необратимому обезличиванию. Человека иногда можно определить по сочетанию должности, редкой покупки, города и даты, даже если имя уже заменено.

Техническая кнопка не отвечает на юридический вопрос. Часть 3 статьи 6 закона № 152-ФЗ перечисляет, что должно быть определено в поручении на обработку: перечень данных и операций, цель, конфиденциальность, меры безопасности и требования к защите.

При этом ответственность перед субъектом данных остаётся у оператора. Поэтому до запуска нужно определить:

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

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

Часть 5 статьи 18 закона № 152-ФЗ ограничивает использование зарубежных баз данных при сборе персональных данных граждан России через интернет. Одновременно нужно отдельно оценивать дальнейшие передачи и конкретные исключения. Поэтому фраза «сервер находится в России» сама по себе не описывает весь путь запроса.

В provod.ai публично описан такой технический контур: исходный текст приходит в российский шлюз, прямые идентификаторы заменяются псевдонимами, внешняя модель получает подготовленный текст, а обратная подстановка выполняется внутри контура Provod.

Живой экран документации provod.ai о защите данных перед отправкой модели

*Живая продуктовая документация provod.ai, обновлённая 17 августа 2026 года. На экране также указано главное ограничение: автоматический детектор не гарантирует нахождение всех чувствительных данных.*

Маскирование provod.ai — дополнительная техническая мера для текстовых запросов. При включённом режиме детектор ищет выбранные категории и заменяет значения типизированными псевдонимами до отправки внешней модели.

Согласно продуктовой документации, поддерживаются ФИО, email, телефоны, адреса, паспортные данные, ИНН, СНИЛС, банковские счета, номера карт, IP-адреса и секреты похожего формата. Функция применяется к тексту сообщений и инструкций, текстовым аргументам и результатам инструментов.

Если детектор недоступен, превысил время ожидания или вернул некорректный результат, защита работает по принципу fail-closed: API отвечает ошибкой 503 guardrail_unavailable, а исходный запрос не уходит внешнему провайдеру. Стоимость модели в таком случае не списывается.

Схема маскирования персональных данных до отправки внешней AI-модели

*Путь защищённого текстового запроса: детектор, псевдонимы, внешняя модель и восстановление ответа внутри российского контура.*

Первую проверку нужно делать только на синтетической записи. Не тестируйте защиту на настоящем клиенте, сотруднике или полном API-ключе.

В документации Provod приведён безопасный пример:

Contact test.person@example.com from 192.0.2.10 and repeat both values.

Для такого теста команда проверяет четыре результата:

Замена конкретных значений на [EMAIL_1] и [IP_1] здесь показана как иллюстрация ожидаемого механизма, а не как сохранённый живой прогон этой статьи. Фактический результат нужно подтвердить в журнале вашей организации.

Текущая версия маскирования не проверяет содержимое изображений, аудио, видео, бинарных файлов и URL медиа. Текст документа защищается только после того, как превратился в обычную текстовую часть запроса. Маскирование не является OCR и не редактирует исходный файл.

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

Границы маскирования: поддерживаемый текст, ограничения, цена и журнал

*Граница функции по документации Provod: текстовые категории обрабатываются, но правовые основания, файлы и специальные данные требуют отдельных мер.*

Успешный запрос с включённым маскированием стоит на 5% дороже фактической цены выбранной модели. Это отдельная опция платформы: стоимость модели и маскирование показываются разными списаниями в истории баланса.

Отдельной подписки или оплаты за каждую найденную категорию в текущей документации нет. Если защита остановила запрос до отправки модели, цена модели и наценка за маскирование не списываются.

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

Provod предоставляет слой доступа к моделям и подтверждённую техническую меру, а компания управляет своим процессом. Разделение ответственности выглядит так:

Если приложение автоматически собирает данные из CRM, оно же должно владеть расписанием, правилами отбора, подтверждением человека и остановкой процесса. Provod не превращает такой сценарий в автономного агента и не принимает за компанию юридические решения.

Чаще всего он полезен там, где AI работает с неструктурированным текстом и прямые идентификаторы не нужны для результата. Например:

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

Не обязательно. Псевдонимизация сохраняет возможность обратной подстановки, а человека иногда можно определить по оставшемуся контексту. Документация Provod прямо предупреждает: функция помогает минимизировать передачу прямых идентификаторов, но не является автоматическим подтверждением соответствия 152-ФЗ.

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

При включённом режиме используется fail-closed: запрос останавливается с ошибкой 503 guardrail_unavailable до отправки внешнему провайдеру. По текущей документации стоимость модели и наценка за маскирование в этом случае не списываются.

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

Маскирование Provod закрывает важную часть маршрута: прямые идентификаторы в поддерживаемом тексте заменяются до внешней модели, а сбой защиты останавливает запрос. Но юридическая оценка, права доступа, работа с файлами и решение человека остаются у вашей организации.

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

Актуальные текстовые модели, проверенные в каталоге 4 сентября 2026 года: GLM 5.3 Flash, Claude Opus 5, Claude Fable 5, Gemini 2.5 Flash Lite, DeepSeek V4 Flash 0731 и Qwen3.7 Max. Перед внедрением сверяйте карточку и точный API ID в каталоге.

Тариф модели без дополнительных функций применяется 1:1, без наценки provod.ai. Маскирование — отдельно оплачиваемая функция: успешный защищённый запрос получает наценку 5% к фактической стоимости модели по текущей документации.

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

Дополнительно: каталог и цены · маскирование данных · 152-ФЗ и границы функции · API и интеграции

Нормативные и продуктовые источники: статья 6 закона № 152-ФЗ · статья 18 · статья 18.1 · Федеральный закон № 420-ФЗ · правовая страница provod.ai