Эксперименты в мобильных приложениях

С 30.05.2025 штрафы за утечки ПДн выросли до 15 млн ₽ за разовый инцидент и до 500 млн ₽ при повторности (ч. 14, ч. 15 ст. 13.11 КоАП в редакции ФЗ-420 от 30.11.2024). Эксперименты в мобильных приложениях — сбор поведения, сегментация аудитории, передача событий в аналитику — это полноценная обработка ПДн. В этом материале разберём, как техническая архитектура экспериментов пересекается с требованиями 152-ФЗ, где возникают риски и что CTO должен зафиксировать в документах до начала следующего спринта.

Почему эксперименты в приложениях — это обработка персональных данных?

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

Ключевой риск — автоматическое включение SDK экспериментов (Firebase Remote Config, Amplitude Experiment, Statsig и аналоги) до получения согласия пользователя. Согласно ст. 9 ФЗ-152, обработка ПДн без правового основания — это нарушение по ч. 1 ст. 13.11 КоАП с штрафом от 150 000 до 300 000 ₽ за юрлицо. При повторном нарушении — до 500 000 ₽ (ч. 1.1).

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

Как выбрать уровень защищённости УЗ для ИСПДн эксперимента?

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

Для типичного мобильного приложения с экспериментами картина выглядит так:

• УЗ-4 — общие ПДн, тип угрозы 3, менее 100 000 субъектов. Минимальный набор мер Приказа ФСТЭК №21: идентификация и аутентификация (ИАФ), управление доступом (УПД), защита носителей (ЗНИ), антивирус (АВЗ).
• УЗ-3 — общие ПДн, тип угрозы 2 или более 100 000 субъектов. Добавляются: регистрация и учёт (РСБ — журналы), контроль защищённости (АНЗ), целостность (ОЦЛ).
• УЗ-2 — специальные категории (здоровье, религия) или биометрия при более 100 000 субъектов. Характерно для медицинских и финтех-приложений с функцией входа по лицу.
• УЗ-1 — специальные категории ПДн сотрудников оператора или тип угрозы 1. На практике — редкость для коммерческих мобильных приложений.

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

Облако, SDK и поручение обработки: кто оператор в мультиарендном SaaS?

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

В мультиарендной SaaS-платформе (несколько клиентов-операторов на одном инстансе) возникает дополнительная сложность: провайдер платформы является обработчиком для каждого из своих клиентов одновременно. Разграничение данных между арендаторами должно быть подтверждено технически — отдельными схемами в БД или логическим разделением — и зафиксировано в договоре поручения. Смешение данных разных операторов нарушает ст. 5 ФЗ-152 (принцип несовместимости целей).

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

Практическое решение: разделить события на два потока. Российские пользователи — события пишутся в ClickHouse/PostgreSQL на хостинге в РФ (Yandex Cloud, SberCloud, собственный ЦОД). После обезличивания (см. следующий раздел) — синхронизация в зарубежный аналитический кластер допустима, поскольку обезличенные данные под определение ПДн по ст. 3 ФЗ-152 не подпадают.

Что такое обезличивание для ML и как его применять в экспериментах?

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

Приказ РКН, введённый в действие с 01.09.2025 (точный номер — верифицировать при публикации), устанавливает пять методов обезличивания:

• Введение идентификаторов — замена прямых идентификаторов (user_id, email, телефон) на случайные токены без возможности обратного преобразования без ключа.
• Изменение состава или семантики — замена конкретных значений на диапазоны или категории (возраст 27 → «25–34», город Новосибирск → «Сибирский ФО»).
• Декомпозиция — разделение датасета на части, каждая из которых в отдельности не позволяет идентифицировать субъекта.
• Перемешивание — перестановка значений атрибутов между записями с сохранением статистических свойств.
• Обобщение и агрегация — замена индивидуальных значений агрегатами (среднее, медиана, процентиль) по группам.

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

Какие риски создаёт логирование как обработка ПДн?

Журналы событий приложения (application logs) содержат IP-адреса, идентификаторы сессий, user_id, параметры запросов. По позиции РКН, IP-адрес в сочетании с другими атрибутами является ПДн. Это означает, что логирование — это тоже обработка ПДн, требующая правового основания и технической защиты.

Для экспериментальной платформы риски возникают в трёх точках. Первая — логи SDK аналитики, которые пишутся в stdout контейнера и попадают в систему агрегации логов без шифрования. Вторая — логи API-сервера экспериментов, где в теле запроса или заголовках может оказаться токен, сопоставимый с конкретным пользователем. Третья — дампы базы данных событий для отладки, которые разработчики копируют на локальные машины. Каждый из этих сценариев — потенциальная утечка. При обнаружении: 24 часа на первичное уведомление РКН (ч. 3.1 ст. 21 ФЗ-152), 72 часа — на отчёт о расследовании (Приказ РКН №187 от 14.11.2022). Неуведомление — штраф от 1 до 3 млн ₽ по ч. 11 ст. 13.11 КоАП.

