A/B-тесты на пользователях: правовая основа

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024: 18 частей вместо прежних семи, оборотный штраф по ч. 15 — до 500 млн ₽. На фоне этого многие IT-команды продолжают запускать A/B-тесты, не разграничив роли оператора и обработчика, не описав цель сегментирования в политике и не настроив обезличивание для ML-моделей. Эта статья разбирает правовую конструкцию A/B-тестов: от выбора правового основания и уровня защищённости (УЗ-1..4 по ПП РФ №1119) до требований ФСТЭК по Приказу №21 и обезличивания по Приказу РКН о методах обезличивания.

Что такое A/B-тест с точки зрения 152-ФЗ?

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

Ключевой вопрос — правовое основание. Ст. 6 ФЗ-152 допускает обработку по одному из 11 оснований. Для большинства коммерческих A/B-тестов доступны два: согласие субъекта (п. 1 ч. 1 ст. 6) или законный интерес оператора. При этом «законный интерес» как самостоятельное основание в российском праве прямо не закреплён в ст. 6 — в отличие от GDPR. Это означает: без согласия пользователя или прямой связи теста с исполнением договора правовое основание нестабильно.

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

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

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

Для стандартного SaaS-продукта с A/B-тестами на общих ПДн (поведенческие метрики, идентификаторы устройств) при числе субъектов до 100 000 и угрозе 3-го типа применяется УЗ-3. При числе субъектов свыше 100 000 — УЗ-2. Если в тест вовлечены данные о здоровье (медицинский EdTech, телемедицина) — специальная категория по ст. 10 ФЗ-152, УЗ-1 при любом объёме.

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

Какие меры защиты требует Приказ ФСТЭК №21?

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

Логирование действий при A/B-тестах — это одновременно требование РСБ и потенциальная проблема по 152-ФЗ. Если в лог-файл попадают полные идентификаторы пользователей (email, user_id в связке с сегментом) — логирование само по себе становится обработкой ПДн. Логирование как пдн — распространённый источник избыточного накопления данных, нарушающий принцип ст. 5 о соответствии объёма целям.

Для КИИ (критическая информационная инфраструктура по 187-ФЗ): если SaaS-платформа признана значимым объектом КИИ, требования к защите ужесточаются. A/B-тесты в таких системах требуют отдельного анализа соответствия.

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

Обезличивание — наиболее корректный способ снять правовые ограничения на сегментирование для ML и тестирования. После обезличивания данные выходят из-под действия ФЗ-152 (ст. 13.1 в редакции ФЗ-233 от 08.08.2024) и могут обрабатываться без согласия субъекта.

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

Распространённая ошибка: разработчики считают, что удаление email из строки делает данные обезличенными. Если в той же базе остаётся user_id, связанный с профилем — данные псевдонимизированы, но не обезличены. РКН при проверке смотрит на техническую возможность обратного сопоставления.

Облако в РФ при хранении промежуточных данных A/B-тестирования — обязательное требование при работе с ПДн граждан РФ (ч. 5 ст. 18 ФЗ-152 — локализация). Использование иностранных облаков допустимо только после первичной записи данных в российских базах и при соблюдении требований трансграничной передачи по ст. 12 ФЗ-152.

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

Кейс 1. SaaS-платформа маркетинговой автоматизации (Сибирский ФО, осень 2025) проводила A/B-тесты рассылок для корпоративных клиентов. В логах инструмента тестирования сохранялись email-адреса с меткой варианта (A или B). При внеплановой проверке РКН выявил: цель «A/B-тестирование» не была указана в уведомлении по ст. 22 ФЗ-152 и в политике обработки. Оператор получил предписание об устранении нарушения и протокол по ч. 1 ст. 13.11 КоАП. Штраф составил сотни тысяч рублей. Устранение потребовало переработки политики, уточнения уведомления в реестре РКН и очистки логов.

Кейс 2. EdTech-платформа (Центральный ФО, начало 2026) тестировала алгоритм рекомендаций курсов. Данные учащихся (в том числе несовершеннолетних) использовались в ML-модели без обезличивания. Технический директор обратился в DATUM после получения жалобы субъекта в РКН: пользователь запросил информацию о своей сегментации по ст. 14 ФЗ-152. Компания не могла ответить в 10-рабочедневный срок, так как данные о принадлежности к группам теста не были структурированы. Юристы DATUM провели аудит, разработали DPIA и помогли выстроить процесс ответа на запросы субъектов до вынесения постановления о штрафе.

Сценарии нарушений: что идёт не так

Сценарий 1. Цель не описана в реестре РКН. Компания зарегистрирована в реестре операторов, но цель «оптимизация интерфейса методом A/B-тестирования» не указана. Уведомление устарело: реальная обработка шире заявленного. При проверке — протокол по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽). При повторности — ч. 1.1 (300 000–500 000 ₽). Стратегия: подать уточнение уведомления по ст. 22 ФЗ-152 через pd.rkn.gov.ru до прихода проверяющего.

Сценарий 2. Подрядчик по тестированию без договора поручения. CTO подключил зарубежный SaaS-инструмент для тестирования. Договор не содержит раздела о поручении обработки ПДн. Данные уходят на серверы в ЕС. Это одновременно: нарушение требования к поручению обработки (ст. 6 ФЗ-152) и трансграничная передача без уведомления РКН (ст. 12 ФЗ-152) + нарушение локализации (ч. 5 ст. 18). Штраф по ч. 8 ст. 13.11 — 1–6 млн ₽. Стратегия: перевести первичный сбор на российскую инфраструктуру, оформить поручение, уведомить РКН о трансграничной передаче.

Сценарий 3. ML-модель обучена на необезличенных данных тестов. Data Science-команда выгрузила логи A/B-тестов с user_id для обучения модели персонализации. user_id связан с профилем в основной базе. Данные не обезличены. Цель «обучение ML-модели» не указана в уведомлении. Нарушение принципа ст. 5 (несовместимость целей) и ст. 6 (отсутствие основания). При утечке модели — риск квалификации по ч. 12–14 ст. 13.11 КоАП (3–15 млн ₽) в зависимости от числа субъектов. Стратегия: внедрить обезличивание до выгрузки, закрепить цель ML-обучения в документации.

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

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

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

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

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

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

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

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

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

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

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

5. Какие средства защиты информации (СЗИ) обязательны при УЗ-3?

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

Итог

A/B-тест — законная практика продуктовой разработки, но с точки зрения 152-ФЗ это полноценная обработка персональных данных: сбор, систематизация, хранение, использование. Правовое основание, уровень защищённости по ПП РФ №1119, меры по Приказу ФСТЭК №21, обезличивание логов и корректные договоры поручения — обязательные элементы архитектуры, а не опциональный compliance-слой.

DATUM сопровождает IT-компании и SaaS-вендоров в построении правомерной обработки ПДн: от классификации систем и разработки модели угроз до DPIA, ОРД и защиты в случае претензий РКН.