MLOps и 152-ФЗ

Тема пересечения MLOps и 152-ФЗ не получила отдельного регулятора: закон написан технологически нейтрально, но его требования распространяются на каждый шаг конвейера — сбор фичей, препроцессинг, обучение, версионирование датасетов, мониторинг дрейфа, логирование инференса. Задача CTO — понять, в каком месте пайплайна живут персональные данные и какой правовой режим к ним применяется.

Почему ML-конвейер попадает под 152-ФЗ?

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

Обработкой по ст. 3 считается любое действие: сбор, запись, систематизация, накопление, хранение, уточнение, извлечение, использование. Загрузка датасета в Spark — это систематизация и хранение. Обучение модели — использование. Логирование предсказаний — снова хранение и накопление. Итого: весь MLOps-конвейер от ETL до мониторинга модели в продакшне подпадает под определение обработки.

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

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

Уровень защищённости ИСПДн определяется по матрице из трёх параметров: категория ПДн (специальные / биометрические / общедоступные / иные), тип угроз (1–3), численность субъектов в системе. Порядок определения закреплён в ПП РФ №1119 от 01.11.2012.

Для большинства ML-платформ в SaaS и финтехе актуальны два сценария:

• УЗ-3 — иные персональные данные, угрозы 2-го или 3-го типа, любое число субъектов. Типичен для рекомендательных систем, антифрода, скоринга на поведенческих данных.
• УЗ-2 — специальные категории (здоровье, убеждения) при угрозах 2-го типа и более 100 000 субъектов. Типичен для медицинских ML-платформ и HR-аналитики с психопрофилями.
• УЗ-1 — специальные категории, угрозы 1-го типа (актуальны НДВ в системном ПО). Практически не встречается в коммерческих ML-системах.

Тип угроз CTO определяет самостоятельно через модель угроз. Угрозы 1-го и 2-го типа предполагают актуальность недекларированных возможностей в системном и прикладном ПО соответственно. Если модель угроз не разработана — по умолчанию применяется наиболее консервативная оценка, что автоматически повышает УЗ.

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

Как обезличить датасет для ML и соответствовать требованиям Приказа РКН?

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

Для ML-конвейера наиболее применимы два метода. Введение идентификаторов (псевдонимизация): замена реального user_id на внутренний суррогатный ключ при условии хранения таблицы соответствия в отдельном защищённом хранилище с ограниченным доступом. Обобщение (агрегация): замена точных значений диапазонами — возраст «34» заменяется «30–35», GPS-координата округляется до района. Метод подходит для обучающих выборок, где точность признака некритична для качества модели.

Технически недостаточные методы с точки зрения Приказа РКН: простое удаление имени при сохранении email или телефона; хэширование без соли (rainbow-таблицы восстанавливают исходник); шифрование при наличии ключа у той же системы, что обрабатывает данные. Регулятор рассматривает такие конструкции как псевдообезличивание, не снимающее статус ПДн.

Для feature engineering и обучающих выборок рекомендованная архитектура: ETL-слой выполняет псевдонимизацию до записи в feature store; таблица соответствия user_id → surrogate_id хранится в отдельном хранилище (например, отдельная БД с полным логированием доступа); модель на продакшне получает только surrogate_id и не имеет доступа к таблице соответствия. При таком разделении feature store классифицируется как система с псевдонимизированными данными, что снижает применимый УЗ.

Мультиарендная SaaS: кто оператор и как оформить поручение обработки?

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

Поручение обработки должно быть оформлено письменно. Минимальные реквизиты: перечень действий, которые платформа вправе совершать; цели обработки (не шире, чем у клиента-оператора); обязанность соблюдать конфиденциальность; меры защиты, которые обязана принять платформа; запрет на передачу ПДн третьим лицам без согласия оператора. Отсутствие письменного поручения при фактической обработке по заданию клиента — нарушение п. 3 ст. 6 ФЗ-152 и основание для протокола по ч. 1 ст. 13.11 КоАП.

Проблема ML-платформ — обучение на данных нескольких тенантов. Если модель обучается на объединённом датасете разных клиентов (federated или иначе), возникает риск утечки ПДн одного тенанта через инференс другого (membership inference attack, model inversion). Правовая квалификация такой утечки — неправомерная передача ПДн по ст. 3 ФЗ-152, что при масштабе от 1 000 субъектов влечёт штраф по ч. 12–14 ст. 13.11 КоАП.

Можно ли использовать иностранные облака для хранения ПДн граждан РФ?

Локализация по ч. 5 ст. 18 ФЗ-152 запрещает первичный сбор, запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан России в базах данных, расположенных за пределами РФ. Правило действует с 01.09.2015; с 01.07.2025 контроль усилен в рамках ФЗ-233 от 08.08.2024.

