Предотвращаем катастрофу: разбираемся с тем, как работает защита проектов с AI

Большинство инцидентов с LLM в корпоративной среде происходят не из-за уязвимости самой модели. Они происходят из-за отсутствия контура защиты — набора ограничений вокруг модели, которые определяют, какие данные попадают на вход, кто инициирует запросы, что модель может вызвать и куда уходит результат.

Ниже рассмотрим шесть слоёв защиты, которые мы выстраиваем в каждом проекте. Порядок — от данных к людям: чем ближе к модели, тем больше технических решений; чем ближе к человеку, тем больше процесса.

---

Данные: что попадает в контекст и куда это уезжает

Часто сталкиваемся с типичной проблемой — чувствительные данные защищены от утечки с обычной LLM, но никак не защищаются при работе с RAG.

При использовании RAG в промпт попадают чанки — фрагменты документов, подобранные ретривером под запрос. В этих фрагментах могут оказаться имена, номера договоров, финансовые показатели — всё, что содержится в исходных документах базы знаний. Полный текст каждого запроса, как правило, оседает в логах: у вас, у провайдера модели, иногда у обоих.

Конечно, мы все уповаем на честность крупных провайдеров LLM и верим, что они не будут делать ничего с персональными данными. Да и возникает резонный вопрос — ну утекли какие-то документы, допустим, в OpenAI — кто об этом узнает и что с ними вообще будет? Кому там в OpenAI нужны наши документы?

На самом деле проблема шире — на этих данных может быть обучена следующая версия LLM, и документы могут остаться в памяти модели — соответственно, по запросу можно будет получить эти данные напрямую от новой версии ChatGPT. Это уже опаснее.

Три меры, которые закрывают основную поверхность риска на этом уровне:

• Классификация данных до подключения источника. До первого эмбеддинга должно быть определено: что допустимо отправлять во внешний API, что допустимо только в маскированном виде, что не покидает периметр.
• Явные условия с провайдером модели. OpenAI, Anthropic, YandexGPT, GigaChat — у каждого свои условия по обучению на данных клиентов, срокам хранения и географии обработки. В российском контексте это пересекается с требованиями 152-ФЗ к локализации обработки персональных данных. Этот вопрос требует детальной обработки.
• Маскирование на входе. Имена, ИНН, номера договоров заменяются токенами до отправки в модель. Инструменты вроде Presidio (Microsoft, open source) или самописные regex-пайплайны покрывают базовый уровень. Если задача сложнее — всегда можно отдать задачу маскирования на LLM.

---

Граница контура: где заканчивается «наше» и начинается «их»

На этапе прототипа бэкенд обычно вызывает API модели напрямую: ключ в переменной окружения, запрос уходит в endpoint провайдера без промежуточного слоя. В продуктивной среде такая схема создаёт три проблемы:

1. Отсутствие единой точки отключения. При необходимости заблокировать определённый тип запросов приходится вносить изменения в каждый сервис отдельно.
2. Отсутствие наблюдаемости. Нет данных о том, сколько токенов потребляется, кто инициирует вызовы и что содержится в теле запроса.
3. Смешение сред. Тестовый и прод контуры работают через один endpoint с одним ключом. Ошибка в staging приводит к отправке реальных данных в модель.

Стандартное решение — LLM-прокси или gateway. Для self-hosted инфраструктуры это LiteLLM, Portkey или собственный слой на уровне ingress. Для облачных решений — Azure API Management или аналоги в Yandex Cloud. Весь трафик к моделям проходит через единую точку, где можно логировать, фильтровать и при необходимости полностью отключить канал передачи данных.

---

Доступы и роли: почему авторизация на фронте — это не авторизация

LLM-проекты наследуют проблемы разграничения доступа обычных корпоративных систем — и усиливают их. Типичная ситуация: RAG подключён ко всей файловой базе, сотрудник с ограниченными правами задаёт вопрос, модель формирует ответ на основе документа, к которому у этого сотрудника нет доступа в DMS. Документ никто не открывал и не скачивал — но его содержание ушло в ответ.

Модель не проверяет доступы. Она генерирует ответ из того контекста, который получила. Это значит, что фильтрация должна происходить до модели — на уровне ретривера:

• Каждый чанк в векторной БД наследует доступы исходного документа.
• Ретривер перед формированием контекста проверяет роль текущего пользователя и отсекает запрещённые чанки.
• На этапе пилота, где полноценная система разграничения доступов на уровне чанков избыточна, минимальная мера — раздельные индексы под разные уровни доступа с запретом на cross-index поиск.

Единый индекс без фильтрации по ролям — это, по сути, SELECT * по всей базе для любого авторизованного пользователя.

---

Инструменты агента: когда модель не только говорит, но и делает

Пока LLM только генерирует текст, последствия ошибки ограничены неточным или неуместным ответом. При подключении function calling, MCP-серверов, записи в CRM, отправки писем или вызова внутренних API модель получает возможность действовать — и промпт-инъекция становится полноценным вектором атаки.

