GrowthBook, Optimizely, VWO и 152-ФЗ

A/B-тестирование и feature-флаги стали стандартом в product-разработке. Однако с 30.05.2025 ценой за неправильную конфигурацию стал не только технический долг, но и административный штраф до 18 млн ₽ за повторное нарушение локализации. В этом материале — разбор того, как GrowthBook, Optimizely и VWO работают с ПДн, какие нормы они затрагивают и как CTO выстроить архитектуру, соответствующую ФЗ-152.

Какие данные A/B-платформы собирают и почему это ПДн?

Для проведения эксперимента A/B-платформа собирает минимум: user_id или device_id, назначение пользователя в вариант (bucket), временную метку события. В реальных имплементациях к этому добавляются IP-адрес, user-agent, куки, сессионный токен, поведенческие события (клик, скролл, конверсия). Все эти данные позволяют идентифицировать пользователя прямо или косвенно — что соответствует определению персональных данных по ст. 3 ФЗ-152.

Логирование событий как ПДн — ключевой технический риск для CTO. Если лог-файл содержит user_id + действие + timestamp и доступен сторонней платформе, это передача ПДн по поручению (п. 3 ст. 6 ФЗ-152). Значит, нужен договор поручения обработки с каждым вендором.

VWO передаёт данные на серверы в США и ЕС. Optimizely (Cloud-версия) — в AWS US-East. GrowthBook в self-hosted конфигурации позволяет держать данные на серверах оператора — это принципиально меняет правовую картину.

Как локализация и трансграничная передача применяются к A/B-платформам?

Часть 5 ст. 18 ФЗ-152 обязывает оператора при сборе ПДн российских граждан использовать базы данных, физически расположенные в РФ. С 01.07.2025, после ужесточения, требование распространяется на первичную запись данных — не только на хранение. Это означает, что SDK Optimizely или VWO, отправляющий события напрямую на зарубежный endpoint, нарушает норму в момент первого запроса.

Трансграничная передача (ст. 12 ФЗ-152) — отдельный режим. Для стран без адекватной защиты (США, большинство облачных юрисдикций) до передачи требуется уведомление РКН. Если ваш SaaS отправляет данные в Optimizely EU, формально Германия — страна Совета Европы, подписавшая Конвенцию 108, — но актуальный перечень адекватных стран нужно сверять с действующим приказом РКН: списки периодически обновляются.

Практический итог: cloud-версии VWO и Optimizely без дополнительной конфигурации несовместимы с требованиями ч. 5 ст. 18 ФЗ-152 для российского трафика. GrowthBook self-hosted — совместим при размещении на облаке в РФ (Yandex Cloud, SberCloud, MTS Cloud).

Какой уровень защищённости (УЗ) нужен для SaaS с A/B-тестированием?

Уровень защищённости информационной системы ПДн определяется по ПП РФ №1119. Для типичного SaaS с A/B-тестированием применяется матрица: категория данных × тип актуальных угроз × число субъектов.

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

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

Мультиарендность SaaS создаёт дополнительный риск: данные разных клиентов-операторов физически находятся в одной ИС. По ст. 6 ФЗ-152 каждый клиент — самостоятельный оператор; SaaS-платформа — обработчик по поручению. Отсутствие договора поручения с каждым клиентом — самостоятельное нарушение.

Обезличивание для ML: как GrowthBook-данные легально использовать в моделях?

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

С сентября 2025 года действует приказ РКН, утверждающий 5 методов обезличивания. Для ML-задач практически применимы три: введение идентификаторов (замена реального user_id на псевдоним без обратного ключа), обобщение (замена точных значений диапазонами: возраст «28» → «25–34»), декомпозиция (разделение связок атрибут–субъект на несвязанные таблицы). Перемешивание и изменение семантики для временных рядов поведенческих данных применяются реже.

Технически для GrowthBook: при экспорте событий в аналитический хранилище (ClickHouse, BigQuery on-premise) user_id заменяется на SHA-256 от соли + user_id, соль хранится отдельно с ограниченным доступом. После обезличивания данные выходят из режима ФЗ-152 и могут передаваться в любое облако для обучения моделей — при условии, что обратное сопоставление невозможно без соли.

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

Как выглядят типовые нарушения A/B-платформ на практике?

Сценарий 1. Cloud-версия VWO без локализации. SaaS-компания подключила VWO Cloud для A/B-тестирования интерфейса. SDK отправляет события (session_id, user_id, страница, вариант) на серверы VWO в ЕС. Данные российских пользователей первично записываются вне РФ. Нарушение: ч. 5 ст. 18 ФЗ-152, состав по ч. 8 ст. 13.11 КоАП (1–6 млн ₽). Дополнительно — нет уведомления РКН о трансграничной передаче по ст. 12 ФЗ-152. Стратегия: перейти на self-hosted VWO или GrowthBook в Yandex Cloud; уведомить РКН; заключить договор поручения.

Сценарий 2. GrowthBook self-hosted в AWS Frankfurt. Технически self-hosted, но сервер в зоне eu-central-1. Локализация не соблюдена: ч. 5 ст. 18 ФЗ-152 требует нахождения базы в РФ, а не просто выделенного сервера. Нарушение аналогично сценарию 1. Стратегия: перенести GrowthBook-инстанс в Yandex Cloud RU или аналог, перепроверить, что MongoDB или Postgres с событиями также размещены в RU-регионе.

Сценарий 3. Optimizely с передачей флагов через CDN. Feature-флаги для российских пользователей Optimizely доставляет через edge-ноды в ЕС. Даже если основная база в РФ, edge-кеширование с личными атрибутами пользователя (user_id + контекст) формирует вторичную запись за рубежом. Стратегия: отключить персонализацию через edge для RU-сегмента или использовать server-side флаги без передачи user_id на CDN-слой.

Из практики DATUM. IT-компания (Сибирский ФО, весна 2025) использовала Optimizely Cloud для онбординга B2C-пользователей. При аудите выявлено: SDK передавал user_id, email и назначение варианта на endpoint в Ирландии; договор поручения с Optimizely отсутствовал; уведомление РКН о трансграничной передаче не подавалось. Компания перешла на GrowthBook self-hosted в MTS Cloud, заключила договор поручения с внутренним стеком и подала уведомление РКН. Административное производство возбуждено не было — переход завершён до плановой проверки.

Из практики DATUM. Финтех-SaaS (Центральный ФО, осень 2025) обучал модель персонализации на A/B-данных из VWO. Данные экспортировались напрямую в S3 (AWS US) без обезличивания. При внутреннем аудите технический директор выявил нарушение ч. 5 ст. 18 ФЗ-152 и отсутствие оснований для трансграничной передачи по ст. 12. Введено обезличивание (замена user_id на SHA-256 с солью), экспорт переведён в ClickHouse on-premise в РФ с последующим обезличенным экспортом в S3 для ML. Договор поручения с VWO заменён на self-hosted конфигурацию. Предписаний РКН не поступало.

Связанные услуги DATUM по теме

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

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

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

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

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

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

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

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

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

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

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

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

Итог

GrowthBook в self-hosted конфигурации на российском облаке — единственный из трёх рассмотренных инструментов, который при правильной настройке соответствует ч. 5 ст. 18 ФЗ-152. Optimizely и VWO в cloud-версии требуют либо перехода на self-hosted, либо проксирования через российский endpoint с исключением передачи user_id на зарубежный сервер. Для ML на A/B-данных — обязательное обезличивание по методам РКН до любой передачи за рубеж.

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