Vector database (Pinecone, Weaviate) и ПДн

С 2024 года векторные базы данных вошли в стандартный стек RAG-систем, семантического поиска и рекомендательных движков. Проблема не в самой технологии — а в том, что большинство CTO не разграничивают «обезличенные эмбеддинги» и «ПДн в векторном представлении». Эта статья разбирает правовой статус эмбеддингов по 152-ФЗ, требования к уровню защищённости при хранении в ИСПДн, условия использования облачных vector DB и порядок оформления поручения обработки.

Являются ли эмбеддинги персональными данными по 152-ФЗ?

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

Эмбеддинг текста или изображения сам по себе не содержит имени, телефона или идентификатора. Но если в той же системе или в связанном хранилище находится маппинг «vector_id → user_id», возможность идентификации субъекта сохраняется. Это означает: данные косвенно идентифицируемы, а значит — подпадают под определение ПДн по ст. 3 ФЗ-152.

Практический вывод: если ваш ML-пайплайн включает эмбеддинги документов, где автором или субъектом является физическое лицо, и при этом существует возможность обратного сопоставления — система обрабатывает ПДн. Хранение таких эмбеддингов в Pinecone или Weaviate Cloud — это обработка ПДн на сервере иностранного провайдера без надлежащего правового основания.

Отдельный случай — биометрические эмбеддинги. Векторное представление лица или голоса для задач идентификации — это биометрические ПДн по ст. 11 ФЗ-152. Обработка без письменного согласия субъекта влечёт штраф по ч. 16 ст. 13.11 КоАП. Хранение такого вектора в иностранном облаке дополнительно квалифицируется как нарушение ч. 5 ст. 18 ФЗ-152 (локализация).

Какой уровень защищённости (УЗ-1..4) применим к vector DB с ПДн?

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

Для типичного SaaS с семантическим поиском по корпоративной базе знаний (общие ПДн, угрозы типа 3, до 100 000 субъектов) применяется УЗ-3. Если система обрабатывает специальные категории ПДн — например, медицинские записи для RAG-модели в клинике — или угрозы типа 1–2, уровень повышается до УЗ-2 или УЗ-1.

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

Облачный провайдер vector DB (Pinecone, Weaviate Cloud) не является сертифицированным оператором по ФСТЭК. Это означает: при хранении эмбеддингов ПДн в их managed-инфраструктуре оператор не может выполнить требования Приказа №21. Технически корректное решение — self-hosted Weaviate или Qdrant в российском облаке с соответствующей сертификацией СЗИ.

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

В мультиарендной SaaS-архитектуре вопрос разграничения ролей «оператор / лицо, осуществляющее обработку по поручению» определяется договорной конструкцией, а не технической изоляцией тенантов.

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

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

Можно ли использовать иностранные облака для vector DB с ПДн?

Часть 5 ст. 18 ФЗ-152 устанавливает обязанность оператора обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ с использованием баз данных, находящихся на территории России. Норма действует с 01.09.2015 и была усилена поправками 2025 года.

Pinecone — американская компания, серверы в AWS us-east-1 / us-west-2 / eu-west-1. Weaviate Cloud (WCD) предлагает кластеры в Google Cloud и Azure, регионы: eu-west, us-central, ap-southeast. Ни один из этих регионов не расположен на территории РФ. Хранение в них эмбеддингов, являющихся ПДн граждан РФ, нарушает ч. 5 ст. 18 ФЗ-152.

Нарушение локализации квалифицируется по ч. 8 ст. 13.11 КоАП. Штраф для юридического лица — 1–6 млн ₽. При повторном нарушении (ч. 9) — 6–18 млн ₽. РКН выявляет нарушения в том числе через мониторинг DNS и трассировку соединений из реестра операторов.

Допустимые варианты: self-hosted Weaviate или Qdrant на российских серверах (Yandex Cloud, SberCloud, VK Cloud, собственный ЦОД). Для Pinecone российского managed-сервиса не существует — только self-hosted аналоги с совместимым API. При использовании иностранного облака исключительно для хранения данных, прошедших полное обезличивание по методам Приказа РКН (5 методов: введение идентификаторов, изменение состава/семантики, декомпозиция, перемешивание, обобщение), требование локализации не применяется — при условии, что обезличивание необратимо и маппинг не хранится совместно.

Обезличивание для ML: какие методы освобождают от требований 152-ФЗ?

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

Для освобождения от требований 152-ФЗ необходимо применить метод, при котором восстановление связи с субъектом становится невозможным без несоразмерных усилий — и при этом не существует отдельного маппинга. Применительно к эмбеддингам: если вектор получен из обезличенного текста (без имён, телефонов, идентификаторов), а маппинг vector_id → субъект уничтожен — такой вектор выходит за рамки регулирования.