Технические меры: маскирование ПДн в логах на уровне приложения (log masking — замена email, телефона, user_id на хэш или маску перед записью), ограничение доступа к лог-агрегатору (ELK, Loki) по ролям, запрет копирования production-дампов без согласования с ответственным за обработку ПДн по ст. 22.1 ФЗ-152.

Типовые сценарии для CTO: ситуация, исход, стратегия

Сценарий 1. Firebase Crashlytics и Remote Config в приложении с аудиторией более 100 000. CTO подключил Firebase SDK на старте, события пишутся на серверы Google в США. Ч. 5 ст. 18 ФЗ-152 нарушена: хранение ПДн российских пользователей — за рубежом. При плановой проверке РКН — штраф по ч. 8 ст. 13.11 от 1 до 6 млн ₽. Стратегия: разделить SDK-события на российский буфер (self-hosted или Yandex Cloud), настроить проксирование Firebase через российский сервер, дополнить договор поручения обработки с Google LLC по ст. 12 ФЗ-152 и уведомить РКН о трансграничной передаче.

Сценарий 2. A/B-тест алгоритма ранжирования на датасете с user_id без обезличивания. ML-команда обучает модель на events_log за 12 месяцев. Датасет передаётся подрядчику ML-разработки без договора поручения обработки. Это нарушение ст. 6 ч. 3 ФЗ-152 (поручение без договора) и ст. 5 (обработка сверх заявленных целей). При жалобе пользователя или проверке РКН — протокол по ч. 1 ст. 13.11 (150–300 тыс. ₽) плюс предписание устранить. Стратегия: токенизировать user_id, применить агрегацию по когортам, заключить договор поручения с подрядчиком.

Сценарий 3. Утечка конфигурации feature-флагов с параметрами сегментации. Файл конфигурации экспериментальной платформы (YAML с условиями таргетинга: user_id in list, email contains domain) случайно попал в публичный репозиторий. Список user_id — это ПДн. Оператор обязан уведомить РКН в течение 24 часов с момента обнаружения. Задержка — штраф по ч. 11 ст. 13.11 от 1 до 3 млн ₽. Стратегия: немедленно отозвать доступ к репозиторию, зафиксировать время обнаружения, подготовить первичное уведомление по форме Приказа РКН №187, через 72 часа — отчёт о расследовании.

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

Кейс 1. IT-компания (Северо-Западный ФО, начало 2026) развивала мобильное приложение с активной аудиторией около 300 000 пользователей. Экспериментальная платформа хранила события в американском облаке. При внеплановой проверке РКН был составлен протокол по ч. 8 ст. 13.11 КоАП (нарушение локализации). Технический директор инициировал миграцию данных на российский хостинг и представил план устранения до рассмотрения дела. Арбитражный суд региона учёл оперативность и назначил штраф в нижней части диапазона — около 1,2 млн ₽. Обжалование позволило снизить сумму дополнительно с применением смягчающих обстоятельств по ст. 4.1 КоАП.

Кейс 2. SaaS-платформа экспериментов (Уральский ФО, осень 2025) передала датасет с user_id и событиями кликов подрядчику ML без договора поручения. Пользователь подал жалобу в РКН, указав на обработку его данных сторонней организацией. РКН возбудил дело по ч. 1 ст. 13.11 КоАП. Компания представила ретроспективно заключённый договор поручения и доказательства применения токенизации. Производство завершилось штрафом в сотни тысяч рублей; повторного нарушения не последовало. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны по Приказу ФСТЭК №21 для мобильного приложения с УЗ-3?

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

Итог

Эксперименты в мобильных приложениях — это не только продуктовая практика, но и полноценная обработка персональных данных, которая требует определённого уровня защищённости по ПП РФ №1119, договоров поручения с каждым SDK-провайдером, локализованного хранения событий и задокументированных процедур обезличивания для ML. С 30.05.2025 санкции по ст. 13.11 КоАП кратно выросли: нарушение локализации — от 1 до 6 млн ₽, неуведомление об утечке — от 1 до 3 млн ₽, повторная утечка — оборотный штраф до 500 млн ₽.

Практика DATUM сопровождает IT-команды и CTO в построении архитектуры обработки ПДн, соответствующей требованиям 152-ФЗ и Приказа ФСТЭК №21: от определения УЗ и разработки модели угроз до оформления договоров поручения с зарубежными SDK-провайдерами и внедрения процедур обезличивания датасетов для ML.