Эксперименты в B2B-сегменте

B2B-сегмент технологических компаний живёт экспериментами: продуктовые команды тестируют функции на реальных данных клиентов, ML-инженеры обучают модели на исторических транзакциях, SaaS-платформы строят мультиарендную архитектуру, где данные разных корпоративных клиентов хранятся в одном кластере. До 2025 года регулятор смотрел на это как на серую зону. После ФЗ-420 и введения оборотных штрафов — зона стала красной. Эта статья разбирает, какие нормы применимы к B2B-экспериментам, как определить уровень защищённости для SaaS-инфраструктуры и что обезличивание значит на практике для ML-команды.

Почему B2B-эксперименты попадают под 152-ФЗ?

Распространённое заблуждение технических директоров: 152-ФЗ регулирует только B2C — физических лиц, пользователей приложений. Это неверно. Корпоративный клиент SaaS-платформы — юридическое лицо, но его сотрудники, чьи данные хранятся в системе (имена, email, телефоны, роли, история действий), — физические лица и субъекты ПДн по ст. 3 ФЗ-152. Каждый A/B-тест, который разбивает этих пользователей на сегменты и анализирует их поведение, — обработка персональных данных.

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

Если SaaS-провайдер использует данные клиентов для обучения собственных ML-моделей, улучшения продукта или бенчмаркинга — это уже самостоятельная цель обработки, не предусмотренная поручением. В этом случае провайдер становится независимым оператором с отдельным правовым основанием. Без него — нарушение ч. 1 ст. 13.11 КоАП, штраф 150–300 тыс. ₽, при повторности — 300–500 тыс. ₽.

Как определить уровень защищённости для B2B SaaS?

Уровень защищённости информационной системы персональных данных (УЗ) определяется по трём параметрам согласно ПП РФ №1119 от 01.11.2012: категория ПДн, тип актуальных угроз и число субъектов. Для B2B-платформ типичный сценарий — общие категории ПДн (ФИО, email, должность, IP-адреса), угрозы второго типа (уязвимости в прикладном ПО) и число субъектов зависит от клиентской базы.

Пороговое значение по ПП РФ №1119 — 100 000 субъектов. B2B SaaS со 150 клиентами-компаниями и в среднем 200 сотрудниками каждой уже преодолевает этот порог (30 000 субъектов — ниже, 200 клиентов по 500 сотрудников — 100 000 ровно). На практике средняя корпоративная SaaS-платформа быстро выходит за этот порог.

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

Для экспериментальных сред отдельный вопрос: если тестовый стенд содержит копию продакшн-данных с реальными ПДн — он тоже ИСПДн со всеми требованиями по уровню защищённости. Использование анонимизированных или обезличенных данных в тестовой среде снимает это требование — но только при соблюдении требований к методам обезличивания.

Что требует Приказ ФСТЭК №21 для экспериментальных сред?

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

• РСБ — регистрация событий безопасности: логирование действий пользователей, администраторов и обращений к ПДн. Для B2B SaaS это означает, что каждое обращение к данным в рамках эксперимента должно фиксироваться с временной меткой и идентификатором субъекта доступа.
• УПД — управление правами доступа: разграничение доступа между tenant-ами в мультиарендной архитектуре. Данные корпоративного клиента A не должны быть доступны даже технически сотрудникам корпоративного клиента B.
• АНЗ — анализ угроз и уязвимостей: регулярное сканирование инфраструктуры на уязвимости, применимое к CI/CD-пайплайнам и экспериментальным окружениям.
• ЗНИ — защита носителей информации: порядок работы с дампами баз данных и резервными копиями, содержащими ПДн.
• ОЦЛ — обеспечение целостности: контроль целостности данных при экспериментальных трансформациях и миграциях.

Для ML-экспериментов особенно важна группа ЗИС — защита информационной системы. Обученная ML-модель может содержать извлекаемые ПДн (через атаки восстановления тренировочных данных — model inversion attacks). Регулятор пока не сформулировал специальные требования к ML-моделям, но общие требования ЗИС к защите от НСД применяются к артефактам моделей как к компьютерной информации с ПДн.

Как правильно обезличить данные для ML-экспериментов?

Приказ РКН о методах обезличивания (действует с 01.09.2025 вместе с ФЗ-233) закрепил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание и обобщение. Для ML-команд принципиально понимать разницу между методами по степени необратимости и применимости к разным типам экспериментов.

Введение идентификаторов (псевдонимизация) — замена прямых идентификаторов (ФИО, email) на технические ключи с хранением таблицы соответствия отдельно. Метод сохраняет структуру данных и применим для большинства продуктовых A/B-тестов: поведенческие паттерны сохраняются, личность субъекта — нет. Риск: при наличии таблицы соответствия данные остаются персональными в смысле ст. 3 ФЗ-152 — обезличенными они не считаются.

Обобщение и агрегация — перевод точных значений в диапазоны (возраст 34 года → «31–40 лет», город «Москва, Ленинский проспект» → «Москва»). Наиболее безопасный метод для аналитических ML-задач, где важны статистические паттерны, а не индивидуальные записи. Обобщённые данные при правильном применении выходят из-под режима ПДн.

