# Корпоративный ИИ вырос из пилота — и теперь CISO хочет пять слоёв контроля
Каноническая страница: https://plainews.ru/posts/llm-ai-firewall-enterprise-requirements
Опубликовано: 2026-09-26T07:01:40.937Z

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

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

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

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

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

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

| Режим | Где стоит | Типичный сценарий |
| --- | --- | --- |
| API-шлюз | Между клиентом и провайдером | Корпоративные ассистенты |
| Прозрачный прокси | На уровне сети | Контроль браузерных чатов |
| Sidecar | Рядом с контейнером агента | Агентные пайплайны |
| Браузерный плагин | На устройстве сотрудника | Теневой ИИ |
| Толстый клиент | На конечной точке | Офлайн-сценарии |

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

> **Важно.** Отказ от любого слоя контроля должен быть явным задокументированным риском, а не «незаметным упрощением проекта». Если агентный sidecar не развёрнут — это решение, которое кто-то подписал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> **Важно.** Если находка из Red Teaming живёт только в отчёте и не становится правилом шлюза — сканер можно считать бесполезным. Вердикт должен давать прямой вход в политику LLM/AI Firewall: что блокировать, что маскировать, какой маршрут закрыть.

## Слой 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