RAG-системы и ПДн в индексе

RAG-архитектуры проникли в корпоративные продукты быстрее, чем регуляторная практика успела их осмыслить. Когда база знаний компании — это векторный индекс из тысяч документов с реальными данными клиентов или сотрудников, вопрос о роли оператора ПДн становится конкретным и срочным. В этом материале разбираем: как ФЗ-152 и подзаконные акты ФСТЭК соотносятся с технической архитектурой RAG, какие уровни защищённости применимы, когда обезличивание для ML закрывает проблему, а когда нет, и какие нарушения уже зафиксированы в судебной практике.

Почему RAG-индекс — это информационная система персональных данных?

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

Технические директора иногда ошибочно полагают, что преобразование текста в вектор является обезличиванием. Это не так: обезличивание по смыслу ст. 13.1 ФЗ-152 и методам, установленным приказом РКН, предполагает необратимое устранение возможности идентификации. Инвертирование эмбеддинга частично возможно через атаки типа membership inference или prompt injection, поэтому регулятор не признаёт векторизацию методом обезличивания. Пять официальных методов обезличивания (введение идентификаторов, изменение состава/семантики, декомпозиция, перемешивание, обобщение) описаны в подзаконном акте РКН — ни один из них не тождествен созданию эмбеддингов.

Практическое следствие: если в RAG-систему загружены медицинские записи пациентов или переписка с клиентами, ИСПДн содержит специальные категории ПДн по ст. 10 ФЗ-152. Это автоматически повышает требуемый уровень защищённости и сужает допустимые облачные архитектуры.

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

ПП РФ №1119 задаёт матрицу: категория данных × тип угроз × число субъектов. Для большинства корпоративных RAG-систем актуальна следующая логика.

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

УЗ-4

Общие ПДн, угрозы 3-го типа, до 100 000 субъектов. Типичная CRM или корпоративный wiki с именами сотрудников.

УЗ-3

Общие ПДн + угрозы 2-го типа, или специальные ПДн до 100 000 субъектов. Типичная B2C-платформа с историей транзакций.

УЗ-2

Специальные ПДн, угрозы 2-го типа, более 100 000 субъектов, или биометрия широкого охвата.

УЗ-1

Специальные ПДн + угрозы 1-го типа (НДВ в системном ПО). Государственные и критические системы.

Угрозы 1-го и 2-го типа связаны с наличием недекларированных возможностей (НДВ) в системном или прикладном ПО. Большинство коммерческих SaaS-платформ не имеет сертифицированного системного ПО, поэтому по умолчанию нельзя исключить угрозы 2-го типа. Это практически означает, что RAG на медицинских данных с высокой вероятностью потребует УЗ-2 или УЗ-3.

Важный нюанс для мультиарендных SaaS: если один tenant-клиент загрузил в RAG-индекс документы со специальными ПДн, а инфраструктура общая — уровень защищённости определяется по наиболее уязвимому tenant. Изоляция индексов на уровне namespace в векторной БД (Weaviate, Qdrant, Pinecone) сама по себе не является достаточной мерой по ФСТЭК; требуется сертифицированное разграничение или отдельная ИСПДн для каждого класса данных.

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

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

• Замена реальных идентификаторов на псевдонимы (введение идентификаторов) — допустима для тренировочных корпусов, если таблица соответствия не попадает в обучающую выборку.
• Генерализация (обобщение) числовых полей — возраст «32» заменяется диапазоном «30–35»; подходит для аналитических задач, но разрушает семантику для ряда NLP-задач.
• Синтетическая генерация данных на основе обезличенных реальных — наиболее перспективный подход для RAG-корпусов, но требует верификации, что синтетические данные не реконструируют исходные ПДн.

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

Облако, мультиаренда и поручение: кто отвечает за ПДн в RAG-инфраструктуре?

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

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

В мультиарендной SaaS (multi-tenant) особый риск создаёт смешение данных разных клиентов в одном векторном хранилище. Оператором ПДн конечных субъектов обычно является клиент-компания (tenant), а SaaS-провайдер — обработчиком по поручению. Но если SaaS-провайдер самостоятельно определяет цели или методы обработки (например, использует данные всех tenants для дообучения общей модели) — он приобретает статус оператора со всеми вытекающими обязанностями, включая уведомление РКН по ст. 22 ФЗ-152.