Механика простая: пользователь передаёт в чат текст для анализа, внутри которого содержится инструкция, замаскированная под цитату — например, вызов функции отправки письма. Если агент не разделяет пользовательские данные и системные инструкции (а базовые реализации этого не делают), вызов будет выполнен.

Пример максимально практичен: чат-бот в Телеграме, обрабатывающий лид-поток, часто имеет доступ в CRM — так удобно добавлять лидов сразу в CRM. Но есть ли гарантия, что пользователь бота не обойдёт защиту и не вытащит всю вашу базу лидов? Если не боитесь отдать конкурентам весь список своих лидов, который вы так тщательно обогащали много лет, — можно не задумываться о безопасности на этом слое.

Меры, которые работают на практике:

• Белый список инструментов на уровне сессии. Для каждого контекста определяется набор допустимых операций: поиск и чтение — без ограничений, запись — только с подтверждением.
• Валидация аргументов вызова отдельным слоем. Модель формирует JSON-вызов, промежуточный сервис проверяет: адресат письма в разрешённом домене, сумма в пределах лимита, ID документа существует в системе.
• Подтверждение человеком на деструктивных операциях. Удаление, отправка за периметр, изменение прав — через явное подтверждение. Потеря скорости на этом шаге несопоставима с последствиями несанкционированной записи в продуктивную среду.

---

Логи и аудит: инструменты расследования после инцидентов

Здесь существуют две крайности: полное логирование в открытом виде и полное отсутствие логов. Первое создаёт дополнительный чувствительный актив — лог с полными промптами по сути дублирует ваши данные. Второе делает расследование инцидента невозможным.

Минимальный набор для пилота, не создающий избыточного риска:

• Идентификатор сессии, роль пользователя, timestamp.
• Хеш или маскированная версия запроса — достаточно для корреляции с инцидентом, но не является копией данных.
• Факт вызова инструмента с маскированными аргументами.
• Потребление токенов и стоимость — для финансового контроля и обнаружения аномалий. Резкий всплеск потребления часто оказывается первым сигналом злоупотребления.

Логи с фрагментами данных подпадают под те же правила хранения, что и сами данные. Сроки ретеншна, круг доступа, место хранения — часть архитектуры, а не отложенная задача.

---

Человек в контуре: где модель не должна быть последней инстанцией

Этот слой — не технический, а процессный. Он отвечает на вопрос: кто несёт ответственность, если модель ошиблась и это привело к последствиям?

Автоматическая отправка ответа клиенту, генерация юридического документа без ревью, ответ на рекламацию — ситуации, где степень уверенности модели не имеет значения. LLM не калибрована: уровень уверенности в правильном и неправильном ответе может быть одинаковым.

На практике это решается явным реестром сценариев:

• Зелёные: модель работает автономно — внутренний FAQ, черновик саммари, поиск по документации. Цена ошибки низкая.
• Жёлтые: модель готовит черновик, человек подтверждает перед отправкой — ответ клиенту, коммерческое предложение, запись в CRM.
• Красные: модель используется только как справочный инструмент, решение принимает человек — юридические заключения, медицинские рекомендации, финансовые обязательства.

Границы между зонами определяет бизнес, не разработка. При отсутствии такого реестра все сценарии по умолчанию оказываются зелёными — и остаются таковыми до первого инцидента.

---

Как это работает вместе

Шесть слоёв — это не шесть отдельных проектов. На раннем пилоте поверхность атаки сужается сознательно: один источник данных, один инструмент, ограниченный круг пользователей, полное логирование. Каждый слой тонкий, но присутствует. Расширение идёт поэтапно: новый источник — пересмотр классификации и доступов; новый инструмент — валидация и логирование вызовов.

Распространённая ошибка — сводить безопасность к выбору провайдера. Провайдер отвечает за свою инфраструктуру. За контур, данные в промптах, доступы и действия пользователей отвечает владелец системы. Модель — это компонент. Безопасность — это контур вокруг компонента.

---

Три вопроса, которые стоит задать себе сейчас

1. Можете ли вы нарисовать схему потока данных от пользователя до API модели и обратно — без неопределённых участков? Если нет, с этого стоит начать, а не с выбора модели.
2. Кто единоличный владелец контура безопасности этого пилота? Один конкретный человек, к которому обращаются при инциденте, — не комитет и не распределённая ответственность.
3. Есть ли план отключения? Что произойдёт с пользователями и данными, если LLM-контур будет остановлен целиком? Отсутствие ответа обычно означает, что зависимость от модели уже выше допустимой.

---

Как мы работаем

В sequo мы выстраиваем контур безопасности до выбора модели — не после. Это означает, что архитектура проекта учитывает границы данных, доступы и аудит с первого дня, а не добавляется как слой поверх работающей системы.

Если хотите разобрать конкретную задачу — напишите. Скажем прямо, если видим, что контур не готов.

---

FAQ