RAG-системы с корпоративными ПДн

RAG (Retrieval-Augmented Generation) стал стандартом для корпоративных LLM-ассистентов: документация, CRM-переписка, кадровые данные, медкарты, финансовые отчёты — всё это попадает в векторные базы и становится контекстом для языковой модели. Правовая рамка при этом остаётся той же: ФЗ-152 «О персональных данных», уровни защищённости по ПП РФ №1119, меры по Приказу ФСТЭК №21. Ниже — как эта рамка накладывается на конкретные компоненты RAG-стека.

Что в RAG-системе является обработкой персональных данных?

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

Индексация документов в векторное хранилище — это накопление и систематизация. Семантический поиск по запросу — извлечение. Включение релевантных фрагментов в промпт — использование. Передача промпта во внешний API (OpenAI, Anthropic, Yandex GPT) — трансграничная передача или передача третьей стороне. Кеш результатов — хранение в отдельной ИСПДн.

Логирование запросов и ответов — отдельный вопрос. Если лог содержит имена, должности, фрагменты переписки или иные идентифицирующие сведения, он образует отдельную ИСПДн. Согласно позиции ФСТЭК, такие логи должны учитываться при определении уровня защищённости. Логирование как ПДн — типичная точка несоответствия при аудите RAG-инфраструктуры.

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

Уровень защищённости определяется по четырём параметрам, установленным ПП РФ №1119 от 01.11.2012: категория ПДн, тип субъектов (сотрудники или иные), объём обрабатываемых данных и тип актуальных угроз (1–3).

Для большинства корпоративных RAG-систем типичен следующий расчёт:

• Данные сотрудников (ФИО, должность, контакты) — общие ПДн, тип угроз 3, субъекты — сотрудники, объём менее 100 000: УЗ-4 (минимальный).
• Данные клиентов (ФИО, email, история переписки) — общие ПДн, тип угроз 3, субъекты — не сотрудники, объём менее 100 000: УЗ-3.
• Медицинские данные пациентов или финансовые данные с кредитными историями — специальные или биометрические категории по ст. 10–11 ФЗ-152, тип угроз 3, объём менее 100 000: УЗ-2.
• Любые категории, объём более 100 000 субъектов, угрозы 2-го типа: УЗ-1 — самый высокий.

При использовании SaaS-платформы для RAG мультиарендность создаёт дополнительный риск: одна инсталляция обслуживает несколько арендаторов, и вектор атаки включает межарендную утечку. ФСТЭК рассматривает это в контексте угроз 1-го и 2-го типов. CTO должен документально зафиксировать: данные каждого арендатора изолированы на уровне хранилища и при поиске.

Как обезличить данные для ML и что это даёт юридически?

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

Для RAG-систем наиболее применимы два подхода:

• Псевдонимизация при индексации: имена и контакты заменяются идентификаторами; маппинг хранится отдельно в защищённом хранилище с ограниченным доступом. Поиск и генерация работают с псевдонимами. Результат — снижение уровня защищённости (УЗ-3 вместо УЗ-2 при спецкатегориях).
• Агрегация при дообучении: модель обучается на обобщённых паттернах, не на индивидуальных записях. Контроль — дифференциальная приватность (DP-SGD), аудит членства (membership inference attack test).

Юридическое значение: если данные успешно обезличены по требованиям приказа РКН, они перестают быть ПДн по ст. 3 ФЗ-152. Система обработки обезличенных данных не является ИСПДн и не подпадает под требования ПП РФ №1119 и Приказа ФСТЭК №21. Однако обязанность доказать необратимость обезличивания лежит на операторе.

Практический вывод: CTO, внедряющий RAG для ML-задач, должен зафиксировать в техническом задании и в ОРД — какой метод обезличивания применён, на каком этапе конвейера, как верифицируется его необратимость. Отсутствие такой документации при проверке РКН = обработка ПДн без надлежащих мер, ч. 1 ст. 13.11 КоАП.

Кто является оператором и обработчиком в RAG-архитектуре?

В типичной корпоративной RAG-системе роли распределяются так:

• Компания-заказчик — оператор по ст. 3 ФЗ-152: определяет цели и состав обрабатываемых данных.
• Вендор векторной базы (Weaviate, Pinecone, Qdrant) на облачной инфраструктуре — обработчик по ст. 6 ч. 3 ФЗ-152: обрабатывает данные по поручению оператора.
• Провайдер LLM-API (при передаче промпта с ПДн) — либо обработчик по поручению, либо самостоятельный оператор — зависит от условий договора и data processing agreement.

Ключевой риск: многие компании подключают LLM-API без оформления договора на обработку ПДн. Передача промпта с именами, должностями или иными идентификаторами во внешний API — это передача ПДн третьей стороне. Если эта сторона находится за рубежом — это трансграничная передача по ст. 12 ФЗ-152 с обязательным уведомлением РКН (при отсутствии адекватной защиты в стране размещения серверов).

При SaaS-модели с мультиарендностью вопрос усложняется: SaaS-провайдер обрабатывает данные нескольких арендаторов на общей инфраструктуре. Юридически необходим отдельный договор-поручение с каждым арендатором-оператором, а архитектурно — изоляция данных на уровне векторных коллекций и namespace.

Как меры ФСТЭК №21 применяются к компонентам RAG-стека?

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

