l-diversity для ML-датасета

С 1 сентября 2025 года Роскомнадзор ввёл в действие порядок обезличивания персональных данных с закреплением конкретных методов. Для IT-команды это означает: решение «мы заменили имена на хэши» больше не считается достаточным обоснованием. Регулятор проверяет результат — нельзя ли восстановить личность по совокупности полей. l-diversity и смежные подходы (t-closeness, k-анонимность) описывают именно этот результат. В материале — как применить l-diversity к ML-датасету в рамках требований 152-ФЗ, какой уровень защищённости (УЗ) влечёт какие обязательства по ФСТЭК, и что происходит, когда обезличивание сделано формально.

Что такое обезличивание по 152-ФЗ и почему хэш не равен обезличиванию?

Обезличивание по ст. 3 ФЗ-152 — это действия, в результате которых невозможно без использования дополнительной информации определить принадлежность данных конкретному субъекту. Ключевое слово — «невозможно». Хэш SHA-256 от телефонного номера технически обратим при наличии таблицы номеров — это не обезличивание, это псевдонимизация.

Приказ РКН 2025 года описывает пять методов. Обобщение (generalization) — замена точного значения диапазоном: возраст «34» становится «30–40». Перемешивание (permutation) — случайная замена значений между записями внутри группы. Декомпозиция — разбиение таблицы на части без общего ключа. Изменение состава — удаление или замена отдельных полей. Введение идентификаторов — замена прямых идентификаторов суррогатными ключами с хранением таблицы соответствия в изолированной системе.

l-diversity — результирующий критерий, который проверяют поверх применённых методов. Он требует, чтобы в каждом эквивалентном классе (группе записей с одинаковыми квазиидентификаторами) присутствовало не менее l различных значений чувствительного атрибута. Если в датасете пациентов с одинаковым полом, возрастным диапазоном и регионом у всех один и тот же диагноз — l=1, и датасет уязвим для атаки по однородности.

Для ML-датасета важны три уровня защиты: k-анонимность (каждый квазиидентификатор встречается не менее k раз), l-diversity (в каждом классе не менее l различных чувствительных значений) и t-closeness (распределение чувствительных значений в классе близко к общему распределению). Только совокупность этих критериев даёт защиту от атак по однородности и фоновым атакам. Документально подтвердить результат по требованию РКН проще всего через автоматизированный отчёт Python/ARX с фиксацией параметров.

Какой уровень защищённости (УЗ) требуется для ML-инфраструктуры?

Уровень защищённости определяется по ПП РФ №1119 через три параметра: категория ПДн, тип актуальных угроз и число субъектов (пороговое значение — 100 000). Для ML-проекта это означает: тип датасета полностью меняет уровень обязательств.

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

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

Практическая проблема ML-систем: датасет на входе может соответствовать УЗ-4, но после обогащения (join с CRM, добавление геолокации) система переходит в УЗ-3 без пересмотра модели угроз. Приказ ФСТЭК №21 требует пересматривать модель угроз при изменении состава обрабатываемых ПДн. Большинство ML-команд этого не делают.

Как применить l-diversity на практике: четыре шага для ML-команды

Применение l-diversity к реальному датасету — итеративный процесс. Оптимальные параметры зависят от распределения данных и требуемого качества модели. Ниже — практическая последовательность.

Шаг 1. Идентификация квазиидентификаторов и чувствительных атрибутов. Квазиидентификаторы — поля, которые по отдельности не идентифицируют субъекта, но в сочетании — могут. Типичные примеры для e-commerce: пол + возрастной диапазон + регион + категория покупок. Чувствительный атрибут — то, что нельзя раскрыть: диагноз, кредитный рейтинг, факт увольнения.

Шаг 2. Построение эквивалентных классов и проверка k-анонимности. Сгруппируйте записи по уникальным комбинациям квазиидентификаторов. Если размер класса меньше k (рекомендуемое k≥5 для чувствительных данных) — обобщайте атрибуты или удаляйте записи. Библиотеки: Python ARX (через Jython), anonympy, pycanon.

Шаг 3. Проверка l-diversity в каждом классе. Для каждого эквивалентного класса подсчитайте число различных значений чувствительного атрибута. Если l меньше целевого значения — применяйте перемешивание или удаляйте избыточные записи. Рекомендуемое l≥3 для медицинских и финансовых данных; l≥2 для общих категорий.

Шаг 4. Фиксация результата и документирование. Сохраните параметры обезличивания (k, l, список квазиидентификаторов, метод), версию датасета, дату и ответственного. Этот документ — основание для ответа на запрос РКН и аргумент в арбитраже при оспаривании протокола по ст. 13.11 КоАП.

Что меняется при передаче датасета подрядчику или в облако?

