Train/test split с обезличиванием

С 01.09.2025 в силу вступил Приказ РКН, закрепивший пять методов обезличивания для использования операторами. Одновременно ФЗ-233 от 08.08.2024 ввёл в ФЗ-152 ст. 13.1 — регулирование обезличенных данных, включая передачу в ЕИП НСУД. В этой ситуации вопрос «как разрезать датасет для обучения и не нарушить закон» перестал быть теоретическим: от ответа зависит уровень защищённости системы, состав технических мер и правовой статус данных в каждой выборке.

Почему train/test split остаётся обработкой персональных данных?

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

Критический момент: обезличивание должно предшествовать созданию выборок, а не следовать за ними. Если сначала сделан split, а затем предпринята попытка «замазать» поля в каждой части по отдельности — связность между train и test сохраняется на уровне индексов и идентификаторов строк. Такая схема не даёт правовой защиты обезличенности.

Следствие для CTO: перед формированием датасета нужен явный ответ на вопрос, достигается ли цель обучения без прямых идентификаторов. Если да — обезличивание обязательно до начала любой обработки для ML-задач. Если нет (например, модель предсказывает индивидуальный риск конкретного клиента) — применяются нормы о специальных категориях, автоматизированных решениях и, при необходимости, DPIA.

Какой уровень защищённости (УЗ) определяет требования к ML-инфраструктуре?

ПП РФ №1119 устанавливает четыре уровня защищённости ИСПДн. Уровень определяется пересечением трёх параметров: категория ПДн (общие / специальные / биометрические), тип угроз (1–3) и количество субъектов (порог — 100 000).

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

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

Для ML-инфраструктуры ключевые группы мер — РСБ (регистрация событий безопасности) и ЗНИ (защита носителей информации). Датасеты, контрольные выборки и веса обученных моделей — это носители, содержащие производные от ПДн. Даже если исходные данные обезличены, журналы экспериментов MLflow или DVC могут содержать персональные идентификаторы в метаданных.

Как правильно применить обезличивание перед формированием датасета?

Приказ РКН (действует с 01.09.2025) закрепляет пять методов обезличивания. Для ML-задач применимы не все одинаково — выбор метода влияет на качество модели и юридическую оценку результирующего датасета.

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

Ключевой технический риск при train/test split — утечка признаков (data leakage). При обезличивании методом введения идентификаторов псевдоним одного субъекта может присутствовать одновременно в train и test. Это допустимо с точки зрения качества модели (temporal split решает проблему по-другому), но создаёт риск реидентификации через корреляцию признаков между выборками. Надёжная схема: обезличивание → перетасовка → split, а не split → обезличивание каждой части отдельно.

Что меняет SaaS-мультиарендность и облако в вопросе ответственности оператора?

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

Такая схема нарушает принцип несовместимости целей по ст. 5 ФЗ-152: данные, переданные платформе для оказания услуги конкретному арендатору, не могут без отдельного правового основания использоваться для обучения модели в интересах самой платформы или других арендаторов. Необходимо либо получить отдельное согласие каждого субъекта на такую обработку (ст. 9 ФЗ-152 в редакции с 01.09.2025 — отдельный документ), либо обеспечить полное обезличивание до агрегации.

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

Как это работает на практике: три сценария для CTO

Сценарий 1. Обучение модели рекомендаций на транзакционных данных e-commerce. Компания (Центральный ФО, лето 2025) использовала историю покупок 2 млн пользователей для обучения рекомендательной системы. Датасет хранился в облаке зарубежного провайдера без договора поручения обработки и без предшествующего обезличивания. При плановой проверке РКН инспектор установил нарушение ч. 5 ст. 18 ФЗ-152 (локализация) и отсутствие документа о методе обезличивания. Возбуждены дела по ч. 8 ст. 13.11 (локализация, 1–6 млн ₽) и ч. 1 ст. 13.11 (несовместимые цели, 150–300 тыс. ₽). Обезличивание методом введения идентификаторов с переносом датасета в российское облако позволило урегулировать ч. 8 в досудебном порядке. ⚠️ Конкретный номер дела и точная сумма штрафа — менеджер уточняет при публикации.

Сценарий 2. Федеративное обучение в B2B SaaS. Разработчик аналитической платформы (Северо-Западный ФО, осень 2025) предложил арендаторам участвовать в федеративном обучении общей модели аномалий. Данные арендаторов не покидали их контуры — градиенты передавались на центральный сервер. Юридически схема корректна при условии: каждый арендатор оформил поручение обработки платформе в части агрегации градиентов, а не исходных данных; в уведомлении РКН по ст. 22 ФЗ-152 указана цель «совершенствование ML-моделей»; декомпозиция данных задокументирована как применённый метод обезличивания. При выполнении этих условий уровень регуляторного риска минимален.

Сценарий 3. Утечка из тестовой выборки через публичный репозиторий. IT-компания (Приволжский ФО, начало 2026) случайно опубликовала в публичном GitHub-репозитории test.csv с именами и email пользователей — разработчик считал файл синтетическим, но он содержал реальные данные из production-базы. Факт обнаружен через 18 часов — уведомление РКН направлено в установленный срок (24 часа, ч. 3.1 ст. 21 ФЗ-152). Штраф по ч. 12 ст. 13.11 (утечка до 10 000 субъектов) составил от 3 до 5 млн ₽. Оперативное уведомление исключило дополнительный штраф по ч. 11 ст. 13.11 (1–3 млн ₽ за неуведомление). ⚠️ Точная сумма — менеджер уточняет при публикации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Train/test split — это обработка ПДн, если исходный датасет содержит идентифицирующие признаки. Обезличивание должно предшествовать любому разделению выборок, выполняться одним из пяти методов по Приказу РКН и документироваться в составе ОРД оператора. Уровень защищённости ML-инфраструктуры определяется по ПП РФ №1119 и фиксируется в акте; меры защиты выбираются по Приказу ФСТЭК №21.

DATUM сопровождает IT-команды в задачах определения УЗ для ML-систем, разработки модели угроз, оформления поручений обработки с облачными провайдерами и подготовки комплекта ОРД — включая регламент обезличивания для конкретного pipeline.