Требования заказчиков к LLM/AI Firewall

Корпоративный ИИ перестал быть пилотным проектом в одном департаменте. Запросы к моделям идут из IDE, внутренних ассистентов, агентных контуров и «теневых» чатов сотрудников. При этом поверхность атаки выглядит иначе, чем у классического периметра: промпт-инъекция, утечка ПДн во внешнюю модель, неконтролируемый расход токенов, вызов инструмента ИИ-агентом без права на это действие.

В этой статье сделаем разбор реальной матрицы требований к LLM/AI Firewall. Цель статьи – не каталог фич, а карта того, что Заказчик считает обязательным, и как эти требования складываются в архитектуру контроля, где важны границы доверия, деньги, регуляторика и управляемость.

Что на самом деле требует Заказчик

За последний год сильно изменились требования крупных enterprise компании к защите генеративного ИИ. Сначала это был короткий перечень задач к «прокси для ChatGPT». Сейчас это матрица на десятки страниц, в которой описаны более 500 формализованных требований: сначала стандартные задачи, а затем том требований к ИИ-агентам, MCP, 152-ФЗ, цепочке поставок моделей и т.д. Это уже не запрос на фильтр. Это запрос на контрольный контур.

CISO больше не спрашивает, умеет ли система «ловить jailbreak». Он спрашивает, где стоит точка контроля, что происходит, если анализатор упал, уходит ли конфиденциальный документ во внешнюю модель даже в замаскированном виде, и кто в три часа ночи увидит, что сервисная учётка выжгла месячный бюджет токенов.

Матрицу с требованиями можно разделить на две части, при этом вторая часть требований намного жёстче первой.

Часть I – исходная форма. Это то, с чего обычно начинается анализ: общие характеристики, каталог моделей, базовый конвейер безопасности, защита агентов, анонимизация ПДн, роли и лимиты, API, классификация и маршрутизация, MCP Gateway.

Часть II – дополнительные требования. Здесь Заказчик уже думает как владелец риска: варианты развёртывания, fail-closed, теневой ИИ, цепочка поставки моделей, ML Red Teaming и регрессия, производительность, защита самого шлюза, локализация данных, ИИ-агенты на конечной точке и т.д.

Как эти требования группируются?

Первый слой – точка контроля. LLM/AI Firewall должен встать в разрыв трафика: API-шлюз, прозрачный прокси, sidecar, браузерный плагин, толстый клиент на конечной точке. Подключение не должно ломать работу ИИ-агентов и ассистентов. Важно выявлять «теневой» ИИ (Shadow AI), когда сотрудники уходят в публичный ИИ-чат мимо шлюза. ИИ-трафик должен попадать под тот же режим, что и остальной корпоративный канал.

Здесь же возникает требование к разделению зон ответственности:

• шлюз к моделям,

• шлюз к инструментам (MCP),

• агент на конечной точке,

• контроль кода, который генерирует ИИ.

Отказ от любого слоя должен быть явным риском, а не «незаметным упрощением проекта».

Второй слой – каталог моделей. Публичное имя, которое видит клиент, и конкретное развёртывание за ним – это разные сущности. За одним именем живёт пул: локальный vLLM, GigaChat, внешний провайдер. У каждой записи есть режим, цена входа и выхода, цена кэша, пределы контекста, RPM/TPM и обязательная метка размещения: локальная модель или внешняя. Без этой метки маршрутизатор не имеет права принимать решение о допуске данных.

Минимальный набор провайдеров: Anthropic, OpenAI, DeepSeek. На практике Заказчики сразу добавляют GigaChat, YandexGPT, Ollama, vLLM, llama.cpp.

Для безопасности критичны также два пункта: запрет обучения на переданных данных (где провайдер это умеет) и allow/deny-листы моделей на уровне организации, команды и ключа.

Третий слой – конвейер безопасности. Это не один классификатор, а большой пайплайн с явным порядком шагов, отдельной реакцией на каждую проверку и событием аудита на каждое срабатывание. Сначала нормализация и правила, затем небольшие модели, затем судья на спорных оценках. Отдельные требования на русскоязычную морфологию, гомоглифы, косвенные инъекции из файлов, почты, RAG и результатов инструментов, разбор офисных форматов, OCR и речь.

