Метод 2: изменение состава и семантики

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

Что такое метод изменения состава и семантики в контексте ФЗ-152?

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

Практический пример: дата рождения «14.03.1987» заменяется на возрастной диапазон «35–40 лет»; точный адрес — на административный округ; ФИО — на внутренний идентификатор без словарной связи с именем. При этом остаток датасета должен сохранять аналитическую ценность для заявленной цели обработки — иначе метод обесценивает данные без выполнения обязательства оператора перед субъектом.

Ключевое условие корректности: если по оставшимся атрибутам субъект восстанавливается с вероятностью выше случайной — данные не считаются обезличенными. Это особенно актуально для SaaS с мультиарендностью: когда клиент-арендатор видит агрегированную аналитику своего арендатора, риск де-анонимизации через редкие комбинации атрибутов (например, «должность + отдел + регион + возрастной диапазон» при малой численности группы) остаётся реальным.

Как метод 2 соотносится с уровнями защищённости УЗ-1..4 и требованиями ФСТЭК?

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

Для SaaS-продуктов это имеет прямое финансовое значение. Сертифицированные СЗИ класса КС1–КС3, аттестация АС по требованиям УЗ-1 или УЗ-2 — это затраты от нескольких сотен тысяч до нескольких миллионов рублей и сроки от трёх месяцев. Если ML-пайплайн работает на обезличенных по методу 2 данных, а исходные ПДн хранятся в отдельной системе с полным набором мер — архитектурно оправдано держать их изолированными.

Распространённая ошибка CTO: применить метод 2 к датасету для ML, задокументировать это в политике обработки, но при этом хранить маппинг «псевдоним → субъект» в той же системе или том же облаке. По ст. 3 ФЗ-152 данные с доступным ключом де-анонимизации остаются персональными. Маппинг должен быть физически или логически отделён и защищён как минимум на уровне УЗ исходной системы.

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

Как применять метод 2 при обучении ML-моделей и передаче данных подрядчику?

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

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

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

Типичные ошибки при применении метода 2 в SaaS-инфраструктуре

Аудит IT-компаний выявляет несколько устойчивых паттернов нарушений, связанных с методом изменения состава и семантики.

Ошибка 1: псевдонимизация вместо обезличивания. UUID вместо user_id — это псевдонимизация, а не обезличивание, если маппинг хранится в том же кластере баз данных. По позиции РКН псевдонимизированные данные остаются персональными. Метод 2 требует, чтобы удалённые или изменённые атрибуты не были восстановимы без привлечения отдельно хранимой дополнительной информации.

Ошибка 2: обезличивание только «горячих» данных. Архивные таблицы, резервные копии, dev-среды и логи нередко содержат исходные ПДн. Метод 2 должен применяться ко всем копиям датасета, включая снапшоты и экспорты.

Ошибка 3: недостаточное обобщение редких комбинаций. В мультиарендной SaaS небольшой арендатор (20–30 пользователей) с детализированными атрибутами профиля создаёт риск де-анонимизации по уникальным комбинациям. Стандарт k-анонимности (k ≥ 5) — минимальная проверка перед публикацией датасета.

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

Ошибка 5: нарушение требований КИИ при обезличивании. Для субъектов КИИ (187-ФЗ) применение методов обезличивания к данным, обрабатываемым на значимых объектах КИИ, не отменяет требований по защите самих объектов. Обезличивание снимает требования ФЗ-152, но не требования 187-ФЗ и ФСТЭК по КИИ.

Как это применяется на практике: кейсы 2025–2026

Кейс 1. IT-компания (Сибирский ФО, лето 2025) передавала обучающие датасеты для рекомендательной модели внешней ML-команде. UUID вместо user_id применялся как метод обезличивания, однако маппинг-таблица хранилась в том же PostgreSQL-кластере, доступном подрядчику через VPN. При внеплановой проверке РКН квалифицировал данные как персональные, оформил протокол по ч. 1 ст. 13.11 КоАП. Штраф составил несколько сотен тысяч рублей. После введения корректного метода 2 (замена возраста на диапазон, удаление прямых идентификаторов, физическое отделение маппинга) данные перестали квалифицироваться как ПДн.

Кейс 2. SaaS-платформа управления персоналом (Центральный ФО, осень 2025) обрабатывала данные работников нескольких арендаторов. Аналитический модуль выгружал агрегированные отчёты, в которых по комбинации «должность + отдел + стаж» в малых подразделениях (3–4 человека) субъект определялся однозначно. Технический директор по итогам аудита внедрил порог k=5 и обобщение редких комбинаций, зафиксировал это в регламенте обезличивания. Претензий при последующей плановой проверке не возникло.

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

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

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

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

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

2. Можно ли использовать иностранные облака для данных, обезличенных методом 2?

Обезличенные данные, к которым неприменимо понятие «персональные данные» по ст. 3 ФЗ-152, формально не подпадают под требование локализации ч. 5 ст. 18 ФЗ-152 и под регулирование трансграничной передачи ст. 12 ФЗ-152. Однако это работает только при корректном обезличивании: если де-анонимизация технически возможна через маппинг — данные остаются персональными независимо от того, где хранятся. Исходные ПДн до обезличивания должны собираться и храниться в российской инфраструктуре. Штраф за нарушение локализации — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП.

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

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

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

В мультиарендной SaaS оператором в смысле ст. 3 ФЗ-152 является лицо, самостоятельно или совместно с другими определяющее цели и способы обработки. Как правило, это арендатор (клиент платформы), чьи работники или пользователи являются субъектами. SaaS-провайдер, предоставляющий инфраструктуру и не определяющий цели, — лицо, осуществляющее обработку по поручению (ст. 6 п. 3 ФЗ-152). Если провайдер анализирует данные арендаторов в собственных целях (продуктовая аналитика, A/B-тесты) — он становится самостоятельным оператором по этой цели и обязан иметь правовое основание обработки.

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

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

Итог

Метод 2 — изменение состава и семантики — рабочий инструмент для CTO, который позволяет законно передавать данные в ML-пайплайны, аналитические системы и облачным подрядчикам без выполнения полного объёма требований ФЗ-152. Условие одно: обезличивание должно быть реальным, а не номинальным — маппинг физически отделён, комбинации атрибутов не позволяют де-анонимизировать субъекта, метод задокументирован.

Практика DATUM по технической стороне 152-ФЗ включает аудит ML-пайплайнов, проверку архитектуры SaaS на соответствие ПП РФ №1119 и Приказу ФСТЭК №21, подготовку регламентов обезличивания и договоров поручения обработки.