ML-эксперименты на ПДн пользователей

Для технического директора SaaS-компании или ML-платформы граница между «исследовательской выборкой» и «незаконной обработкой ПДн» определяется двумя документами: ПП РФ №1119 о уровнях защищённости и Приказом ФСТЭК №21 о составе мер. С 01.09.2025 вступили в силу нормы об обезличивании по Приказу РКН №140, а оборотный штраф за повторную утечку по ч. 15 ст. 13.11 КоАП составляет 1–3% годовой выручки, но не менее 20 млн ₽. В этом материале — практический разбор правового режима ML-экспериментов на ПДн: от выбора уровня защищённости до архитектуры поручения обработки в мультиарендной среде.

Какой правовой режим распространяется на ML-эксперименты с ПДн пользователей?

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

Типичная ошибка CTO: согласие пользователя оформлено на «улучшение сервиса», но не распространяется на передачу ПДн подрядчику ML-аннотации или облачной вычислительной платформе. Согласно ч. 3 ст. 6 ФЗ-152, передача ПДн третьему лицу для обработки по поручению требует отдельного договора с перечнем действий и мер защиты. Отсутствие такого договора — самостоятельный состав нарушения.

С 01.09.2025 согласие пользователя оформляется отдельным документом по ФЗ-156 от 24.06.2025. Согласие, встроенное в пользовательское соглашение или политику конфиденциальности, заключённое до этой даты, формально остаётся действующим — но новые эксперименты, выходящие за рамки старых целей, требуют переоформления.

Как выбрать уровень защищённости УЗ-1...УЗ-4 для ML-инфраструктуры?

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

Практический расчёт для типичного SaaS-оператора с ML-функциональностью:

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

Для ML-систем угрозы 2-го типа (связанные с недекларированными возможностями в прикладном ПО) актуальны при использовании open-source фреймворков (PyTorch, TensorFlow, Hugging Face). Если CTO применяет такие фреймворки без проверки их безопасности — по умолчанию следует принять угрозы 2-го типа и соответственно выбрать УЗ.

Отдельный вопрос — ML-ноутбуки разработчиков, содержащие фрагменты реальных ПДн из обучающих выборок. Они входят в периметр ИСПДн. Если разработчик работает на личном устройстве без корпоративного агента защиты — это нарушение мер группы ЗТС (защита технических средств) по Приказу ФСТЭК №21.

Что такое обезличивание для ML и как оно снижает регуляторные риски?

Обезличивание ПДн — это комплекс действий, после которых данные теряют прямую связь с конкретным субъектом без возможности обратного восстановления без дополнительной информации. С 01.09.2025 Приказ РКН №140 закрепил пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

Юридическое значение для ML: если обучающий датасет обезличен в соответствии с требованиями Приказа №140, он перестаёт быть ПДн по ст. 3 ФЗ-152. Это означает, что дальнейшие эксперименты с таким датасетом не требуют правового основания по ст. 6 и не подпадают под требования УЗ. Это кардинально меняет архитектуру ML-пайплайна с точки зрения комплаенса.

Практически значимые методы для ML-команды:

• Введение идентификаторов — замена прямых идентификаторов (email, телефон, user_id) на суррогатные ключи, хранящиеся в отдельной защищённой системе. Подходит для табличных данных и логов.
• Обобщение и агрегация — замена точных значений на диапазоны (возраст «28» → «25–30», геолокация точная → административный район). Подходит для обучающих выборок в задачах рекомендаций.
• Декомпозиция — разбиение таблицы на части, каждая из которых не позволяет идентифицировать субъекта. Применимо при передаче данных между командами.

Важно: псевдонимизация (замена идентификатора на псевдоним при сохранении таблицы соответствий) не является обезличиванием по российскому праву. Если таблица соответствий хранится у оператора — данные остаются ПДн и обрабатываются с сохранением всех требований ФЗ-152.

Кто является оператором ПДн в мультиарендной SaaS с ML-функциональностью?

В мультиарендной SaaS возникает структура «оператор клиента — SaaS-платформа — ML-подрядчик», каждый из которых обрабатывает ПДн конечных пользователей. Правовой статус определяется тем, кто устанавливает цели и способы обработки. Клиент платформы (B2B-покупатель) — как правило, оператор. SaaS-платформа в части хостинга и хранения — лицо, осуществляющее обработку по поручению (ч. 3 ст. 6 ФЗ-152).

Проблема возникает, когда SaaS-платформа использует данные клиентов для обучения собственных ML-моделей. В этом случае платформа выходит за рамки поручения и фактически становится самостоятельным оператором — со всеми вытекающими обязательствами: отдельное согласие субъектов, уведомление РКН по ст. 22, соблюдение требований УЗ.

Три модели распределения ответственности в SaaS с ML:

• Модель «чистый обработчик» — платформа не использует данные для собственных целей. Достаточен договор поручения с перечнем действий. Ответственность за законность обработки — на клиенте-операторе.
• Модель «совместные операторы» — платформа и клиент совместно определяют цели. Требуется соглашение о совместной обработке, определяющее ответственного перед субъектами. Повышенные риски для обеих сторон.
• Модель «независимый оператор» — платформа обрабатывает данные для собственных ML-задач на основании собственного согласия. Полная самостоятельная ответственность, включая уведомление РКН и соблюдение ч. 5 ст. 18 ФЗ-152 (локализация).

Как обстоят дела на практике: сценарии для CTO

