Тесты с UX-манипуляциями (dark patterns)

Роскомнадзор формирует индикаторы риска с 2024 года, и паттерны сбора согласий через манипулятивный UX входят в перечень признаков нарушений. CTO, отвечающий за архитектуру продукта и инфраструктуру обработки ПДн, несёт ответственность не только за техническую защиту, но и за корректность механизма получения согласия. Эта статья разбирает конкретные типы dark patterns, их связь с нормами ФЗ-152, и объясняет, как провести технический тест на предмет UX-нарушений до того, как это сделает регулятор.

Что такое dark patterns с точки зрения 152-ФЗ?

Термин «dark patterns» описывает интерфейсные решения, которые направляют пользователя к действию, которое он не планировал совершить осознанно. В контексте обработки персональных данных это означает получение согласия, не отвечающего критериям ст. 9 ФЗ-152: конкретность, информированность, добровольность и однозначность.

Закон устанавливает, что согласие субъекта должно быть свободным — без давления, без условий «согласитесь или уходите», без скрытых форм активации. С 01.09.2025 (ФЗ-156 от 24.06.2025) согласие оформляется как отдельный документ и не может быть встроено в текст договора, оферты или политики конфиденциальности. Любой интерфейс, который маскирует согласие под другое действие, нарушает это требование.

На практике выделяют несколько типов UX-манипуляций, прямо затрагивающих законность обработки ПДн. Каждый из них создаёт отдельное основание для протокола по ст. 13.11 КоАП.

Какие типы dark patterns нарушают требования к согласию?

Наиболее распространённые в российских продуктах паттерны, создающие правовой риск:

• Pre-checked checkbox — флажок согласия на маркетинговые рассылки или передачу данных партнёрам заранее активирован. Пользователь должен снять галочку, чтобы отказаться. По ст. 9 ФЗ-152 это не согласие — активное действие должен совершить сам субъект.
• Bundling / связанное согласие — согласие на обязательную и необязательную обработку объединены в одной форме. Пользователь не может принять одно без другого. Нарушает принцип раздельности целей (ст. 5 ФЗ-152) и требование ст. 9 о конкретности согласия.
• Confirmshaming — кнопка отказа сформулирована унижающим образом («Нет, я не хочу скидки» вместо «Отказаться»). Создаёт психологическое давление — признак отсутствия добровольности.
• Hidden unsubscribe / скрытый отзыв — механизм отзыва согласия (ст. 9 ч. 2 ФЗ-152) намеренно затруднён: спрятан за несколькими переходами, требует письма или звонка при том, что согласие давалось в один клик.
• Roach motel — регистрация с согласием занимает 30 секунд, удаление аккаунта и уничтожение данных требует ручной заявки и 10 рабочих дней обработки. Нарушает ст. 21 ФЗ-152 (обязанность уничтожить данные по требованию субъекта).
• Privacy zuckering — данные о пользователе собираются в большем объёме, чем заявлено в форме согласия. Нарушает принцип минимизации (ст. 5 ФЗ-152) и требование к составу согласия (перечень ПДн).

Каждый из этих паттернов создаёт отдельный риск: оспаривание субъектом факта согласия, предписание РКН, протокол по ч. 2 ст. 13.11 КоАП с штрафом до 700 000 ₽ для юрлица.

Как провести технический тест интерфейсов на dark patterns?

Тестирование UX-манипуляций — структурированный процесс, включающий несколько уровней проверки. Для CTO важно понимать: тест должен охватывать не только визуальный слой, но и логику API-запросов, состав передаваемых данных и порядок логирования событий согласия.

На техническом уровне тест включает несколько инструментов. Сетевой перехват (Burp Suite, Charles) позволяет сравнить заявленный и фактический состав ПДн в запросе. Анализ DOM-дерева выявляет скрытые поля и pre-checked состояния. Сценарное тестирование по ролям воспроизводит путь пользователя при регистрации, изменении настроек и удалении аккаунта.

Отдельный пласт — аудит журналов. Если событие согласия не логируется с достаточной детализацией, компания не может доказать ни факт его получения, ни объём согласованной обработки. При проверке РКН это равносильно отсутствию согласия.

Какой уровень защищённости (УЗ) назначить SaaS с UX-форма согласия?

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

