Передача обученной модели как поручение

ML-пайплайн в SaaS-продуктах редко проектируется под ФЗ-152: данные собирают, обучают модель, затем передают артефакт заказчику. В 2025 году Роскомнадзор начал квалифицировать передачу весов моделей, обученных на персональных данных, как трансграничную передачу или поручение обработки. Это меняет требования к договорам, УЗ-уровням по ПП РФ №1119 и набору СЗИ по Приказу ФСТЭК №21. Статья разбирает юридическую природу операции, критерии квалификации, последствия и архитектурные решения, снижающие риск.

Что такое поручение обработки по ФЗ-152 и когда под него подпадает ML-модель?

По п. 3 ст. 6 ФЗ-152 оператор вправе поручить обработку персональных данных третьему лицу на основании договора или иного документа. Поручение означает, что третье лицо действует в интересах и по заданию оператора, не становясь самостоятельным оператором. Вопрос в том, является ли обученная модель «обработкой» в смысле закона.

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

На практике квалификация зависит от двух параметров: степени запоминания модели и назначения передачи. Модели с высокой степенью запоминания (LLM, обученные на пользовательских текстах; рекомендательные системы на транзакциях; медицинские модели на снимках с метаданными пациентов) создают риск извлечения. Передача такой модели заказчику без договора поручения — нарушение ст. 6 ФЗ-152 и потенциально ст. 272.1 УК, введённой ФЗ-421 от 30.11.2024.

Какой уровень защищённости (УЗ) применяется при передаче модели в SaaS-среде?

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

Для SaaS-платформ, обслуживающих нескольких заказчиков (мультиарендность), проблема сложнее. Каждый тенант фактически является отдельным оператором. ML-модель, разделяемая между тенантами или обученная на объединённой выборке, создаёт риск смешения баз с несовместимыми целями — нарушение принципа ст. 5 п. 2 ФЗ-152. В такой конфигурации применяется наивысший УЗ из всех задействованных тенантов: если хотя бы один тенант обрабатывает специальные категории (ст. 10 ФЗ-152) с угрозами 2 типа — вся платформа работает под УЗ-2.

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

Как обезличивание для ML снижает правовой риск при передаче модели?

Обезличенные данные по ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) выведены из-под действия норм о персональных данных при условии, что обратная идентификация невозможна без несоразмерных усилий. Если обучающая выборка обезличена до обучения по одному из пяти методов, установленных приказом РКН (введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение/агрегация), обученная модель не является носителем персональных данных.

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

Критическая проблема: ряд архитектур моделей (особенно LLM и генеративные) склонны к запоминанию обучающих примеров. Обезличивание выборки до обучения не гарантирует отсутствие персональных данных в весах, если модель переобучена или обучена на недостаточно больших объёмах данных. Технически правильная стратегия — differential privacy при обучении с параметром ε ≤ 1 для высокорисковых данных. Это снижает риск memorization-атак до уровня, при котором РКН не может доказать восстановимость исходных ПДн.

Логирование запросов к модели само по себе создаёт базу персональных данных: IP-адрес, идентификатор сессии, содержание промпта — всё это потенциально ПДн по позиции РКН. Журналы обращений к ML API подпадают под требования к ИСПДн, если позволяют косвенно идентифицировать субъекта.

Какие правовые сценарии возникают при передаче модели в 2025–2026 году?

Сценарий 1. CTO передаёт файл весов заказчику без договора поручения. Модель обучена на транзакциях 500 000 пользователей. Заказчик деплоит модель в собственной инфраструктуре. Роскомнадзор при проверке заказчика устанавливает, что модель воспроизводит фрагменты транзакций при инверсионных атаках. Квалификация: передача персональных данных без законного основания (ч. 1 ст. 13.11 КоАП) + возможное возбуждение дела по ст. 272.1 УК. Для оператора-разработчика штраф 150–300 тыс. ₽ по ч. 1 ст. 13.11 при первичном нарушении; при доказательстве умысла — до 5 лет лишения свободы по ч. 3 ст. 272.1 УК. Стратегия: до передачи — провести атаку на запоминание, зафиксировать результат, заключить договор поручения с ограничением на дообучение и экспорт данных из модели.

Сценарий 2. SaaS-платформа с мультиарендностью обучает общую модель на данных всех тенантов. Один тенант — медицинская лаборатория, обрабатывающая специальные категории ПДн по ст. 10 ФЗ-152. Общая модель получает УЗ-2 по наивысшему тенанту. CTO выставил УЗ-3 для всей платформы — нарушение ПП РФ №1119. При проверке РКН: предписание об устранении + штраф по ч. 1 ст. 13.11. Если нарушение повторное (ч. 1.1) — 300–500 тыс. ₽. Стратегия: изоляция тенантов на уровне обучающих данных, отдельные модели или federated learning без передачи сырых данных, актуализация модели угроз.

