Дискриминационные A/B-тесты: запрет

A/B-тестирование — стандартный инструмент продуктовых команд. Но с 2024–2025 годов регуляторный ландшафт изменился: ст. 272.1 УК (ФЗ-421 от 30.11.2024, с 11.12.2024), оборотные штрафы по ФЗ-420 (с 30.05.2025) и ужесточение локализации по ФЗ-233 (с 01.07.2025) совместно создали условия, при которых ряд стандартных практик тестирования перешёл в зону уголовного и административного риска. Этот материал разбирает, где проходит граница между законным экспериментом и дискриминационной обработкой ПДн, что значат уровни защищённости УЗ-1..4 применительно к данным A/B-групп и как выстроить поручение обработки при работе с ML-моделями на пользовательских данных.

Что делает A/B-тест дискриминационным по 152-ФЗ?

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

Ст. 7 ФЗ-152 закрепляет принцип конфиденциальности и запрещает раскрывать ПДн третьим лицам без согласия субъекта. Если A/B-тест реализован через внешнюю платформу (Optimizely, LaunchDarkly, VWO, AB Tasty), данные пользователей передаются за пределы оператора без явного поручения обработки — нарушение ст. 6 ч. 3 ФЗ-152 (поручение обработки требует договора с перечнем действий).

Таким образом, дискриминационный A/B-тест определяется тремя признаками: (1) группа назначается на основании ПДн, а не случайного идентификатора сессии; (2) результат теста влечёт разные условия договора или обслуживания; (3) субъект не уведомлён и не дал согласия на такую обработку. Каждый признак самостоятелен — достаточно одного.

Какой уровень защищённости выбрать для данных A/B-групп?

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

Проблема возникает, когда A/B-тест начинает использовать поведенческие паттерны, позволяющие делать выводы о здоровье (частота визитов к врачу в медицинском приложении), политических взглядах (время просмотра новостного контента определённой тематики) или финансовом положении. Такие данные суды и РКН квалифицируют как специальные категории по ст. 10 ФЗ-152. Специальные категории + угрозы 2-го типа + любое число субъектов = УЗ-2. Специальные + угрозы 1-го типа = УЗ-1. Разница в требованиях к СЗИ по Приказу ФСТЭК №21 принципиальная.

На практике многие продуктовые команды присваивают ИСПДн УЗ-4 «по умолчанию», не анализируя реальный состав обрабатываемых данных. Если эксперимент добавляет в профиль пользователя данные, способные раскрыть специальную категорию — УЗ автоматически растёт, а существующий набор СЗИ оказывается недостаточным.

Как работает обезличивание для ML и где оно не защищает?

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

Обученная ML-модель может «запомнить» ПДн через механизм memorization — это задокументированная атака (membership inference attack). Если модель способна с высокой точностью воспроизвести конкретные записи из обучающей выборки — данные не считаются обезличенными. Следовательно, хранение такой модели = хранение ПДн, и к ней применяется полный набор требований: УЗ, СЗИ, локализация по ч. 5 ст. 18 ФЗ-152.

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

Логирование как ПДн: когда журнал доступа становится нарушением?

Логи A/B-платформы в стандартной конфигурации содержат: user_id, timestamp, вариант эксперимента, событие конверсии, IP-адрес, user_agent. IP-адрес в комбинации с user_id — это ПДн по устойчивой позиции РКН: комбинация позволяет идентифицировать пользователя без дополнительных усилий. Хранение таких логов — операция обработки ПДн.

Проблема для CTO возникает в нескольких конфигурациях. Первая: логи A/B-платформы хранятся в облаке за пределами РФ — нарушение ч. 5 ст. 18 ФЗ-152 (локализация), штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽. Вторая: срок хранения логов не ограничен и не прописан в политике — нарушение принципа хранения не дольше необходимого (ст. 5 ФЗ-152), основание для штрафа по ч. 1 ст. 13.11 (150–300 тыс. ₽). Третья: доступ к логам A/B-тестов имеют подрядчики без договора поручения — нарушение ст. 6 ч. 3.

Допустимое решение: псевдонимизация user_id через однонаправленный хэш с солью, хранение соли отдельно от логов. При таком подходе лог-запись без ключа не позволяет идентифицировать субъекта, что соответствует методу «введение идентификаторов» из методов обезличивания РКН. Однако псевдонимизация не освобождает от требований к ИСПДн — лишь снижает вероятность квалификации как ПДн при проверке.

SaaS-мультиарендность: кто оператор и кто несёт ответственность?

В мультиарендной SaaS-архитектуре данные нескольких клиентов (арендаторов) хранятся в общей инфраструктуре. Применительно к A/B-тестам это создаёт специфический риск: алгоритм распределения по группам может использовать агрегированные данные всех арендаторов для построения модели — а значит, данные пользователей клиента А участвуют в обучении модели, влияющей на пользователей клиента Б.