Для ML-инфраструктуры это означает: feature store, обучающие датасеты, логи инференса, содержащие привязанные к субъектам признаки, должны размещаться в облаке с локацией в РФ. Использование AWS eu-west, GCP europe-west или Azure западноевропейских регионов для хранения первичных ПДн граждан РФ — прямое нарушение ч. 5 ст. 18, за которое предусмотрен штраф по ч. 8 ст. 13.11 КоАП в размере 1–6 млн ₽, при повторности — 6–18 млн ₽ по ч. 9.

Допустимые архитектурные решения: российские облака (Yandex Cloud, VK Cloud, SberCloud, Selectel) как основное хранилище ПДн; обезличенные датасеты (при подтверждённом методе обезличивания) могут реплицироваться в зарубежное облако для распределённого обучения — обезличенные данные не являются ПДн; трансграничная передача ПДн в иностранное облако-обработчик допустима при уведомлении РКН по ст. 12 ФЗ-152 и оценке страны адекватной защиты.

Логирование как источник риска: когда логи становятся ПДн?

В MLOps-системах логи инференса — это записи вида: timestamp, user_id (или session_id), входной вектор признаков, предсказание модели, уверенность. Если user_id или session_id позволяет идентифицировать физическое лицо — лог является персональными данными и подпадает под требования ФЗ-152 в полном объёме.

Критические точки: логи A/B-тестов с привязкой к пользователям; логи мониторинга дрейфа данных, сохраняющие фактические значения входных признаков; трассировка запросов с передачей user context в distributed tracing (Jaeger, Zipkin). Ошибка CTO — считать, что логи «технические» и не относятся к ПДн. РКН при проверке запрашивает все системы хранения данных, включая ELK/OpenSearch, ClickHouse-журналы, S3-бакеты с логами.

Решение: псевдонимизация на уровне логирования — замена реального user_id на session-level суррогат с TTL; ротация и автоматическое удаление логов инференса по истечении срока, необходимого для отладки (принцип ст. 5 ФЗ-152 — не дольше необходимого для целей обработки); разграничение доступа к логам с полными ПДн — только DevOps с необходимостью знать (need-to-know), фиксация доступа в журнале.

Практика: как разрывы в MLOps приводят к штрафам

Кейс 1. Финтех-компания (Приволжский ФО, зима 2025–2026) эксплуатировала антифрод-модель, обучённую на транзакционных данных и поведенческих профилях около 180 000 пользователей. Feature store размещался в иностранном облаке без уведомления РКН о трансграничной передаче и без локализации первичных данных в РФ. При плановой проверке РКН выявил нарушение ч. 5 ст. 18 ФЗ-152 и составил протокол по ч. 8 ст. 13.11 КоАП. Штраф — в диапазоне 1–6 млн ₽. Параллельно зафиксировано отсутствие модели угроз и поручения обработки с облачным провайдером. CTO инициировал экстренную миграцию feature store в российское облако в течение 45 дней.

Кейс 2 (case_S2_pkr_analitika). В деле АС Санкт-Петербурга и Ленинградской области (март 2026) по факту утечки около 70 000 субъектов через взломанный API-эндпоинт платформы суд квалифицировал нарушение по ч. 14 ст. 13.11 КоАП. Суд учёл смягчающие обстоятельства: оперативное уведомление РКН в срок 24 часов, представленный 72-часовой отчёт с описанием мер реагирования. Итог: штраф с применением понижающих коэффициентов. Техническая причина утечки — отсутствие контроля доступа к эндпоинту, возвращавшему необезличенные признаки из feature store.

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

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

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

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

Зависит от категории данных и модели угроз. Для платформ, обрабатывающих иные персональные данные (поведение, транзакции) при угрозах 2-го или 3-го типа, — УЗ-3. Если платформа работает со специальными категориями (здоровье, финансовые профили с выводами о платёжеспособности) и более 100 000 субъектов при угрозах 2-го типа — УЗ-2. Тип угроз определяется моделью угроз, которую оператор разрабатывает самостоятельно или с привлечением лицензиата ФСТЭК. Без актуальной модели угроз УЗ считается неопределённым, что фиксируется как нарушение ст. 18.1 ФЗ-152.

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

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

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

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

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

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

5. Какие средства защиты информации обязательны при УЗ-3?

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

Итог

MLOps-конвейер — полноценная ИСПДн, которая проходит по всем требованиям ФЗ-152: от определения УЗ и разработки модели угроз до оформления поручений обработки с облачными провайдерами и документирования методов обезличивания. Технологическая нейтральность закона означает, что регулятор не делает исключений для ML-пайплайнов — он смотрит на факт обработки ПДн, а не на её архитектурную форму.

Практика DATUM по IT-сектору и SaaS-платформам включает аудит MLOps-инфраструктуры, разработку модели угроз, оформление поручений обработки с зарубежными и российскими облачными провайдерами, а также подготовку к проверкам РКН с учётом специфики многотенантных архитектур.