Vector embeddings как ПДн

С 2025 года вопрос о правовой природе vector embeddings перестал быть академическим. Роскомнадзор методически закрепил пять методов обезличивания и установил требования к их применению. Это означает: если CTO не может документально подтвердить, что вектор обезличен надлежащим методом, РКН вправе расценить его как персональные данные со всеми вытекающими обязанностями оператора. Ниже — анализ норм, практики и конкретных сценариев для IT-команды.

Почему vector embedding может быть персональными данными?

Ст. 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся прямо или косвенно к определённому или определяемому физическому лицу. Ключевое слово — «определяемому». Если вектор позволяет идентифицировать субъекта хотя бы в сочетании с иными данными у оператора, он подпадает под это определение.

Применительно к embeddings работает тест на идентифицируемость: достаточно ли у оператора ресурсов (вычислительных, модельных, контекстных), чтобы по вектору восстановить личность? Для большинства production-систем ответ положительный: модель, породившая вектор, хранится рядом с ним в той же инфраструктуре.

Отдельный вопрос — face embeddings. Если вектор вычислен из изображения лица и служит для верификации личности, это биометрические персональные данные по ст. 11 ФЗ-152. Обработка возможна только с письменного согласия субъекта. Штраф за нарушение — до 20 млн ₽ по ч. 17 ст. 13.11 КоАП (утечка биометрии) или по ч. 16 (обработка без согласия). Это кратно выше обычного состава.

Текстовые embeddings (из резюме, переписки, комментариев) попадают в общую категорию ПДн. Поведенческие векторы (клик-стримы, сессии) — тоже, если позволяют идентифицировать пользователя. Граница проходит по тесту: есть ли у оператора техническая возможность инверсии.

Какой уровень защищённости (УЗ) применим к ИСПДн с embeddings?

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

Практическая матрица для типовых ML-сценариев:

• Рекомендательная система (текстовые embeddings, <100 000 пользователей, угрозы 3-го типа): УЗ-4. Минимальный набор мер по Приказу ФСТЭК №21 — ИАФ, УПД, ЗНИ, АВЗ.
• Рекомендательная система (>100 000 пользователей, угрозы 2-го типа): УЗ-2. Добавляются СОВ, АНЗ, ОЦЛ, обязательная сертификация СЗИ.
• Face recognition в СКУД (биометрия, любое число субъектов, угрозы 2-го типа): УЗ-1. Максимальный набор мер, включая ЗТС и ЗИС.
• Медицинская аналитика (спецкатегория по ст. 10 ФЗ-152, >100 000 субъектов): УЗ-1 или УЗ-2 в зависимости от типа угроз.

Приказ ФСТЭК №21 содержит 109 мер в 15 группах. Для УЗ-4 базовый набор — около 30 мер. Для УЗ-1 — весь перечень с обязательной адаптацией и дополнением. Ошибка в определении УЗ означает применение заниженного набора мер, что при проверке фиксируется как нарушение ст. 19 ФЗ-152.

Обезличивание для ML: что изменилось с 2025 года?

С 01.09.2025 действует Приказ РКН о методах обезличивания (введён ФЗ-233 от 08.08.2024). Установлено пять методов: введение идентификаторов, изменение состава или семантики данных, декомпозиция, перемешивание, обобщение и агрегация.

Для ML-pipeline ключевая развилка — метод введения идентификаторов. Суть: прямые идентификаторы (имя, email, телефон) заменяются суррогатными ключами, ссылочная таблица хранится изолированно. Если обученная модель не имеет доступа к ссылочной таблице и не может самостоятельно восстановить личность — данные считаются обезличенными.

Проблема embeddings в том, что сам вектор может функционировать как идентификатор. Особенно если:

• векторное пространство модели достаточно уникально, чтобы k-NN-поиск по вектору выдавал одного конкретного пользователя;
• модель и векторное хранилище (Qdrant, Pinecone, Weaviate) находятся в одной сети с production-базой субъектов;
• вектор связан с user_id через таблицу маппинга без изоляции.

Применение метода декомпозиции — разделение векторов и маппинга по изолированным контурам с разными правами доступа — является надёжным архитектурным решением. Обобщение (снижение размерности, квантизация) снижает уникальность вектора, но само по себе не гарантирует обезличивание.

Как работает поручение обработки и кто оператор в мультиарендной SaaS?

В SaaS-архитектуре с несколькими клиентами (мультиарендность) вопрос о распределении ролей «оператор / лицо, осуществляющее обработку по поручению» является ключевым. Ст. 6 ч. 3 ФЗ-152 допускает поручение обработки третьему лицу — но оператор несёт ответственность за действия обработчика перед субъектом.

Типовая схема:

