Embeddings и ПДн

Embeddings — математические векторы, кодирующие семантику текста, изображения или поведения пользователя — стали стандартным инструментом в рекомендательных системах, RAG-архитектурах и ML-классификаторах. Проблема для CTO: если исходные данные содержат ПДн, вектор может сохранять достаточно информации для повторной идентификации субъекта. Роскомнадзор и ФСТЭК пока не выпустили разъяснений специально под embeddings, но действующая правовая база ФЗ-152, ПП РФ №1119 и Приказ ФСТЭК №21 применяется к любой форме обработки ПДн — включая векторные базы данных. В этом материале разобраны ключевые вопросы: когда embedding считается ПДн, какой уровень защищённости нужен, как обезличить данные для обучения ML и кто несёт ответственность в мультиарендной SaaS.

Когда embedding считается персональными данными по ФЗ-152?

Ответ определяется через ст. 3 ФЗ-152: персональными данными признаётся любая информация, относящаяся к прямо или косвенно определённому физическому лицу. Embedding, полученный из текста электронной почты конкретного пользователя, профиля в CRM или голосовой записи, относится к этому лицу — независимо от того, что исходный текст заменён числовым вектором. Критерий — возможность обратного сопоставления: если у атакующего есть доступ к модели и достаточной вспомогательной информации, восстановление исходного текста или идентификация субъекта технически реализуема.

На практике следует различать три ситуации. Первая: embedding построен на идентификаторе (user_id, email) — это связанные ПДн, режим полный. Вторая: embedding из анонимизированного текста без связи с идентификатором в хранилище — возможно квалифицировать как обезличенные, если применён метод из приказа РКН о методах обезличивания. Третья: агрегированные embeddings по когорте пользователей без привязки к конкретному субъекту — выходят за рамки ФЗ-152, но только при условии, что обратное восстановление невозможно технически. Промежуточные векторы в пайплайне — логи трансформеров, кэш attention-слоёв — также могут содержать ПДн и подпадают под требование о защите по ст. 19 ФЗ-152.

Биометрические embeddings — отдельный случай. Вектор лица или голоса, полученный нейросетью, квалифицируется как биометрические ПДн по ст. 11 ФЗ-152 при наличии хотя бы одной из двух характеристик: физиологические особенности или поведенческие особенности, используемые для идентификации. За нарушение требований к обработке биометрии — штраф по ч. 16 ст. 13.11 КоАП; за утечку биометрических embeddings — ч. 17, от 15 до 20 млн ₽.

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

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

Типовые сценарии для ML-систем:

• УЗ-4: vectorstore с общими ПДн (имя, email, поведение на сайте), угрозы 3-го типа, число субъектов до 100 000. Большинство B2B SaaS-продуктов попадают сюда. Базовый набор мер ФСТЭК по Приказу №21.
• УЗ-3: те же категории, но субъектов более 100 000, либо угрозы 2-го типа (атаки через недекларированные возможности прикладного ПО). Большинство B2C-приложений с рекомендательными системами.
• УЗ-2: специальные категории ПДн (состояние здоровья, политические взгляды — ст. 10 ФЗ-152) при угрозах 2-го типа. Медицинские ML-сервисы, психографические модели.
• УЗ-1: специальные или биометрические ПДн при угрозах 1-го типа (атаки через недекларированные возможности системного ПО). Face recognition с хранением исходных векторов в ЕБС не попадает — регулируется ФЗ-572 отдельно.

Практическая проблема: многие ML-команды не разграничивают ИСПДн при обучении модели и ИСПДн при inference. Если embeddings, полученные на этапе обучения, сохраняются в vectorstore для retrieval — это самостоятельная ИСПДн со своим УЗ. Набор мер по Приказу ФСТЭК №21 включает 15 групп (идентификация и аутентификация, управление доступом, регистрация событий, антивирус, обнаружение вторжений и др.). Для УЗ-3 и выше часть мер должна быть реализована сертифицированными СЗИ.

Как обезличить данные для обучения ML и выйти из-под ФЗ-152?

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

Ключевое условие: обезличивание должно быть необратимым в разумных пределах. Если таблица соответствия «суррогатный ключ — реальный субъект» хранится в той же инфраструктуре, данные юридически остаются персональными. Для embeddings это означает: vectorstore без таблицы соответствия, обученный на агрегированных данных когорт, может считаться обезличенным — при условии, что атака инверсии модели (model inversion attack) не позволяет восстановить исходные данные с разумными вычислительными ресурсами. Это технический факт, который нужно зафиксировать в модели угроз и подтвердить тестированием.

Обезличенные ПДн передаются в Единую информационную платформу национальной системы управления данными (ЕИП НСУД) по требованию Минцифры согласно ст. 13.1 ФЗ-152 (ФЗ-233 от 08.08.2024). Это необходимо учитывать при проектировании ML-пайплайна в компаниях, взаимодействующих с государственными системами.

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

Распределение ролей в мультиарендной SaaS определяется по ст. 3 и ст. 6 ФЗ-152. Клиент (тенант) загружает данные своих пользователей в платформу — он оператор. SaaS-вендор формирует embeddings из этих данных для работы продукта — он действует по поручению оператора (п. 3 ст. 6 ФЗ-152). Это стандартная модель «оператор — обработчик». Обязательное условие: договор поручения обработки с исчерпывающим перечнем допустимых действий, включая создание и хранение embeddings.

