Federated learning и 152-ФЗ

Federated learning привлекает разработчиков ML-продуктов как способ обучить модель на распределённых данных без их физического перемещения. Банки, медицинские платформы, EdTech-системы и промышленный IoT используют этот подход, чтобы обойти ограничения локализации и трансграничной передачи. Проблема в том, что ни ФЗ-152, ни Приказ ФСТЭК №21 не делают исключений для архитектурных паттернов: если в узле хранятся ПДн — оператор отвечает за их защиту по полной программе. В этом материале — как правильно квалифицировать роли, выбрать уровень защищённости и выстроить обезличивание, чтобы федеративная архитектура стала аргументом в разговоре с регулятором, а не уязвимостью.

Что такое federated learning с точки зрения 152-ФЗ: кто оператор?

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

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

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

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

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

Для типичной SaaS с федеративным ML-пайплайном: если в обучающем датасете присутствуют медицинские, биометрические или финансовые данные — это специальная категория по ст. 10 ФЗ-152, что немедленно поднимает планку до УЗ-1 или УЗ-2. Если датасет содержит только общие ПДн (имя, email, поведенческие паттерны без прямой идентификации) — вероятно УЗ-3 или УЗ-4. Но поведенческие данные в ML-контексте часто позволяют повторную идентификацию — и регулятор может переквалифицировать их в биометрические (ст. 11 ФЗ-152).

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

Как работает обезличивание для ML и почему градиенты — не анонимные данные?

Распространённое заблуждение: раз центральный сервер получает только веса или градиенты модели, а не сырые ПДн — обезличивание не нужно. Это неверно по двум причинам. Во-первых, обучение в узле происходит на сырых ПДн, и именно к ним применяются требования ФЗ-152 и Приказа ФСТЭК №21. Во-вторых, атаки на восстановление данных из градиентов (gradient inversion attacks) технически позволяют реконструировать обучающие примеры — что означает риск утечки ПДн через модельные обновления.

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

Первый — обобщение и агрегация: вместо точных значений признаков используются диапазоны или статистические агрегаты. Применимо на этапе формирования обучающей выборки — до начала обучения в узле. Второй — введение идентификаторов: замена прямых идентификаторов (имя, email, телефон) на псевдонимы с хранением таблицы соответствия в изолированном контуре. Модель обучается на псевдонимизированных данных. Третий — дифференциальная приватность: добавление калиброванного шума к градиентам перед передачей агрегатору. Этот метод снижает риск gradient inversion, но не покрыт явно Приказом РКН — применяется как техническая мера в дополнение к обязательным методам обезличивания.

Для Передачи обезличенных данных в Единую информационную платформу национальной системы управления данными (ЕИП НСУД) применяется регулирование ст. 13.1 ФЗ-152 в редакции ФЗ-233. Если ML-платформа работает с обезличенными данными, переданными Минцифрой, — это отдельный правовой режим с дополнительными ограничениями на цели использования.

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

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

Проблема возникает, когда платформа использует данные разных тенантов для совместного обучения федеративной модели. Ст. 5 ФЗ-152 запрещает объединять базы ПДн с несовместимыми целями. Если цель тенанта А — обслуживание розничных клиентов, а тенанта Б — кредитный скоринг, то обучение единой модели на их данных без явного согласия каждого тенанта и его субъектов может нарушить принцип целевого использования.

Отдельный вопрос — логирование. В федеративной архитектуре логи на уровне узла (события обращения к датасету, запуска обучения, передачи градиентов) сами могут содержать ПДн или метаданные, позволяющие идентифицировать субъектов. Требования к регистрации событий безопасности входят в группу РСБ Приказа ФСТЭК №21. Хранение таких логов на сервере агрегатора может создавать самостоятельную обязанность уведомления РКН, если агрегатор расположен за рубежом — это трансграничная передача по ст. 12 ФЗ-152.

Облако в РФ, КИИ и локализация: что меняется для федеративной системы?

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

Сервер-агрегатор, расположенный за рубежом и получающий градиенты, может квалифицироваться РКН как элемент системы обработки ПДн, если из градиентов возможна реконструкция данных субъектов. Безопасная конфигурация: агрегатор в облаке в РФ (реестр ФСБ/ФСТЭК для классифицированных систем), узлы — у клиентов или в дата-центрах в РФ, внешние ML-фреймворки (TensorFlow Federated, PySyft) — развёрнуты на серверах в РФ без передачи сырых данных за рубеж.

