Synthetic data как альтернатива

С 30.05.2025 регуляторная нагрузка на операторов ПДн кратно выросла. IT-команды, которые используют производственные базы для обучения моделей, тестирования и нагрузочных испытаний, фактически держат в работе лишний слой риска — данные клиентов в средах без должного уровня защищённости. Синтетические данные устраняют эту проблему, но только если процесс генерации и использования оформлен правильно. В этом материале разбираем правовой статус synthetic data, требования к УЗ, поручение обработки и оформление под 152-ФЗ.

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

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

Если synthetic data созданы на основе реальных ПДн (generative adversarial network, вариационный автоэнкодер), сам процесс генерации является обработкой ПДн по ст. 3 ФЗ-152 и требует правового основания по ст. 6. Результирующий набор перестаёт быть персональными данными только тогда, когда исключена возможность деанонимизации — то есть применён один из пяти методов обезличивания, установленных Приказом РКН №140.

Распространённая ошибка — считать, что удаление ФИО и номера телефона само по себе обезличивает данные. Если по комбинации оставшихся атрибутов (возраст, геолокация, профессия, история транзакций) субъект восстанавливаем, данные остаются персональными. Оценить риск деанонимизации обязан оператор — самостоятельно или через DPIA.

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

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

Для ML-среды, где данные реальных клиентов используются на этапе препроцессинга перед синтезом, действует та же логика, что и для любой ИСПДн. Типичная конфигурация e-com или fintech: общие ПДн (не специальные), угроза 3-го типа, более 100 000 субъектов — это УЗ-3. Если категория данных включает сведения о состоянии здоровья или биометрию — минимум УЗ-2.

На этапе, когда реальные данные уже обезличены и в работе находится только синтетический набор, требования ПП №1119 формально к нему не применяются — при условии, что метод обезличивания задокументирован, а исходные данные уничтожены или изолированы. Именно этот момент требует доказательной базы при проверке РКН: аудитного журнала, подтверждающего факт уничтожения промежуточных наборов.

Меры защиты по Приказу ФСТЭК №21 (109 мер в 15 группах) применяются к ИСПДн, в которой хранятся или обрабатываются реальные ПДн. Синтетическая среда, физически изолированная от исходных данных, не требует полного набора мер — но это нужно зафиксировать в модели угроз и техническом задании.

Кто несёт ответственность в SaaS-продукте с мультиарендностью?

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

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

Применительно к synthetic data это создаёт отдельный вопрос: если SaaS-вендор самостоятельно генерирует синтетические данные на основе клиентских ПДн для тестирования или улучшения модели — он выходит за рамки поручения и становится оператором по этому направлению обработки. Это требует отдельного правового основания по ст. 6 и, как правило, уведомления РКН.

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

Логирование как ПДн: где проходит граница?

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

Это означает, что система логирования, используемая для отладки ML-модели, — это ИСПДн. К ней применяются требования ПП №1119 и Приказа ФСТЭК №21 в части соответствующего УЗ. Хранение логов с ПДн за пределами РФ нарушает ч. 5 ст. 18 ФЗ-152.

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

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

Сценарий 1. ML-модель обучается на продовых данных без обезличивания. Продовая база клиентов (500 000 субъектов, общие ПДн) прокачивается через GPU-кластер в dev-среде без договора поручения и без УЗ-3. РКН в ходе внеплановой проверки фиксирует обработку в ИСПДн без аттестации. Применяется ч. 1 ст. 13.11 КоАП (обработка в случаях, не предусмотренных целями) совместно с требованием об устранении по ст. 19 ФЗ-152. Стратегия: разграничить среды, оформить договор поручения, применить обезличивание перед передачей в dev, задокументировать УЗ-3 и меры по Приказу ФСТЭК №21.

Сценарий 2. SaaS-вендор генерирует синтетику для улучшения своей модели. Вендор B2B-SaaS без уведомления клиентов использует их данные для дообучения встроенного ML-рекомендатора. Договор поручения не предусматривает этой цели. Такое использование выходит за рамки поручения и формирует самостоятельное основание для обработки. Без согласия субъектов или иного основания по ст. 6 — это нарушение ч. 1 ст. 13.11 КоАП: от 150 000 до 300 000 ₽, плюс предписание прекратить обработку. Стратегия: либо получить отдельное основание, либо перейти на synthetic data, сгенерированные методами, не связанными с конкретными субъектами.

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

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

Кейс 1. IT-компания (Приволжский ФО, начало 2026 года) использовала продовую базу пользователей сервиса (~200 000 субъектов) как обучающую выборку для рекомендательной модели. Dev-среда размещалась в иностранном облаке без договора поручения. По результатам внеплановой проверки РКН компания получила предписание об устранении и протокол по ч. 1 и ч. 8 ст. 13.11 КоАП. После разработки схемы синтетических данных, миграции обучающей выборки в российский ЦОД и оформления ОРД техническим директором компании удалось обосновать отсутствие умысла и снизить итоговую санкцию. Совокупный штраф составил сотни тысяч рублей вместо максимально возможного по ч. 8.

Кейс 2. Финтех-SaaS (Центральный ФО, весна 2025 года) — мультиарендная платформа для МФО — проводила синтез тестовых данных для нагрузочного тестирования. Метод не соответствовал ни одному из пяти по Приказу РКН №140 (простая анонимизация без подтверждённой необратимости). Аудит DATUM зафиксировал риск квалификации синтетического набора как ПДн и потенциальное нарушение ч. 1 ст. 13.11 КоАП. Команда перешла на метод обобщения с агрегацией, задокументировала процедуру, внесла изменения в договоры поручения с арендаторами. Проверка РКН, состоявшаяся через три месяца, нарушений не выявила.

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

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

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

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

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

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

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

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

Обезличивание для ML — это применение одного из пяти методов по Приказу РКН №140 к исходным ПДн перед их использованием в обучающей выборке. Цель — исключить возможность деанонимизации результирующего набора. Для ML наиболее применимы обобщение (агрегация значений по категориям), введение идентификаторов (замена прямых идентификаторов на псевдонимы) и перемешивание (перераспределение атрибутов между записями). Метод должен быть задокументирован, применён до передачи данных в dev-среду и подтверждён журналом операций. Только после этого результирующий набор теряет статус ПДн по ст. 13.1 ФЗ-152.

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

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

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

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

Итог

Синтетические данные снижают регуляторный риск при работе с ПДн в ML-процессах — но только при соблюдении трёх условий: метод генерации соответствует одному из пяти по Приказу РКН №140, исходные данные обрабатывались с учётом требуемого УЗ по ПП РФ №1119, а договор поручения охватывает именно эту операцию обработки. Без документальной базы переход на synthetic data не снимает регуляторный риск — он его маскирует.

Практика DATUM по технической стороне 152-ФЗ включает аудит ИСПДн, определение УЗ, проверку договоров поручения и оформление регламентов обезличивания для ML-команд в IT, финтехе и SaaS.

11 февраля 2029 года