Передача датасета для обучения модели внешней ML-командой или в облачный GPU-кластер — это поручение обработки по п. 3 ст. 6 ФЗ-152. Оператор обязан заключить договор поручения, в котором явно указаны: цель обработки, перечень действий, обязанность по конфиденциальности, требования к безопасности и право оператора на контроль.

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

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

Три типовых сценария нарушений при обезличивании ML-датасетов

Сценарий 1. Псевдонимизация без проверки k-анонимности. Ситуация: ML-команда заменила email и телефон на UUID, передала датасет подрядчику. В датасете 200 записей пациентов редкого возраста из одного района — каждая запись уникальна по совокупности квазиидентификаторов. Доказательства: подрядчик восстановил 12 субъектов через открытый реестр. Исход: РКН квалифицировал передачу как обработку ПДн без надлежащего согласия (ч. 2 ст. 13.11) — штраф 300–700 тыс. ₽ для юрлица. Стратегия: перед передачей — верифицировать k-анонимность (k≥5), зафиксировать результат в акте.

Сценарий 2. Датасет с биометрией без письменных согласий. Ситуация: разработчик системы видеоаналитики обучает модель на архиве видеозаписей с камер в торговом зале. Видеозаписи содержат изображения лиц — это биометрические ПДн по ст. 11 ФЗ-152. Согласие на обработку биометрии — письменное, субъект должен знать цель. Исход: РКН выдал предписание, возбуждено дело по ч. 16 ст. 13.11 КоАП. Стратегия: либо получить письменные согласия, либо применить обезличивание до уровня, исключающего идентификацию личности (размытие, crop без лица), — и зафиксировать это в техническом регламенте.

Сценарий 3. Облако без локализации при работе с персональными данными. Ситуация: стартап хранит сырые данные пользователей в AWS EU-West, туда же выгружает датасеты для дообучения LLM. Данные не обезличены — содержат имена и email. Исход: при проверке установлено нарушение ч. 5 ст. 18 ФЗ-152 — штраф по ч. 8 ст. 13.11 от 1 до 6 млн ₽. Стратегия: перенести первичную запись в российское облако (Yandex Cloud, SberCloud, облако МТС) или применить обезличивание до передачи — с документальным подтверждением результата.

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

Кейс 1. IT-компания Центрального ФО (весна 2026) передала датасет из 85 000 записей клиентов ML-подрядчику для обучения модели рекомендаций. В датасете применялась только замена ID — k-анонимность не проверялась. РКН при проверке установил, что 3 200 записей идентифицируемы по совокупности «возраст + регион + категория». Возбуждено дело по ч. 1 ст. 13.11 КоАП, штраф в диапазоне 150–300 тыс. ₽. Технический директор инициировал перепроектирование пайплайна: автоматическая проверка k≥5 и l≥3 перед каждой выгрузкой датасета. Повторных нарушений зафиксировано не было.

Кейс 2. Финтех-компания Северо-Западного ФО (осень 2025) обучала скоринговую модель на данных из CRM. Датасет содержал кредитные истории и финансовые признаки — специальные категории не использовались, но число субъектов превышало 100 000. Система обрабатывалась как УЗ-4; после аудита DATUM установлено, что требуется УЗ-3 по ПП РФ №1119. Отсутствовали: регистрация событий (РСБ по Приказу ФСТЭК №21), защита виртуальной среды (ЗСВ), документация по модели угроз. Компания привела инфраструктуру в соответствие за 45 рабочих дней — до начала плановой проверки.

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

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

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

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

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

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

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

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

Обезличивание по ст. 3 ФЗ-152 — результат, при котором без дополнительной информации невозможно определить принадлежность данных конкретному субъекту. Псевдонимизация (замена ID на хэш или UUID) — обратима при наличии таблицы соответствия или перебора. Для ML-датасета обезличивание означает: квазиидентификаторы обобщены до уровня k-анонимности (k≥5), чувствительные атрибуты распределены с l-diversity (l≥3), результат верифицирован инструментально и зафиксирован документально. Хэш без этих проверок — не обезличивание по российскому праву.

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

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

5. Какие СЗИ обязательны для ML-инфраструктуры с ПДн?

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

Итог

l-diversity — не академическая метрика, а практический инструмент, который позволяет доказать регулятору необратимость обезличивания. Без документально подтверждённого результата (k, l, метод, версия датасета) любая передача данных ML-подрядчику или в облако несёт риски по ч. 1, ч. 8 и ч. 12–14 ст. 13.11 КоАП — суммарно от 150 тыс. до 15 млн ₽ за один инцидент при первичном нарушении.

DATUM сопровождает IT-компании при аудите ML-инфраструктуры, разработке регламентов передачи датасетов и приведении ИСПДн к актуальному УЗ по ПП РФ №1119. Практика охватывает как стартапы с одним датасетом, так и SaaS-платформы с мультиарендной архитектурой.