Тесты с ценовой дискриминацией

Ценовая дискриминация через A/B-тесты — стандартная практика для SaaS и e-commerce. Показ разных цен разным сегментам пользователей требует обработки их профилей: история покупок, геолокация, тип устройства, поведенческие паттерны. Каждый из этих признаков в связке с идентификатором — персональные данные по ст. 3 ФЗ-152. Материал разбирает, при каких условиях такой тест законен, какой уровень защищённости ИСПДн он требует и что CTO должен сделать до запуска.

Что такое ценовой тест с точки зрения 152-ФЗ?

Ценовой A/B-тест — это сбор и использование ПДн для принятия автоматизированного решения, влияющего на условия договора с конкретным субъектом. Статья 16 ФЗ-152 прямо регулирует такие ситуации: оператор вправе принимать решения исключительно на основе автоматизированной обработки ПДн только при наличии согласия субъекта или в случаях, предусмотренных законом. Показ пользователю цены на 15% выше, чем другому, — это решение, которое порождает юридически значимые последствия для него.

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

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

Какой уровень защищённости (УЗ) выбрать для ИСПДн ценового теста?

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

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

На практике большинство SaaS-компаний самостоятельно определяет тип угроз без привлечения ФСТЭК-лицензиата — и выбирает заниженный УЗ. Это системная проблема: РКН при проверке может потребовать модель угроз, и если она не соответствует фактической архитектуре, протокол по ст. 13.11 ч. 1 следует автоматически.

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

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

Если платформа запускает ценовой тест централизованно — для всех арендаторов сразу, определяя алгоритм сегментации самостоятельно — она выступает совместным оператором или самостоятельным оператором в части такой обработки. Это означает: нужно уведомление РКН по ст. 22 ФЗ-152, политика обработки ПДн по ст. 18.1, ответственный по ст. 22.1. Неуведомление РКН о намерении обрабатывать — ч. 10 ст. 13.11 КоАП, штраф 100–300 тыс. ₽.

Если ценовой тест запускает арендатор через API, а платформа лишь исполняет его инструкции — платформа является обработчиком. Тогда требуется договор поручения обработки с обязательными условиями: цели, перечень действий, обязанность соблюдать конфиденциальность, право на проверку. Отсутствие такого договора при фактической передаче обработки — нарушение по ч. 1 ст. 13.11.

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

С 01.07.2025 по ФЗ-233 требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на первичный сбор ПДн граждан РФ: запись, систематизация, накопление, хранение, уточнение и извлечение должны происходить в базах данных на территории России. Иностранное облако — AWS, Azure, GCP — не выполняет это требование само по себе.

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

Повторное нарушение локализации — ч. 9 ст. 13.11 КоАП, штраф 6–18 млн ₽. Это уже сумма, сопоставимая с затратами на миграцию в российское облако.

Логирование и обезличивание: где граница между тестовыми данными и ПДн?

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

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

Логирование как отдельная проблема: журналы событий ИСПДн с user_id хранятся для целей безопасности. Это самостоятельная обработка ПДн. Срок хранения логов должен быть зафиксирован в политике обработки и не превышать срок, необходимый для достижения цели. Избыточное накопление логов с ПДн — нарушение принципа минимизации по ст. 5 ФЗ-152.

Типовые ситуации для CTO при запуске ценового теста

Ситуация 1. Тест на реальных профилях без правового основания. CTO запустил сплит-тест через внутреннюю платформу: 50% пользователей видят цену выше на 12% на основе признаков лояльности. Правовое основание — исполнение договора (п. 5 ст. 6). Однако оферта не содержит условия о персонализации цены и не информирует пользователей о ст. 16 ФЗ-152. При проверке РКН: протокол по ч. 1 ст. 13.11 (обработка несовместимая с заявленными целями), штраф 150–300 тыс. ₽. Стратегия: внести условие о персонализации в оферту или получить отдельное согласие по ФЗ-156 до следующего теста.

Ситуация 2. Данные теста переданы в иностранную ML-платформу. Аналитический стек платформы включает Segment (США) как CDP: профили пользователей передаются туда для обогащения и сегментации. CTO полагает, что это покрыто договором DPA. Нарушение: данные граждан РФ записываются и хранятся вне РФ (ч. 5 ст. 18 ФЗ-152) + трансграничная передача без уведомления РКН по ст. 12. Два состава одновременно: ч. 8 ст. 13.11 (1–6 млн ₽) и ч. 10 ст. 13.11 (100–300 тыс. ₽). Стратегия: миграция первичного хранения в российское облако, уведомление РКН о трансграничной передаче в США.

Ситуация 3. Обезличивание признано недостаточным. IT-компания (Уральский ФО, 2025) обучала модель ценовой сегментации на данных, которые считала псевдонимизированными. При внутреннем аудите выяснилось: ключ сопоставления user_id с реальными клиентами хранился в той же ИСПДн. Данные не признавались обезличенными по методам Приказа РКН. Подготовлена DPIA по ст. 18.1 и проведено реальное обезличивание методом обобщения до когорт. РКН при внеплановой проверке нарушений не выявил.

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

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

Зависит от трёх параметров по ПП РФ №1119: категория ПДн (для ценового теста — как правило, «иные»), тип актуальных угроз (1, 2 или 3) и число субъектов. При угрозах 3-го типа и числе субъектов более 100 000 минимальный уровень — УЗ-3. При угрозах 2-го типа и тех же параметрах — УЗ-2. Модель угроз разрабатывается до выбора УЗ; ошибка в модели ведёт к занижению уровня и несоответствию мер защиты Приказу ФСТЭК №21.

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

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

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

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

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

Роль определяется тем, кто определяет цели и состав обработки ПДн. Если ценовой тест запускается арендатором через API, а платформа только исполняет инструкции — платформа является обработчиком, нужен договор поручения по п. 3 ст. 6 ФЗ-152. Если платформа самостоятельно определяет алгоритм сегментации для всех арендаторов — она оператор или совместный оператор. В этом случае требуется уведомление РКН по ст. 22 и отдельная политика обработки ПДн по ст. 18.1.

5. Какие СЗИ обязательны для ИСПДн ценового теста?

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

Итог

Ценовые тесты с персонализацией — это обработка ПДн с автоматизированным принятием решений по ст. 16 ФЗ-152, требования к которой действуют вне зависимости от того, называет ли команда эксперимент «тестом» или «аналитикой». CTO несёт ответственность за соответствие архитектуры обработки — уровень защищённости, локализацию, правовое основание, роли оператора/обработчика — до запуска, а не после предписания.

Практика DATUM по технологическим компаниям охватывает аудиты ИСПДн, разработку моделей угроз, DPIA для ML-систем и сопровождение взаимодействия с РКН. Мы работаем с SaaS-продуктами, e-commerce и аналитическими платформами, обрабатывающими ПДн в промышленных объёмах.

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

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

17 апреля 2029 года