DATUM-сопровождение ИИ-проектов

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420: 18 частей, оборотный штраф при повторной утечке до 500 млн ₽. Одновременно с 11.12.2024 работает ст. 272.1 УК — уголовная ответственность за незаконное использование компьютерной информации с ПДн, максимум по ч. 5 — 10 лет лишения свободы. Для ИИ-проекта это означает, что каждый этап пайплайна — сбор, хранение датасета, обучение, инференс, логирование — создаёт отдельную точку правового риска. В этой статье разберём: как определить уровень защищённости для ML-системы, что требует ФСТЭК, как легально обезличивать данные для обучения моделей и кто несёт ответственность в мультиарендной SaaS-архитектуре.

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

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

Если датасет содержит только общие ПДн (ФИО, email, поведенческие паттерны), число субъектов превышает 100 000 и угрозы 2-го типа — система попадает в УЗ-3. При угрозах 1-го типа (недекларированные возможности системного ПО) — УЗ-2. Если в датасет включены медицинские записи, сведения о здоровье или биометрия — автоматически подключается спецкатегория по ст. 10 ФЗ-152, и при угрозах 2-го типа система получает УЗ-2 или УЗ-1.

Ошибка при классификации угрозы в меньшую сторону — это занижение УЗ и, как следствие, неполный набор защитных мер по Приказу ФСТЭК №21. Роскомнадзор при проверке сопоставляет задекларированный УЗ с фактической архитектурой. Расхождение — основание для предписания и протокола по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽ для юрлица в редакции с 30.05.2025).

Практический алгоритм для CTO: составить карту потоков ПДн внутри ML-пайплайна (источник → ETL → датасет → обучение → модель → инференс → логи), для каждого узла определить категорию данных и число субъектов, установить тип угроз на основании анализа архитектуры, зафиксировать УЗ в акте классификации ИСПДн.

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

Приказ ФСТЭК №21 от 18.02.2013 устанавливает 15 групп мер защиты. Базовый набор зависит от УЗ: чем выше уровень, тем больше мер из каждой группы становятся обязательными. Для ML-систем критически важны четыре группы.

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

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

Для SaaS-архитектуры с мультиарендностью (multi-tenancy) добавляется требование изоляции данных между тенантами на уровне хранилища. Использование единого S3-бакета с разграничением только на уровне приложения без шифрования по отдельным ключам — типичная уязвимость, которую ФСТЭК фиксирует при проверке. Сертифицированные средства защиты (МЭ, СОВ, антивирус) требуются только при УЗ-1 и УЗ-2 для государственных систем; коммерческие операторы при УЗ-3 вправе применять несертифицированные СЗИ с подтверждённым функционалом.

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

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

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

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

Для градиентного бустинга и деревьев решений агрегация (группировка возраста по десятилетиям, региона по федеральному округу) часто достаточна и не снижает качество модели. Для нейросетевых архитектур с точечными признаками — применяется декомпозиция с добавлением дифференциальной приватности (differential privacy) как дополнительной технической меры.

Кто несёт ответственность за ПДн в мультиарендной SaaS и при поручении обработки?

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

Следствие: SaaS-компания обязана заключить договор поручения с каждым тенантом, в котором перечислены: состав ПДн, цели обработки, срок, обязанность уничтожить данные по окончании договора, меры защиты не ниже требований оператора. Если договора нет — SaaS-компания сама становится оператором без правового основания, что квалифицируется по ч. 1 ст. 13.11 КоАП.

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

Для КИИ-объектов (ФЗ-187) дополнительно применяются требования по категорированию и защите значимых объектов КИИ. Если ML-система обрабатывает данные в рамках КИИ-инфраструктуры — требования ФСТЭК по защите КИИ и требования по ИСПДн действуют параллельно и не заменяют друг друга.

Практические сценарии: где CTO теряет защиту и как это выглядит для РКН

Сценарий 1. Датасет с ПДн хранится в иностранном облаке. Команда использует AWS S3 или Azure Blob для хранения обучающей выборки. С 01.07.2025 (ФЗ-233) запись, систематизация, накопление и хранение ПДн граждан РФ должны осуществляться только в базах данных на территории РФ (ч. 5 ст. 18 ФЗ-152). Датасет на зарубежном хранилище — прямое нарушение. Штраф по ч. 8 ст. 13.11 КоАП: 1–6 млн ₽ для юрлица. При повторном нарушении по ч. 9: 6–18 млн ₽. Стратегия: перенести хранилище датасетов и резервных копей в облако, расположенное в РФ (Yandex Cloud, SberCloud, VK Cloud). Трансграничная передача для обработки моделью за рубежом требует отдельного уведомления РКН по ст. 12 ФЗ-152.

Сценарий 2. Логи инференса содержат ПДн без правового основания. Сервис логирует запросы к модели «на всякий случай» в Elasticsearch или ClickHouse. Если запрос содержит имя, email или идентификатор пользователя — лог является базой ПДн. Правовое основание для хранения логов должно быть зафиксировано. Если его нет — нарушение ст. 5 ФЗ-152 (принцип минимизации) и основание для штрафа по ч. 1 ст. 13.11. Стратегия: анонимизировать запросы на уровне прокси перед логированием либо установить срок хранения логов и правовое основание в политике хранения данных.

Сценарий 3. Подрядчик по разработке модели получил доступ к датасету без договора поручения. ML-команда на аутсорсе работает с production-данными напрямую. Ответственность за утечку через подрядчика несёт оператор (принцип ВС РФ: оператор отвечает за действия лица, которому поручил обработку). Если утечка произошла — оператор платит штраф по ч. 12–14 ст. 13.11 (от 3 до 15 млн ₽ в зависимости от масштаба). Стратегия: договор поручения с подрядчиком по ст. 6 ч. 3 ФЗ-152, предоставление доступа только к обезличенным данным, аудит доступов в логах.

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

Кейс 1. IT-компания (Уральский ФО, осень 2025) разрабатывала рекомендательную систему на основе поведенческих данных пользователей e-commerce клиента. Датасет хранился в S3-совместимом облаке европейского провайдера. После внеплановой проверки РКН по жалобе субъекта технический директор получил предписание о переносе данных в РФ. Компания выполнила предписание в установленный срок, перенесла хранилище в российское облако и заключила договор поручения обработки с клиентом. Административное дело прекращено в связи с устранением нарушения до вынесения постановления.

Кейс 2. SaaS-платформа для HR-аналитики (Центральный ФО, начало 2026) обучала модель прогнозирования текучести на данных всех тенантов без их согласия и без договора поручения. При аудите выявлено: обработка ПДн без правового основания (ч. 1 ст. 13.11), отсутствие договоров поручения с тенантами (ч. 1 ст. 13.11 как самостоятельное нарушение). Суммарный риск — два протокола на общую сумму в пределах 300–600 тыс. ₽ по действующим нормам. После вмешательства юристов DATUM: разработан договор поручения для каждого тенанта, ML-пайплайн переведён на обезличенные агрегаты, проведён аудит правовых оснований для каждого источника данных.

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

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

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

1. Какой УЗ выбрать для SaaS с персональными данными пользователей?

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

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

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

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

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

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

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

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

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

Итог

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

DATUM сопровождает ИИ-проекты на всех этапах: от классификации ИСПДн и установления УЗ до договоров поручения, методологии обезличивания и DPIA. Практика охватывает ML-платформы, SaaS с мультиарендностью и КИИ-смежные системы.

4 марта 2029 года