Аудит ML-pipeline на 152-ФЗ

Аудит ML-pipeline на 152-ФЗ стал самостоятельной задачей с 2025 года: регулятор выпустил методы обезличивания для машинного обучения, ФСТЭК обновил трактовку Приказа №21 применительно к облачным вычислениям, а суды начали применять новые составы ст. 13.11 КоАП к утечкам через ML-системы. Эта статья разбирает, где именно pipeline нарушает 152-ФЗ, как определить уровень защищённости ИСПДн с ML-компонентой и какие технические меры обязательны по Приказу ФСТЭК №21.

Почему ML-pipeline попадает под 152-ФЗ и что это означает для CTO?

Машинное обучение работает с данными. Если обучающая выборка содержит имена, телефоны, идентификаторы пользователей, геолокацию или поведенческие паттерны — она содержит персональные данные по ст. 3 ФЗ-152. Факт, что данные «переработаны» в веса модели, не освобождает от обязанностей оператора: ФСТЭК и РКН рассматривают обучение модели как отдельную операцию обработки ПДн.

Типичная архитектура pipeline создаёт несколько точек риска одновременно. Первая — хранилище сырых данных (data lake): часто без контроля доступа уровня строк, с ПДн в открытом виде. Вторая — feature store: агрегированные признаки могут деанонимизироваться обратно при наличии внешней таблицы соответствий. Третья — артефакты модели: веса нейросети могут воспроизвести обучающие примеры при атаке model inversion. Четвёртая — эксперименты в MLflow, Weights&Biases: логи экспериментов хранят срезы данных без политики удаления.

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

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

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

Категории ПДн в ML-контексте часто смешанные. Рекомендательная система e-commerce работает с общими данными (УЗ-3 или УЗ-4). Кредитный скоринг включает финансовую историю — формально «общие», но де-факто чувствительные. Медицинская диагностическая модель работает со специальными категориями по ст. 10 ФЗ-152 — здесь порог УЗ автоматически выше (УЗ-2 или УЗ-1 при угрозах 1-го типа).

Порог в 100 000 субъектов меняет УЗ на шаг вниз (то есть ужесточает требования). Для ML-систем крупных платформ этот порог почти всегда превышен уже на этапе формирования обучающей выборки. CTO должен считать не только активных пользователей продакшн-сервиса, но и все записи в обучающем датасете.

Тип угроз — ключевой параметр, который чаще всего занижается. Угрозы 1-го типа предполагают наличие недекларированных возможностей в системном ПО. Для ML-платформ, работающих на open-source фреймворках (PyTorch, TensorFlow, Spark), РКН и ФСТЭК склонны рассматривать их как угрозы не ниже 2-го типа из-за отсутствия сертифицированных версий. Это сдвигает УЗ и увеличивает состав обязательных мер.

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

Приказ ФСТЭК №21 описывает 109 мер в 15 группах. Для ML-платформы критически важны несколько групп, которые технически отличаются от классических корпоративных ИСПДн.

Группа ИАФ (идентификация и аутентификация): сервисные аккаунты ML-компонентов (Airflow, Spark, Jupyter) часто используют общий логин или статические токены. Приказ №21 требует индивидуальной идентификации даже для технических учётных записей при УЗ-2 и выше.

Группа УПД (управление правами доступа): feature store и model registry должны иметь разграничение доступа на уровне проекта и роли. Возможность прочитать весь обучающий датасет должна быть у минимального числа сотрудников — принцип минимальных привилегий фиксируется в политике доступа.

Группа РСБ (регистрация событий): все операции чтения/записи из data lake и model registry должны логироваться с сохранением записей не менее установленного срока. Это то самое «логирование как ПДн» — логи сами становятся ИСПДн и требуют защиты.

Группа ЗНИ (защита носителей информации): обучающие датасеты на объектных хранилищах (S3-совместимые) должны быть зашифрованы. При использовании облачных хранилищ в РФ — проверить, что шифрование управляется ключами оператора, а не только провайдером.

Что такое обезличивание для ML и когда оно снимает риски 152-ФЗ?

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

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

