ИИ и персональные данные: как выполнить требования 152-ФЗ

Когда данные в ИИ-системе считаются персональными

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

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

С чего начинается аудит ИИ по 152-ФЗ

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

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

Правовое основание нельзя заменить галочкой

Согласие — не единственное возможное основание обработки, но оно должно соответствовать конкретной цели, составу данных и операциям. В зависимости от сценария основанием также может быть исполнение договора, обязанность по закону или иной случай, предусмотренный статьей 6 152-ФЗ. Универсальная формулировка «для улучшения сервиса» не объясняет обучение модели, профилирование и передачу данных внешнему поставщику.

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

Автоматизированные решения и статья 16 152-ФЗ

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

Для таких решений важно не только основание, но и процедура: оператор должен объяснить порядок принятия решения и возможные последствия, предоставить возможность заявить возражение и описать порядок защиты прав. Формальная кнопка «обратиться в поддержку» недостаточна, если никто не уполномочен пересмотреть результат модели по существу.

Внешние LLM, поручение обработки и локализация

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

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

Обезличивание для обучения модели

Удаление ФИО не всегда делает набор обезличенным. Редкая должность, последовательность событий, координаты, голос или сочетание признаков могут позволить повторно определить человека. Поэтому метод обезличивания оценивают вместе с риском деанонимизации, доступом к исходным таблицам и возможностью сопоставления с внешними источниками.

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

Какие документы нужны ИИ-проекту

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

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

1. Инвентаризировать систему. Зафиксировать модель, версию, назначение, пользователей и интеграции.
2. Построить карту данных. Отметить источники, категории, места хранения, получателей и сроки.
3. Определить роли. Развести оператора, обработчиков, поставщиков и самостоятельных участников.
4. Сверить основания и документы. Проверить договоры, согласия, политику, интерфейс и уведомления.
5. Проверить алгоритмические решения. Оценить последствия, участие человека и процедуру возражения.
6. Сформировать матрицу рисков. Для каждого разрыва указать норму, доказательство, приоритет и владельца исправления.

Итог

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