Типовые сценарии нарушений в RAG-архитектурах

Сценарий 1. RAG на медицинских документах без модели угроз. Ситуация: медтех-стартап строит RAG-ассистента на базе выгрузок из МИС клиники-клиента. Данные содержат диагнозы и ФИО — специальные категории ПДн по ст. 10 ФЗ-152. Провайдер облачной инфраструктуры — зарубежный. Модель угроз не составлялась, УЗ не определён. Вероятный исход: проверка РКН по индикатору риска (наличие зарубежного облака при обработке ПДн граждан РФ) → предписание → при неустранении протокол по ч. 8 ст. 13.11 (1–6 млн ₽) и по ч. 1 ст. 13.11 (150–300 тыс. ₽ за отсутствие политики). Стратегия: миграция векторной БД в российский облачный провайдер (Yandex Cloud, Sber Cloud, МТС Cloud), составление модели угроз, классификация ИСПДн на УЗ-3, заключение договора поручения.

Сценарий 2. Дообучение LLM на клиентских диалогах без обезличивания. Ситуация: IT-компания (Центральный ФО, осень 2025) дообучала языковую модель на архиве поддержки, содержащем имена клиентов, email и описания проблем. Тренировочный датасет не проходил обезличивание. При проверке РКН запросил документы, подтверждающие правовое основание обработки и применение мер защиты. Обосновать согласие субъектов на использование данных для ML компания не смогла. Протокол по ч. 1 ст. 13.11 — штраф в пределах 150–300 тыс. ₽. Стратегия: применение методов обезличивания (введение идентификаторов + замена семантики) до включения данных в тренировочный корпус; при невозможности обезличивания — получение отдельных согласий субъектов с указанием цели «обучение ML-моделей».

Сценарий 3. SaaS-провайдер использует tenant-данные для улучшения общей RAG-модели. Ситуация: SaaS-платформа (документооборот, Северо-Западный ФО) индексировала документы всех клиентов в единое векторное хранилище и использовала эмбеддинги для ранжирования ответов модели без разделения по tenants. Часть документов содержала ПДн сотрудников клиентов. Договоры поручения с клиентами не предусматривали такой цели обработки. Вероятный исход: несоответствие ч. 5 ст. 5 ФЗ-152 (цели обработки) + ч. 3 ст. 6 (обработка по поручению без соответствующего договора). Штраф по ч. 1 ст. 13.11 — 150–300 тыс. ₽; риск гражданских исков от клиентов-операторов. Стратегия: изоляция индексов по tenant, обновление договоров поручения, исключение cross-tenant обучения без отдельного согласования.

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

Кейс 1. IT-компания (Приволжский ФО, начало 2026) развернула RAG-систему на корпоративных договорах и переписке с контрагентами. При подготовке к аудиту выяснилось, что векторное хранилище находится в европейском регионе облачного провайдера. Технический директор инициировал миграцию на российский регион до начала проверки РКН, заключил договор поручения с провайдером, составил акт классификации ИСПДн (УЗ-4) и обновил уведомление в реестре операторов. Проверка РКН завершилась без административных мер — нарушение было устранено до момента контроля.

Кейс 2 (из реестра). В деле о дообучении модели на клиентских данных (практика DATUM, Сибирский ФО, осень 2025) CTO обнаружил, что тренировочный корпус содержит email и ФИО пользователей без признаков обезличивания. После консультации юристов было установлено правовое основание для обработки (исполнение договора с пользователем по ст. 6 п. 5 ФЗ-152), применена замена идентификаторов в тренировочном датасете, составлен акт обезличивания. Это позволило подтвердить соответствие требованиям ст. 5 и ст. 19 ФЗ-152 при последующем запросе регулятора.

Связанные услуги DATUM по теме

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

Практика DATUM по технической стороне 152-ФЗ охватывает аудит ИСПДн, составление моделей угроз для ML-систем, DPIA для новых архитектур и сопровождение взаимодействия с РКН при проверках в IT-компаниях.