Тесты в продакшене: правовые риски

С 30.05.2025 действует расширенная ст. 13.11 КоАП в редакции ФЗ-420 от 30.11.2024: 18 составов вместо прежних семи. Тесты в продакшене попадают под несколько из них одновременно — в зависимости от архитектуры, категории данных и наличия подрядчика. Ниже — разбор ключевых точек риска, которые технический директор обязан закрыть до, а не после инцидента.

Почему тест в продакшене — это обработка ПДн по ФЗ-152?

Многие команды разграничивают «настоящую» обработку данных и технические эксперименты. С точки зрения ФЗ-152 это разграничение не работает. Ст. 3 определяет обработку широко: любое действие с данными, включая извлечение, использование, модификацию, — это обработка. Если A/B-тест читает профиль пользователя, чтобы определить, в какую группу его поместить, — это обработка. Если feature-флаг логирует идентификатор сессии и IP-адрес — это тоже обработка.

Ключевой вопрос — цель. По ст. 5 ФЗ-152 обработка должна ограничиваться конкретными, заранее определёнными целями. Если согласие пользователя или иное правовое основание по ст. 6 не охватывает «проведение технических экспериментов для улучшения продукта», оператор нарушает принцип целевого ограничения. Большинство политик конфиденциальности SaaS-продуктов этой цели не содержат.

Дополнительный риск — логирование как ПДн. IP-адрес в сочетании с идентификатором устройства и временными метками позволяет однозначно идентифицировать пользователя. Роскомнадзор рассматривает такие комбинации как персональные данные. Логи тестовых сценариев, записанные в боевую систему журналирования, — отдельный объём ПДн с собственным сроком хранения и требованиями к защите.

Какой уровень защищённости (УЗ) применяется к тестовой среде?

Уровни защищённости ИСПДн определяются ПП РФ №1119 от 01.11.2012. Если тестовая среда работает с боевыми данными, она автоматически входит в ту же информационную систему персональных данных (ИСПДн), что и продакшн. Уровень не снижается от того, что среда называется «тестовой».

Матрица определения УЗ строится по трём параметрам: категория ПДн, тип угроз и число субъектов. Порог в 100 000 субъектов принципиален — при его превышении минимально допустимый уровень повышается. Для SaaS с несколькими тысячами активных пользователей типичен УЗ-3, при специальных категориях (здоровье, биометрия) — УЗ-2 или УЗ-1.

Меры защиты для каждого УЗ конкретизированы в Приказе ФСТЭК №21 от 18.02.2013. Он содержит 15 групп мер (идентификация и аутентификация, управление доступом, защита носителей, регистрация и учёт и др.). Тестовая среда, подключённая к боевой ИСПДн, обязана реализовывать тот же базовый набор мер, что и продакшн. Отдельный вопрос — среда CI/CD и репозитории: если в них попадают реальные дампы или конфиги с ПДн, они тоже становятся частью ИСПДн.

Как правильно использовать обезличивание для ML и A/B-тестов?

Обезличивание — основной инструмент снижения правового риска при тестировании. Если данные приведены к виду, при котором субъект не определяется без дополнительной информации, они выходят за пределы регулирования ФЗ-152. Однако обезличивание должно соответствовать методам, утверждённым Роскомнадзором.

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

Для обучения ML-моделей и проведения A/B-тестов правильная последовательность такая:

• Определить минимально необходимый набор атрибутов для эксперимента.
• Применить утверждённый метод обезличивания к боевым данным до передачи в тестовую среду.
• Зафиксировать метод, дату и ответственного в журнале обработки.
• Не хранить ключи реидентификации в той же среде, что и обезличенные данные.
• Проверить, что результаты эксперимента не позволяют восстановить исходные ПДн.

Обезличивание для ML имеет дополнительную сложность: модели могут запоминать отдельные записи из обучающей выборки и воспроизводить их при определённых запросах (атака membership inference). Это означает, что даже обученная модель может быть квалифицирована как носитель ПДн при недостаточном объёме и диверсификации выборки.

Мультиарендность SaaS: кто оператор при тестах на данных клиента?

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

Выход за рамки поручения означает, что в части тестового использования данных вы становитесь самостоятельным оператором без правового основания. Это нарушение ч. 1 ст. 13.11 КоАП: обработка в случаях, не предусмотренных законом. Штраф для юрлица — 150 000–300 000 ₽ за первичное нарушение, 300 000–500 000 ₽ при повторном.