Усложнение возникает, когда SaaS-вендор использует embeddings тенантов для дообучения собственной модели (fine-tuning). В этом случае вендор выходит за рамки поручения и становится самостоятельным оператором в части дообучения — со всеми вытекающими: отдельное правовое основание, уведомление РКН по ст. 22 ФЗ-152, собственная ИСПДн с оценкой УЗ. Отсутствие этого разграничения — распространённая точка риска при проверках. Принцип ответственности оператора за действия обработчика по решениям ВС РФ означает: если обработчик-вендор допустит утечку embeddings тенанта, оператор-клиент несёт административную ответственность по ст. 13.11 КоАП.

Практика: три сценария для CTO

Сценарий 1. RAG-сервис с корпоративными документами. Ситуация: компания развернула RAG-систему, vectorstore содержит embeddings из внутренней переписки и HR-документов. Сотрудники — субъекты ПДн, данные — общие (имена, должности, контакты) с элементами специальных (оценки, личные дела). Доказательства: нет отдельного уведомления в реестре РКН на ИСПДн «корпоративный RAG», нет модели угроз, нет поручения обработки на LLM-провайдера. Вероятный исход при проверке: протокол по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) за обработку без надлежащего правового основания; при утечке — ч. 12–14 (3–15 млн ₽) в зависимости от числа субъектов. Стратегия: зарегистрировать ИСПДн, заключить договор поручения с LLM-провайдером, провести оценку УЗ по ПП РФ №1119, реализовать меры по Приказу ФСТЭК №21.

Сценарий 2. Биометрические embeddings в системе контроля доступа. Ситуация: СКУД с face recognition хранит векторы лиц сотрудников в локальной базе. Векторы получены нейросетью, исходные фото не сохраняются. Доказательства: по ст. 11 ФЗ-152 биометрические ПДн — физиологические и биологические особенности; вектор лица использован для идентификации. Согласие работников оформлено в трудовом договоре до 01.09.2025. Вероятный исход: с 01.09.2025 согласие в трудовом договоре недействительно (ФЗ-156), нарушение ч. 2 ст. 9 ФЗ-152 — штраф по ч. 2 ст. 13.11 КоАП (300–700 тыс. ₽). При утечке vectorstore — ч. 17 ст. 13.11 (15–20 млн ₽). Стратегия: переоформить согласия как отдельные документы, разграничить ИСПДн СКУД от основной HR-системы, реализовать меры УЗ-3 (биометрия, угрозы 2-го типа, сотрудников более 100 чел.).

Сценарий 3. Embeddings в облаке иностранного провайдера. Ситуация: vectorstore размещён в AWS eu-west или GCP europe-west. Обработка ПДн граждан РФ — запись, хранение, обновление — происходит на зарубежных серверах. Доказательства: нарушение ч. 5 ст. 18 ФЗ-152 (локализация): первичный сбор, систематизация и хранение должны осуществляться в базах на территории РФ с 01.07.2025 (ФЗ-233). Трансграничная передача без уведомления РКН по ст. 12 ФЗ-152. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП за нарушение локализации — 1–6 млн ₽; при повторности — ч. 9, 6–18 млн ₽. Стратегия: перевести vectorstore в российское облако (Yandex Cloud, VK Cloud, SberCloud), уведомить РКН о трансграничной передаче остальных потоков данных, заключить договор поручения с российским облачным провайдером.

Кейс 1. IT-компания (Уральский ФО, осень 2025) развернула рекомендательный сервис на embeddings из профилей 200 000+ пользователей. Vectorstore размещался у зарубежного облачного провайдера. При плановой проверке РКН выявил нарушение ч. 5 ст. 18 ФЗ-152. Компания получила предписание, перенесла vectorstore в российское облако за 45 дней, предоставила доказательства миграции. Штраф по ч. 8 ст. 13.11 КоАП составил сумму в нижней части диапазона с учётом устранения нарушения. Параметры поручения обработки с новым провайдером были согласованы при участии юристов на этапе миграции.

Кейс 2. SaaS-платформа для HR (Центральный ФО, начало 2026) при аудите обнаружила, что embeddings из резюме кандидатов использовались для дообучения модели без отдельного уведомления в реестре РКН и без правового основания, отличного от договора с тенантами. Роль вендора была переквалифицирована с обработчика на самостоятельного оператора в части дообучения. Стоимость устранения нарушений — разработка ОРД под отдельную ИСПДн, уведомление РКН, DPIA — составила около 350 000 ₽; потенциальный штраф при проверке до устранения — 150–300 тыс. ₽ по ч. 1 ст. 13.11 КоАП плюс предписание.

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

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

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

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

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

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

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

3. Что такое обезличивание для ML и когда данные перестают быть ПДн?

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

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

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

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

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

Итог

Embeddings из пользовательских данных по умолчанию остаются персональными данными по ст. 3 ФЗ-152 — пока не доказано обратное через задокументированное обезличивание. Уровень защищённости vectorstore определяется по ПП РФ №1119 независимо от остальной инфраструктуры; биометрические embeddings добавляют ч. 16–17 ст. 13.11 КоАП в список рисков. Роли оператора и обработчика в мультиарендной SaaS требуют явного разграничения в договорах поручения; хранение в иностранных облаках нарушает требование локализации с 01.07.2025.

DATUM сопровождает IT-компании и SaaS-вендоров в оценке соответствия ML-инфраструктуры требованиям ФЗ-152 и ФСТЭК: от модели угроз до комплекта ОРД и подготовки к проверке РКН.