Перемешивание — замена значений атрибутов между записями разных субъектов. Применимо для синтетических датасетов, но разрушает корреляции, критичные для большинства ML-задач. На практике используется редко.

Практическая проблема большинства ML-команд: обезличивание применяется к структурированным полям (имя, email), но не к неструктурированным текстам (комментарии, тикеты поддержки, описания задач). Поисковый запрос «Иван Петров, заказ №12345, адрес доставки Пресненская набережная» в тексте не обезличивается заменой email-адреса. Для NLP-экспериментов это означает, что метод обезличивания должен включать обработку свободного текста.

Кто оператор в мультиарендной SaaS: практические сценарии

Мультиарендная архитектура (multi-tenancy) — технически удобное, юридически сложное решение. Три практических сценария с разными правовыми последствиями.

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

Стратегия для провайдера: заключить с каждым клиентом явный договор поручения обработки с исчерпывающим перечнем действий, обеспечить логическую изоляцию tenant-ов, не использовать данные клиента А в каких-либо процессах, связанных с клиентом Б.

Сценарий 2. SaaS-платформа использует данные для улучшения продукта. Провайдер анализирует поведение пользователей всех клиентов для улучшения алгоритмов, обучения ML-моделей, формирования бенчмарков. Правовой статус: провайдер — самостоятельный оператор в части этих целей. Нужно собственное правовое основание: либо согласие субъектов (ст. 9 ФЗ-152, с 01.09.2025 — отдельный документ по ФЗ-156), либо явное включение этой цели в договор с корпоративным клиентом, который обеспечивает соответствующее согласие своих сотрудников.

Стратегия: разграничить в документации цели обработки для каждого потока данных. Для ML-экспериментов — либо обезличивание до уровня, выводящего данные из-под ПДн-режима, либо отдельное правовое основание.

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

Стратегия: все типы экспериментов на данных клиентов — в приложение к договору поручения с явным согласием клиента-оператора. Opt-out для корпоративного клиента должен быть технически реализован.

Облачная инфраструктура и требования локализации для B2B

Требование локализации по ч. 5 ст. 18 ФЗ-152 применяется при обработке ПДн граждан Российской Федерации. Для B2B SaaS с российскими корпоративными клиентами это означает: первичный сбор, систематизация, накопление и хранение ПДн российских сотрудников этих клиентов должны происходить в базах данных, физически расположенных в России.

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

Практическое решение для B2B SaaS с зарубежной инфраструктурой: гибридная архитектура с российским регионом для хранения и первичной обработки российских ПДн. Аналитические и ML-задачи могут выполняться за рубежом — при условии обезличивания данных до передачи туда. Если обезличивание сделано корректно, оставшийся набор данных не является ПДн и ограничения локализации к нему не применяются.

Для платформ, попадающих под критерии субъектов КИИ по 187-ФЗ, требования к инфраструктуре дополнительно ужесточены. Категорированные объекты КИИ должны использовать сертифицированные средства защиты и российскую инфраструктуру вне зависимости от требований 152-ФЗ.

Практика: как это работает в реальных B2B-проектах

Кейс 1. SaaS-платформа автоматизации продаж (Уральский ФО, весна 2025) хранила данные 180 корпоративных клиентов — около 140 000 сотрудников-пользователей. Тестовый стенд для ML-экспериментов использовал еженедельные дампы продакшн-базы без обезличивания. При внеплановой проверке РКН (инициирована после жалобы физического лица) выявили отсутствие договора поручения с шестью клиентами, использование данных для ML-экспериментов без правового основания и нарушение требований УЗ-3 в части логирования. Совокупные штрафы по ч. 1 и ч. 4 ст. 13.11 составили несколько сотен тысяч рублей; предписание об устранении нарушений в части технических мер — выполнение в течение 90 дней под угрозой повторных санкций. Технический директор инициировал полный аудит архитектуры и переход на обезличенные датасеты для экспериментов.

Кейс 2. Согласно делу АС Санкт-Петербурга и Ленинградской области (дело № А56-4733/2026, кейс case_S2_pkr_analitika), цифровая платформа допустила утечку около 70 000 субъектов — ФИО, должности, служебные email, телефоны. Квалификация — ч. 14 ст. 13.11 КоАП (утечка более 100 000 идентификаторов). Несмотря на тяжесть нарушения, суд применил смягчающие обстоятельства. Для B2B-платформ этот кейс демонстрирует: корпоративные email и должности в сочетании с именами — полноценные ПДн, не «просто рабочие контакты».

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Эксперименты в B2B-сегменте — A/B-тесты, ML-пайплайны, продуктовая аналитика — работают с персональными данными вне зависимости от корпоративного характера клиентов. Правовой статус SaaS-провайдера (обработчик или самостоятельный оператор), уровень защищённости инфраструктуры по ПП РФ №1119 и корректность обезличивания по методам РКН — три параметра, которые определяют весь профиль риска. С 30.05.2025 повторная утечка переводит риск в категорию оборотного штрафа по ч. 15 ст. 13.11 КоАП с нижней планкой 20 млн ₽.

DATUM сопровождает B2B-платформы в определении УЗ, разработке договоров поручения, DPIA для новых ML-функций и подготовке архитектурной документации для прохождения проверок ФСТЭК и РКН.

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