Обезличивание ПДн для ML: 5 методов по приказу РКН 2025

С 1 сентября 2025 года приказ РКН о методах обезличивания обязателен для операторов, которые передают обезличенные данные в Единую информационную платформу национальной системы управления данными (ЕИП НСУД). Для CTO в SaaS, финтехе и медтехе это означает конкретную техническую повестку: выбрать метод, задокументировать его в ОРД, встроить в CI/CD. Далее — разбор каждого из пяти методов с точки зрения ML-практики, выбора уровня защищённости по ПП РФ №1119 и требований Приказа ФСТЭК №21.

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

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

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

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

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

Метод 1. Введение идентификаторов — замена прямых идентификаторов (ФИО, email, телефон) на суррогатные ключи. Ключ сопоставления хранится отдельно от датасета. Для CTO: псевдонимизация в терминах GDPR. Применима в задачах рекомендательных систем, где модели нужен стабильный идентификатор пользователя без привязки к ПДн.

Метод 2. Изменение состава и семантики — замена, обобщение или удаление атрибутов. Дату рождения заменяют возрастным диапазоном, регион — федеральным округом, точный диагноз — группой МКБ. Применима в медтехе и EdTech, где признаки модели можно огрубить без потери предсказательной силы.

Метод 3. Декомпозиция — разбиение датасета на несколько частей, каждая из которых не позволяет идентифицировать субъекта в отдельности. Часть с идентификаторами и часть с содержательными атрибутами хранятся в разных системах с разными правами доступа. Применима в мультиарендных SaaS-архитектурах, где данные клиентов сегрегированы физически.

Метод 4. Перемешивание — перестановка значений атрибутов между записями так, чтобы нарушить связь между идентификатором и содержанием. Применима при подготовке синтетических датасетов для тестирования моделей, но требует контроля статистического распределения — иначе теряется репрезентативность обучающей выборки.

Метод 5. Обобщение и агрегация — замена точных значений интервалами или агрегатами. Суммы транзакций — диапазонами, геолокация — кластерами. Стандартный метод для аналитических витрин в финтехе и ретейле. Для ML: признаки на основе агрегатов часто информативнее точных значений — метод не снижает качество модели и одновременно выполняет требование приказа.

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

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

Матрица определения УЗ строится из трёх параметров: категория ПДн (специальные, биометрические, общедоступные, иные), тип актуальных угроз (1 — атаки через НДВ в ПО системы, 2 — через НДВ в прикладном ПО, 3 — без НДВ), количество субъектов (пороговое значение — 100 000).

Для типового SaaS с ML на поведенческих данных (иная категория, угрозы 2–3 типа) чаще применяются УЗ-3 или УЗ-4. Если в обучающую выборку попадают данные о здоровье или биометрия — УЗ-1 или УЗ-2 неизбежны. При этом многие CTO определяют УЗ формально, не учитывая, что переобучение модели на production-данных меняет фактическую категорию ИСПДн. Это выявляется при проверке РКН как несоответствие заявленного реестра фактическому.

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

Чем грозит обучение ML-модели без обезличивания: три сценария для CTO

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

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

Сценарий 3. Мультиарендный SaaS: данные одного клиента попали в обучающую выборку другого. Ситуация: shared ML-модель дообучается на данных всех арендаторов без сегрегации. Клиент A обнаруживает в выходных данных модели фрагменты, соответствующие данным клиента B. Доказательства: запрос субъекта, экспертиза выходных данных модели. Вероятный исход: нарушение ч. 5 ст. 18 ФЗ-152 (если арендаторы — зарубежные компании), ч. 1 ст. 13.11 КоАП, претензии по договору SaaS. Стратегия: разделить ML-модели по арендаторам или применить федеративное обучение с локализацией данных на стороне клиента.

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

Кейс 1. IT-компания из Сибирского федерального округа (осень 2025) разрабатывала рекомендательную систему для ретейл-клиента. Датасет — 280 000 записей покупателей с историей транзакций. Обезличивание не применялось, договор поручения обработки с внутренней ML-командой отсутствовал. При плановой проверке РКН был выявлен факт обработки без правового основания. Компания получила протокол по ч. 1 ст. 13.11 КоАП. Юристы, привлечённые после вынесения протокола, документально подтвердили применение метода обобщения задним числом и организовали заключение договора поручения. В итоге суд назначил штраф в нижней части диапазона. После инцидента компания внедрила шаг обезличивания в CI/CD с автоматической проверкой перед каждой выгрузкой датасета.

Кейс 2. Финтех-стартап (Центральный федеральный округ, начало 2026) использовал облачную ML-платформу зарубежного провайдера для обучения скоринговой модели на данных заёмщиков. Объём — около 50 000 субъектов. Уведомление РКН о трансграничной передаче подано не было. Дополнительно: ИСПДн требовала УЗ-2 (финансовые данные + угрозы 2 типа), но была задекларирована как УЗ-4. При внеплановой проверке РКН, инициированной жалобой субъекта, были выявлены оба нарушения. Обезличивание методом введения идентификаторов, применённое до передачи данных в облако, позволило снизить квалификацию нарушения по трансграничной передаче. Итого — штраф в сотни тысяч рублей вместо потенциальных миллионов по ч. 8 ст. 13.11 КоАП за нарушение локализации.

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

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

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

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

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

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

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

3. Что такое обезличивание для ML и достаточно ли удалить ФИО из датасета?

Удаление прямых идентификаторов (ФИО, email, телефон) само по себе не является обезличиванием по приказу РКН 2025 и не делает данные необезличенными в правовом смысле. Косвенные идентификаторы — комбинация возраста, профессии, геолокации и времени активности — позволяют повторно идентифицировать субъекта. Корректное обезличивание требует применения одного из пяти методов приказа РКН с документальным подтверждением применённого метода и хранения ключа сопоставления отдельно от датасета.

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

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

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

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

Итог

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

Юристы и технические аналитики DATUM сопровождают IT-компании и SaaS-провайдеров при приведении ML-инфраструктуры в соответствие с ФЗ-152: от определения УЗ и выбора метода обезличивания до подготовки договоров поручения и сопровождения проверок РКН.

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