Передача обезличенных в ЕИП НСУД (ст. 13.1)

С августа 2024 года российское законодательство о персональных данных сделало следующий шаг в сторону государственного контроля над обезличенными данными. ФЗ-233 ввёл ст. 13.1 ФЗ-152, которая создаёт механизм принудительной передачи обезличенных ПДн в ЕИП НСУД. Для технических директоров это не абстрактный правовой вопрос: речь идёт о конкретных требованиях к форматам данных, методам обезличивания и инфраструктуре, которая должна обеспечивать как соответствие закону, так и работоспособность продукта.

Что такое ЕИП НСУД и зачем туда передавать данные?

Национальная система управления данными — государственная инфраструктура, развиваемая Минцифры для консолидации и повторного использования данных государственных органов и компаний с госучастием. ЕИП НСУД — единая информационная платформа этой системы, куда стекаются массивы обезличенных данных для аналитики и государственного управления.

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

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

Как соотносятся уровни защищённости УЗ-1..4 и обезличенные данные?

CTO SaaS-компании часто задаётся вопросом: если мы обезличиваем данные, нужно ли нам соблюдать требования УЗ-3 или УЗ-4 по ПП РФ №1119? Ответ зависит от стадии обработки.

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

После обезличивания (если оно выполнено методами, утверждёнными РКН) данные выходят из-под режима ФЗ-152 в части требований к защите ПДн. Однако здесь возникает архитектурная проблема: в реальном конвейере обработки данных оба состояния существуют одновременно. У вас есть «сырые» ПДн в одной части системы и обезличенные — в другой. Требования УЗ применяются к части с «сырыми» данными, и граница между ними должна быть жёстко задокументирована.

Для SaaS с мультиарендностью (multi-tenancy) это дополнительный уровень сложности: данные разных клиентов-арендаторов изолированы на уровне приложения, но могут физически находиться в одной ИСПДн. Если хотя бы один арендатор передаёт специальные категории ПДн (медицинские, биометрические), вся система может попасть под УЗ-2 или УЗ-1.

Что меняется в обезличивании данных для ML с 2025 года?

Машинное обучение — один из главных потребителей обезличенных данных. Модели обучаются на исторических данных о поведении пользователей, транзакциях, медицинских событиях. До 2025 года большинство компаний использовали собственные подходы к псевдонимизации и называли результат «обезличенными данными». Это больше не работает.

РКН утвердил пять методов обезличивания, и только данные, обработанные этими методами, считаются обезличенными по смыслу ст. 13.1 ФЗ-152. Метод «введение идентификаторов» (замена прямых идентификаторов на суррогатные ключи) — наиболее близок к традиционной псевдонимизации, но он требует, чтобы таблица соответствия хранилась отдельно и с дополнительными мерами защиты. Метод «обобщение и агрегация» подходит для обучения статистических моделей, но теряет гранулярность, необходимую для персонализированных рекомендательных систем.

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

Дополнительный риск: если ваши модели дообучаются (fine-tuning) на данных клиентов SaaS-платформы, вопрос о роли оператора становится острее. Согласно принципу поручения обработки по ст. 6 ФЗ-152, если вы обрабатываете данные клиента по его поручению — вы обработчик, а не оператор. Но если вы используете данные клиента для обучения собственных моделей, выходящих за рамки поручения, — вы становитесь самостоятельным оператором с полным объёмом обязательств.

Можно ли хранить ИСПДн в иностранных облаках после 01.07.2025?

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

Для CTO SaaS-компании с инфраструктурой в AWS, GCP или Azure это означает одно из трёх: перенести ПДн российских пользователей в российское облако (Яндекс.Облако, SberCloud, облако МТС), выстроить гибридную архитектуру с раздельными базами, или прекратить сбор ПДн российских граждан на зарубежной инфраструктуре. «Можно хранить копию в России» — недостаточно. Первичная запись должна происходить в российской базе.

Нарушение требования локализации — ч. 8 ст. 13.11 КоАП: штраф для юрлица от 1 до 6 млн ₽ при первичном нарушении, от 6 до 18 млн ₽ при повторном (ч. 9 ст. 13.11). При этом передача обезличенных данных в ЕИП НСУД не освобождает от требований локализации «сырых» ПДн.

Salesforce, HubSpot и аналогичные CRM-системы с обработкой в европейских ДЦ создают прямое нарушение ч. 5 ст. 18 ФЗ-152. Если в этих системах хранятся ПДн российских граждан — это основание для внеплановой проверки РКН. Вопрос не в том, «заметят ли» — РКН мониторит крупные утечки и жалобы, и иностранные облака становятся индикатором риска.

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