Через сканер ML Red Teaming Заказчик хочет реализовать регулярный контур проверки устойчивости внутренних ИИ-моделей: текстовые атаки, визуальные вставки и скрытые слои на изображениях, речевые инструкции в аудио, многошаговые сценарии и атаки через результаты инструментов. Набор проб должен расширяться своими кейсами, а не только поставкой вендора, а вердикт должен опираться на фиксированную методику и модель-судью, чтобы пентест можно было повторить после смены модели, системного промпта или корпуса базы знаний. Сканер обязан не просто набрать процент отражённых атак на публичном бенчмарке, а привязать каждую пробу к классу угрозы и сразу дать вход в политику LLM/AI Firewall: что блокировать, что маскировать, какой маршрут закрыть. Если находка живёт только в отчёте и не становится правилом шлюза, то сканер ML Red Teaming можно считать бесполезным.

Четвёртый слой – данные. Здесь Заказчик говорит языком 152-ФЗ. Нужны ИНН, СНИЛС, паспорт, полис, спецкатегории, контрольные суммы, устойчивый плейсхолдер на всю сессию и обратная подстановка в потоковом ответе. Маскирование должно накрывать историю диалога и саммари, иначе модель уносит сущность, найденную три хода назад. Секреты и корпоративные категории идут тем же механизмом, что и персональные данные.

Пятый слой – люди, команды и деньги. Заказчики требуют иерархию «организация – команда – пользователь», двухуровневый RBAC и вход только через корпоративный каталог, без локальных учёток, которые потом никто не отзывает. Человек может состоять в нескольких командах, но каждый запрос живёт ровно в одной: её задаёт ключ, и именно по нему считаются доступные модели, квота и бюджет. Иначе расследование упирается в общую кучу токенов, где нельзя понять, чей это контур.

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

Почему важно контролировать расход LLM-токенов

В закупках этот блок часто прячут в раздел лимитов, и зря. Токен это одновременно единица стоимости, единица риска (индикатор аномалии) и единица нагрузки на инференс. Если LLM/AI Firewall не считает его до вызова модели, он не управляет риском, а CISO и CIO не смогут объяснить, почему счёт на оплату вырос в четыре раза.

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

Счётчик должен проверять квоту до обращения к ИИ-модели. Иначе prompt-based DoS или зацикленный ИИ-агент успевают быстро списать деньги и «заглушить» локальный инференс. Необходимо задать потолок контракта, при котором команда живёт внутри своего бюджета, пользователь или сервисный ключ не может забрать чужой лимит, у модели есть собственный RPM/TPM, у одного запроса есть ограничение длины. При этом индивидуальная квота перекрывает командную.

Для CISO в этом месте важнее не красивый график, а поведение системы в момент отказа. Превышение должно возвращать понятную ошибку: какой лимит, сколько израсходовано, когда сброс. Обрыв соединения без причины порождает обход. Пример индикатора аномалии: ночной всплеск расхода токенов у учётки, которая днём мало используется. Поэтому алерты на 80% квоты должны уходить не только владельцу команды, но и как событие в SIEM.

Есть ещё одна деталь, которую Заказчики начинают включать после первого же агентного пилота. Бюджет сессии ИИ-агента считается как сумма всех вложенных вызовов, а не как стоимость первой реплики. Иначе инструмент в цикле обходит любую «квоту на чат».

Перераспределение запросов: стоимость, сложность, конфиденциальность

Самый частый запрос – это классификация и маршрутизация запросов к ИИ-модели. Заказчик прямо формулирует: LLM/AI Firewall сам должен выбирать ИИ-модель на каждый запрос.

Критерии выбора в требованиях фиксируются так:

• класс задачи ↔ возможности модели;

• уровень конфиденциальности ↔ допустимое размещение (внутренние или внешние модели);

• стоимость и доступность.

Решение должно быть детерминированным и проверяемым на пробном запросе. Модель может смениться в середине диалога, если изменились задача или гриф данных.

Разберем подробнее.

Перераспределение в зависимости от расхода токенов

Это не правило «отправь туда, где ещё осталась квота». Слепая перекладка на живой контур как раз и ломает защиту.

Если при использовании «дорогой» ИИ-модели подошли к лимитам по частоте, объёму или деньгам, запрос можно спустить на следующее звено цепочки, но только если таблица допуска это разрешает. Если задача несложная («дешёвая»), её нельзя держать на дорогой модели только потому, что на ней есть квота. Если внутренние ИИ-модели перегружены, конфиденциальные данные всё равно не должны уходить во внешние модели. Доступность в этой архитектуре никогда не побеждает гриф.

Цепочка выглядит чаще всего так: сильная локальная модель, затем лёгкая локальная, затем российское облако, затем внешний провайдер. Каждый переход разрешён только политикой и классом данных.

Перераспределение в зависимости от сложности задачи

