Чек-лист этичного A/B-тестирования

A/B-тестирование стало стандартом продуктовой разработки, но правовая рамка вокруг него сформировалась позже, чем сложилась инженерная практика. В 2025 году Роскомнадзор включил профилирование и эксперименты на пользователях в перечень индикаторов риска при плановых проверках. Ниже — структурированный чек-лист: от определения правового основания до технических мер защиты, выстроенный по логике проверяющего, а не по логике продакт-менеджера.

Что считается обработкой ПДн при A/B-тестировании?

По ст. 3 ФЗ-152 обработка персональных данных — это любое действие с информацией, позволяющей прямо или косвенно идентифицировать физическое лицо. A/B-тест работает с идентификаторами пользователя: user_id, cookie, device fingerprint, IP-адрес в сочетании с поведенческими признаками. Каждый из них в отдельности или в совокупности квалифицируется как ПДн по позиции РКН, закреплённой в разъяснениях регулятора 2023–2024 годов.

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

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

ПП РФ №1119 устанавливает четыре уровня защищённости (УЗ-1...УЗ-4) в зависимости от категории данных, типа угроз и числа субъектов. Для большинства SaaS-платформ с A/B-тестированием на общедоступных пользователях применимы УЗ-3 или УЗ-4. Критический порог — 100 000 субъектов: его превышение при угрозах третьего типа автоматически переводит систему в УЗ-3 с расширенным набором мер по Приказу ФСТЭК №21.

• УЗ-4 — общедоступные ПДн, менее 100 000 субъектов, угрозы 3-го типа. Базовый набор мер ФСТЭК: идентификация и аутентификация (ИАФ), управление доступом (УПД), регистрация событий (РСБ), антивирусная защита (АВЗ).
• УЗ-3 — общедоступные ПДн более 100 000 субъектов или иные категории при угрозах 3-го типа. Дополнительно: защита носителей информации (ЗНИ), обнаружение вторжений (СОВ), обеспечение целостности (ОЦЛ).
• УЗ-2 — спецкатегории ПДн (ст. 10 ФЗ-152) при угрозах 2-го типа или биометрия при угрозах 3-го типа. Характерно для медицинских и финтех-продуктов с A/B-экспериментами над пациентами или заёмщиками.
• УЗ-1 — спецкатегории или биометрия при угрозах 1-го типа. Встречается редко; требует аттестации и сертифицированных СКЗИ.

Экспериментальная среда нередко получает отдельный УЗ, ниже чем продакшн. Это допустимо только если она физически и логически изолирована и работает исключительно на обезличенных данных. Если в staging-окружении фигурируют реальные user_id — уровень защищённости обязан совпадать с продакшном.

Что такое обезличивание для ML и почему оно не отменяет требования 152-ФЗ?

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

Регулятор установил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Применительно к A/B-тестированию наиболее релевантны два: замена user_id на псевдоним через однонаправленное хэширование (введение идентификаторов) и агрегация поведенческих метрик до уровня когорты без хранения индивидуальных событий (обобщение).

Ключевое ограничение: обезличенные данные всё равно подпадают под ст. 13.1 ФЗ-152 в части методов и порядка обезличивания. Компания не освобождается от документирования факта обезличивания и не может использовать обезличенные данные для повторной идентификации. Если ML-модель обучена на псевдонимизированных данных и в ней сохранилась возможность de-anonymization — это нарушение ст. 5 ФЗ-152 и потенциальный состав по ст. 272.1 УК (введена ФЗ-421 от 30.11.2024).

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

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

Для A/B-тестирования это разграничение критично. Если вендор SaaS самостоятельно запускает эксперименты на данных всех тенантов без поручения каждого из них — он де-факто оператор и обязан иметь самостоятельное правовое основание по ст. 6 ФЗ-152. При отсутствии поручения или согласия это нарушение ч. 1 ст. 13.11 КоАП. Договор поручения обработки (ст. 6 ч. 3) должен явно перечислять цели передачи данных; A/B-тестирование как отдельная цель — в этот перечень входит не автоматически.

Как логирование событий превращается в ПДн?

Логи A/B-тестирования содержат минимум: user_id, timestamp, bucket (вариант A или B), событие. На первый взгляд — технические данные. На практике совокупность user_id + временная метка + поведенческое событие квалифицируется как ПДн, если user_id позволяет идентифицировать пользователя через основную базу. РКН в своей позиции относит технические идентификаторы к ПДн в случае, если оператор способен установить личность субъекта с их помощью.

Это означает: логи экспериментов должны храниться в ИСПДн с соответствующим УЗ, срок хранения должен быть документирован в политике обработки, доступ к логам — разграничен по ролям (мера УПД по Приказу ФСТЭК №21), а удаление — фиксироваться в журнале. Бессрочное хранение логов ради «накопленной аналитики» нарушает принцип ст. 5 ФЗ-152: хранение не дольше, чем необходимо для достижения целей обработки.

Облачные провайдеры за пределами РФ дополнительно создают риск нарушения требований локализации по ч. 5 ст. 18 ФЗ-152. Первичный сбор и хранение логов с ПДн граждан РФ должны происходить на серверах в РФ. Передача обезличенных агрегатов за рубеж допустима, но требует документирования метода обезличивания и наличия поручения.

Какие требования ФСТЭК применяются к SaaS с A/B-тестами?

Приказ ФСТЭК №21 определяет 109 мер в 15 группах. Для SaaS-платформы с A/B-тестированием на уровне УЗ-3 обязательны меры в следующих группах:

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