Большинство B2C-продуктов с регистрацией попадают минимум под УЗ-3 (общие категории ПДн, угрозы 2-го типа, более 100 000 субъектов). Если продукт собирает данные о здоровье, платёжные данные или биометрию — уровень повышается. Если при этом используется мультиарендная архитектура (saas мультиарендность), УЗ нужно определять отдельно для каждого контура обработки.

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

Как dark patterns связаны с поручением обработки и облачной инфраструктурой?

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

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

Для CTO практический вывод: если форма согласия отправляет данные в Salesforce, HubSpot, Intercom или аналогичные зарубежные системы до записи в российскую базу — архитектура нарушает требование локализации. Необходимо либо перейти на российский аналог, либо обеспечить первичную запись в РФ с последующей трансграничной передачей по уведомлению РКН.

Три сценария: как CTO сталкивается с риском dark patterns

Сценарий 1. Pre-checked согласие в legacy-коде. Продукт запущен до 01.09.2025, форма согласия на маркетинговые рассылки встроена в онбординг с заранее активированным чекбоксом. После ФЗ-156 это согласие юридически ничтожно. Пользователь подаёт жалобу в РКН — регулятор запрашивает журнал событий согласия. Если журнал показывает pre-checked состояние — протокол по ч. 2 ст. 13.11 КоАП неизбежен. Стратегия: ревизия всех форм согласия в продукте, переход к явному opt-in, принудительный re-consent для существующей базы.

Сценарий 2. Bundling в мультиарендной SaaS. Платформа собирает согласие на обязательную обработку данных аккаунта и необязательную передачу данных аналитическому партнёру в одном чекбоксе. Клиент-арендатор (B2B) не знает, что его пользователи согласились на передачу партнёру. При проверке РКН выяснится: оператор (владелец платформы) не имел раздельных согласий по целям. Штраф — по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) плюс предписание устранить. Стратегия: разделить согласия по целям, добавить granular consent с раздельными переключателями.

Сценарий 3. Скрытый отзыв согласия при требовании субъекта. Пользователь требует отозвать согласие на маркетинговую обработку. Механизм отзыва — письмо на support@, обрабатываемое вручную в течение нескольких недель. Ст. 9 ФЗ-152 устанавливает, что оператор обязан прекратить обработку по цели в разумный срок. РКН при проверке фиксирует: за период после требования субъекта рассылки продолжались. Штраф по ч. 5 ст. 13.11 КоАП — 50–90 тыс. ₽, при повторности — 300–500 тыс. ₽. Стратегия: автоматизированный механизм отзыва в личном кабинете с мгновенным прекращением обработки по цели.

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

Кейс 1. IT-компания из Северо-Западного ФО (осень 2025) получила предписание РКН по итогам внеплановой проверки: форма регистрации продукта содержала pre-checked согласие на передачу данных партнёрской сети. Технический директор подтвердил, что паттерн существовал с запуска продукта в 2022 году. Компания представила обновлённый код формы и журнал re-consent для существующей базы пользователей. РКН вынес штраф по ч. 2 ст. 13.11 КоАП в размере в несколько сотен тысяч рублей; суд первой инстанции подтвердил. При своевременном техническом аудите нарушение было бы устранено до проверки.

Кейс 2. Исходя из практики DATUM (Сибирский ФО, начало 2026): SaaS-платформа для HR использовала единую форму онбординга, где согласие на обязательную и необязательную обработку было объединено. Клиент обратился после получения запроса от субъекта об уничтожении данных — выяснилось, что раздельный учёт согласий не велся, неясно, на что именно соглашался каждый пользователь. Юристы DATUM провели аудит логов, сформировали техническое задание на разработку granular consent, подготовили пакет ОРД с договорами поручения для каждого интегрированного сервиса.

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

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

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

1. Какой УЗ выбрать для SaaS?

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

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

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

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

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

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

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

5. Какие СЗИ обязательны?

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

Итог

Dark patterns в интерфейсах — это технический долг, который конвертируется в правовой риск. С 01.09.2025 требования к согласию ужесточены, и механизм его получения через pre-checked чекбоксы или bundling автоматически делает существующую базу согласий уязвимой при проверке РКН или жалобе субъекта.

DATUM сопровождает IT-компании и SaaS-продукты в части технико-правового аудита форм согласия, определения УЗ для ИСПДн, разработки требований к granular consent и формирования полного пакета ОРД с учётом мультиарендной архитектуры.