Модели как ПДн: правовой статус

С 2025 года регуляторная среда для ML в России изменилась принципиально. ФЗ-233 от 08.08.2024 ввёл регулирование обезличенных ПДн, Приказ РКН закрепил пять методов обезличивания, а ст. 13.1 ФЗ-152 обязала операторов документировать применяемые техники. Для CTO это означает: архитектурные решения по хранению датасетов, выбору облака и передаче весов модели — теперь юридически значимы. Ниже — анализ правового статуса ML-моделей, обязательных мер защиты по ПП РФ №1119 и Приказу ФСТЭК №21, а также практических сценариев, где архитектура становится доказательством соответствия или нарушения.

Являются ли ML-модели персональными данными по ФЗ-152?

Прямого ответа в ФЗ-152 нет. Закон определяет ПДн как любую информацию, относящуюся к прямо или косвенно определённому физическому лицу. Модель, обученная на обезличенных данных по всем пяти методам из приказа РКН, формально выходит за периметр этого определения. Однако практика РКН и позиция ФСТЭК сложнее: регулятор смотрит на возможность реидентификации.

Биометрические модели — отдельный случай. Векторное представление лица (face embedding), голосовой отпечаток, модели радужки — это производные биометрических ПДн по ст. 11 ФЗ-152. Регулятор квалифицирует их как биометрические ПДн вне зависимости от того, хранится ли исходное изображение. Хранение таких моделей вне ГИС ЕБС без письменного согласия субъекта — нарушение ч. 16 ст. 13.11 КоАП.

Для общих моделей (рекомендации, скоринг, NLP) правило таково: если из модели можно восстановить исходные записи о конкретном человеке методами атаки по членству (membership inference) или инверсии модели — она содержит ПДн. Это не теоретический риск: в 2024–2025 годах несколько публичных исследований продемонстрировали извлечение конкретных записей из LLM, обученных без достаточного обезличивания.

Практический критерий для CTO: если датасет обучения содержал ПДн — проверьте, применены ли все пять методов обезличивания по приказу РКН до передачи данных в обучающий пайплайн. Если нет — модель наследует правовой режим исходных данных.

Какой уровень защищённости (УЗ) нужен для ИСПДн с ML-пайплайном?

Уровень защищённости ИСПДн определяется по ПП РФ №1119 от 01.11.2012. Матрица зависит от трёх переменных: категория ПДн, тип актуальных угроз и число субъектов. Порог по субъектам — 100 000 человек: если больше, требования автоматически смещаются вверх.

Для ML-систем ключевые сценарии следующие. Рекомендательная система на данных пользователей (ФИО, история покупок, геолокация) с базой более 100 000 субъектов — как правило, УЗ-3 при угрозах 2-го типа. Скоринговая модель банка или МФО с обработкой финансового поведения — нередко УЗ-2, если в выборке присутствуют данные о здоровье или судимостях. Биометрические модели (face ID, voice ID) при любом числе субъектов — УЗ-3 минимум, при угрозах 1-го типа — УЗ-1.

Распространённая ошибка: CTO определяет УЗ для основной БД, но не переносит его на вспомогательные системы ML-пайплайна — MLflow, векторные хранилища, S3-бакеты с чекпоинтами модели. Если в чекпоинт попали исходные embedding-и лиц — хранилище становится ИСПДн с режимом биометрии. Проверка Роскомнадзора в 2025 году зафиксировала именно такую схему в одном из финтех-операторов.

Как правильно обезличивать данные для обучения ML-моделей?

С 2025 года методы обезличивания зафиксированы приказом РКН — их пять: введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение и агрегация. Для ML-пайплайна каждый метод имеет разный профиль применимости.

Введение идентификаторов (псевдонимизация) — наиболее распространённый выбор для обучающих датасетов. ФИО и email заменяются на UUID; таблица маппинга хранится отдельно с ограниченным доступом. Минус: при компрометации таблицы маппинга реидентификация тривиальна. РКН рассматривает псевдонимизацию без дополнительных мер как недостаточную для снятия режима ПДн.

Обобщение и агрегация — наиболее подходящий метод для NLP-датасетов. Конкретные даты заменяются диапазонами, точные суммы — квантилями, имена — ролями. Для табличных данных дифференциальная приватность (differential privacy) реализует статистически обоснованный вариант этого метода и является де-факто стандартом для промышленного ML в зарубежных юрисдикциях. Приказ РКН прямо не называет дифференциальную приватность, но обобщение/агрегация как метод охватывает её технически.

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

