Выборки для эксперимента: согласие

Когда дата-инженеры берут срез продовой базы для обучения модели или проведения контролируемого эксперимента, они, как правило, ориентируются на технические ограничения: размер выборки, репрезентативность, балансировку классов. Правовой вопрос — на каком основании данные вообще попали в ноутбук исследователя — остаётся за скобками. Именно этот пробел стал источником протоколов РКН в 2024–2025 годах. Ниже — разбор того, когда достаточно существующего согласия, когда нужно новое, и что делать с обезличиванием как альтернативой.

Почему существующее согласие не покрывает эксперименты?

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

Первое: цель обработки при согласии и фактическая цель эксперимента должны совпадать не на уровне маркетинговой формулировки, а на уровне конкретных действий с данными. Обучение модели — это систематизация, накопление, извлечение по критериям выборки. Если в согласии не упомянуто «обучение алгоритмов» или эквивалентная формулировка, правовое основание отсутствует.

Второе: принцип минимальности по ст. 5 ФЗ-152 требует, чтобы состав обрабатываемых данных соответствовал цели. Если для A/B-теста достаточно поведенческих событий без идентификаторов — передача в выборку полного профиля пользователя нарушает этот принцип, даже при наличии широкого согласия.

Практический вывод: перед тем как передавать срез данных в среду эксперимента, нужно сверить формулировки действующих согласий с фактическими действиями в ML-пайплайне. Если соответствия нет — либо переформулировать согласие для новых пользователей, либо применить обезличивание.

Как правильно оформить согласие под выборку для эксперимента?

С 01.09.2025 по требованиям ФЗ-156 согласие оформляется отдельным документом — его нельзя встраивать в договор, оферту или общую политику конфиденциальности. Для выборок под эксперименты это создаёт конкретный чеклист реквизитов.

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

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

Обезличивание как альтернатива согласию: что говорит Приказ РКН о методах?

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

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

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

Критическое ограничение: обезличивание должно быть необратимым при реалистичных условиях. Если ключ псевдонимизации хранится в той же инфраструктуре, что и датасет, — это не обезличивание по смыслу ст. 13.1 ФЗ-152, а псевдонимизация. Такие данные остаются персональными. РКН при проверке вправе потребовать продемонстрировать невозможность деобезличивания.

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

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

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

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

Если выборка превышает 100 000 субъектов или содержит специальные категории (данные о здоровье, биометрия) — уровень поднимается до УЗ-2 или УЗ-1. На этих уровнях Приказ ФСТЭК №21 требует сертифицированных средств защиты информации (антивирус, межсетевой экран, СЗИ от НСД) с конкретным классом по соответствующим требованиям ФСТЭК.

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

Практические сценарии: когда возникают нарушения

Ниже — три типовые ситуации, с которыми сталкиваются CTO при организации ML-экспериментов.

Сценарий 1. Дата-инженер берёт дамп продовой базы «на один раз». Ситуация: команда разработки запрашивает выгрузку пользователей для калибровки рекомендательной модели. Выгрузка содержит 150 000 записей с email, историей покупок и поведенческими событиями. Формы согласия упоминают «персонализацию», но не обучение алгоритмов. Доказательства: логи СУБД фиксируют полный SELECT по таблице users. Хранение — на рабочей машине инженера, вне периметра ИСПДн. Вероятный исход: нарушение ст. 5 ФЗ-152 (несоответствие цели) + выход за периметр ИСПДн. При выборке свыше 100 000 субъектов — состав по ч. 13 ст. 13.11 КоАП (штраф 5–10 млн ₽). Стратегия: ввести политику доступа к данным, исключающую работу с продовыми данными вне аттестованной среды; переоформить согласия под ML-цели.

Сценарий 2. Платформа B2B SaaS использует агрегированные данные для улучшения модели без согласования с арендаторами. Ситуация: SaaS-платформа HR-аналитики агрегирует данные сотрудников клиентов для обучения модели оценки производительности. В договорах с клиентами (арендаторами) поручение не предусматривает такого использования. Вероятный исход: нарушение ст. 6 ч. 3 ФЗ-152 — выход за рамки поручения. Арендаторы как операторы несут основную ответственность, но платформа как обработчик — солидарные риски по договору и репутационные. Стратегия: включить в DPA (соглашение об обработке данных) явную формулировку о праве платформы создавать обезличенные агрегаты для продуктовых улучшений.

Сценарий 3. Обезличивание реализовано псевдонимизацией с доступным ключом. Ситуация: команда заменила user_id на случайный UUID, ключ соответствия хранится в той же базе данных. Датасет передан в облако для обучения. Вероятный исход: данные не являются обезличенными по критериям ст. 13.1 ФЗ-152, поскольку деобезличивание возможно при наличии ключа. Обработка в зарубежном облаке — нарушение локализации (ч. 8 ст. 13.11, штраф 1–6 млн ₽). Стратегия: хранить ключ псевдонимизации в изолированном хранилище без доступа из среды эксперимента; либо перейти к методу агрегации, при котором ключ не нужен.

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

Кейс 1. IT-компания (Северо-Западный ФО, осень 2025): команда данных запускала A/B-тесты на выборках ~80 000 пользователей. В ходе внеплановой проверки РКН установил, что формы согласия не упоминали обучение алгоритмов, а среда эксперимента — Jupyter Hub — располагалась вне аттестованной ИСПДн. Протокол составлен по ч. 1 ст. 13.11 КоАП. Компания переоформила согласия, включила среду в периметр ИСПДн и обжаловала постановление, получив штраф в нижней части диапазона с учётом принятых мер.

Кейс 2. SaaS-платформа в сфере EdTech (Центральный ФО, начало 2026): оператор обрабатывал ПДн несовершеннолетних учащихся (специальная категория по возрастному признаку). Выборка для персонализационной модели содержала записи более 15 000 субъектов. Уровень защищённости ИСПДн был установлен как УЗ-4, тогда как наличие специальных категорий требовало УЗ-2. Аудит DATUM выявил несоответствие; платформа провела переаттестацию ИСПДн и получила заключение о соответствии до начала проверки РКН. Административное производство не возбуждалось.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с ML-нагрузкой?

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

Итог

Выборки для ML-экспериментов и A/B-тестов требуют самостоятельного правового основания: действующее согласие покрывает эксперименты только при точном соответствии формулировок. После 01.09.2025 новые согласия оформляются отдельным документом по ст. 9 ФЗ-152 в редакции ФЗ-156. Обезличивание — допустимая альтернатива, но только при применении методов из перечня РКН и при невозможности деобезличивания. Среда экспериментов обязана находиться в аттестованной ИСПДн; хранение в зарубежном облаке нарушает требование локализации.

DATUM сопровождает IT-компании и SaaS-платформы в выстраивании архитектуры обработки ПДн: от аудита оснований обработки до DPIA и подготовки пакета ОРД для ML-пайплайнов.

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