Тренировочные датасеты: правовые требования

С 01.09.2025 согласие на обработку ПДн — отдельный документ (ФЗ-156). С 01.07.2025 первичная запись ПДн граждан РФ должна происходить только в базах на территории страны (ч. 5 ст. 18 ФЗ-152 в редакции ФЗ-233). Оба изменения напрямую затрагивают ML-пайплайны: датасеты собираются из продакшн-БД, облако нередко иностранное, а роль оператора или обработчика в мультиарендной SaaS-архитектуре до сих пор не зафиксирована в договорах. Эта статья разбирает три уровня требований — классификацию ИСПДн, меры защиты и правила обезличивания — применительно к тренировочным датасетам в IT-продуктах.

Как определить уровень защищённости датасета?

Основание — ПП РФ №1119 от 01.11.2012. Классификация зависит от трёх параметров: категория ПДн, тип актуальных угроз и число субъектов. Для тренировочного датасета порог 100 000 субъектов принципиален: если датасет содержит данные более 100 000 пользователей, нижняя граница уровня защищённости сдвигается вверх.

Категории ПДн в датасетах чаще всего распределяются так:

• Поведенческие события (клики, время сессии, устройство) — общие ПДн при наличии идентификатора пользователя.
• Геолокация, история покупок, финансовые события — общие ПДн с повышенной чувствительностью; могут раскрывать сведения об интимной жизни (ст. 10 ФЗ-152).
• Данные о состоянии здоровья, диагнозы, результаты анализов — специальные категории; обработка запрещена без прямого основания из п. 2 ст. 10 ФЗ-152.
• Голос, изображение лица, ДНК, отпечатки — биометрические ПДн по ст. 11 ФЗ-152; для ML-моделей распознавания — самый жёсткий режим.

Угрозы 1-го типа предполагают наличие недокументированных (недекларированных) возможностей в системном ПО. На практике большинство коммерческих SaaS-платформ принимают угрозы 3-го типа как актуальные — это снижает требуемый уровень. Но если инфраструктура подпадает под критическую информационную инфраструктуру (ФЗ-187 о КИИ), угрозы 1-го и 2-го типа становятся актуальными по умолчанию.

Итоговый уровень УЗ фиксируется в акте классификации ИСПДн — документе, который при проверке РКН или ФСТЭК запрашивается первым.

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

Приказ ФСТЭК №21 от 18.02.2013 определяет базовый набор организационных и технических мер для каждого уровня УЗ. Всего 15 групп мер, 109 позиций. Для тренировочных датасетов наиболее критичны следующие группы.

Идентификация и аутентификация (ИАФ). Доступ к датасету — только авторизованным субъектам. В ML-пайплайне это означает ролевую модель доступа: дата-инженер, ML-инженер, аналитик — разные роли с разными правами. Токен сервисного аккаунта с правами на чтение всей БД пользователей нарушает требования ИАФ для УЗ-3 и выше.

Регистрация событий (РСБ). Логирование операций с ПДн обязательно начиная с УЗ-4. Журнал доступа к датасету — обработка ПДн. Если лог содержит идентификаторы пользователей и хранится в системе мониторинга (ELK, Grafana), он сам становится ИСПДн и требует классификации.

Защита носителей информации (ЗНИ). Датасет в формате Parquet или CSV на S3-совместимом хранилище — носитель ПДн. Шифрование at-rest обязательно для УЗ-1 и УЗ-2. Для УЗ-3 шифрование at-rest входит в базовый набор при угрозах, связанных с несанкционированным физическим доступом.

Антивирусная защита (АВЗ) и обнаружение вторжений (СОВ). Применяются к серверным компонентам, где хранится или обрабатывается датасет. Если датасет в облаке — использование облачного провайдера не снимает с оператора ответственность за соответствие мер Приказу №21.

Отдельный вопрос — использование иностранных облаков. После ужесточения требований к локализации с 01.07.2025 первичная запись, систематизация и хранение ПДн граждан РФ возможны только в базах на территории РФ. Это означает: если тренировочный датасет формируется из продакшн-данных российских пользователей и первичная запись происходит в AWS eu-west или GCP us-central — возникает нарушение ч. 5 ст. 18 ФЗ-152, штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽.

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

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

