Утечки через обученную модель (model inversion)

С июля 2025 года ужесточение требований по локализации и появление ст. 272.1 УК изменили уравнение рисков для IT-команд. ML-модель, обученная на массиве клиентских данных без надлежащего обезличивания, стала отдельным вектором утечки — независимо от того, взломана ли инфраструктура. В этом материале — механика атаки, применимые нормы 152-ФЗ и ФСТЭК, практические сценарии для CTO и минимальный набор мер, снижающих правовой риск.

Что такое model inversion и почему это утечка ПДн?

Атака model inversion (инверсия модели) — это метод, при котором злоумышленник или исследователь, имея доступ к интерфейсу модели (API, локальные веса), многократно запрашивает предсказания и реконструирует данные, использовавшиеся при обучении. Смежные атаки — membership inference (проверка, входил ли конкретный субъект в обучающую выборку) и model extraction (копирование модели).

По ст. 3 ФЗ-152, персональные данные — любая информация, прямо или косвенно относящаяся к определённому физическому лицу. Если по ответам модели можно восстановить имя, диагноз, транзакцию или иной атрибут конкретного субъекта, это квалифицируется как доступ к ПДн. Распространение, предоставление или обеспечение несанкционированного доступа к ПДн — формы обработки по ст. 3. Следовательно, успешная model inversion — это неправомерный доступ к ПДн, то есть утечка в смысле ч. 3.1 ст. 21 ФЗ-152.

Для CTO это означает: публичный inference API над моделью, обученной на реальных ПДн без обезличивания, — это потенциальная точка регуляторного инцидента, а не только техническая уязвимость. Обнаружение успешной атаки запускает 24-часовые часы.

Какие нормы 152-ФЗ, ФСТЭК и КоАП применяются к ML-системам?

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

Типичные уровни для ML в продакшене:

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

Ключевые нормы, напрямую затрагивающие ML-системы с ПДн:

• Ст. 19 ФЗ-152 — обязанность принять организационные и технические меры защиты; состав мер привязан к ПП РФ №1119 и Приказу ФСТЭК №21.
• Ст. 5 ФЗ-152 — принцип минимальности: объём обрабатываемых ПДн не должен превышать необходимый для цели. Обучение модели на исходных ПДн при наличии возможности обезличивания — потенциальное нарушение.
• Ст. 6 ФЗ-152 (п. 3) — поручение обработки третьему лицу допустимо только при наличии договора-поручения, в котором исчерпывающе перечислены действия с ПДн. Внешний ML-провайдер без такого договора — нарушение.
• Ст. 18 ч. 5 ФЗ-152 — локализация: запись, систематизация, хранение ПДн граждан РФ — только в базах на территории РФ. Обучающие датасеты, хранящиеся в зарубежном облаке, — прямое нарушение.
• Ст. 272.1 УК РФ (ФЗ-421, действует с 11.12.2024) — незаконное использование компьютерной информации, содержащей ПДн. Применяется при передаче весов модели или датасета без правового основания.

Как обезличивание снижает риск model inversion?

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

С 2025 года действует регулирование по ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024). Приказ РКН закрепил пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение (агрегация). Для ML-систем практически применимы три из них:

• Введение идентификаторов (псевдонимизация) — замена прямых идентификаторов (ФИО, телефон, email) на суррогатные ключи. Снижает риск membership inference, но не устраняет атаку model inversion при наличии квазиидентификаторов (возраст + регион + диагноз).
• Обобщение (агрегация) — замена точных значений диапазонами: возраст «34» → «30–40», сумма транзакции «12 340 ₽» → «10–15 тыс. ₽». Существенно снижает точность реконструкции.
• Декомпозиция — разбиение датасета на несвязанные фрагменты, хранимые и обрабатываемые раздельно. Усложняет атаку при доступе к одному фрагменту.

Технические меры, дополняющие обезличивание: дифференциальная приватность (differential privacy) при обучении, ограничение числа запросов к inference API, мониторинг аномальных паттернов запросов (признак membership inference атаки), отсутствие в ответах модели вероятностных оценок свыше определённого порога (prediction confidence throttling).

Как применяется ответственность в типовых сценариях для CTO?

