k-anonymity для ML-датасета

С 1 сентября 2025 года методы обезличивания ПДн закреплены подзаконным актом Роскомнадзора: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. k-anonymity формально относится к группе обобщения и декомпозиции, но нормативный документ не ограничивает технические реализации — важен результат: невозможность идентификации субъекта без несоразмерных усилий. Для CTO это означает, что применение k-anonymity в ML-пайплайне технически допустимо, но требует документального обоснования в рамках DPIA и ОРД.

Что такое обезличивание для ML и почему k-anonymity — не панацея?

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

k-anonymity решает задачу частично. Алгоритм гарантирует, что каждая запись по набору квазиидентификаторов (возраст, регион, пол, профессия) совпадает минимум с k−1 другими. Стандартное значение k на практике — 5 или 10. Проблема в том, что атаки типа homogeneity attack и background knowledge attack позволяют реидентифицировать субъекта даже при соблюдении k-anonymity. Поэтому для чувствительных категорий — данных о здоровье, финансах, поведенческих паттернах — применяют расширения: l-diversity и t-closeness.

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

Как выбрать уровень защищённости для ML-системы по ПП РФ № 1119?

УЗ-1..УЗ-4 определяются на пересечении трёх параметров: категория ПДн (общие, специальные, биометрические), тип актуальных угроз (1-й, 2-й, 3-й) и число субъектов (порог 100 000). Для ML-пайплайна критично понять: датасет — это отдельная ИСПДн или компонент основной системы?

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

На практике большинство SaaS-продуктов с ML-компонентом работают на УЗ-3: общие категории ПДн, угрозы 2-го или 3-го типа, число субъектов свыше 100 000. При мультиарендной архитектуре (один инстанс обслуживает нескольких клиентов-операторов) возникает вопрос поручения обработки по ч. 3 ст. 6 ФЗ-152: SaaS-вендор является обработчиком, а не оператором, и обязан действовать строго по инструкции оператора. Включение клиентских данных в общий ML-датасет без явного указания в договоре поручения — прямое нарушение ст. 6 ФЗ-152.

Какие технические требования ФСТЭК применимы к ML-инфраструктуре?

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

Первая — РСБ (регистрация и учёт событий). Логи доступа к датасету, операции копирования и экспорта данных, события аутентификации в ноутбуках Jupyter и MLflow должны централизованно собираться и храниться. При объёме свыше 100 000 субъектов логирование становится обязательной мерой базового набора. Второй компонент — УПД: разграничение прав между дата-инженерами, ML-инженерами и аналитиками на уровне файловой системы и объектного хранилища (S3-совместимого). Третий — ЗНИ: шифрование дисков и томов с датасетами; для облачного хранения — шифрование с ключами, управляемыми оператором, а не провайдером. Четвёртый — ОЦЛ (обеспечение целостности): контроль хэш-сумм датасетов, чтобы модель обучалась именно на проверенной выборке.

Логирование само по себе создаёт вторичные ПДн. Лог-запись вида «пользователь Иванов Иван Иванович открыл файл dataset_2024.parquet в 14:23» содержит ПДн и подпадает под требования ФЗ-152. Это означает, что система логирования — отдельная ИСПДн или компонент основной, к которой применяются те же меры защиты.

Для облачных развёртываний российское законодательство не запрещает использование иностранных провайдеров прямо, но ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись в базах, физически расположенных в России. Если ML-датасет содержит ПДн российских граждан и хранится в AWS us-east-1 или GCP europe-west — это нарушение ч. 5 ст. 18, санкция по ч. 8 ст. 13.11 КоАП: от 1 до 6 млн ₽; повторное нарушение — от 6 до 18 млн ₽ по ч. 9.

Как правильно применять k-anonymity в пайплайне: практические сценарии

Рассмотрим три характерные ситуации, с которыми сталкивается CTO при построении ML-пайплайна на реальных данных.