Пять методов по Приказу РКН (методы обезличивания):

• Введение идентификаторов. Замена прямых идентификаторов (ФИО, email, телефон) на суррогатный ключ. Таблица соответствия хранится отдельно, доступ к ней ограничен. В ML-контексте — разумный выбор для поведенческих датасетов.
• Изменение состава или семантики. Обобщение значений: возраст вместо даты рождения, регион вместо адреса, диапазон дохода вместо суммы. Применяется при агрегации для аналитических моделей.
• Декомпозиция. Разделение датасета на несвязанные части; каждая часть не позволяет идентифицировать субъекта без объединения с другой. Актуально для распределённых систем обучения (federated learning).
• Перемешивание. Нарушение связи между атрибутами одного субъекта. Подходит для статистических моделей, где важны распределения, а не индивидуальные профили.
• Обобщение и агрегация. Группировка субъектов по общим признакам; индивидуальные записи заменяются агрегатами. Применяется для рекомендательных систем на основе кластеров.

Ключевая практическая ловушка — псевдонимизация без полного обезличивания. Замена email на хэш SHA-256 без salt не является обезличиванием: при наличии исходной базы реидентификация тривиальна. Российский регулятор в этом вопросе следует позиции, аналогичной EDPB: псевдонимизация — это мера защиты, но не обезличивание. Датасет с хэшированными идентификаторами остаётся ИСПДн.

Кто несёт ответственность в мультиарендной SaaS?

Мультиарендная SaaS-архитектура (multi-tenant) создаёт нетривиальную ситуацию: данные нескольких клиентов-операторов хранятся в одной инфраструктуре. Правовая квалификация зависит от договорной конструкции.

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

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

Сценарий 3. ML-датасет из агрегированных данных нескольких арендаторов. Обучение общей модели на данных нескольких клиентов без их согласия и без надлежащего обезличивания — нарушение принципа несовместимости целей (ст. 5 ФЗ-152) и возможное нарушение условий поручения. Риск: штраф по ч. 1 ст. 13.11 КоАП (до 300 000 ₽) и гражданско-правовые иски клиентов за нарушение условий SLA.

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

Кейс 1. IT-компания (Сибирский ФО, осень 2025) обучала рекомендательную модель на поведенческих данных 2,3 млн пользователей мобильного приложения. Датасет хранился в S3-бакете иностранного облака. При внутреннем аудите выявлено: акт классификации ИСПДн отсутствовал, шифрование at-rest не было настроено, данные не обезличены. Компания самостоятельно перенесла хранилище в российский облачный провайдер, применила метод введения идентификаторов и подала уведомление в РКН. Административное дело возбуждено не было, поскольку перенос завершён до получения запроса от регулятора.

Кейс 2. SaaS-провайдер (Центральный ФО, начало 2026) предоставлял CRM нескольким клиентам — операторам ПДн. В договорах отсутствовало условие о поручении обработки. При проверке РКН выявлено, что провайдер самостоятельно агрегировал данные клиентов для обучения модели классификации обращений. РКН квалифицировал действия как обработку ПДн без надлежащего основания (ч. 1 ст. 13.11 КоАП). Штраф — в сотнях тысяч рублей. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Тренировочный датасет с персональными данными — это ИСПДн с требованиями по классификации, мерам защиты и обезличиванию. Использование реальных ПДн без надлежащего обезличивания или хранение датасета в иностранном облаке создаёт риски по ч. 1, ч. 8 ст. 13.11 КоАП с суммарным штрафом до 6,3 млн ₽ при первичном нарушении. Мультиарендная SaaS-архитектура требует явной договорной фиксации роли провайдера — обработчик или оператор.

DATUM сопровождает IT-компании и SaaS-платформы в классификации ИСПДн, разработке моделей угроз, проведении DPIA для ML-пайплайнов и формировании договорной базы поручения обработки. Специализация — технические и правовые требования 152-ФЗ для продуктовых команд.