Ниже — три сценария, характерных для IT-команд, работающих с ML на реальных ПДн.

Сценарий 1. Внешний inference API без ограничений запросов. Компания развернула рекомендательную модель, обученную на 150 000 профилей клиентов. API открыт без аутентификации и rate limiting. Исследователь через 40 000 запросов восстанавливает атрибуты 200 пользователей. Компания получает уведомление от исследователя. Ситуация: утечка ПДн более 100 субъектов, данные не были обезличены. Доказательства: логи API-запросов, отчёт исследователя. Вероятный исход: штраф по ч. 12 ст. 13.11 КоАП — 3–5 млн ₽, при повторности — ч. 15 (оборотный). Стратегия: немедленное уведомление РКН (24 часа), ограничение API, аргумент о принятых мерах по ст. 19 ФЗ-152 как основание для снижения штрафа.

Сценарий 2. ML-модель в облаке за рубежом. CTO использует AWS Frankfurt для хранения обучающего датасета с ПДн граждан РФ и обучения модели. С 01.07.2025 (ФЗ-233) требование локализации ужесточено. Ситуация: нарушение ч. 5 ст. 18 ФЗ-152, независимо от факта утечки. Доказательства: выписка из инфраструктуры, договор с облачным провайдером. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽; повторно — ч. 9, 6–18 млн ₽. Стратегия: миграция датасета в российское облако (Яндекс Cloud, SberCloud, VK Cloud) до обнаружения РКН; обновление уведомления в реестре.

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

Как это применяется на практике

Кейс 1. IT-компания (Центральный ФО, осень 2025) развернула рекомендательную систему, обученную на 80 000 профилей пользователей без обезличивания. Технический директор после аудита безопасности обнаружил признаки membership inference атаки в логах. Компания уведомила РКН за 22 часа, представила 72-часовой отчёт с описанием мер. Параллельно был заключён ретроспективный договор-поручение с облачным провайдером. По результатам рассмотрения штраф составил сотни тысяч рублей по ч. 12 ст. 13.11 КоАП; арбитражный суд региона принял во внимание оперативность уведомления и факт принятых корректирующих мер как смягчающие обстоятельства.

Кейс 2. Финтех-стартап (Северо-Западный ФО, начало 2026) использовал скоринговую ML-модель, обученную на данных заёмщиков из датасета, хранящегося в зарубежном облаке. Внеплановая проверка РКН по индикатору риска выявила нарушение ч. 5 ст. 18 ФЗ-152. Компания мигрировала датасет в российскую инфраструктуру в течение двух недель после начала проверки. Штраф по ч. 8 ст. 13.11 КоАП составил в нижней части диапазона (1–6 млн ₽) с учётом добровольного устранения нарушения. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

1. Какой УЗ выбрать для SaaS с ML, обрабатывающего ПДн клиентов?

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

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

Нет. С 01.09.2015 ч. 5 ст. 18 ФЗ-152 требует хранить обучающий датасет с ПДн граждан РФ исключительно в базах на территории России. С 01.07.2025 (ФЗ-233) требование ужесточено. Использование AWS, Azure или Google Cloud за рубежом для первичного хранения — нарушение локализации, штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. Трансграничная передача уже обезличенных данных (не являющихся ПДн) локализации не подчинена, но требует документального подтверждения надлежащего обезличивания.

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

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

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

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

5. Какие СЗИ обязательны для ML-системы с уровнем УЗ-3?

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

Итог

Model inversion — не только техническая уязвимость, но и правовой риск по ФЗ-152, ст. 13.11 КоАП и ст. 272.1 УК РФ. Обучающий датасет без обезличивания, inference API без ограничений и внешний ML-провайдер без договора-поручения — три самостоятельных основания для штрафа от 3 до 500 млн ₽ и уголовного преследования с 11.12.2024. Правовой ответ на эту угрозу — DPIA до запуска, обезличивание датасета по одному из пяти методов Приказа РКН, договоры-поручения и локализация в российской инфраструктуре.

Юристы и аналитики DATUM сопровождают ML-проекты на этапах проектирования ИСПДн, определения уровня защищённости и взаимодействия с РКН. Практика по 152-ФЗ с технической стороной — в кластере IT и ИБ.

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