• Клиент SaaS (B2B-компания) — оператор: определяет цели и состав обработки своих пользователей.
• SaaS-вендор — обработчик по поручению: действует строго в рамках инструкций клиента, не вправе самостоятельно определять цели.

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

Договор поручения обязан содержать: перечень действий с ПДн, цель обработки, обязанность соблюдать конфиденциальность, технические меры по ст. 19 ФЗ-152. Без надлежащего договора поручения SaaS-вендор автоматически становится самостоятельным оператором — со всеми обязанностями, включая уведомление РКН по ст. 22 ФЗ-152.

Логирование как ПДн: что фиксировать нельзя

Логи приложения часто содержат ПДн в явном или скрытом виде: IP-адреса (идентифицирующий признак по позиции РКН), user_id, email, координаты, содержание запросов к LLM. Логирование — это обработка ПДн по ст. 3 ФЗ-152.

Практические требования для IT-команды:

• Политика логирования должна быть частью ОРД и фиксировать, какие поля допустимо записывать в лог.
• Срок хранения логов — только в рамках задокументированной цели (диагностика, безопасность). Бессрочное хранение нарушает ст. 5 ФЗ-152.
• Логи с ПДн относятся к ИСПДн и требуют применения УЗ-мер. Хранение в незащищённых S3-бакетах без шифрования — типовое нарушение по Приказу ФСТЭК №21.
• Для LLM-запросов: если содержание запроса может содержать ПДн третьих лиц — необходим технический барьер перед записью в лог (маскирование, замена на placeholder).

Облако в РФ и трансграничная передача: что изменилось с 01.07.2025?

Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись в базах данных на территории РФ. С 01.07.2025 ужесточение локализации (ФЗ-233) распространилось на первичный сбор: даже первоначальная фиксация ПДн должна происходить в российской инфраструктуре.

Для CTO это означает конкретные архитектурные ограничения:

• Salesforce, HubSpot, Amplitude, Mixpanel как первичные хранилища ПДн граждан РФ — под вопросом. Если данные сначала пишутся в зарубежное облако, а затем реплицируются в РФ — это нарушение.
• Векторное хранилище с embeddings граждан РФ (Pinecone, Weaviate cloud) должно иметь деплой в российском регионе или быть заменено на self-hosted решение на российском хостинге.
• Трансграничная передача в страны без адекватной защиты требует предварительного уведомления РКН по ст. 12 ФЗ-152. Штраф за нарушение требований локализации — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП, повторно — 6–18 млн ₽ по ч. 9.

КИИ-субъекты (ФЗ-187) сталкиваются с дополнительным слоем: обработка ПДн в значимых объектах КИИ регулируется отдельно, миграция в зарубежное облако требует согласования с ФСТЭК.

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

Кейс 1. Финтех-компания (Центральный ФО, осень 2025) использовала поведенческие embeddings для антифрод-модели. Векторы хранились в Pinecone cloud (US region) и были связаны с user_id через незашифрованную таблицу маппинга. При плановой проверке РКН инспектор квалифицировал хранилище как ИСПДн с нарушением ч. 5 ст. 18 ФЗ-152 (нелокализованная база). Компания получила предписание о переносе инфраструктуры и штраф по ч. 8 ст. 13.11 КоАП. После переноса в российский облачный регион и заключения договора поручения нарушение было устранено.

Кейс 2. SaaS-платформа для HR (Сибирский ФО, начало 2026) обучала рекомендательную модель на агрегированных данных всех арендаторов без уведомления клиентов. Технический директор инициировал внутренний аудит после запроса одного из клиентов об объёме обрабатываемых данных. Аудит выявил отсутствие договора поручения на ML-обработку и несоответствие УЗ-мер уровню УЗ-2 (число субъектов превышало 100 000). Компания перестроила архитектуру: изолировала ML-контур, внедрила метод декомпозиции для эмбеддингов, заключила обновлённые договоры поручения. Претензий от РКН удалось избежать до начала проверки.

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

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

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

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

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

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

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

3. Что такое обезличивание для ML и как его документировать?

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

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

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

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

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

Итог

Vector embeddings подпадают под определение ПДн везде, где оператор технически способен идентифицировать субъекта по вектору. Face embeddings дополнительно квалифицируются как биометрия со штрафами до 20 млн ₽. Обезличивание через методы РКН требует документального подтверждения; мультиарендная SaaS требует явного разграничения ролей в договоре поручения; хранение в зарубежных облаках нарушает локализацию с 01.07.2025.

DATUM сопровождает IT-команды в классификации ML-данных, определении УЗ и подготовке ОРД для систем с embeddings. Практика охватывает аудиты SaaS-платформ, подготовку к проверкам РКН и DPIA для высокорисковых систем с биометрическими данными.

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