Логирование запросов к vector DB — отдельная зона риска. Если query-лог содержит тексты поисковых запросов, а среди них — имена, адреса или иные ПДн пользователей, лог является ПДн. Хранение таких логов в иностранном облаке — повторное нарушение локализации. Рекомендуемое решение: хеширование запросов в лог-конвейере до записи или хранение логов исключительно в российской инфраструктуре.

Типовые ситуации для CTO: вектор + 152-ФЗ

Ситуация 1. RAG-система на корпоративных документах с именами сотрудников. Компания строит внутренний ChatBot на базе Weaviate Cloud (EU-West). Документы — корпоративные регламенты, где упоминаются ФИО и должности сотрудников. Эмбеддинги хранятся в managed-кластере Weaviate в Ирландии. Доказательства нарушения: IP-трассировка до eu-west-1, данные whois провайдера. Вероятный исход: протокол РКН по ч. 8 ст. 13.11 КоАП (1–6 млн ₽) + предписание о переносе в российскую инфраструктуру. Стратегия: перенести индексы в self-hosted Weaviate на Yandex Cloud, дополнительно применить предобработку с удалением прямых идентификаторов из чанков до эмбеддинга.

Ситуация 2. SaaS-рекомендательный движок, тренируемый на данных всех клиентов. SaaS-платформа для e-commerce собирает поведенческие данные пользователей всех клиентов-ретейлеров и использует их для обучения shared embedding-модели. Каждый клиент-ретейлер полагает, что его данные обрабатываются изолированно. Нарушение: совместное использование ПДн клиентов разных операторов без правового основания и без отдельного согласия субъектов — нарушение принципа несовместимости целей (ст. 5 ФЗ-152) и условий поручения обработки (ст. 6). Стратегия: ввести архитектурную изоляцию тенантов на уровне индексов, оформить отдельные договоры поручения, при необходимости — получить согласие на использование данных для улучшения сервиса.

Ситуация 3. Биометрические эмбеддинги для СКУД. ИТ-компания внедряет систему контроля доступа с распознаванием лиц; векторные представления лиц сотрудников хранятся в Pinecone (us-east-1). Нарушение: биометрические ПДн по ст. 11 ФЗ-152 обрабатываются без соответствующего уровня защищённости и хранятся за рубежом. Ответственность: ч. 16 ст. 13.11 (нарушение требований к биометрии) + ч. 8 ст. 13.11 (локализация). Стратегия: перенести хранение в on-premise решение, оформить письменные согласия сотрудников по ст. 11 ФЗ-152, определить УЗ по ПП РФ №1119 (вероятно УЗ-2 или УЗ-3), реализовать меры ФСТЭК №21.

Кейс 1. Финтех-компания (Центральный ФО, весна 2025) использовала Weaviate Cloud для семантического поиска по заявкам клиентов. Юридическая служба в ходе внутреннего аудита обнаружила, что индексы содержат векторы, полученные из текстов с ФИО и паспортными данными, и хранятся в кластере на серверах в Германии. Компания самостоятельно уведомила РКН о нарушении, перенесла индексы в Yandex Cloud за 3 недели и подала отчёт. Штраф по ч. 8 ст. 13.11 составил менее 2 млн ₽ с учётом добровольного устранения нарушения и отсутствия повторности. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

Кейс 2. EdTech-платформа (Сибирский ФО, осень 2024) обучала рекомендательную модель на данных 150 000 студентов. Эмбеддинги учебных активностей хранились в Qdrant self-hosted, но маппинг «vector_id → user_id» находился в той же базе данных. Аудит DATUM показал: данные косвенно идентифицируемы, уровень защищённости не определён, договор поручения обработки с облачным провайдером не оформлен. По результатам аудита оформлен пакет ОРД, проведено обезличивание маппинга с ротацией ключей, установлены меры УЗ-3 по ФСТЭК №21.

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

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

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

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

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

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

Только если хранимые эмбеддинги не являются ПДн граждан РФ — то есть обезличивание проведено необратимо и маппинг на субъектов отсутствует. В остальных случаях хранение в Pinecone, Weaviate Cloud или любом иностранном managed-решении нарушает ч. 5 ст. 18 ФЗ-152 и влечёт штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. При повторном нарушении — от 6 до 18 млн ₽.

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

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

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

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

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

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

Итог

Векторные базы данных не выводят ML-системы за рамки 152-ФЗ автоматически. Правовой статус эмбеддинга определяется наличием маппинга на субъекта и обратимостью преобразования. Хранение в иностранных managed-сервисах при наличии такого маппинга — нарушение локализации с прямыми санкциями по ст. 13.11 КоАП.

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

9 апреля 2029 года