Differential privacy для ML

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

Что такое дифференциальная приватность и почему она не равна обезличиванию по 152-ФЗ?

Дифференциальная приватность — формальная гарантия: добавление или удаление одной записи из датасета изменяет выходное распределение модели не более чем в e^ε раз, где ε (эпсилон) — параметр приватности. Чем меньше ε, тем сильнее защита, но хуже точность модели.

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

Практическое следствие: датасет, обработанный дифференциально-приватным шумом, формально остаётся ПДн до тех пор, пока оператор не получит от РКН подтверждение, что применённый метод признаётся надлежащим. Это означает, что весь ML-пайплайн с таким датасетом подпадает под требования ст. 19 ФЗ-152 об организационных и технических мерах защиты, и к нему применяются нормы ПП РФ №1119 об уровнях защищённости.

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

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

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

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

Вторая развилка — тип угроз. Угрозы 1-го типа связаны с недокументированными возможностями системного ПО, угрозы 2-го типа — с прикладным ПО. Большинство ML-платформ на базе open-source (PyTorch, TensorFlow, Hugging Face) квалифицируются регуляторами как прикладное ПО — это угрозы 2-го типа и, соответственно, более высокий УЗ.

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

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

Как применяется differential privacy в контексте требований ФСТЭК и РКН?

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

DP в контексте ML чаще реализуется через два механизма: добавление шума к градиентам при обучении (DP-SGD, библиотека Google DP или Opacus от Meta) и добавление шума к агрегированным запросам в инференсе. Оба механизма не заменяют меры из Приказа №21, но могут документироваться как дополнительные меры в модели угроз (раздел оценки остаточных рисков) и в DPIA.

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

Где проходит граница ответственности при облачном ML и мультиарендной SaaS?

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

Для ML-систем это означает, что обучение модели на данных граждан РФ в облаке AWS, GCP или Azure (датацентры за пределами РФ) нарушает требование локализации. Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽, повторное нарушение — 6–18 млн ₽ по ч. 9. Дообучение (fine-tuning) на российских данных в зарубежном облаке — та же ситуация.

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

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

Типовые сценарии: как развиваются риски для CTO

Сценарий 1. ML-платформа классифицирует ИСПДн как УЗ-4, но фактически обрабатывает данные о здоровье. Ситуация: компания использует поведенческие данные приложения для фитнеса в качестве обучающего датасета — косвенные сведения о состоянии здоровья. Данные о здоровье — специальная категория по ст. 10 ФЗ-152. Доказательства: проверка РКН обнаруживает признаки специальных категорий в feature engineering (пульс, активность, сон). Вероятный исход: переклассификация ИСПДн на УЗ-3, предписание об устранении недостатков, штраф по ч. 1 ст. 13.11 (150–300 тыс. ₽) за нарушение условий обработки. Стратегия: до запуска модели провести классификацию данных с участием юриста, при наличии косвенных медицинских признаков — применять требования ст. 10 ФЗ-152.

Сценарий 2. Утечка из системы логирования инференс-сервера. Ситуация: ML-сервис хранит запросы к модели в незащищённом S3-бакете в российском облаке. Хакерская группа публикует 150 000 записей. Доказательства: дата обнаружения, объём утечки, содержание (запросы содержат email и контент пользователей). Вероятный исход: ч. 14 ст. 13.11 КоАП (утечка свыше 100 000 субъектов) — штраф 10–15 млн ₽; параллельно обязанность уведомить РКН в течение 24 часов по ч. 3.1 ст. 21 ФЗ-152, при нарушении срока — ещё штраф 1–3 млн ₽ по ч. 11 ст. 13.11. Стратегия: аудит конфигурации хранилищ логов с применением принципа минимизации (ст. 5 ФЗ-152) — хранить только необходимые поля, шифровать, ограничивать TTL.

Сценарий 3. SaaS-провайдер использует клиентские данные для дообучения базовой модели без поручения. Ситуация: стартап, предоставляющий ML-API корпоративным клиентам, добавил в пользовательское соглашение пункт об использовании данных для улучшения сервиса. Клиенты — операторы ПДн своих пользователей — не давали поручения на такую обработку. Доказательства: анализ договора показывает отсутствие специального поручения по ст. 6 ч. 3 ФЗ-152 с перечнем действий. Вероятный исход: обработка за пределами поручения = самостоятельная обработка без правового основания — ч. 1 ст. 13.11 (150–300 тыс. ₽ за каждого клиента-оператора, подавшего жалобу) и риск расторжения договоров. Стратегия: ввести отдельное согласие на участие в программе улучшения модели либо строго ограничить обработку рамками поручения.

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

Кейс 1. IT-компания Уральского ФО (осень 2025) обучала модель персонализации на данных 80 000 пользователей, хранившихся в Yandex Cloud. Внеплановая проверка РКН выявила отсутствие договора-поручения с облачным провайдером и классификации ИСПДн. Технический директор получил предписание об устранении нарушений; штраф по ч. 1 ст. 13.11 составил сотни тысяч рублей. После сопровождения DATUM оператор оформил поручение, провёл классификацию на УЗ-3 и реализовал базовый набор мер Приказа ФСТЭК №21 в течение 45 дней.

Кейс 2. В деле, рассмотренном арбитражным судом Центрального ФО в начале 2026 года, ML-стартап получил штраф по ч. 13 ст. 13.11 КоАП (утечка от 10 000 до 100 000 субъектов) в размере нескольких миллионов рублей. Утечка произошла через незащищённый эндпоинт inference API, который возвращал в ответах фрагменты обучающих данных — классический membership inference. Суд отклонил довод о применении дифференциальной приватности как смягчающее обстоятельство, поскольку оператор не смог документально подтвердить применённый параметр ε и его соответствие актуальной модели угроз.

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

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

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

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

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

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

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

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

По смыслу ст. 3 ФЗ-152, обезличивание — это приведение данных к виду, при котором без дополнительной информации нельзя установить принадлежность конкретному субъекту. РКН утвердил пять методов: введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение и агрегация. Дифференциальная приватность (DP-SGD, шум к градиентам) не входит в этот перечень как самостоятельный метод, но применяется как дополнительная техническая мера поверх одного из пяти — это снижает риск повторной идентификации (membership inference) и может быть задокументировано в модели угроз и DPIA.

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

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

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

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

Итог

Differential privacy — технически обоснованный метод снижения риска повторной идентификации в ML, но он не является обезличиванием по российскому праву сам по себе. Оператор, обучающий модель на ПДн граждан РФ, обязан классифицировать ИСПДн по ПП РФ №1119, реализовать меры Приказа ФСТЭК №21 и соблюдать локализацию по ч. 5 ст. 18 ФЗ-152. DP применяется как дополнительная мера в модели угроз и DPIA — поверх, а не вместо регуляторных требований.

Практика DATUM включает классификацию ML-систем как ИСПДн, подготовку моделей угроз с учётом ML-специфичных атак (membership inference, model inversion), оформление договоров-поручений с облачными провайдерами и сопровождение при проверках РКН в IT-компаниях.