Для объектов КИИ (критической информационной инфраструктуры) по ФЗ-187 дополнительно применяются требования Приказа ФСТЭК №239. SaaS-платформа может попасть в перечень КИИ, если обрабатывает данные в финансовой, медицинской или транспортной сфере — это отдельная проверка, которая предшествует определению УЗ.

Типовые нарушения: три сценария с последствиями

Сценарий 1. A/B-платформа — иностранный SaaS без поручения обработки. Команда подключила зарубежный A/B-инструмент (Optimizely, VWO, аналог), передав user_id и поведенческие события. Договор поручения обработки по ст. 6 ч. 3 ФЗ-152 не заключён. Уведомление РКН о трансграничной передаче по ст. 12 ФЗ-152 не подавалось. При проверке: протокол по ч. 1 ст. 13.11 (150 000 — 300 000 ₽) + протокол за нарушение локализации по ч. 8 ст. 13.11 (1 000 000 — 6 000 000 ₽). Стратегия: расторгнуть договор или перейти на российский аналог, подать уведомление о трансграничке ретроспективно, оформить поручение обработки.

Сценарий 2. Эксперимент на спецкатегориях ПДн без осознания этого факта. Медтех-продукт тестирует два варианта экрана с медицинскими показателями пользователя. Показатели здоровья — спецкатегория по ст. 10 ФЗ-152. Обработка требует письменного согласия субъекта по п. 4 ч. 2 ст. 10. Если согласие получено только на «обработку ПДн» общего характера — оно не покрывает спецкатегории. При утечке данных эксперимента от 1 000 субъектов — штраф по ч. 12 ст. 13.11 составит 3 000 000 — 5 000 000 ₽. Уголовный риск по ст. 272.1 УК — при доказанном умысле. Стратегия: провести DPIA, переоформить согласия, изолировать обработку спецкатегорий в отдельную ИСПДн с УЗ-2.

Сценарий 3. Утечка данных контрольной группы через подрядчика аналитики. Данные сегмента B (контрольная группа, 15 000 пользователей) утекли через уязвимость в аналитической системе подрядчика. РКН должен быть уведомлён в течение 24 часов с момента обнаружения по ч. 3.1 ст. 21 ФЗ-152. Через 72 часа — отчёт о расследовании по Приказу РКН №187. Квалификация: ч. 13 ст. 13.11 (10 000 — 100 000 субъектов) — штраф 5 000 000 — 10 000 000 ₽. Оператор несёт ответственность за утечку через подрядчика независимо от того, кто фактически допустил инцидент. Стратегия: до инцидента — договор поручения с пунктом об ответственности подрядчика за безопасность; после — немедленное уведомление РКН и параллельная юридическая поддержка.

Как это работает на практике

Кейс 1. IT-компания (Центральный ФО, весна 2025) провела аудит перед масштабированием A/B-платформы на аудиторию более 500 000 пользователей. Аудит выявил: экспериментальный контур работал на той же ИСПДн, что и продакшн, но без документированного УЗ — фактически на уровне УЗ-4 при обязательном УЗ-3 по ПП РФ №1119. Дополнительно — отсутствие договора поручения обработки с провайдером аналитики. Компания устранила нарушения до проверки РКН, что исключило основания для возбуждения административного производства.

Кейс 2. В деле о реагировании на инцидент с данными A/B-экспериментов (Северо-Западный ФО, осень 2025) технический директор зафиксировал факт несанкционированного доступа к базе логов за 3 часа, направил первичное уведомление РКН за 21 час и представил 72-часовой отчёт в полном объёме по Приказу РКН №187. Число затронутых субъектов составило около 8 000 — квалификация по ч. 12 ст. 13.11 КоАП (3 000 000 — 5 000 000 ₽). В арбитражном суде региона штраф был снижен с учётом оперативности реагирования и добровольного уведомления регулятора.

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

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

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

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

Уровень защищённости определяется по ПП РФ №1119 через три параметра: категория ПДн (общедоступные, иные, спецкатегории, биометрия), тип угроз (1–3) и число субъектов. Для общедоступных ПДн менее 100 000 субъектов при угрозах третьего типа — УЗ-4. При превышении 100 000 субъектов — УЗ-3 с расширенным набором мер по Приказу ФСТЭК №21 (добавляются СОВ, ОЦЛ, ЗНИ). Если в эксперименте участвуют данные о состоянии здоровья или финансовом поведении — уровень повышается до УЗ-2 или УЗ-1 вне зависимости от числа субъектов.

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

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

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

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

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

Вопрос решается через анализ фактических полномочий: кто определяет цели и способы обработки конечных пользователей. Если вендор SaaS предоставляет только инфраструктуру и не имеет доступа к данным конечных пользователей тенанта — он обработчик по поручению (ст. 6 ч. 3 ФЗ-152). Если вендор самостоятельно запускает A/B-эксперименты на всей пользовательской базе без поручения тенантов — он оператор с самостоятельными обязанностями: уведомление РКН, политика, согласия. Смешанная модель требует явного разграничения в договоре с тенантом.

5. Какие СЗИ обязательны для ИСПДн с A/B-тестами?

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

Итог

A/B-тестирование — это обработка ПДн по умолчанию, а не по исключению. Правовое основание, уровень защищённости ИСПДн, обезличивание данных для ML, договоры поручения с подрядчиками и документированное логирование — не опции, а обязательные элементы технического комплаенса с 30.05.2025.

DATUM сопровождает IT-команды в части технического соответствия 152-ФЗ: от определения УЗ и подготовки ОРД до DPIA и защиты от штрафов по ст. 13.11 КоАП при инцидентах с данными экспериментов.

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