Если система попадает под критическую информационную инфраструктуру (КИИ) по ФЗ-187, требования ужесточаются: необходима категоризация объекта КИИ, подключение к ГосСОПКА, согласование применяемых СЗИ. Финтех, телеком, медицина и энергетика — основные отрасли пересечения федеративного ML и КИИ.

Практические сценарии для CTO: три типичные ситуации

Сценарий 1. Мобильное приложение с федеративным обучением на пользовательских устройствах. Пользователи устанавливают приложение, данные обрабатываются локально, на сервер передаются только обновления модели. Ситуация: разработчик считает, что ПДн не покидают устройство, и уведомление РКН не нужно. Доказательства: согласие пользователя на установку приложения не является согласием на обработку ПДн для ML-обучения по ст. 9 ФЗ-152. Исход: РКН квалифицирует отсутствие отдельного согласия как нарушение ч. 2 ст. 13.11 КоАП (300–700 тыс. ₽). Стратегия: включить в оферту или отдельный документ явное согласие с перечнем действий и целей ML-обучения; при наличии специальных ПДн — письменное согласие по ст. 9 ФЗ-152.

Сценарий 2. B2B SaaS с мультиарендностью: корпоративные клиенты предоставляют датасеты для совместного федеративного обучения. Ситуация: платформа обучает единую модель на датасетах нескольких тенантов, договор поручения есть только с одним из них. Доказательства: отсутствие договора поручения с остальными тенантами — нарушение п. 3 ст. 6 ФЗ-152 и ч. 1 ст. 13.11 КоАП. Объединение датасетов с разными целями — нарушение ст. 5 ФЗ-152. Исход: штраф 150–300 тыс. ₽ плюс предписание об устранении. Стратегия: унифицированный договор поручения обработки, явная оговорка об участии в федеративном обучении, ограничение на совмещение данных с несовместимыми целями на уровне архитектуры.

Сценарий 3. ML-платформа с агрегатором в иностранном облаке. Ситуация: агрегатор размещён на AWS Frankfurt, узлы с ПДн граждан РФ — в РФ. Разработчик полагает, что градиенты — не ПДн. Доказательства: РКН вправе запросить техническую документацию и установить, что из градиентов возможна атака восстановления. Исход: потенциальная квалификация как нарушение локализации (ч. 8 ст. 13.11, 1–6 млн ₽) и трансграничной передачи без уведомления (ч. 10 ст. 13.11, 100–300 тыс. ₽). Стратегия: перевод агрегатора в российское облако; применение дифференциальной приватности на уровне передачи градиентов как дополнительной технической меры; фиксация позиции в технической документации.

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

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

Кейс 2. Медицинская EdTech-платформа (Центральный ФО, осень 2025) использовала федеративное обучение для персонализации контента на основе данных о здоровье пользователей — специальная категория ПДн по ст. 10 ФЗ-152. УЗ-1 требовал сертифицированных СЗИ по Приказу ФСТЭК №21, но реально применялся несертифицированный open-source-стек. После DPIA с юристами компания привлекла интегратора с лицензией ФСТЭК, пересобрала стек на сертифицированных компонентах, получила аттестат соответствия. Штраф по ч. 12 ст. 13.11 в размере от 3 до 5 млн ₽ удалось предотвратить: нарушение устранено до обращения РКН.

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

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

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

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

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

2. Можно ли использовать иностранные облака для федеративной системы с ПДн граждан РФ?

Нет, если в иностранном облаке хранятся, обрабатываются или накапливаются ПДн граждан РФ — это нарушение ч. 5 ст. 18 ФЗ-152 (локализация). Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽, при повторном нарушении по ч. 9 — 6–18 млн ₽. Агрегатор в иностранном облаке, получающий градиенты из которых возможна реконструкция ПДн, также создаёт риск квалификации как нарушение локализации. Безопасное решение — российское облако (Яндекс.Облако, VK Cloud, Selectel, Росттелеком) с аттестацией под нужный УЗ.

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с федеративным ML?

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

Итог

Federated learning не создаёт правового иммунитета от ФЗ-152: каждый узел системы с ПДн — это ИСПДн со своим УЗ, составом мер защиты и ответственностью оператора. Градиенты, передаваемые агрегатору, при определённых условиях могут квалифицироваться как ПДн или их производные. Обезличивание, договоры поручения и локализация инфраструктуры — три обязательных элемента архитектурного комплаенса для любой SaaS с федеративным ML.

Юристы DATUM сопровождают IT-компании при проектировании ML-систем: проводят DPIA, определяют уровень защищённости, формируют ОРД-пакет под мультиарендную архитектуру и помогают пройти аттестацию ИСПДн у лицензиата ФСТЭК.