Важное ограничение: обезличивание снимает требования 152-ФЗ только если оно необратимо. Если из обученной модели можно воспроизвести исходные записи (атака model inversion или membership inference), данные считаются псевдонимизированными, а не обезличенными. Это означает, что для высокорискованных моделей (медицина, кредит) необходим технический аудит устойчивости к таким атакам.

Практически: для большинства B2B SaaS с рекомендательными и классификационными моделями достаточно применить обобщение на этапе feature engineering и задокументировать метод в политике обработки ПДн. Это снижает УЗ и сокращает состав обязательных мер ФСТЭК.

Мультиарендность SaaS и поручение обработки: кто оператор в ML-системе?

В мультиарендной SaaS архитектуре вопрос о разграничении ролей оператора и обработчика критичен для распределения ответственности по 152-ФЗ. Ст. 6 ФЗ-152 устанавливает конструкцию поручения обработки: оператор (ваш клиент) поручает обработку ПДн обработчику (SaaS-провайдеру) на основании договора.

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

Облако в РФ: требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на все операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан РФ. Если ML-платформа (обучение, инференс, хранение весов) размещена на серверах за пределами РФ и обрабатывает ПДн российских граждан — это нарушение с санкцией по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. Для KII (критической информационной инфраструктуры по 187-ФЗ) требования к размещению ещё жёстче.

Типовые сценарии нарушений в ML-pipeline

Сценарий 1. Обучение на сырых данных без обезличивания. IT-компания (Сибирский ФО, весна 2025) обучала модель прогнозирования оттока на выгрузке из CRM: имена, телефоны, история транзакций. Датасет хранился в S3-бакете без шифрования и контроля доступа. РКН обнаружил факт при плановой проверке. Компании выставили протокол по ч. 1 ст. 13.11 КоАП и предписание о приведении ИСПДн в соответствие с Приказом ФСТЭК №21. Срок устранения — 30 дней. Штраф по итогу — в диапазоне сотен тысяч рублей. Стратегия при схожей ситуации: немедленно задокументировать меры обезличивания, которые уже применяются де-факто, и предъявить их инспектору до составления постановления.

Сценарий 2. Мультиарендная SaaS и дообучение на данных клиентов. SaaS-провайдер HR-аналитики (Центральный ФО, осень 2025) использовал поведенческие данные сотрудников всех клиентов для дообучения модели оценки вовлечённости. Договоры поручения обработки не предусматривали такого использования. Один из клиентов-операторов провёл собственный аудит и выявил нарушение. Претензия клиента переросла в уведомление РКН. Риск провайдера — ч. 1 ст. 13.11 КоАП (несовместимость целей по ст. 5 ФЗ-152) и расторжение договоров. Стратегия: прописать в договоре поручения явный запрет на агрегацию данных арендаторов без отдельного согласия и технически изолировать обучающие датасеты по клиентам.

Сценарий 3. Облако за рубежом и требование локализации. Финтех-стартап (Северо-Западный ФО, начало 2026) разворачивал ML-платформу на AWS EU (Франкфурт) для снижения латентности. Данные российских пользователей обрабатывались и хранились за пределами РФ. Нарушение ч. 5 ст. 18 ФЗ-152 — штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. При повторном нарушении — от 6 до 18 млн ₽ по ч. 9. Стратегия: миграция ML-компонентов на российский облачный провайдер или гибридная схема с обезличиванием данных до передачи за рубеж.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

ML-pipeline — полноценная ИСПДн в смысле 152-ФЗ. Четыре точки риска — data lake, feature store, артефакты модели и логи экспериментов — требуют отдельного анализа по матрице ПП РФ №1119 и привязки к конкретному УЗ. Обезличивание снимает требования закона, но только если оно необратимо и выполнено методами, утверждёнными РКН. Мультиарендность и иностранные облака создают самостоятельные составы нарушений.

DATUM сопровождает аудиты ML-инфраструктуры IT-компаний и SaaS-провайдеров: определение УЗ, формирование модели угроз, разработка политики обезличивания, подготовка договоров поручения обработки. Аудит соответствия 152-ФЗ — от 100 000 ₽, DPIA — от 200 000 ₽.

5 июня 2026 года