Сценарий 1. Рекомендательная система интернет-магазина. Датасет содержит историю покупок: user_id (токенизированный), категории товаров, временные метки, регион. Формально user_id — псевдоним, но вместе с регионом и временными метками он позволяет реидентификацию через перекрёстное сопоставление с данными доставки. Ситуация: CTO считает датасет обезличенным и не ведёт ИСПДн. Доказательства нарушения: RKN в ходе проверки запрашивает модель угроз — она отсутствует. Вероятный исход: штраф по ч. 1 ст. 13.11 КоАП от 150 до 300 тыс. ₽ плюс предписание. Стратегия: применить k=10 по квазиидентификаторам (регион + возрастная группа + устройство), задокументировать метод в DPIA, хранить таблицу соответствия токенов и реальных ID отдельно с УЗ-3.

Сценарий 2. ML-модель для кредитного скоринга в МФО. Датасет содержит финансовые данные — специальная категория по смежным нормам, высокий риск. Облако: AWS Frankfurt. Ситуация: CTO перенёс обучение в иностранное облако ради GPU-мощностей. Доказательства нарушения: хранение ПДн за рубежом при наличии российских субъектов. Вероятный исход: штраф по ч. 8 ст. 13.11 от 1 до 6 млн ₽. Стратегия: перевести датасет в российское облако (Yandex Cloud, SberCloud, VK Cloud), применить дифференциальную приватность поверх k-anonymity для финансовых признаков, получить согласие субъектов на автоматизированное решение по ст. 16 ФЗ-152.

Сценарий 3. Мультиарендная SaaS-платформа для HR-аналитики. Несколько клиентов-операторов загружают данные сотрудников; вендор хочет обучить общую модель на агрегированных данных. Ситуация: в договоре поручения нет пункта об использовании данных для обучения ML. Доказательства нарушения: обработка ПДн за пределами инструкции оператора — нарушение ч. 3 ст. 6 ФЗ-152. Вероятный исход: каждый клиент-оператор вправе предъявить претензию; РКН — возбудить дело по ч. 1 ст. 13.11 по каждому арендатору. Стратегия: внести в договор поручения явное указание на обучение модели, применить федеративное обучение (Federated Learning) — данные не покидают инфраструктуру клиента, к центральному серверу уходят только градиенты.

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

Кейс 1. IT-компания (Сибирский ФО, осень 2025) строила рекомендательный движок на данных ~180 000 пользователей интернет-магазина. CTO применил токенизацию user_id, считая датасет обезличенным, и не уведомил РКН об обработке ПДн. Роскомнадзор провёл внеплановую проверку по жалобе пользователя. Выяснилось: таблица соответствия токенов хранится в той же базе, что и датасет, — ПДн не обезличены. Арбитражный суд региона назначил штраф в диапазоне ч. 1 ст. 13.11 КоАП и выдал предписание разработать модель угроз. После привлечения юристов компания подала DPIA, переработала архитектуру хранения и получила снижение штрафа до минимального по ст. 4.1 КоАП за содействие следствию. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

Кейс 2. SaaS-вендор (Центральный ФО, начало 2026) предоставлял HR-платформу нескольким корпоративным клиентам и обучал модель предсказания текучести кадров на агрегированных данных сотрудников без явного указания в договорах поручения. Один из клиентов-операторов обнаружил факт при аудите и направил уведомление в РКН. Дело возбуждено по ч. 1 ст. 13.11 КоАП; вендор применил ст. 4.1.1 КоАП (первичное нарушение, микропредприятие) и получил предупреждение. Договоры поручения переработаны с указанием допустимости федеративного обучения. ⚠️ Конкретный номер дела — менеджер уточняет при публикации.

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

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

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

1. Какой УЗ выбрать для SaaS?

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

2. Можно ли использовать иностранные облака?

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

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

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

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

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

5. Какие СЗИ обязательны?

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

Итог

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

DATUM сопровождает IT-команды при классификации ML-инфраструктуры, проведении DPIA и построении пакета ОРД для продуктов с машинным обучением — от стартапа до корпоративной платформы.