От прокси к контрольному контуру: что заказчики реально требуют от LLM/AI Firewall
В корпоративной среде ИИ перестал быть просто пилотным проектом. Запросы now исходят из IDE, внутренних ассистентов и «теневых» чатов, что кардинально меняет поверхность атаки. Заказчики больше не ищут простой фильтр для промптов — им нужен полноценный контрольный контур, объединяющий безопасность, управление рисками и бюджет. Новые требования включают более 500 формализованных пунктов, охватывающих всё от предотвращения промпт-инъекций до строгого контроля расходов токенов и соблюдения 152-ФЗ. Это трансформация подхода от «пущено ли это через шлюз» к сложной архитектуре доверия, где каждая переменная имеет значение.
# Эволюция требований к безопасности ИИ: от фильтра к системе управления рисками
Корпоративный ИИ больше не живет в изолированном департаменте. Запросы к генеративным моделям теперь исходят из самых разных точек: интегрированных сред разработки (IDE), внутренних когнитивных помощников, агентных контуров и так называемых «теневых» чатов сотрудников. Именно эта диверсификация источников и путей доступа привела к тому, что поверхность атаки корпорации выглядит совершенно иначе, чем традиционный защищаемый периметр. Мы сталкиваемся с новыми векторами угроз: промпт-инъекции, потенциальная утечка персональных данных во внешние модели, неконтролируемый расход вычислительных ресурсов и выполнение инструментов ИИ-агентами без должных прав.
Рынок безопасности генеративного ИИ (GenAI) претерпел фундаментальные изменения за последний год. Если ранее заказчики формулировали запросы на «прокси для ChatGPT», то сейчас мы наблюдаем формирование сложных матриц требований, которые на десятки страниц описывают более 500 формализованных условий. Эти условия затрагивают всё: от требований к ИИ-агентам и протоколов управления контекстом (MCP) до соблюдения российского законодательства (152-ФЗ) и управления цепочками поставок моделей.
Стать целью является не создание каталога функций, а прояснение карты обязательных требований для Заказчика и понимание того, как они формируют архитектуру контроля. В центре этой архитектуры лежат вопросы границ доверия, финансовой управляемости и строгого регуляторного соответствия.
Точка контроля и каталог моделей
Архитектура защиты генеративного ИИ выстраивается слоями, каждый из которых имеет критическое значение для безопасности бизнеса.
Первый слой — точка контроля. LLM/AI Firewall должен физически или логически встать в разрыв трафика, выступая в роли API-шлюза, прозрачного прокси, sidecar-сидика или браузерного плагина. Важно, чтобы подключение такого элемента безопасности не ломало работу существующих ИИ-агентов и ассистентов. Ключевым требованием является выявление «теневой» ИИ-инфраструктуры (Shadow AI), когда сотрудники по привычке используют публичные чаты, минуя корпоративный шлюз. Весь ИИ-трафик должен подчиняться тем же правилам контроля, что и стандартные корпоративные каналы связи. Здесь же решается вопрос зон ответственности: кто контролирует доступ к моделям, а кто — к инструментам (MCP), особенно когда агент действует автономно на конечной точке.
Второй слой — каталог моделей. Для заказчика критически важно различие между публичным именем модели и её физическим развёртыванием. Под именем «GigaChat» может скрываться как локальный инстанс vLLM, так и внешний сервис провайдера. Карточка модели в системе должна содержать не только имя, но и режим работы, стоимость входа и выхода, пределы контекста, ограничения по запросам в минуту (RPM) и токен в минуту (TPM). Без явной метки размещения (локальное или внешнее) маршрутизатор не имеет права принимать решение о допуске данных.
Третий слой — конвейер безопасности. Защита не может сводиться к одному классификатору. Это длинный пайплайн, включающий нормализацию, базовые правила, применение небольших моделей и финальную оценку «судьей» (judge model) на спорных сценариях. Система должна уметь обрабатывать специфические угрозы: русскоязычную морфологию, гомоглифы, косвенные инъекции из файлов или почтовых сообщений. Важным аспектом является защита самого шлюза и проведение регулярных проверок устойчивости внутренних моделей с помощью ML Red Teaming, что позволяет выявлять слабые места до того, как ими воспользуются злоумышленники.
Управленческий контроль: люди, данные и деньги
Требования к безопасности ИИ выходят далеко за рамки технических параметров, затрагивая организационные процессы и финансовые потоки компании.
Четвёртый слой — управление данными. В контексте российского законодательства этот слой строится вокруг требований 152-ФЗ. Система должна гарантировать сохранность персональной информации (ИНН, СНИЛС, паспортные данные и специальные категории). Это включает создание устойчивых плейсхолдеров для чувствительных данных на протяжении всей сессии и их обратную подстановку в ответе модели. Маскирование должно работать не только в реальном времени, но и на историческую часть диалога и суммаризации, чтобы модель не «подсмотрела» скрытые сущности несколько ходов назад. Корпоративные секреты и конфиденциальные категории обрабатываются теми же механизмами.
Пятый слой — управление людьми и бюджетом. Здесь внедряется строгая иерархия прав: организация, команда и конкретный пользователь. Вход осуществляется только через корпоративный каталог без создания локальных учётных записей, которые сложно отзываться. Уникальной особенностью является привязка квот и бюджета именно к ключу, а не к пользователю, что позволяет точно атрибутировать расход ресурсов. Бюджет становится инструментом контроля рисков: если лимит исчерпан, шлюз должен вернуть понятную ошибку с указанием времени сброса, предотвращая бесконтрольный расход токенов, который может привести к финансовым потерям.
Маршрутизация на основе стоимости и конфиденциальности
Одной из ключевых функций современного LLM/AI Firewall является интеллектуальная маршрутизация. Система должна сама выбирать наиболее подходящую модель для каждого запроса на основе фиксированных критериев: класс задачи, уровень конфиденциальности и стоимость.
Решение должно быть детерминированным и проверяемым. Например, запрос с высоким уровнем конфиденциальности (Restricted) никогда не должен покидать периметр, даже если на внешнем провайдере есть свободная квота. Он обрабатывается исключительно локальными внутренними моделями. Для данных, которые были обезличены или замаскированы (Masked), допускается отправка во внешние контуры, но только при соблюдении политики запрета на обучение провайдера на этих данных.
Открытые данные (Public) могут обрабатываться любым разрешённым в реестре провайдером. Система классификации анализирует не только текущую реплику, но и всю историю диалога, производный контекст и результаты работы инструментов. Если детектор с неуверенностью фиксирует чувствительные фрагменты, уровень доступа автоматически повышается до Restricted.
Такая гибкая архитектура позволяет динамически менять модель в середине диалога, если изменилась задача или гриф данных. Пользователь мог начать с общего вопроса через публичную модель, а затем добавить фрагмент договора — в этот момент маршрутизатор обязан перевести сессию на локальный контур, сохранив ранее сделанные маскировки.
Заключение
Требования к LLM/AI Firewall стремительно усложняются по мере перехода от экспериментов к внедрению корпоративных ИИ-платформ. Заказчики больше не довольствуются простым шлюзом, который считает токены и блокирует известные сценарии взлома. Им необходима система, которая выступает в роли централизованного контрольного контура.
Современное решение должно учитывать множество параметров одновременно: профиль пользователя, команду, приложение, используемую модель, источник данных, историю диалога и действия ИИ-агента. В единой политике безопасности должны гармонично переплетаться требования к конфиденциальности, размещению моделей, стоимости запросов, производительности и журналированию событий.
Классические средства защиты периметра, такие как WAF, DLP или API-шлюзы, остаются важными, но они не способны в полной мере понять семантику взаимодействия с ИИ. Они проверяют формат и адреса, но не могут детерминировать, пытается ли промпт изменить системные правила или заставить агента выполнить незаконное действие. Именно поэтому LLM/AI Firewall становится механизмом управления риском на всём пути прохождения запроса. Его ценность определяется способностью связывать семантический анализ, маршрутизацию, контроль агентов и финансовый учёт в единую последовательную систему.
В условиях, когда ИИ-агент может запустить цикл запросов, исчерпающий бюджет за несколько минут, контроль становится вопросом выживания бизнеса. Алерты о превышении квот должны поступать не только владельцам команд, но и в системы мониторинга (SIEM) для немедленного реагирования. Таким образом, безопасность генеративного ИИ превращается из технической задачи в комплексную дисциплину управления рисками, где каждый элемент архитектуры имеет значение для устойчивости корпорации.