Риск усиливается при использовании данных нескольких тенантов в одном эксперименте. Это может нарушить принцип недопустимости объединения баз с несовместимыми целями (ст. 5 ФЗ-152) и создать дополнительный состав. Контракт с клиентом должен явно разрешать использование его данных для улучшения платформы — или такое использование должно быть исключено технически.

Тесты через зарубежное облако: что изменилось с 01.07.2025?

Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись с использованием баз данных, расположенных в России. С 01.07.2025 (на основании ФЗ-233) требования к локализации стали строже в части первичного сбора.

Это напрямую касается тестовых сред в иностранных облаках: AWS, GCP, Azure без локального региона. Если тест передаёт реальные ПДн граждан РФ на сервера за пределами РФ — это нарушение требований локализации. Штраф по ч. 8 ст. 13.11 КоАП — 1 000 000–6 000 000 ₽, при повторном нарушении — 6 000 000–18 000 000 ₽.

Трансграничная передача данных в страну без адекватной защиты дополнительно требует уведомления РКН по ст. 12 ФЗ-152. Если данные передаются в рамках эксперимента «временно», это не освобождает от обязанности уведомления. Ни одна из известных практических ситуаций — тестирование модели на AWS, синхронизация логов с Datadog EU, отправка событий в Amplitude — не является исключением.

Допустимый путь: облако с дата-центром в РФ (Яндекс.Облако, VK Cloud, SberCloud и аналоги) либо on-premise инфраструктура. Для модели Feature Flag как сервиса — проверить, где физически хранится конфигурация и логи решений.

Как это выглядит на практике

Кейс 1. IT-компания (Приволжский ФО, осень 2025) проводила A/B-тест рекомендательного алгоритма, подключив тестовую среду к продакшн-базе с профилями 230 000 пользователей. При инциденте в тестовой среде произошла утечка идентификаторов и поведенческих паттернов. РКН квалифицировал тестовую среду как часть ИСПДн и возбудил дело по ч. 13 ст. 13.11 КоАП (утечка от 10 000 до 100 000 субъектов). Технический директор не смог документально подтвердить, что меры по Приказу ФСТЭК №21 были реализованы для тестового контура. Штраф составил несколько миллионов рублей. ⚠️ Конкретные сумма и номер дела — менеджер верифицирует при публикации.

Кейс 2. SaaS-платформа для HR (Центральный ФО, начало 2026) использовала данные нескольких клиентских тенантов для обучения модели ранжирования резюме. В договорах поручения обработки цель «улучшение алгоритмов платформы» прописана не была. При плановой проверке РКН выявил обработку данных за пределами поручения. Компания получила предписание, составлены протоколы по ч. 1 ст. 13.11 по каждому тенанту. Итоговые штрафы и предписания оспорены в арбитраже; DATUM помогло переработать договоры поручения и политику обработки в части экспериментальных целей, что позволило суду снизить санкции. ⚠️ Номер дела и точные суммы — менеджер уточняет при публикации.

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

• DPIA (оценка воздействия) — оценка рисков тестовых сценариев с ПДн, разграничение ролей оператор/обработчик.
• Аудит соответствия 152-ФЗ — проверка тестовых сред, ИСПДн, мер ФСТЭК №21 по чек-листу из 38 пунктов.
• Комплект ОРД под ключ — договоры поручения, политика обработки с тестовыми целями, журналы обезличивания.

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

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

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

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

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

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

Обезличивание для ML — применение одного из пяти методов, утверждённых приказом РКН (введение идентификаторов, изменение состава/семантики, декомпозиция, перемешивание, обобщение), к обучающей выборке или данным эксперимента так, чтобы субъект не мог быть идентифицирован без дополнительной информации. Результат обезличивания должен исключать атаки реидентификации, в том числе membership inference. Самодельный хэш email без разрыва связи с другими атрибутами обезличиванием не считается.

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

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

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

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

Итог

Тесты в продакшене — это обработка реальных ПДн, к которой применяются все требования ФЗ-152: определение УЗ по ПП РФ №1119, реализация мер по Приказу ФСТЭК №21, обезличивание по утверждённым методам, локализация данных и оформление поручения обработки при участии подрядчиков. Архитектурное разделение боевой и тестовой сред — не опциональная best practice, а юридическое требование.

Юристы DATUM сопровождают IT-команды и технических директоров в определении УЗ, разработке модели угроз, оформлении договоров поручения для CI/CD-подрядчиков и подготовке к проверкам РКН. Практика охватывает SaaS-архитектуры, мультиарендные платформы и ML-пайплайны.