Кто несёт ответственность в мультиарендной SaaS: оператор или обработчик?

Мультиарендная SaaS создаёт классическую неопределённость ролей по ст. 6 ФЗ-152. Если платформа обрабатывает ПДн клиентов своих клиентов (B2B2C), вопрос о том, кто является оператором, напрямую определяет размер штрафа при инциденте.

Позиция РКН последовательна: оператор — тот, кто определяет цели и состав обрабатываемых ПДн. Если SaaS-платформа сама задаёт, какие поля собирать, какие аналитики запускать и сколько хранить — она оператор. Если конфигурацию полностью задаёт клиент-бизнес, а платформа лишь исполняет технические инструкции — она обработчик по поручению (п. 3 ст. 6 ФЗ-152). Разграничение фиксируется договором поручения обработки ПДн.

Практическая проблема: большинство SaaS-вендоров в России в 2024–2025 годах работали без таких договоров. В результате при проверке клиента РКН запрашивает договор поручения — и при его отсутствии квалифицирует передачу данных платформе как несанкционированную передачу третьему лицу без правового основания. Это ч. 1 ст. 13.11 КоАП — от 150 000 ₽ для каждой из сторон.

Практические сценарии: где архитектура становится доказательством нарушения

Сценарий 1. Обучение модели в AWS/GCP без уведомления РКН о трансграничной передаче. Компания передаёт обучающий датасет с ПДн российских пользователей в S3-бакет в регионе EU-West. Формально это трансграничная передача по ст. 12 ФЗ-152. До 01.07.2025 практика была размытой; после — ужесточение локализации по ФЗ-233 исключило переходный период. При проверке РКН запросит архитектурную схему и договоры с облачным провайдером. Отсутствие уведомления о трансграничке — штраф по ч. 10 ст. 13.11 от 100 000 ₽, плюс предписание устранить нарушение. Стратегия: перевести обучение в облако РФ (Yandex Cloud, Сбер Cloud, VK Cloud) или применить обезличивание всех пяти методов до передачи за рубеж с документированием.

Сценарий 2. Передача весов биометрической модели зарубежному партнёру. CTO передаёт обученную face-embedding модель иностранному вендору для интеграции. Если модель обучалась на биометрических ПДн российских граждан — это передача производных биометрических ПДн. Нарушение ст. 11 и ст. 12 ФЗ-152 одновременно. Санкция по ч. 16–17 ст. 13.11 КоАП: от 15 до 20 млн ₽ при утечке биометрических ПДн; при повторности — оборотный штраф по ч. 18 (1–3% выручки). Стратегия: юридическая экспертиза модели на предмет наличия биометрических атрибутов, оформление уведомления о трансграничной передаче, отдельное согласие субъектов.

Сценарий 3. Логирование запросов к ML API с ПДн пользователей. Стандартная практика — логировать input/output ML API для дебага и мониторинга дрейфа. Если в запросах передаются ФИО, email или биометрия — логи становятся дополнительной ИСПДн. Хранятся они, как правило, без УЗ-требований — в ELK-стеке или Loki без шифрования и ролевого доступа. РКН при анализе инцидента запросит логи: их содержимое станет доказательством объёма утечки. Стратегия: маскирование ПДн в логах на уровне middleware до записи в log-storage, отдельная политика хранения логов с ПДн (срок, доступ, шифрование).

Реальная практика: как это выглядит на проверке

Кейс 1. IT-компания Сибирского ФО (осень 2025, B2B SaaS для HR-автоматизации) использовала AWS для обучения модели ранжирования резюме на данных 180 000 соискателей. Датасет содержал ФИО, контакты, фото. РКН провёл внеплановую проверку по жалобе субъекта. CTO не смог предъявить документацию об обезличивании и уведомление о трансграничной передаче. Возбуждено дело по ч. 1 и ч. 10 ст. 13.11 КоАП. Штраф составил сотни тысяч рублей по совокупности; компания получила предписание перевести обработку в российское облако в течение 30 дней. Дополнительный расход — экстренная миграция в Yandex Cloud с потерей двух спринтов разработки.

Кейс 2. Финтех-стартап Центрального ФО (начало 2026) передал обученную скоринговую модель (более 50 000 записей кредитных историй в обучающем датасете) зарубежному партнёру по API без договора поручения обработки. Арбитражный суд региона квалифицировал это как передачу ПДн без правового основания по ч. 1 ст. 13.11. Применена ст. 4.1.1 КоАП — замена штрафа предупреждением при первичности нарушения и статусе микропредприятия. Однако параллельно возбуждено дело по ст. 272.1 УК РФ в отношении технического директора, санкционировавшего передачу. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