Класс задачи задаётся конфигурацией, а не привычкой пользователя. Например, краткое изложение протокола совещания не должно отправляться в дорогую внешнюю модель только потому, что она первая в списке чата.

Важно разделять в запросах к модели генерацию кода, анализ данных, сжатие текста, ответ по базе знаний (RAG), работу с изображением, задачи с длинным внутренним рассуждением и т.д.

Карточка модели должна быть машиночитаемой: какие модальности принимает, какое окно контекста, умеет ли рассуждать, где физически стоит, сколько стоит вход, выход и внутренние рассуждения. Важная оговорка из требований: правила маршрутизации администрируются без перезапуска. Иначе ИБ не сможет быстро закрыть дорогой контур после инцидента или исчерпания лимита.

Перераспределение в зависимости от конфиденциальности запроса

Три уровня фиксируются жёстко:

• Конфиденциальные или закрытые данные (Restricted) не покидают периметр ни в каком виде, в том числе после маскирования. Используются только локальные (внутренние) ИИ-модели.

• Обезличенные или маскированные данные (Masked) можно отдать во внешний контур только после замены (маскирования) сущностей и только тем провайдерам, которым это прямо разрешено политикой, с запретом обучения на этих данных.

• Открытые данные (Public) ходят по перечню разрешённых моделей.

Классификатор смотрит не одну реплику пользователя. В оценку входят текущий ввод, история диалога, производный контекст сессии и то, что вернул инструмент. Если детектор не уверен, что нашёл все чувствительные фрагменты, Masked поднимается до Restricted. Ослаблять это можно только явно, с фиксированием в журнале и именем того, кто принял риск.

Таблица допуска:

Внутренние запросы с пометкой «только внутри» не уходят во внешнюю модель потому, что она умнее. Решение принимается на каждый ход, поэтому модель в диалоге может смениться. Человек начал с публичного вопроса, затем вставил фрагмент договора. В этом случае маршрутизатор обязан увести сессию на локальный контур и сохранить согласованные подстановки. Если карта замен живёт только в памяти одного развёртывания, смена модели ломает и защиту, и смысл ответа.

Что из этого следует

По мере перехода от отдельных экспериментов к корпоративным ИИ-платформам требования к LLM/AI Firewall быстро усложняются. Заказчику уже недостаточно прокси, который пропускает запрос к модели, считает токены и блокирует несколько известных jailbreak-сценариев. От LLM/AI Firewall ожидают полноценного контрольного контура, способного учитывать пользователя, команду, приложение, модель, источник данных, историю диалога и действия ИИ-агента.

Эти требования становятся не только более многочисленными, но и более разнообразными. В одной политике должны одновременно учитываться конфиденциальность данных, допустимое размещение модели, стоимость запроса, сложность задачи, лимиты производительности, права агента и требования к журналированию. Система должна контролировать не только текст запроса и ответа, но и содержимое файлов, результаты RAG-поиска, изображения, аудио, вызовы инструментов и обмен данными через MCP. При этом политики должны применяться к каждому шагу цепочки, включая промежуточные вызовы модели и вложенные действия ИИ-агента.

Классических средств защиты для такого контура недостаточно. WAF, IAM, DLP, API-шлюзы и SIEM остаются важными компонентами инфраструктуры, но сами по себе не понимают семантику промпта и ответа модели. Они могут проверить формат запроса, адрес назначения, права доступа или наличие известных шаблонов, но не способны определить, что безобидная на вид инструкция фактически пытается изменить системные правила, извлечь скрытый контекст, обойти ограничение или заставить ИИ-агента выполнить неразрешённое действие.

Поэтому LLM/AI Firewall анализирует смысл и контекст взаимодействия. В его задачи входят выявление prompt injection и jailbreak, контроль утечек чувствительной информации, обнаружение опасного вывода, противодействие чрезмерной автономности агентов, проверка результатов инструментов и защита от сценариев OWASP Top 10 for LLM Applications, включая supply-chain-риски, уязвимости векторных представлений и неограниченное потребление ресурсов.

Таким образом, LLM/AI Firewall превращается в механизм управления риском на всём пути прохождения ИИ-запроса. Его ценность определяется не количеством отдельных функций, а тем, насколько последовательно он связывает семантический анализ, политики доступа, маршрутизацию, маскирование, контроль агентов, бюджетирование, аудит и реагирование. Именно поэтому требования к таким решениям продолжают расти: корпоративному ИИ требуется не только доступ к моделям, но и управляемая, проверяемая и безопасная среда их применения.