Отправка резюме, письма клиента или внутреннего тикета в публичную LLM в общем случае считается обработкой персональных данных по 152-ФЗ. Это происходит, когда в промпте есть сведения об определенном или определяемом человеке: ФИО, телефон, email, идентификатор заказа, редкое сочетание должности и компании. Правовой риск не сводится к гипотетической утечке. Сама передача данных внешнему сервису требует цели, правового основания и оценки провайдера.
Практический безопасный маршрут для типовых задач: сначала исключить возможность идентификации человека, затем отправлять только обезличенный текст. Сам процесс обезличивания тоже обработка ПДн, поэтому выполнять его нужно внутри вашего контура и по тем же правовым правилам.
Коротко: промпт с данными человека нельзя считать просто текстом
Если в резюме, письме, тикете или ином промпте есть сведения об определенном или определяемом человеке, отправка этого текста в LLM становится обработкой ПДн. Для публичного сервиса нужно отдельно оценить цель, правовое основание, роль внешнего провайдера, условия передачи и хранения. Типовой безопасный маршрут: сначала устранить возможность идентификации человека, затем отправлять только обезличенный текст.
Что сделать до первой отправки документа в AI-сервис
- Остановить несанкционированную загрузку исходных документов сотрудниками.
- Описать сценарии использования LLM: какие документы, какие данные, кто отправляет запрос.
- Определить категории данных: прямые идентификаторы, квазиидентификаторы, контекстные описания.
- Проверить договорные и технические условия поставщика: хранение, обучение на запросах, трансграничная передача.
- Внедрить промежуточную обработку промптов до отправки во внешний сервис.
Один запрет на использование ChatGPT или одна настройка в админке не закрывают все требования 152-ФЗ.
Почему резюме в ChatGPT и другой публичной LLM подпадает под 152-ФЗ
Закон смотрит на возможность идентификации, а не на формат файла. Резюме почти всегда содержит прямые контакты. Даже без паспорта комбинация «должность + компания + период работы + образование» часто позволяет найти конкретного человека. Поэтому загрузка резюме в публичную LLM это обработка ПДн.
Определяемое лицо 152-ФЗ: идентификатором бывает не только паспорт
Персональные данные закон определяет как любую информацию, относящуюся прямо или косвенно к определенному или определяемому физическому лицу. Определяемое лицо это не только человек с паспортными данными. Если по набору признаков можно вычислить конкретного субъекта, данные персональные.
Примеры из промптов, которые могут идентифицировать человека:
- ФИО, телефон, email, адрес.
- IP-адрес, cookie-идентификатор, user-agent в связке с сессией.
- ID клиента, номер договора, история покупок, состав корзины.
- Текст отзыва с именем.
- Редкая должность в небольшой компании и период работы.
Оценивать нужно комбинацию сведений и доступный контекст. Внутри компании круг лиц может быть ограничен, и даже должность с отделом может указывать на одного человека.
Отправка промпта во внешний сервис: какие операции обработки происходят
Фактическая цепочка включает подготовку, передачу, возможное хранение у провайдера, использование для генерации ответа, журналирование и удаление. Нужно проверить условия конкретного сервиса: кто получает данные, где они обрабатываются и хранятся, используются ли для улучшения модели, какие настройки доступны, как регулируется передача третьему лицу и трансграничная передача. Условия разных LLM-поставщиков неодинаковы.
Договор, согласие и новая цель обработки: где проходит практическая граница
Телефон и адрес для доставки можно обрабатывать для исполнения договора купли-продажи, отдельное согласие не требуется. Дата рождения для скидки или подписка на новости не обязательны для договора и требуют отдельной оценки основания, в том числе согласия.
Тот же принцип применим к LLM: использование модели для нового внутреннего процесса нельзя автоматически считать продолжением исходной цели сбора данных. Конкретный сценарий должен проверять юрист и ответственный за ПДн.
Почему удалить ФИО недостаточно: скрытые идентификаторы в документах и промптах
Человек может оставаться определяемым после удаления имени. Номер телефона в подписи, ссылка на профиль, редкое сочетание компании, должности и периода работы, номер договора, адрес, уникальная ситуация из обращения все это выдает субъекта. LLM получает весь контекст, а не только поле, которое команда считает чувствительным.
Прямые идентификаторы, квазиидентификаторы и свободный текст
- Прямые идентификаторы: ФИО, телефон, email, паспорт, СНИЛС.
- Квазиидентификаторы: дата рождения, пол, город, должность, компания, период работы, редкое сочетание навыков.
- Контекстные описания: уникальная ситуация из обращения, название внутреннего проекта, ссылка на профиль.
Квазиидентификаторы особенно опасны в небольших выборках и корпоративных данных, где круг потенциальных людей ограничен.
Разбор резюме: что нужно убрать или обобщить перед анализом
- Контакты, ссылки на личные профили, адрес, дата рождения.
- Фото и подписи к нему.
- Названия небольших команд и уникальные проекты.
- Редкие сочетания компании, должности и периода работы.
Для подбора по навыкам модели не нужны контактные данные кандидата. Точный набор полей зависит от задачи.
Обезличивание персональных данных: критерий, который важнее названия инструмента
Обезличивание закон определяет как действия, в результате которых без использования дополнительной информации невозможно определить принадлежность персональных данных конкретному субъекту. Практический вывод: ценность имеет фактическая невозможность связать набор данных с человеком, а не название функции в продукте. Неполное обезличивание оставляет данные персональными.
Маскировка, псевдонимизация и обезличивание: в чем разница
На одном примере. Маскировка: телефон +7 999 123-45-67 заменяется на +7 999 ***-**-67, но человек может оставаться определяемым по остальным данным. Псевдонимизация: ID клиента 48213 заменяется токеном T-771, таблица соответствий хранится отдельно. Обезличивание: данные изменены так, что без дополнительной информации определить человека нельзя.
Если оператор сохраняет таблицу соответствий и может восстановить личность, исходные данные внутри его контура не выходят автоматически из режима ПДн.
Как обезличить данные для нейросети, не сломав полезность запроса
Подход минимизации данных: для ранжирования резюме оставьте навыки, опыт, уровень и требования вакансии, а контакты и прочие идентификаторы исключите. Для клиентского обращения сохраните суть проблемы, тип продукта и статус заказа, но удалите имя, телефон, адрес и номера, позволяющие связать текст с человеком. Замена должна учитывать контекст, иначе модель может восстановить идентификатор из соседних фрагментов.
Проверка на повторную идентификацию перед запуском
Проведите ревью типовых промптов. Оцените, может ли сотрудник или внешний получатель по тексту определить человека, используя обычный рабочий контекст. Проверьте, остались ли уникальные комбинации признаков и передается ли во внешний сервис таблица соответствий. Проверка должна учитывать конкретный набор данных и круг лиц с доступом.
Маскировка данных для нейросетей: как устроить LLM-прокси
Целевой поток данных такой: пользователь или система отправляет документ во внутренний шлюз, шлюз выявляет чувствительные сущности, заменяет их согласованными токенами, передает очищенный промпт в LLM, получает ответ, при необходимости выполняет обратную подстановку только во внутреннем защищенном контуре. Обратная подстановка уместна не для всех задач и требует ограничения доступа к таблице соответствий.
Похожий защитный контур с цепочкой детекторов, маскированием ПДн и контролем tool calls описан в статье про LLM Guardrails в Enterprise.
Минимальный поток: детектирование, токены, модель, обратная подстановка
Компоненты: NER или правила для поиска сущностей, нормализация форматов телефонов и email, токенизация, защищенное хранилище соответствий, маршрутизация к модели, аудит запросов без исходных секретов. Устойчивые токены нужны, если модели важно понимать, что несколько упоминаний относятся к одному человеку.
Для части задач качественное детектирование можно построить на каскаде регулярок, словарей и классификаторов без полноценного RAG, об этом есть разбор более дешевых NLP-методов.
Что нельзя отправлять вместе с обезличенным промптом
- Таблицу соответствий токенов и исходных значений.
- CRM-выгрузки и внутренние ссылки с доступом к карточке клиента.
- Полные логи с исходным запросом.
- Системные инструкции с персональными данными.
Токен сам по себе не должен быть ключом к карточке человека за пределами внутреннего контура.
Локальная LLM не отменяет требования 152-ФЗ
Локальная модель упрощает контроль инфраструктуры, доступа и журналов. Компания по-прежнему обрабатывает ПДн и остается оператором. Для локального контура также нужны цель обработки, права доступа, защита данных, управление логами и сроками хранения. Если рассматриваете локальную модель, подбор под конкретную задачу важнее универсального лидерборда, об этом есть разбор идеи прикладного бенчмарка.
Почему DLP-система может не заметить персональные данные в промпте
Типовые правила DLP работают по сигнатурам и шаблонам. Свободная форма текста, опечатки, нестандартные форматы, косвенные идентификаторы, данные в нескольких сообщениях, изображения и вложения, API-интеграции все это создает пропуски. Это ограничение нужно проверять на конфигурации конкретной DLP, а не считать универсальным недостатком всех систем.
Сигнатуры хорошо ловят шаблоны, но хуже понимают контекст
Хорошо формализуемые данные, например телефон или номер документа, ловятся регулярными выражениями. Сведения, которые идентифицируют человека только в совокупности, редкая должность, история обращения, внутренний проект, сигнатурные правила часто пропускают. Одновременно возможны ложные срабатывания.
Защита должна стоять до внешней LLM, а не только на выходе из сети
- Политика допустимых сценариев использования LLM.
- LLM-прокси с классификацией и обезличиванием до отправки.
- DLP как дополнительный слой контроля каналов передачи.
- Разграничение доступа и запрет прямых API-ключей у неавторизованных приложений.
- Аудит запросов и результатов.
Один слой не закрывает все риски.
Штрафы за утечку персональных данных и почему ждать инцидента поздно
Нарушение может начаться до публичной утечки. Передача исходных данных в неподходящий внешний процесс сама требует правовой оценки. Сопутствующие риски: неконтролируемые логи, личные аккаунты сотрудников, повторное использование промптов, отсутствие понятного срока удаления.
Нарушение начинается не только в момент утечки
Отсутствие публичного инцидента не означает отсутствие правового риска. Неправомерная обработка или передача данных может привести к ответственности до того, как данные попадут в открытый доступ.
Какие источники проверить перед публикацией суммы штрафа
Сверьте актуальную редакцию статьи 13.11 КоАП РФ, переходные положения и дату вступления изменений по официальным правовым источникам. При необходимости добавьте комментарий профильного юриста. Суммы, категории нарушений и условия ответственности публикуйте только после этой проверки. В предоставленной фактуре нет подтвержденных цифр новых штрафов, поэтому финальные суммы в этой статье не приводим.
Чек-лист: как запустить LLM-сценарий без передачи исходных ПДн
- Опишите бизнес-задачу.
- Соберите типовые промпты.
- Классифицируйте данные по категориям идентификаторов.
- Сократите поля до необходимого минимума.
- Определите, возможна ли реальная анонимизация.
- Выберите локальный или внешний контур.
- Настройте LLM-прокси и правила доступа.
- Проверьте логи и вложения.
- Проведите тест на повторную идентификацию.
- Закрепите владельцев процесса и регулярный пересмотр правил.
Чек-лист не заменяет юридическую оценку конкретной обработки.
Вопросы владельцу процесса, разработчику и специалисту по ИБ
- Нужна ли модели личность человека или только свойства документа?
- Куда физически и логически уходит промпт?
- Кто имеет доступ к исходнику и таблице токенов?
- Что попадает в логи?
- Можно ли отключить обучение на запросах?
- Как удаляются данные?
- Кто подтверждает изменение промпт-шаблона?
Когда лучше не использовать публичную LLM для задачи
- Задача не работает без прямых идентификаторов.
- Невозможно надежно исключить повторную идентификацию.
- Поставщик или маршрут обработки не проходит требования организации.
- В промпт попадают особо чувствительные документы.
В таких случаях выбирайте локальную модель, внутренний защищенный сервис или переработайте процесс. Для локальной очистки текста иногда достаточно небольшой узкой модели, как в кейсе fine-tune локальной LLM.