Корпоративный ИИ вырос из пилота — и теперь CISO хочет пять слоёв контроля

Год назад заказчики просили «прокси для ChatGPT с фильтром матов». Сейчас это матрица на десятки страниц и более 500 формализованных требований. Если вы строите или выбираете LLM/AI Firewall для enterprise, этот гайд покажет, из чего реально состоит такая архитектура и где чаще всего возникают пробелы.

Зачем вообще нужен отдельный контрольный контур

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

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

Слой 1: точка перехвата трафика

LLM/AI Firewall должен встать в разрыв трафика — не сбоку, а именно в разрыв. Варианты развёртывания, которые требуют заказчики:

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

Зоны ответственности разделяются явно: шлюз к моделям, шлюз к инструментам (MCP Gateway), агент на конечной точке, контроль генерируемого кода. Каждая зона — отдельная политика.

Слой 2: каталог моделей с метками размещения

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

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

Каждая запись в каталоге должна содержать:

• режим (локальная / внешняя) — обязательная метка
• цену входа и выхода, цену кэша
• пределы контекста, RPM/TPM
• флаг запрета обучения на переданных данных
• allow/deny-листы на уровне организации, команды и ключа

Без метки «локальная / внешняя» маршрутизатор не имеет права принимать решение о допуске данных. Это не рекомендация — это архитектурное ограничение.

Слой 3: конвейер безопасности и ML Red Teaming

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

Типовой порядок:

1. Нормализация + правила (гомоглифы, кодировки)
2. Лёгкие модели-классификаторы
3. Модель-судья на спорных оценках
4. Аудит-событие → SIEM

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

ML Red Teaming — не разовый пентест, а регулярный контур проверки устойчивости. Заказчики требуют:

• текстовые атаки, визуальные вставки и скрытые слои на изображениях, речевые инструкции в аудио
• многошаговые сценарии и атаки через результаты инструментов
• возможность добавлять свои кейсы, а не только получать обновления от вендора
• привязку каждой пробы к классу угрозы

Слой 4: анонимизация персональных данных по 152-ФЗ

Здесь заказчик говорит языком регулятора. Система обязана распознавать и маскировать:

• ИНН, СНИЛС, паспортные данные, полис ОМС
• спецкатегории персональных данных
• контрольные суммы и корпоративные секреты

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

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

Слой 5: люди, команды и бюджеты токенов

Иерархия: организация → команда → пользователь. Двухуровневый RBAC (ролевая модель доступа) и вход только через корпоративный каталог — без локальных учёток, которые потом никто не отзывает.

Каждый запрос живёт ровно в одной команде: её задаёт ключ API. По этому ключу считаются доступные модели, квота и бюджет. Если этого нет — расследование инцидента упирается в общую кучу токенов, где невозможно понять, чей это контур.

Бюджет токенов — такой же контрольный механизм, как политика допуска. Не «мягкое ограничение», а твёрдый лимит с алертом: кто, когда, по какому ключу выжег месячный бюджет за одну ночь.

Где это ломается

• Нет метки размещения в каталоге. Маршрутизатор отправляет данные с грифом «конфиденциально» во внешнюю модель, потому что не знал, что она внешняя.
• Маскирование только в текущем запросе. Модель помнит ПДн из третьего хода диалога и выдаёт их в шестом — маскировщик этого не видит.
• Red Teaming без интеграции в политику. Отчёт есть, правила не обновились, уязвимость осталась.
• Fail-open при падении анализатора. Если классификатор недоступен и трафик проходит без проверки — это не деградация, это дыра.
• Локальные учётки в RBAC. Уволенный сотрудник сохраняет доступ, потому что его ключ не был привязан к корпоративному каталогу.

Что попробовать дальше

Если вы только начинаете проектировать контур: начните с каталога моделей и меток размещения — это фундамент, без которого остальные слои не работают корректно. Затем добавьте маскирование ПДн с сессионными плейсхолдерами и только после этого — конвейер классификации.

Для оценки зрелости текущего решения: проверьте, что происходит при падении анализатора (fail-closed или fail-open), и попробуйте косвенную инъекцию через RAG-документ — большинство базовых фильтров её не видят.

FAQ

Чем LLM/AI Firewall отличается от обычного API-шлюза?

Обычный API-шлюз контролирует авторизацию и rate limiting. LLM/AI Firewall анализирует содержимое промптов и ответов: ищет инъекции, маскирует персональные данные, проверяет, куда уходят данные (локальная или внешняя модель), и ведёт аудит каждого срабатывания.

Обязателен ли режим fail-closed?

Заказчики из enterprise и regulated-секторов требуют fail-closed: если анализатор недоступен, трафик блокируется, а не пропускается. Fail-open допустим только в dev-окружениях с явным решением владельца риска.

Как маскировать ПДн в многоходовом диалоге?

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

Что делать с теневым ИИ, если сотрудники используют личные устройства?

Полностью закрыть невозможно без MDM (управление мобильными устройствами). Реалистичный минимум — браузерный плагин на корпоративных устройствах и мониторинг DNS/прокси на известные ИИ-эндпоинты.

Нужен ли отдельный MCP Gateway или достаточно основного шлюза?

Требования заказчиков разделяют их явно: шлюз к моделям и шлюз к инструментам (MCP) — разные зоны с разными политиками. Агент, вызывающий инструмент, должен проходить отдельную проверку прав, независимо от того, прошёл ли его промпт через основной фильтр.

Источники

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