Сценарий 1. ML-пайплайн без поручения. IT-компания (Приволжский ФО, 2025) использовала пользовательские клики и сессионные данные (email, user_id, поведенческие метрики) для обучения модели персонализации. Данные передавались подрядчику ML-разметки без договора поручения и без указания мер защиты. При внеплановой проверке РКН зафиксировал нарушение ч. 3 ст. 6 и ст. 18.1 ФЗ-152. Компания получила предписание об устранении в течение 30 дней и штраф по ч. 1 ст. 13.11 КоАП. Стратегия: заключить договор поручения со всеми подрядчиками аннотации и вычислений до первой передачи данных; включить обязательства по мерам защиты в соответствии с УЗ.

Сценарий 2. Утечка обучающего датасета через облачное хранилище. SaaS-платформа (Центральный ФО, осень 2025) хранила обучающие выборки (120 000 записей с email и поведенческими метриками) в иностранном облаке без локализации в РФ. Хакерская группа получила доступ через открытый S3-бакет. Компания нарушила одновременно ч. 5 ст. 18 ФЗ-152 (локализация) и ч. 3.1 ст. 21 (уведомление об утечке за 24 часа). Уведомление в РКН было направлено с опозданием на 36 часов. Итоговые риски: штраф по ч. 8 ст. 13.11 (1–6 млн ₽ за нелокализацию), штраф по ч. 11 (1–3 млн ₽ за просрочку уведомления), штраф по ч. 13 (5–10 млн ₽ за утечку 10 000–100 000 субъектов). Стратегия: хранить обучающие выборки исключительно в облаках с инфраструктурой в РФ; настроить автоматическое оповещение SIEM-системы для старта процедуры 24-часового уведомления немедленно после обнаружения инцидента.

Сценарий 3. Обезличивание проведено неверным методом. EdTech-компания (Северо-Западный ФО, начало 2026) применила псевдонимизацию (замену user_id на хэш SHA-256) и передала «обезличенный» датасет аутсорс-команде ML. Таблица соответствий хэш–user_id хранилась в той же базе. После проверки РКН квалифицировал данные как ПДн, поскольку восстановление идентификации возможно при наличии дополнительной информации у оператора. Договор поручения отсутствовал. Стратегия: применять методы из Приказа РКН №140; при использовании хэш-идентификаторов хранить таблицу соответствий в изолированной системе с отдельным контролем доступа или использовать односторонние функции без сохранения соответствия.

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

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

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

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

Уровень защищённости определяется по ПП РФ №1119 индивидуально для каждой ИСПДн. Для типового SaaS с общими ПДн (email, поведенческие метрики) и менее 100 000 субъектов при угрозах 3-го типа — УЗ-4. При превышении 100 000 субъектов или при угрозах 2-го типа (актуальны для open-source ML-фреймворков без проверки безопасности) — УЗ-3. Специальные категории (здоровье, биометрия) повышают уровень минимум до УЗ-2. Расчёт рекомендуется документировать: РКН при проверке запрашивает обоснование выбора УЗ.

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

По ч. 5 ст. 18 ФЗ-152 запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах данных на серверах в РФ. Это распространяется на обучающие выборки, содержащие ПДн. Использование AWS us-east-1, Google Cloud europe-west или Azure westeurope для хранения таких датасетов нарушает требование локализации. Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽ (при повторном — 6–18 млн ₽). Допустимо использовать облачных провайдеров, имеющих зоны доступности в РФ (Яндекс Облако, SberCloud, MTC Cloud), при условии, что ПДн физически хранятся в этих зонах.

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

Обезличивание по Приказу РКН №140 — это действия, после которых данные теряют связь с субъектом без возможности восстановления без дополнительной информации, которой у обрабатывающего нет. Псевдонимизация (замена идентификатора на хэш или суррогатный ключ при сохранении таблицы соответствий у оператора) обезличиванием по российскому праву не является: данные по-прежнему относятся к ПДн. Для ML-пайплайна юридически безопасны методы обобщения, агрегации и декомпозиции при условии невозможности реидентификации. Это позволяет исключить обучающий датасет из периметра ФЗ-152.

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

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

5. Какие СЗИ обязательны для ML-инфраструктуры по Приказу ФСТЭК №21?

Состав обязательных средств защиты информации зависит от уровня защищённости. Для УЗ-3 (наиболее распространённый для SaaS с более 100 000 субъектов) Приказ ФСТЭК №21 предписывает реализацию мер групп: ИАФ (многофакторная аутентификация к ИСПДн), УПД (ролевой доступ, разграничение прав для ML-команды), РСБ (журналирование событий доступа к ПДн), АВЗ (антивирусная защита рабочих мест и серверов), СОВ (обнаружение вторжений на периметре). Использование несертифицированных ФСТЭК СЗИ не является автоматическим нарушением, но проверяющий вправе запросить обоснование. Для УЗ-1 и УЗ-2 применение сертифицированных СЗИ обязательно.

Итог

ML-эксперименты на ПДн пользователей находятся в зоне повышенного регуляторного внимания с 30.05.2025: ст. 13.11 КоАП содержит 18 составов, совокупный потенциальный штраф за утечку в ходе ML-эксперимента (нелокализация + просрочка уведомления + сам инцидент) превышает 15 млн ₽ при объёме от 10 000 субъектов. Правовая архитектура безопасного ML-пайплайна состоит из четырёх элементов: правовое основание на каждом этапе, договор поручения со всеми участниками, обезличивание по методам Приказа РКН №140, инфраструктура в облаке с локализацией в РФ.

Практика DATUM по сопровождению IT-компаний и SaaS-платформ в части 152-ФЗ включает разработку архитектуры поручения обработки, оценку воздействия (DPIA) для высокорискованных ML-систем и комплектование ОРД для технических команд.