Prompt injection и утечка ПДн через модель

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

Почему prompt injection — это инцидент с ПДн по ФЗ-152?

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

Ч. 3.1 ст. 21 ФЗ-152 обязывает оператора уведомить Роскомнадзор о таком инциденте в течение 24 часов с момента обнаружения. Через 72 часа — отчёт о результатах внутреннего расследования по Приказу РКН №187 от 14.11.2022. Если инцидент затрагивает от 1 000 до 10 000 субъектов, штраф по ч. 12 ст. 13.11 КоАП составляет от 3 до 5 млн ₽. Масштаб 10 000–100 000 субъектов — ч. 13, от 5 до 10 млн ₽. Более 100 000 — ч. 14, от 10 до 15 млн ₽.

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

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

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

Практически значимый момент: языковая модель, работающая с RAG-индексом по клиентской базе, — это ИСПДн. Не «инструмент поиска», не «аналитика» — именно ИСПДн, для которой нужна модель угроз, оценка актуальных угроз и набор мер по Приказу ФСТЭК №21.

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

Как обезличивание для ML снижает регуляторный риск?

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

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

Логирование запросов к модели само по себе создаёт новую ИСПДн, если в логах сохраняются ПДн из промптов. Это типичная ошибка архитектуры: разработчики включают полный debug-лог для диагностики, и он становится хранилищем данных без надлежащей защиты. Логирование как ПДн требует того же уровня защиты, что и основная система. Если лог отправляется в внешний SaaS-мониторинг (Datadog, Grafana Cloud, hosted ELK) — возникает вопрос трансграничной передачи и локализации по ч. 5 ст. 18 ФЗ-152.

Облако в РФ и локализация: что реально требует закон от SaaS-оператора?

Ч. 5 ст. 18 ФЗ-152 обязывает записывать, систематизировать, накапливать, хранить, уточнять и извлекать ПДн российских граждан только в базах на территории РФ. ФЗ-233 от 08.08.2024 ужесточил требование с 01.07.2025: первичный сбор данных также должен происходить на российской инфраструктуре. Для SaaS с языковой моделью это означает: векторная база RAG-индекса, хранилище диалогов, лог-системы, содержащие ПДн, — всё должно размещаться на серверах в РФ.

Иностранные облака (AWS, GCP, Azure, в том числе через российских реселлеров) допустимы для хранения обезличенных данных или при условии, что на иностранной инфраструктуре не хранятся ПДн российских граждан. Нарушение требований локализации — ч. 8 ст. 13.11 КоАП, штраф от 1 до 6 млн ₽ для юридического лица, при повторном нарушении — ч. 9, от 6 до 18 млн ₽.

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

Типовые сценарии: как prompt injection становится регуляторным событием

Сценарий 1. RAG-ассистент с общим индексом для всех tenant. Разработчики подключили языковую модель к единому векторному индексу, содержащему документы всех клиентов платформы. Пользователь одной компании формирует промпт вида «покажи все документы с упоминанием [имя клиента другой компании]» и получает данные чужого tenant. Ситуация: утечка ПДн через отсутствие изоляции контекста. Доказательства: лог обращений к модели с ответами, содержащими ПДн сторонних субъектов. Вероятный исход: штраф по ч. 12 ст. 13.11 (3–5 млн ₽) + предписание об устранении нарушений архитектуры. Стратегия: немедленная изоляция индексов по tenant, уведомление РКН в течение 24 часов, документирование мер по Приказу РКН №187.

Сценарий 2. Чат-бот с историей диалогов в контексте без очистки между сессиями. В корпоративном helpdesk-боте контекстное окно не очищается между сессиями разных пользователей. Атакующий через indirect prompt injection в тело обращения добавляет инструкцию вернуть содержание предыдущей сессии. Ситуация: данные одного сотрудника доступны другому. Доказательства: конфигурация системы без session isolation, логи с перекрёстными обращениями. Вероятный исход: при масштабе более 100 000 записей — ч. 14 ст. 13.11 (10–15 млн ₽). Стратегия: изоляция контекста по session ID на уровне промпт-шаблона и хранилища, аудит архитектуры на соответствие УЗ-3.

Сценарий 3. Модель обучена на исходных ПДн без обезличивания. Команда дообучала модель на тикетах поддержки, содержащих ФИО, email и телефоны клиентов. Через целевые промпты исследователь извлёк тренировочные данные методом extraction attack. Ситуация: ПДн вошли в веса модели, фактически хранятся без отдельной правовой базы. Доказательства: воспроизводимые примеры извлечения конкретных записей. Вероятный исход: нарушение ст. 5 (хранение дольше необходимого) и ст. 10 при наличии спецкатегорий, штраф по ч. 1 ст. 13.11 (150–300 тыс. ₽) + требование об уничтожении модели или её дообучении на обезличенных данных. Стратегия: внедрение pipeline обезличивания по пяти методам Приказа РКН до подачи данных в fine-tuning, документирование процедуры.

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

Кейс 1. IT-компания (Сибирский ФО, лето 2025) запустила RAG-ассистент для клиентов B2B-платформы. Через три месяца после запуска служба ИБ обнаружила, что векторный индекс не изолирован по tenant-сегментам. CTO инициировал внутреннее расследование, зафиксировал факт возможного cross-tenant доступа к ПДн сотрудников клиентских организаций. Первичное уведомление РКН направлено за 21 час с момента фиксации. В рамках 72-часового отчёта описаны меры по архитектурной изоляции и ограничению доступа. Штраф по ч. 12 ст. 13.11 составил несколько миллионов рублей; при рассмотрении дела суд учёл оперативность реагирования и самостоятельное выявление инцидента как смягчающие обстоятельства.

Кейс 2. Финтех-компания (Центральный ФО, осень 2025) использовала корпоративного LLM-ассистента на внешнем облачном API без проверки страны размещения инфраструктуры. При аудите обнаружено, что диалоги с ПДн клиентов сохранялись на серверах за пределами РФ. Нарушение локализации по ч. 5 ст. 18 ФЗ-152. Предписание РКН с требованием перевести хранилище диалогов на российскую инфраструктуру и оформить уведомление о трансграничной передаче (ст. 12 ФЗ-152) для промежуточного периода. Штраф по ч. 8 ст. 13.11 в диапазоне нескольких миллионов рублей.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Prompt injection переходит из категории академических угроз в регуляторную: успешная атака на LLM-компонент с доступом к ПДн — это утечка по ч. 3.1 ст. 21 ФЗ-152 с обязательным уведомлением РКН в 24 часа и потенциальным штрафом от 3 до 500 млн ₽ в зависимости от масштаба и повторности. Технические меры — изоляция контекста по tenant, pipeline обезличивания, логирование как ИБ-событие — должны быть задокументированы и соответствовать УЗ по ПП РФ №1119 и мерам Приказа ФСТЭК №21.

DATUM сопровождает IT-компании и SaaS-платформы в выстраивании комплаенса по ФЗ-152 для систем с языковыми моделями: от определения УЗ и разработки модели угроз до оформления поручения обработки и подготовки к проверке Роскомнадзора.