В мультиарендной SaaS-архитектуре персональные данные разных клиентов-арендаторов обрабатываются в одной инфраструктуре. Это создаёт правовую неопределённость: кто оператор, кто обработчик, и как соотносятся их обязательства.

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

Проблема возникает, когда SaaS-компания использует агрегированные данные всех арендаторов для обучения ML-моделей или аналитики продукта. Если в договоре поручения это явно не разрешено — это выход за рамки поручения и самостоятельная обработка. В таком случае SaaS-компания становится оператором в отношении этих данных и обязана иметь собственное правовое основание обработки по ст. 6 ФЗ-152.

Ст. 272.1 УК РФ (введена ФЗ-421, действует с 11.12.2024) устанавливает уголовную ответственность за незаконное использование, передачу, сбор или хранение компьютерной информации с ПДн. Для технического директора, который санкционировал использование клиентских данных за рамками поручения для обучения ML-моделей, это не абстрактный риск: максимум по ч. 5 — лишение свободы до 10 лет при тяжких последствиях.

Типовые ситуации для CTO при передаче обезличенных данных в ЕИП НСУД

Ситуация 1. SaaS-платформа получила требование Минцифры о передаче обезличенных данных в ЕИП НСУД, но данные обезличены собственным алгоритмом псевдонимизации. Ситуация: данные «обезличены» заменой ID на суррогатные ключи — метод, не входящий в перечень РКН. Доказательства: таблица соответствия суррогатных и реальных ID существует и доступна оператору. Вероятный исход: РКН квалифицирует данные как персональные, передача в ЕИП НСУД невозможна, оператор получает предписание об устранении. Стратегия: применить утверждённые методы обезличивания (обобщение/агрегацию для ML-данных, введение идентификаторов с уничтожением таблицы соответствия для исторических) и повторно передать.

Ситуация 2. Мультиарендная SaaS-платформа: арендатор-клиника передаёт специальные категории ПДн пациентов. Ситуация: один из арендаторов B2B SaaS — медицинская организация, передающая через API данные пациентов (специальная категория по ст. 10 ФЗ-152). Вся ИСПДн платформы попадает под УЗ-2 или выше. Доказательства: отсутствие технической изоляции данных на уровне ИСПДн. Вероятный исход: при проверке РКН — нарушение требований к уровню защищённости, предписание, штраф в сотни тысяч рублей. Стратегия: сегментировать ИСПДн, выделить данные медицинского арендатора в отдельную аттестованную систему с УЗ-2 и мерами по Приказу ФСТЭК №21.

Ситуация 3. CTO перенёс часть инфраструктуры в российское облако, но первичная запись ПДн до сих пор происходит в AWS через европейский endpoint. Ситуация: архитектура репликации — запись в EU, репликация в RU. Требование ч. 5 ст. 18 ФЗ-152 о первичной записи в российской базе нарушено. Вероятный исход: при проверке — штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. Стратегия: изменить точку первичной записи (primary write) на российский ДЦ, EU-инстанс перевести в режим read replica или отдельного хранилища для нероссийских пользователей.

Как это работает на практике: примеры из судебной и регуляторной практики

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

Кейс 2. Согласно материалам дела АС Санкт-Петербурга и Ленинградской области (дело № А56-4733/2026, первые штрафы по новым нормам ст. 13.11), утечка данных около 70 000 субъектов произошла в результате хакерской атаки. Несмотря на последующую готовность компании к диалогу с регулятором, отсутствие надлежащей документации о методах обезличивания и классификации ИСПДн существенно осложнило позицию в суде. Своевременная классификация ИСПДн и документирование мер защиты по Приказу ФСТЭК №21 изменили бы исход в части смягчающих обстоятельств.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн по Приказу ФСТЭК №21?

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

Итог

Ст. 13.1 ФЗ-152 встраивает обязательную передачу обезличенных данных в ЕИП НСУД в контекст уже существующих требований: классификации ИСПДн по УЗ, мер защиты по Приказу ФСТЭК №21, локализации по ч. 5 ст. 18 и надлежащего оформления поручения обработки. Для CTO это означает, что «обезличивание для compliance» и «обезличивание для ML» — не тождественные задачи: метод, подходящий для передачи в НСУД, может не подходить для обучения рекомендательной модели, и наоборот. Выстраивать конвейер обработки нужно с учётом обеих задач одновременно.

DATUM сопровождает IT-компании и SaaS-платформы в классификации ИСПДн, выборе методов обезличивания под требования РКН и документировании архитектуры обработки для диалога с регулятором. Практика по 152-ФЗ в части технической стороны — аудит, DPIA, ОРД для IT-команд.

22 января 2029 года