По позиции РКН, SaaS-провайдер, который самостоятельно определяет цели и методы обработки (выбирает алгоритм, строит модели), является оператором, а не лицом, осуществляющим обработку по поручению. Это принципиально: оператор несёт ответственность по ст. 13.11 КоАП напрямую, тогда как обработчик отвечает перед оператором-клиентом по договору.

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

Практика: как это выглядело в реальных делах

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

Кейс 2. Продуктовая команда финтех-сервиса (Северо-Западный ФО, осень 2025) использовала ML-модель для A/B-теста скоринга кредитного лимита. Модель обучалась на данных пользователей без отдельного согласия по ст. 9 ФЗ-152 на автоматизированное принятие решений, затрагивающих права (ст. 16 ФЗ-152). Компания до начала проверки провела DPIA, зафиксировала правомерное основание — исполнение договора (ст. 6 п. 5) — и получила от пользователей отдельные согласия на профилирование. РКН при проверке констатировал соответствие; предписание не выносилось. Ключевым документом на проверке оказался именно отчёт DPIA с обоснованием правомерности автоматизированного решения.

Типовые сценарии и стратегии защиты

Сценарий 1. A/B-тест на специальных категориях без явного согласия. Медицинский или EdTech-продукт собирает данные о поведении, из которых можно вывести состояние здоровья или возраст ребёнка. Алгоритм назначения в группу использует эти паттерны. Доказательства: лог платформы с полями, договор с ML-провайдером без ограничений на использование данных. Вероятный исход: ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) + предписание об устранении. Стратегия: псевдонимизировать входные данные до передачи в алгоритм, установить технический барьер передачи специальных категорий, зафиксировать в ОРД.

Сценарий 2. Подрядчик A/B-платформы без договора поручения. Команда подключила внешний сервис через SDK без юридического оформления. Подрядчик получает user_id, IP и события. При инциденте на стороне подрядчика оператор отвечает по ч. 12–14 ст. 13.11 (3–15 млн ₽), поскольку принцип ВС РФ — оператор отвечает за утечку через подрядчика. Стратегия: немедленно заключить договор поручения с перечнем операций, ограничить передаваемые поля до минимально необходимых, включить требование локализации и уведомления об инцидентах.

Сценарий 3. Повторное нарушение при второй утечке данных A/B-группы. Компания уже привлекалась по ч. 12 ст. 13.11. При повторной утечке данных экспериментальной группы (более 1 000 субъектов) применяется ч. 15 — оборотный штраф: 1–3% совокупной годовой выручки, не менее 20 млн ₽, не более 500 млн ₽. Скидка 50% за быструю уплату по ст. 32.2 КоАП на оборотный штраф не распространяется. Стратегия: после первого инцидента — полный аудит 152-ФЗ с приоритизацией A/B-инфраструктуры, инвестиции в ИБ не ниже 0,1% выручки за 3 года (ст. 4.1 КоАП, примечание 3.4-2 — снижает оборотный штраф до 1/10 минимума, но не менее 15 млн ₽).

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

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

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

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

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

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

С 01.07.2025 (ФЗ-233) запрещена первичная запись, систематизация и хранение ПДн граждан РФ в базах за пределами России. Логи A/B-платформы с user_id и IP российских пользователей — это ПДн. Хранение таких логов в AWS, GCP или Azure без российского региона нарушает ч. 5 ст. 18 ФЗ-152 и влечёт штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽. Допустима следующая схема: первичный сбор и хранение — в РФ, репликация обезличенных (псевдонимизированных) данных — за рубеж после верификации метода обезличивания.

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

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

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

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

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

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

Итог

Дискриминационный A/B-тест — это не узкоспециализированная проблема комплаенса, а системный риск для любого SaaS-продукта с персонализацией: неправильно сконфигурированная платформа может одновременно нарушать принцип целевой ограниченности (ст. 5 ФЗ-152), запрет на автоматизированные решения без согласия (ст. 16) и требования к поручению обработки (ст. 6 ч. 3). С 30.05.2025 совокупный штраф по трём составам при масштабе аудитории от 10 000 субъектов может превысить 10 млн ₽, а при повторности — оборотный штраф до 500 млн ₽.

Практика DATUM включает сопровождение IT-компаний и SaaS-провайдеров по вопросам соответствия 152-ФЗ, проведение DPIA для экспериментов с профилированием, разработку договоров поручения обработки для ML-платформ и оценку уровней защищённости ИСПДн по ПП РФ №1119 и Приказу ФСТЭК №21.