Сценарий 3. CTO передаёт модель в облако иностранного провайдера (AWS EU, Azure West Europe). Обучающие данные — граждане РФ. Передача весов в зарубежный дата-центр квалифицируется как трансграничная передача персональных данных по ст. 12 ФЗ-152 и нарушение локализации по ч. 5 ст. 18 ФЗ-152. Штраф за локализацию по ч. 8 ст. 13.11 КоАП: 1–6 млн ₽; при повторности по ч. 9: 6–18 млн ₽. Стратегия: деплой модели только в российском облаке (Яндекс Облако, SberCloud, VK Cloud) с актуализацией уведомления в реестре РКН по ст. 22 ФЗ-152.

Как облако в РФ и КИИ влияют на архитектуру ML-пайплайна

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

Если платформа относится к критической информационной инфраструктуре по ФЗ-187 (телеком, здравоохранение, финансы, транспорт), требования дополнительно расширяются: подключение СОПКА, обязательная категоризация объекта КИИ, уведомление ФСБ об инцидентах. ML-пайплайны в медицине (диагностические модели) и банкинге (скоринг, фрод-детект) с высокой вероятностью подпадают под КИИ.

При выборе российского облака для ML-нагрузок CTO должен убедиться, что провайдер имеет аттестат на обработку ПДн нужного УЗ. Сертификат ФСТЭК на платформу виртуализации закрывает группу ЗСВ Приказа ФСТЭК №21, но не заменяет аттестацию ИСПДн оператора. Аттестация — обязанность самого оператора, а не провайдера.

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

Кейс 1. IT-компания Центрального ФО (осень 2025) передала заказчику рекомендательную модель, обученную на 1,2 млн пользовательских профилей. Договор поручения отсутствовал; в техническом задании операция была описана как «передача программного обеспечения». При плановой проверке заказчика РКН установил, что через инверсионные запросы к модели можно извлечь фрагменты профилей. Возбуждено дело по ч. 1 ст. 13.11 КоАП в отношении разработчика. Юристы CTO настояли на применении ст. 4.1.1 КоАП (замена штрафа на предупреждение): первичное нарушение, отсутствие реального вреда субъектам, устранение в течение 30 дней. Результат — предупреждение вместо штрафа. Модель ретренирована с differential privacy.

Кейс 2. SaaS-платформа медицинской аналитики (Сибирский ФО, начало 2026) обслуживала 14 клиник в рамках мультиарендной архитектуры. CTO установил для всей платформы УЗ-3, не разграничив тенантов. При проверке РКН установил, что один тенант обрабатывает специальные категории ПДн пациентов (диагнозы по ст. 10 ФЗ-152) с угрозами 2 типа — значит, платформа обязана соответствовать УЗ-2. Разрыв по мерам ФСТЭК: отсутствие ЗНИ (защита носителей) и ЗСВ (защита среды виртуализации). РКН выдал предписание и возбудил дело по ч. 1 ст. 13.11. Штраф в диапазоне 150–300 тыс. ₽, устранение нарушений — 60 дней.

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

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

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

1. Какой УЗ выбрать для SaaS?

УЗ определяется по матрице ПП РФ №1119: категория ПДн × тип актуальных угроз × число субъектов. Для мультиарендных SaaS берётся наивысший УЗ из всех тенантов. Если хотя бы один тенант обрабатывает специальные категории (ст. 10 ФЗ-152) и угрозы соответствуют 2 типу — вся платформа работает под УЗ-2 независимо от числа субъектов. Определение типа угроз — обязанность оператора, закреплённая в модели угроз.

2. Можно ли использовать иностранные облака?

Для первичной записи, хранения и обработки ПДн граждан РФ — нет. Ч. 5 ст. 18 ФЗ-152 требует локализации этих операций в России. Обучение и деплой ML-моделей на данных граждан РФ в AWS EU, Azure или GCP нарушает требование локализации. Штраф по ч. 8 ст. 13.11 КоАП составляет 1–6 млн ₽, при повторности по ч. 9 — 6–18 млн ₽. Допускается зеркалирование уже обезличенных данных за рубеж при соблюдении требований ст. 12 и ст. 13.1 ФЗ-152.

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

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

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

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

5. Какие СЗИ обязательны?

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

Итог

Передача обученной ML-модели — не нейтральная IT-операция. При наличии запоминания обучающих данных она квалифицируется как поручение обработки персональных данных или их несанкционированная передача со всеми вытекающими последствиями по ст. 13.11 КоАП и ст. 272.1 УК. Ключевые точки контроля — договор поручения, уровень защищённости ИСПДн, локализация инференса и корректное обезличивание выборки до обучения.

DATUM сопровождает IT-команды при квалификации ML-операций, подготовке модели угроз и договоров поручения, проведении DPIA до передачи весов и аудите соответствия SaaS-платформ требованиям ПП РФ №1119 и Приказа ФСТЭК №21.

11 января 2029 года