DATUM-аудит ML-инфраструктуры

Для CTO задача выглядит технической: выбрать облако, настроить pipeline, обеспечить latency. Но каждый этап ML-обучения — сбор фичей, хранение датасетов, логирование инференса — это обработка персональных данных по смыслу ст. 3 ФЗ-152. С 30.05.2025 регулирование ужесточилось: ст. 13.11 КоАП расширена до 18 частей (ФЗ-420 от 30.11.2024), ст. 272.1 УК действует с 11.12.2024. Эта статья объясняет, как DATUM-аудит ML-инфраструктуры выявляет разрывы между архитектурными решениями и требованиями 152-ФЗ.

Почему ML-инфраструктура попадает под 152-ФЗ?

Технический директор нередко считает, что закон о персональных данных касается только CRM и HR-систем. На практике под действие ФЗ-152 подпадает любая система, где обрабатываются данные, прямо или косвенно идентифицирующие физическое лицо. В ML-стеке таких точек несколько.

Первая — обучающий датасет. Если он содержит записи транзакций, профили пользователей, историю запросов или медицинские показатели — это персональные данные по ст. 3 ФЗ-152. Обезличивание с помощью удаления полей «ФИО» и «email» не делает данные анонимными: Роскомнадзор признаёт данные персональными, если их можно реидентифицировать с использованием доступных источников.

Вторая точка — логи инференса. Запросы к модели в реальном времени часто содержат поведенческие паттерны, геолокацию, IP-адреса или прямые пользовательские данные. По позиции РКН, IP-адрес в сочетании с иными атрибутами — персональные данные.

Третья — векторные эмбеддинги. Встраивание (embedding) пользовательского профиля сохраняет статистическую корреляцию с исходными данными. Хранение векторов без надлежащего обезличивания создаёт самостоятельный риск.

Из этого следует: ML-pipeline — это информационная система персональных данных (ИСПДн). Для неё обязательно определить уровень защищённости по ПП РФ №1119 и применить соответствующий набор мер по Приказу ФСТЭК №21.

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

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

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

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

Практическая ошибка CTO: назначить УЗ-4 по умолчанию, не проводя формальную модель угроз. Если в ходе проверки РКН или ФСТЭК будет установлено, что реальный УЗ выше, это создаёт основание для предписания и штрафа по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽ за первичное нарушение, 300 000–500 000 ₽ при повторности).

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

Приказ ФСТЭК №21 от 18.02.2013 устанавливает 109 мер защиты в 15 группах. Для ML-стека наиболее уязвимы четыре группы.

Идентификация и аутентификация (ИАФ). Доступ к обучающим датасетам и хранилищам векторов должен контролироваться через многофакторную аутентификацию. Сервисные аккаунты MLOps-оркестраторов (Airflow, Prefect, Kubeflow) часто имеют избыточные права — это прямая уязвимость.

Регистрация событий (РСБ). Логирование обращений к моделям и датасетам обязательно. Важный нюанс: сами логи могут содержать ПДн (запросы пользователей, идентификаторы сессий). Логи — это тоже ИСПДн с соответствующим УЗ.

Защита машинных носителей информации (ЗНИ). Checkpoint'ы весов модели, экспортированные датасеты на S3-совместимых хранилищах — всё это носители, которые должны шифроваться при хранении и передаче.

Управление конфигурацией (УКФ). Docker-образы с зависимостями, Helm-чарты, Terraform-конфиги — изменения должны фиксироваться и авторизовываться. Неконтролируемые изменения конфигурации ИСПДн нарушают требования УЗ.

Для SaaS с мультиарендной архитектурой (multi-tenant) добавляется требование изоляции данных между арендаторами. Если ML-модель обучается на смешанном датасете нескольких клиентов — это нарушает принцип конкретных целей и недопустимого объединения баз по ст. 5 ФЗ-152.

Обезличивание для ML: что считается достаточным?

Обезличивание — ключевой инструмент снижения рисков при работе с ML-данными. Правильно обезличенные данные выходят из-под части требований ФЗ-152, поскольку перестают быть персональными.

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

• Введение идентификаторов — замена ФИО, email, телефона на суррогатный ключ. Применяется в feature store при подготовке обучающего датасета.
• Обобщение (агрегация) — замена точных значений диапазонами: возраст «34» → «30–39», доход «87 420 ₽» → «80 000–100 000 ₽». Снижает точность модели, но устраняет риск реидентификации.
• Декомпозиция — разделение атрибутов по разным хранилищам без прямой связи. Классическая схема: ML-модель получает только агрегированные фичи, ключ соответствия хранится в изолированной базе.

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

Облако и локализация: где можно обучать ML-модель?

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

С 01.07.2025 (ФЗ-233) требования к локализации ужесточены: первичный сбор данных гражданина РФ также должен осуществляться на российской инфраструктуре. Использование зарубежных GPU-облаков (AWS, GCP, Azure, Lambda Labs) для первичной обработки пользовательских данных создаёт нарушение ч. 8 ст. 13.11 КоАП — штраф 1–6 млн ₽; при повторности — ч. 9, 6–18 млн ₽.

Допустимые сценарии для CTO:

• Хранение и обработка данных — в российском облаке (Yandex Cloud, VK Cloud, SberCloud, Selectel). Обучение на иностранных GPU — только если данные прошли достаточное обезличивание до передачи.
• Трансграничная передача данных в страну без адекватной защиты требует предварительного уведомления РКН по ст. 12 ФЗ-152. Американские и европейские облака — не в перечне адекватных стран по умолчанию.
• Федеративное обучение (federated learning) — потенциально безопасный подход: градиенты, а не сырые данные, передаются на внешние серверы. Но реализация требует правовой оценки.

Поручение обработки в ML-стеке: кто оператор, кто обработчик?

В мультиарендной SaaS возникает типовой правовой вопрос: если платформа обучает модели на данных клиентов — кто является оператором ПДн? Ответ зависит от архитектуры и договора.

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

Практическое следствие: договор с ML-платформой или облачным провайдером должен содержать явное поручение с перечнем разрешённых действий. Без договора поручения оператор не снимает с себя ответственность за действия платформы — это подтверждается сложившейся практикой ВС РФ по принципу ответственности оператора за утечку через подрядчика.

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

Сценарий 1. Обучение модели на production-данных без обезличивания. Ситуация: CTO подключил production PostgreSQL к Spark-кластеру для обучения модели рекомендаций. Данные содержат email, историю покупок, геолокацию — более 500 000 субъектов. Доказательства нарушения: отсутствие модели угроз, нет договора поручения с провайдером кластера, нет мер УЗ-3. Вероятный исход: при утечке — ч. 13 ст. 13.11 КоАП, штраф 5–10 млн ₽. Стратегия: до запуска следующего обучения — провести DPIA, составить модель угроз, применить обезличивание фичей.

Сценарий 2. GPU-облако за рубежом без уведомления РКН о трансграничной передаче. Ситуация: команда ML-инженеров использует AWS SageMaker (регион eu-west-1) для дообучения LLM на данных российских пользователей. Трансграничная передача не уведомлена, локализация нарушена. Доказательства: S3-бакеты с датасетом находятся вне РФ. Вероятный исход: ч. 8 ст. 13.11 КоАП, штраф 1–6 млн ₽ за локализацию + предписание перенести данные. Стратегия: перенести первичное хранение в российское облако, использовать зарубежные GPU только для обезличенных данных с уведомлением.

Сценарий 3. Логи инференса как необезличенные ПДн. Ситуация: стартап развернул ML-сервис для B2B-клиентов. Логи запросов к модели содержат пользовательские данные клиентов. Лог-агрегатор (Elastic Cloud, регион вне РФ) не охвачен договором поручения. Доказательства: логи хранятся за рубежом, договора поручения нет, уведомление в реестре РКН отсутствует. Вероятный исход: совокупность нарушений — ч. 1 ст. 13.11 (150–300 тыс.) + ч. 8 (1–6 млн) + ч. 10 за отсутствие уведомления (100–300 тыс.). Стратегия: немедленно подать уведомление в РКН, перенести лог-хранилище в РФ или обеспечить обезличивание на стороне ML-сервиса до передачи в агрегатор.

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

Кейс 1. Финтех-компания (Центральный ФО, осень 2025) обратилась в DATUM после получения предписания РКН по итогам плановой проверки. Проверка выявила обучение скоринговой модели на необезличенных данных заёмщиков в количестве более 200 000 субъектов без актуальной модели угроз и без мер УЗ-3. DATUM провёл экстренный аудит за 10 рабочих дней, подготовил модель угроз, согласовал план устранения с РКН и обеспечил защиту от штрафа в диапазоне нескольких миллионов рублей за счёт демонстрации принятых мер.

Кейс 2. SaaS-платформа для HR-аналитики (Северо-Западный ФО, начало 2026) использовала AWS Glue (регион eu-central-1) для ETL-обработки данных российских сотрудников клиентов. После консультации с DATUM CTO перенёс хранилище в Yandex Cloud, заключил договоры поручения с 14 облачными провайдерами и сервисами, получил статус обработчика по договорам с клиентами-операторами. Риск нарушения ч. 8 ст. 13.11 КоАП (1–6 млн ₽) был устранён до возбуждения дела.

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

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

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

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

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

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

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

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

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

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

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

5. Какие средства защиты информации (СЗИ) обязательны для ML-системы?

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

Итог

ML-инфраструктура — это полноценная ИСПДн с обязательным уровнем защищённости, требованиями локализации и ограничениями на трансграничную передачу. Обучающие датасеты, логи инференса и векторные хранилища подпадают под ФЗ-152 в той мере, в которой содержат идентифицирующие атрибуты. С 30.05.2025 стоимость ошибки выросла: ч. 8 ст. 13.11 КоАП за локализацию — до 6 млн ₽, ч. 13 за утечку — до 10 млн ₽, ч. 15 при повторности — до 500 млн ₽.

DATUM проводит аудит ML-инфраструктуры по чек-листу из 38 пунктов: от определения УЗ и модели угроз до проверки договоров поручения с облачными провайдерами и валидации методов обезличивания. Практика по технической стороне 152-ФЗ ведётся с 2014 года.

14 января 2030 года