• ИАФ — идентификация и аутентификация: каждый компонент RAG-конвейера (эмбеддинг-сервис, векторная БД, LLM-шлюз, кеш) требует отдельной политики доступа. Service-to-service аутентификация через mutual TLS или SPIFFE/SPIRE — не опция, а требование для УЗ-2 и выше.
• УПД — управление правами доступа: принцип наименьших привилегий. Сервис ретривера не должен иметь доступ к администрированию векторной базы. Права разграничиваются на уровне коллекций.
• РСБ — регистрация событий (логирование): обязательна для УЗ-3 и выше. Логи доступа к векторной базе, логи запросов к LLM-API, логи изменений в индексе — хранятся отдельно, с защитой целостности.
• ЗНИ — защита носителей информации: векторные эмбеддинги, хранящиеся на диске, подлежат шифрованию. Для УЗ-2 и выше требуется шифрование at-rest с ключами, управляемыми оператором (не облачным провайдером).
• ОЦЛ — обеспечение целостности: контроль целостности эмбеддинг-модели и весов LLM. Подмена модели — вектор атаки, позволяющий извлекать обучающие данные через adversarial prompts.

Базовый набор мер определяется уровнем защищённости: УЗ-4 — минимальный набор; УЗ-1 — все 109 мер с возможностью компенсирующих. При облачном деплое часть мер может быть реализована провайдером — но оператор обязан это зафиксировать в модели угроз и подтвердить наличие соответствующих сертификатов или аттестатов.

Применимы ли требования КИИ (187-ФЗ) к RAG-системам?

Если компания является субъектом критической информационной инфраструктуры по ФЗ-187 (банки, телеком, здравоохранение, энергетика, транспорт), RAG-система, обрабатывающая ПДн в промышленных или управленческих процессах, может быть отнесена к значимым объектам КИИ. В этом случае накладываются дополнительные требования: подключение к ГосСОПКА, использование сертифицированных СЗИ, уведомление НКЦКИ об инцидентах.

Для большинства IT-компаний и SaaS-вендоров вне критических отраслей ФЗ-187 неприменим. Однако если RAG-система поставляется как B2B-продукт заказчику из КИИ-отрасли, CTO должен проверить: является ли система частью технологического процесса заказчика и может ли она быть категорирована как объект КИИ на стороне клиента.

Практика: как это выглядит в реальных проектах

Кейс 1. IT-компания (Центральный ФО, первая половина 2026) развернула RAG-ассистента для службы поддержки на данных тикетов из Zendesk (имена клиентов, контакты, тексты обращений). При аудите выявлено: договор с Zendesk не содержал условий поручения обработки ПДн, логи запросов к LLM-API хранились без ограничения срока. Уровень защищённости не определялся. По результатам аудита — составлен договор-поручение, ограничен срок хранения логов до 90 дней, в уведомление РКН внесены изменения. Итог: нарушения устранены до плановой проверки РКН.

Кейс 2. SaaS-вендор (Северо-Западный ФО, осень 2025) предоставлял RAG-платформу клиентам из медицинской отрасли. Клиенты загружали документы с данными пациентов. DPIA показала: эмбеддинги хранились в shared-коллекции без изоляции по арендатору; возможна межарендная утечка через семантически близкие запросы. Медицинские данные — спецкатегория по ст. 10 ФЗ-152, УЗ-2 обязателен. Вендор был признан обработчиком по поручению каждого клиента-оператора. Архитектурно реализована изоляция на уровне namespace и раздельное шифрование коллекций. Договоры-поручения заключены с каждым клиентом-оператором.

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

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

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

1. Какой УЗ выбрать для SaaS с RAG, если не знаю категории ПДн клиентов?

Если SaaS-платформа позволяет клиентам загружать произвольные документы и не контролирует их содержимое, CTO должен исходить из наихудшего сценария: предполагать наличие спецкатегорий (ст. 10 ФЗ-152) и применять УЗ-2 как базовый. Альтернатива — технически ограничить возможность загрузки документов со спецкатегориями и зафиксировать это ограничение в договоре с клиентом и в модели угроз по ПП РФ №1119.

2. Можно ли использовать иностранные облака (AWS, GCP, Azure) для хранения векторов с ПДн граждан РФ?

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

3. Что такое обезличивание для ML и когда оно снимает требования 152-ФЗ?

Обезличивание — это приведение данных к форме, при которой невозможно определить их принадлежность конкретному субъекту без использования дополнительной информации, которой у оператора нет. Приказ РКН (с 01.09.2025) закрепляет 5 методов. Для ML применимы псевдонимизация (введение идентификаторов) и агрегация. Если обезличивание доказуемо и необратимо — данные перестают быть ПДн, ИСПДн не возникает, требования ПП РФ №1119 и Приказа ФСТЭК №21 не применяются. Ключевое условие: оператор обязан доказать необратимость, а не просто задекларировать её.

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

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

5. Какие СЗИ обязательны для RAG-системы с УЗ-3?

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

Итог

RAG-система с корпоративными ПДн — это ИСПДн с уровнем защищённости от УЗ-4 до УЗ-2 в зависимости от категорий данных и объёма субъектов. Каждый компонент стека — векторная база, LLM-API, кеш, логи — требует отдельной оценки с точки зрения ФЗ-152, ПП РФ №1119 и Приказа ФСТЭК №21. Обезличивание снимает часть требований, но должно быть доказуемым. Поручение обработки — обязательный договор с каждым облачным провайдером, получающим ПДн.

Практика DATUM по технической стороне 152-ФЗ охватывает IT-инфраструктуру, ML-конвейеры и SaaS-архитектуры: от определения УЗ и разработки модели угроз до DPIA и комплекта ОРД для IT-команды.

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