Псевдонимизация vs обезличивание для ML
С 01.09.2025 Приказ РКН №140 закрепил пять обязательных методов обезличивания. Одновременно ФЗ-233 ужесточил локализацию: первичный сбор и накопление ПДн граждан РФ допустимы только в российских базах данных. Для CTO это означает ревизию не только инфраструктуры, но и всего ML-пайплайна — от сырых данных до обученных весов модели. В этом материале — практическое разграничение псевдонимизации и обезличивания, выбор уровня защищённости для ИСПДн, требования ФСТЭК и сценарии применимости в SaaS с мультиарендностью.
Чем псевдонимизация отличается от обезличивания по российскому праву?
Псевдонимизация заменяет прямые идентификаторы (ФИО, email, телефон) суррогатными ключами, сохраняя возможность обратного сопоставления при наличии таблицы соответствий. Именно это обратимость делает псевдонимизированные данные персональными по ст. 3 ФЗ-152: они по-прежнему позволяют идентифицировать субъекта — пусть и через дополнительный шаг. Все обязательства оператора сохраняются в полном объёме: согласие, уведомление РКН, соответствие уровню защищённости ИСПДн.
Обезличивание по смыслу ст. 3 ФЗ-152 — это действия, в результате которых установить принадлежность данных конкретному субъекту без дополнительной информации становится невозможным. Если результат соответствует одному из пяти методов Приказа РКН №140 (введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение и агрегация) и обезличивание документально подтверждено — данные выходят за периметр ФЗ-152.
На практике ML-команды часто путают два подхода. Хеширование email без соли — это не обезличивание: радужные таблицы восстанавливают исходное значение за секунды. Удаление поля ФИО при сохранении уникального user_id — тоже не обезличивание: user_id является косвенным идентификатором. Ни один из этих случаев не соответствует методам Приказа РКН №140, а значит, датасет остаётся ИСПДн со всеми правовыми последствиями.
Ваш ML-датасет сформирован — но какой у него правовой статус?
Если CTO не уверен, является ли обучающая выборка персональными данными по ст. 3 ФЗ-152, — это означает неопределённость уровня защищённости ИСПДн и, возможно, незадекларированную трансграничную передачу в облачный GPU-кластер. Аудит DATUM проверяет весь ML-пайплайн: от источника данных до весов модели и инфраструктуры хранения.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru · Telegram
Как выбрать уровень защищённости ИСПДн для ML-системы?
Уровень защищённости (УЗ) определяется по ПП РФ №1119 по трём параметрам: категория обрабатываемых ПДн, тип актуальных угроз и количество субъектов. Для ML-систем ключевым становится вопрос категории: если обучающий датасет содержит специальные категории (диагнозы, политические взгляды, состояние здоровья по ст. 10 ФЗ-152) или биометрические данные (ст. 11 ФЗ-152) — автоматически применяется УЗ-2 или УЗ-1 в зависимости от числа субъектов и типа угроз.
Порог 100 000 субъектов имеет значение: при превышении этого числа требования к защите возрастают на одну ступень. Для большинства коммерческих ML-моделей, обученных на клиентских данных интернет-сервиса, это означает УЗ-3 (общие ПДн, угрозы 2-го или 3-го типа) или УЗ-2 при угрозах 1-го типа. УЗ-1 требует аттестации ИСПДн и, как правило, встречается в государственных системах или при обработке специальных категорий в крупном масштабе.
Приказ ФСТЭК №21 устанавливает 109 мер в 15 группах. Для ML-системы практически значимы: идентификация и аутентификация (ИАФ), управление доступом (УПД), регистрация событий безопасности (РСБ), защита от вредоносного кода (АВЗ), анализ защищённости (АНЗ) и защита информационной системы (ЗИС). При УЗ-3 базовый набор мер включает обязательное ведение журналов доступа к данным — это напрямую касается логов ML-пайплайна.
Что считается логированием как ПДн и где граница SaaS-мультиарендности?
Логи ML-системы нередко сами являются персональными данными. Строка вида «2025-09-14 14:23:11 user_id=4837291 request=predict outcome=declined» содержит косвенный идентификатор (user_id), привязанный к результату автоматизированного решения. По ст. 16 ФЗ-152 субъект вправе потребовать разъяснений по автоматизированным решениям, затрагивающим его права. Это означает, что лог операции принятия решения — это ПДн, требующий защиты по соответствующему УЗ.
В SaaS с мультиарендностью (multi-tenancy) возникает вопрос о роли оператора и обработчика. Если платформа обрабатывает ПДн клиентов своих арендаторов (tenant), — каждый арендатор является оператором, а SaaS-провайдер действует как лицо, осуществляющее обработку по поручению (ст. 6 ч. 3, ст. 6 п. 3 ФЗ-152). Без письменного договора поручения обработки провайдер становится самостоятельным оператором со всеми вытекающими обязательствами, включая уведомление РКН по ст. 22 ФЗ-152.
Отдельно стоит вопрос облачной инфраструктуры. После ужесточения требований к локализации с 01.07.2025 первичный сбор и накопление ПДн граждан РФ должны происходить в базах данных, физически расположенных в России. Использование иностранного облака (AWS, GCP, Azure) для хранения обучающих датасетов с ПДн граждан РФ — нарушение ч. 5 ст. 18 ФЗ-152 с штрафом по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. При повторном нарушении — от 6 до 18 млн ₽ по ч. 9 ст. 13.11 КоАП.
Что проверить CTO перед запуском ML-пайплайна на клиентских данных
- Определить правовой статус датасета: псевдонимизированные или обезличенные данные — провести тест на обратимость по методам Приказа РКН №140.
- Рассчитать УЗ ИСПДн по ПП РФ №1119: категория ПДн × тип угроз × число субъектов — и зафиксировать результат в акте определения уровня.
- Проверить, заключён ли договор поручения обработки с облачным провайдером и ML-платформой — или они де-факто становятся самостоятельными операторами.
- Убедиться, что первичное накопление и хранение данных происходит в базах на территории РФ (ч. 5 ст. 18 ФЗ-152).
- Проверить покрытие базового набора мер ФСТЭК №21 для соответствующего УЗ: ИАФ, УПД, РСБ, АВЗ, ЗИС.
Практические сценарии: где CTO ошибается чаще всего
Сценарий 1. Датасет «очищен» — хеширование без соли. Команда убрала ФИО и email, заменив их MD5-хешами. Внутренний аудит квалифицировал данные как обезличенные и перевела инфраструктуру на облако в Германии. При проверке РКН установил: MD5 без соли восстанавливается радужными таблицами, user_id сохранены в исходном виде, методы Приказа РКН №140 не применялись. Итог — данные квалифицированы как ПДн, обработка вне РФ — нарушение ч. 5 ст. 18 ФЗ-152, протокол по ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽). Дополнительно: трансграничная передача не была уведомлена через РКН по ст. 12 ФЗ-152. Стратегия защиты: применить метод обобщения или декомпозиции с документированием по Приказу РКН №140, перенести хранение в российский облачный регион, подать уведомление о трансграничной передаче.
Сценарий 2. SaaS-платформа без договора поручения. B2B-сервис аналитики обрабатывает события поведения пользователей клиентов-арендаторов. Договор с арендаторами содержит только пользовательское соглашение — отдельного договора поручения обработки нет. При инциденте с утечкой данных одного из арендаторов РКН предъявил претензии SaaS-провайдеру как самостоятельному оператору, а не обработчику. Штраф по ч. 12 ст. 13.11 КоАП (утечка от 1 000 до 10 000 субъектов) — от 3 до 5 млн ₽. Стратегия: внедрить типовой договор поручения обработки с каждым арендатором, зафиксировать перечень действий, цели и меры защиты по ст. 6 ч. 3 ФЗ-152.
Сценарий 3. Логи ML-модели вне периметра ИСПДн. Команда разработки выгрузила логи инференса (включая user_id и outcome) в систему мониторинга без применения мер по Приказу ФСТЭК №21. Система мониторинга не включена в состав ИСПДн, не аттестована, журналы доступа не ведутся. При внутреннем инциденте (несанкционированный доступ сотрудника) зафиксировать момент утечки не удалось. 24-часовой срок уведомления РКН по ч. 3.1 ст. 21 ФЗ-152 нарушен — штраф по ч. 11 ст. 13.11 КоАП от 1 до 3 млн ₽. Стратегия: включить систему мониторинга в состав ИСПДн, настроить РСБ-меры Приказа ФСТЭК №21, разработать регламент реагирования на инциденты с учётом 24/72-часовых сроков.
Если CTO обнаружил, что ML-инфраструктура не покрыта договором поручения или логи инференса не входят в состав ИСПДн — это открытые риски по ч. 11–12 ст. 13.11 КоАП. Юристы DATUM проведут DPIA и зафиксируют состав ИСПДн до того, как это сделает РКН.
Провести DPIAКак это применяется на практике
Кейс 1. IT-компания (Северо-Западный ФО, осень 2025) разрабатывала рекомендательную систему для ритейлера. Обучающий датасет содержал историю покупок с user_id, привязанными к реальным аккаунтам. Команда квалифицировала данные как обезличенные (удалены ФИО и email), не зафиксировала применение методов Приказа РКН №140 и разместила датасет в иностранном облаке для GPU-обучения. При проверке регулятором установлено нарушение ч. 5 ст. 18 ФЗ-152. После привлечения юристов оператор оперативно перенёс хранение в российский облачный регион, подтвердил применение метода обобщения к user_id и заключил договор поручения с облачным провайдером — штраф по ч. 8 ст. 13.11 КоАП удалось снизить до минимального значения диапазона за счёт устранения нарушения до вынесения постановления.
Кейс 2. SaaS-платформа мониторинга сотрудников (Центральный ФО, начало 2026) работала с арендаторами без индивидуальных договоров поручения обработки. После утечки данных через скомпрометированный API-ключ одного из арендаторов РКН квалифицировал платформу как самостоятельного оператора. Объём утечки — порядка 4 000 субъектов. Квалификация по ч. 12 ст. 13.11 КоАП (3–5 млн ₽). Юристы применили ст. 4.1 КоАП, представили доказательства инвестиций в ИБ и заключённых после инцидента договоров поручения. Суд принял смягчающие обстоятельства.
Услуги DATUM по теме
- DPIA (оценка воздействия) — идентификация состава ИСПДн, оценка угроз, формирование отчёта для РКН.
- Аудит соответствия 152-ФЗ — проверка ML-пайплайна, облачной инфраструктуры и договоров поручения по чек-листу из 38 пунктов.
- Комплект ОРД под ключ — договор поручения обработки, политика, регламент реагирования на инциденты.
Частые вопросы
1. Какой УЗ выбрать для SaaS?
УЗ определяется по ПП РФ №1119 по трём параметрам: категория ПДн (общие, специальные, биометрические), тип актуальных угроз (1–3, определяется оператором по модели угроз) и число субъектов. Для большинства B2B SaaS с общими ПДн клиентов при угрозах 2-го или 3-го типа и числе субъектов менее 100 000 применяется УЗ-3. При наличии специальных категорий или биометрии — УЗ-2 или УЗ-1. Определение УЗ фиксируется в акте и является основанием для выбора набора мер по Приказу ФСТЭК №21.
2. Можно ли использовать иностранные облака?
После ужесточения требований к локализации с 01.07.2025 первичное накопление и хранение ПДн граждан РФ должны осуществляться в базах данных на территории России (ч. 5 ст. 18 ФЗ-152). Размещение обучающих датасетов с ПДн в иностранном облаке — нарушение с штрафом по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. Трансграничная передача обезличенных данных, подтверждённо соответствующих методам Приказа РКН №140, под это ограничение не подпадает — они не являются ПДн.
3. Что такое обезличивание для ML?
Обезличивание для ML — преобразование обучающего датасета одним из пяти методов Приказа РКН №140 (введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение и агрегация) так, чтобы установление принадлежности записей конкретному субъекту стало невозможным без дополнительной информации. После корректного обезличивания данные выходят из-под действия ФЗ-152. Ключевое условие — документальное подтверждение применённого метода и его необратимости применительно к конкретному датасету.
4. Кто оператор в мультиарендной SaaS?
Если SaaS-платформа обрабатывает ПДн конечных пользователей клиентов-арендаторов на основании письменного договора поручения (ст. 6 ч. 3 ФЗ-152), провайдер является обработчиком, а арендатор — оператором. При отсутствии такого договора платформа квалифицируется как самостоятельный оператор со всеми обязательствами: уведомление РКН по ст. 22, соответствие УЗ, реагирование на утечки за 24 часа. Наличие договора поручения — обязательное условие для разграничения ответственности.
5. Какие СЗИ обязательны?
Состав средств защиты информации (СЗИ) определяется уровнем защищённости ИСПДн по Приказу ФСТЭК №21. Для УЗ-3 базовый набор включает меры идентификации и аутентификации (ИАФ), управления доступом (УПД), регистрации событий (РСБ), антивирусной защиты (АВЗ) и защиты информационной системы (ЗИС). Использование сертифицированных СЗИ обязательно при обработке специальных категорий ПДн (УЗ-1 и УЗ-2). Конкретный перечень СЗИ определяется в техническом задании на защиту ИСПДн по результатам моделирования угроз.
Итог
Псевдонимизация не снимает обязательств по ФЗ-152 — любой обратимый суррогат остаётся персональными данными по ст. 3. Обезличивание по методам Приказа РКН №140 выводит датасет из-под регулирования, но только при соблюдении необратимости и документировании. Выбор УЗ по ПП РФ №1119, покрытие мер ФСТЭК №21 и корректный договор поручения обработки — три обязательных элемента правомерного ML-пайплайна на клиентских данных.
DATUM сопровождает IT-команды и CTO при структурировании ML-инфраструктуры под требования ФЗ-152: от определения правового статуса датасетов до DPIA и договоров поручения с облачными провайдерами.