Услуги DATUM по теме

• DPIA (оценка воздействия) — анализ рисков ML-пайплайна на ПДн с документированным отчётом
• Аудит соответствия 152-ФЗ — проверка IT-инфраструктуры, облаков и датасетов по чек-листу из 38 пунктов
• Комплект ОРД под ключ — договоры поручения обработки, регламент обезличивания, политика хранения логов

Частые вопросы

1. Какой УЗ выбрать для SaaS с ML-функциями?

УЗ определяется по ПП РФ №1119: категория ПДн × тип угроз × число субъектов. Для SaaS с данными более 100 000 пользователей и обработкой общих ПДн при угрозах 2-го типа — УЗ-3; при наличии биометрии — минимум УЗ-3, при угрозах 1-го типа — УЗ-1. Ошибка — присваивать УЗ только основной БД, игнорируя векторные хранилища и S3-бакеты с чекпоинтами модели. Приказ ФСТЭК №21 устанавливает набор мер для каждого уровня — 109 мер в 15 группах; конкретный базовый набор зависит от присвоенного УЗ.

2. Можно ли использовать иностранные облака для хранения ML-моделей?

Если модель является производной от ПДн российских граждан (в частности, биометрических) — хранение в иностранном облаке с высокой вероятностью квалифицируется как трансграничная передача по ст. 12 ФЗ-152. После ужесточения локализации с 01.07.2025 (ФЗ-233) первичный сбор, хранение и обработка ПДн граждан РФ должны осуществляться в базах данных на территории РФ по ч. 5 ст. 18 ФЗ-152. Для явно обезличенных моделей (все пять методов задокументированы) ограничение теоретически снимается — но это требует юридической оценки конкретной архитектуры.

3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?

Обезличивание по приказу РКН — это применение одного или нескольких из пяти методов, при которых из данных устраняется возможность идентификации субъекта без использования дополнительной информации. Псевдонимизация (введение идентификаторов) — лишь один из пяти методов; сама по себе она не снимает режим ПДн, поскольку реидентификация возможна при наличии таблицы маппинга. Для ML РКН ожидает документированного обоснования: какой метод применён, какова устойчивость к реидентификации, как хранится вспомогательная информация.

4. Кто является оператором ПДн в мультиарендной SaaS?

Оператором по ст. 3 ФЗ-152 признаётся тот, кто самостоятельно или совместно с другими определяет цели обработки ПДн. Если SaaS-вендор задаёт конфигурацию сбора данных — он оператор. Если только исполняет инструкции клиента — обработчик по поручению (п. 3 ст. 6 ФЗ-152). Разграничение оформляется договором поручения обработки ПДн; его отсутствие при проверке РКН = передача ПДн без правового основания для обеих сторон. Оператор несёт ответственность за действия обработчика перед субъектом.

5. Какие СЗИ обязательны для ИСПДн с ML-компонентами?

Конкретный набор СЗИ определяется Приказом ФСТЭК №21 в зависимости от присвоенного УЗ. Обязательные группы мер для УЗ-3: идентификация и аутентификация (ИАФ), управление доступом (УПД), регистрация событий (РСБ), антивирусная защита (АВЗ), контроль целостности (ОЦЛ), защита среды виртуализации (ЗСВ). Для ML-инфраструктуры особое значение имеют РСБ (логирование доступа к обучающим данным и весам модели) и ЗНИ (защита носителей информации, включая S3-бакеты с датасетами). СЗИ должны быть сертифицированы ФСТЭК России для УЗ-1 и УЗ-2; для УЗ-3 и УЗ-4 допустимы несертифицированные средства при наличии оценки эффективности.

Итог

ML-модели находятся в «серой зоне» ФЗ-152: они не поименованы как ПДн, но при определённых условиях наследуют правовой режим данных, на которых обучены. Биометрические модели — уже прямо под режимом ст. 11 ФЗ-152. Для остальных порог — возможность реидентификации и качество задокументированного обезличивания.

DATUM сопровождает IT-компании и SaaS-вендоров в оценке ML-инфраструктуры на соответствие ФЗ-152: от определения УЗ и разработки регламентов обезличивания до оформления договоров поручения обработки и подготовки к проверке РКН. Практика по технической стороне 152-ФЗ — с 2014 года.

14 апреля 2029 года