Чек-лист 152-ФЗ для ML-команды

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024: 18 частей, оборотный штраф до 500 млн ₽ при повторной утечке. ML-инфраструктура — облака, векторные базы, датасеты, логи — остаётся зоной повышенного риска для CTO: данные субъектов перемещаются между контурами, обработчики меняются, правовое основание формулируется по остаточному принципу. Ниже — системный разбор по 9 ключевым позициям: от выбора уровня защищённости до оборотных рисков при повторном инциденте.

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

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

Типичная ошибка ML-команды — занижение уровня путём формального дробления датасета: «у нас два датасета по 80 000 строк, значит порог 100 000 не достигнут». РКН при проверке рассматривает совокупность ИСПДн одного оператора. Занижение уровня защищённости ведёт к недостаточному набору мер по Приказу ФСТЭК №21 и создаёт состав по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽ за первичное нарушение, 300 000–500 000 ₽ при повторном по ч. 1.1).

Для рекомендательных систем e-commerce с поведенческими профилями (покупки + геолокация + устройство) применимо рассмотрение как обработки специальных категорий через косвенные признаки. Это спорная позиция, но РКН её придерживается при плановых проверках. Безопаснее присваивать УЗ-3 и не оспаривать.

Как правильно обезличить данные для обучения ML-модели?

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

Для ML-команды критичны три практических следствия:

• Псевдонимизация (замена имени на UUID) — не является обезличиванием по ст. 13.1, если оператор хранит таблицу соответствия. Продолжает действовать режим ПДн в полном объёме.
• Дифференциальная приватность (добавление статистического шума) — не включена в российский перечень методов напрямую. Применять допустимо как дополнительную меру, но не как самостоятельное основание для вывода данных из-под ФЗ-152.
• Данные, переданные в ЕИП НСУД по требованию Минцифры согласно ст. 13.1 ФЗ-152, должны быть обезличены именно по утверждённым методам — иначе оператор несёт риск по ч. 1 ст. 13.11 КоАП.

Рабочий подход для ML-датасетов: обобщение категориальных атрибутов (возраст → возрастной диапазон, регион → федеральный округ) плюс введение суррогатных идентификаторов вместо прямых личных данных, плюс декомпозиция — разделение атрибутивной части и транзакционной на разные хранилища без общего ключа-идентификатора. Этот набор покрывает три из пяти методов и воспроизводится при проверке.

Кто является оператором в мультиарендной SaaS с ML-функциями?

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

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

Риск мультиарендности: один инцидент в shared-инфраструктуре затрагивает ПДн субъектов нескольких арендаторов одновременно. При утечке от 100 000 субъектов суммарно по всем арендаторам применяется ч. 14 ст. 13.11 КоАП — штраф 10–15 млн ₽ для юрлица. При повторности — оборотный штраф по ч. 15: 1–3% совокупной годовой выручки, не менее 20 млн ₽, не более 500 млн ₽.

Можно ли использовать иностранные облака для хранения и обучения?

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

Иностранное облако допустимо в трёх сценариях:

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

Нарушение требования локализации — ч. 8 ст. 13.11 КоАП: штраф 1–6 млн ₽ при первичном. Повторное — ч. 9: 6–18 млн ₽. Под «повторным» понимается нарушение в течение года после вступления в силу предыдущего постановления о штрафе.

Какие технические меры обязательны по Приказу ФСТЭК №21?

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

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

• РСБ — регистрация событий (логирование): логи доступа к датасетам, логи запросов к API модели, логи экспорта признаков — должны сохраняться в защищённом хранилище без возможности изменения. Сами логи, содержащие ПДн субъектов (имя пользователя, IP, идентификатор сессии), являются ПДн и требуют собственного правового основания.
• ЗСВ — защита среды виртуализации: контейнеры и оркестраторы (Kubernetes, Docker) входят в периметр ИСПДн при обработке ПДн внутри них. Изоляция рабочих нагрузок по УЗ — обязательное требование.
• УПД — управление доступом: разграничение доступа к датасетам по принципу минимальных привилегий; запрет прямого доступа дата-сайентистов к продакшен-базам без процедуры выдачи доступа через тикетинг-систему с журналом.

Логирование как источник ПДн — отдельная юридическая проблема. Если в лог попадают IP-адреса, device fingerprint, идентификаторы пользователей — это ПДн по позиции РКН. Хранить такие логи без правового основания по ст. 6 ФЗ-152 нельзя. Типовое решение: хранение логов на основании легитимного интереса оператора (п. 7 ч. 1 ст. 6) с минимальным сроком хранения и последующим обезличиванием или удалением.

Как выглядит инцидент с ПДн в ML-системе на практике?

Кейс 1. Финтех-компания в Северо-Западном ФО (осень 2025) использовала shared Jupyter-инфраструктуру: несколько дата-сайентистов работали с продакшен-срезами клиентских данных (ФИО, номер счёта, паттерн транзакций) на одном сервере без разграничения доступа. Один из подрядчиков экспортировал датасет во внешнее хранилище без уведомления. CTO обнаружил инцидент через 38 часов после события. Первичное уведомление в РКН было направлено с нарушением 24-часового срока по ч. 3.1 ст. 21 ФЗ-152. РКН возбудил производство по ч. 11 ст. 13.11 КоАП (неуведомление об утечке) — диапазон штрафа 1–3 млн ₽. Параллельно возбуждено дело по ч. 1 ст. 13.11 за отсутствие поручения обработки с подрядчиком. По обоим эпизодам компания применила смягчающие обстоятельства, в том числе последующее внедрение технических мер, и добилась снижения до нижней границы диапазонов.

Кейс 2. SaaS-платформа управления персоналом (Центральный ФО, начало 2026) с NLP-модулем анализа резюме хранила эмбеддинги кандидатов в векторной базе данных. Векторные представления содержали косвенные признаки специальных категорий (предполагаемый этнический профиль по паттернам имён). При аудите выяснилось, что векторная база классифицирована как ИСПДн общих ПДн с УЗ-4, хотя косвенные признаки спецкатегорий потребовали бы УЗ-2. Дополнительно отсутствовало правовое основание для профилирования по ст. 16 ФЗ-152 (автоматизированные решения). До проверки РКН компания провела повторную классификацию, сменила облачного провайдера на российского и получила DPIA — расходы составили сотни тысяч рублей, что значительно меньше потенциального штрафа по ч. 13 ст. 13.11 КоАП (5–10 млн ₽ при утечке данных 10 000–100 000 субъектов).

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

DATUM сопровождает ML-команды и IT-компании при аудите ИСПДн, разработке модели угроз, проведении DPIA и подготовке полного комплекта ОРД, включая договоры поручения обработки с облачными провайдерами и подрядчиками по разработке.

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