Управляемые AI-агенты в enterprise: как LLM gateway обеспечивает контроль, безопасность и compliance

Зачем enterprise нужны управляемые AI-агенты

Три отдела крупной компании одновременно запустили пилоты с AI-агентами. Маркетинг подключил GPT-4 для генерации креативов, разработка тестирует ассистента для код-ревью, HR пробует скоринг резюме. Через месяц финансовый директор получает счёт на $18 000 - втрое выше ожидаемого. Служба безопасности фиксирует, что в промптах мелькают персональные данные клиентов, а compliance-офицер не может ответить регулятору, кто и зачем обрабатывал эти данные.

Это не сценарий, а собирательный образ десятков компаний, с которыми мы сталкивались в 2025–2026 годах. Автономные агенты без контроля создают три проблемы: неконтролируемый рост затрат, утечки конфиденциальной информации и полную непрозрачность для аудита. Решение - концепция управляемых агентов (governed agents), где каждый вызов модели, инструмента или внешнего API проходит через единый runtime-контроллер - LLM gateway.

LLM gateway - это прокси-сервер между агентами и моделями, который перехватывает каждый запрос и применяет политики: аутентификация, маршрутизация, фильтрация данных, логирование. Он не блокирует инновации, а создаёт безопасный периметр, внутри которого команды могут экспериментировать. По данным опроса BISA, более 73% компаний планируют внедрить ИИ-агентов в 2026 году, но лишь 12% имеют зрелые практики управления ими. Разрыв между скоростью внедрения и зрелостью governance - главный риск ближайших двух лет.

LLM gateway: архитектура runtime-контроллера

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

Схема взаимодействия выглядит так: агент → шлюз (аутентификация → применение политик → маршрутизация → guardrails) → модель/API. Шлюз не хранит состояние, каждый запрос обрабатывается независимо, что упрощает горизонтальное масштабирование.

Реализация может быть open-source - например, на базе Envoy с Lua-фильтрами или специализированных фреймворков вроде LiteLLM, - либо коммерческим продуктом. Выбор зависит от требований к производительности, глубине кастомизации и доступности команды для поддержки. Ключевой критерий: шлюз должен обрабатывать каждый вызов за время, не превышающее 50–100 мс дополнительной задержки, чтобы не деградировать пользовательский опыт.

Ключевые функции шлюза: от маршрутизации до логирования

• Маршрутизация запросов - выбор модели под задачу: дешёвая для суммаризации, мощная для генерации кода. Правила задаются декларативно в конфигурации.
• Guardrails - фильтрация входящих промптов и исходящих ответов. Блокировка PII, запрещённых тем, вредоносных инструкций. Подробный разбор архитектуры guardrails мы делали в статье про StarGuard AI: цепочки детекторов и маскирование данных.
• Контроль лимитов и квот - ограничение числа вызовов на пользователя, команду или проект. Предотвращает runaway-расходы.
• Сбор метрик и логов - полная запись каждого запроса: кто, когда, к какой модели, с каким промптом, какой ответ, сколько токенов потрачено.
• Управление секретами - централизованное хранение API-ключей. Разработчики получают внутренние токены, реальные ключи никогда не покидают шлюз.

Три сценария внедрения governance: выбираем фокус

Governance - спектр практик. Не нужно внедрять всё сразу. Выберите приоритетный сценарий и расширяйте охват по мере зрелости процессов. Мы выделяем три типовых вектора: видимость, контроль и аудит.

Сценарий 1: Видимость - берём расходы под контроль

Стартап из 15 разработчиков подключил прямые API-ключи к OpenAI и Anthropic. Через два месяца счёт составил $7 200, при этом 40% вызовов приходилось на тестовые запуски и отладку. После внедрения шлюза с мониторингом и маршрутизацией команда настроила правила: для задач с длиной контекста менее 4K токенов запросы уходят на Mixtral 8x7B (через Together AI), для сложной аналитики - на GPT-4. Итог: расходы снизились до $2 800 при сохранении качества на продуктовых задачах.

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

Сценарий 2: Контроль - защищаем конфиденциальные данные

Финансовая компания внедрила AI-ассистента для обработки клиентских обращений. В первые две недели служба безопасности зафиксировала 23 случая передачи номеров паспортов и банковских карт во внешнее API. Промпт-инструкции «не передавай персональные данные» не работали: агент послушно маскировал данные в ответе, но отправлял их в запросе к модели.

Guardrails на уровне шлюза решают эту проблему. Правила фильтрации применяются до того, как запрос покинет периметр компании:

• Regex-детекторы находят шаблоны номеров карт, паспортов, ИНН и заменяют на [REDACTED].
• ML-детекторы анализируют контекст и выявляют нетипичные паттерны - например, список клиентов с суммами счетов.
• Политика блокировки tool calls запрещает агенту вызывать определённые функции - скажем, delete_record из CRM.

В кейсе финкомпании после настройки guardrails количество инцидентов упало до нуля за первую неделю. За полгода шлюз заблокировал 1 847 попыток передачи чувствительных данных. Средняя задержка от применения фильтров составила 35 мс - незаметно для пользователя.

Сценарий 3: Аудит - готовимся к проверкам регуляторов

Медицинская организация обрабатывает запросы пациентов через AI-агента. GDPR и 152-ФЗ требуют точно знать, какие данные были обработаны, кем и с какой целью. Без централизованного логирования compliance-офицер тратит 4 часа на сбор информации по одному инциденту.

LLM gateway решает эту задачу, записывая полный контекст каждого вызова:

• Субъект - идентификатор пользователя или агента.
• Временная метка с точностью до миллисекунды.
• Целевая модель и её версия.
• Полный промпт и полный ответ.
• Количество токенов и стоимость.
• Результаты проверки guardrails - какие правила сработали.

Логи хранятся в неизменяемом хранилище с retention policy, настроенной под требования регулятора (например, 18 месяцев для медицинских данных). При аудите офицер формирует отчёт за 15 минут вместо 4 часов - мы разбирали этот кейс в статье про системы управления знаниями в AI-эру.

Практика внедрения: управление секретами и контроль расходов

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

Безопасное хранение секретов: от .env к vault

Типичная картина: разработчик получает API-ключ от OpenAI, вставляет в .env-файл и коммитит в репозиторий. Через неделю ключ слит, потому что стажёр форкнул репо с историей коммитов. Компрометация одного ключа даёт злоумышленнику доступ к модели с биллингом на аккаунте компании.

LLM gateway меняет модель: реальные ключи хранятся только в шлюзе. Шлюз при старте получает их из HashiCorp Vault или облачного Secret Manager. Разработчики и агенты используют внутренние токены с ограниченным сроком жизни и scope. Ротация ключа провайдера происходит в одном месте и не требует изменений в коде агентов.

Схема взаимодействия: разработчик → внутренний токен (JWT, TTL 24h) → шлюз → реальный API-ключ → провайдер. При компрометации внутреннего токена его отзывают без влияния на продуктовые вызовы.

Маршрутизация моделей: платим меньше, не теряя в качестве

Не каждый запрос требует GPT-4. Маршрутизация на основе правил позволяет направить простые задачи на быстрые и дешёвые модели, а сложные - на мощные. Пример конфигурации шлюза на YAML:

routes:
  - name: cheap_summarization
    match:
      - intent: summarization
      - context_length_lt: 4096
    target:
      provider: together
      model: mistralai/Mixtral-8x7B-Instruct-v0.1
    
  - name: code_generation
    match:
      - intent: code_gen
    target:
      provider: openai
      model: gpt-4
      fallback: gpt-4o
    
  - name: default
    match:
      - any: true
    target:
      provider: anthropic
      model: claude-3-haiku

Правила можно комбинировать: intent определяется классификатором на входе шлюза, context_length - техническая метрика из запроса. При недоступности основной модели срабатывает fallback. Такой подход снижает среднюю стоимость запроса на 40–60% без заметной деградации качества. Мы детально разбирали архитектуру агентов и выбор моделей в статье про построение AI-агента с нуля.

Защита данных с помощью guardrails: настройка и примеры

Guardrails - набор правил, проверяющих входящие промпты и исходящие ответы. Они работают на трёх уровнях: статические (regex), семантические (ML-классификаторы) и контекстные (LLM-анализатор). Комбинация уровней даёт защиту от prompt injection, утечек PII и нежелательного контента.

Производительность - критический параметр. Regex-проверки выполняются за микросекунды, ML-классификаторы - за 5–15 мс, LLM-анализатор - до 50 мс. Суммарная задержка правильно спроектированной цепочки guardrails укладывается в 30–70 мс, что приемлемо для большинства enterprise-сценариев.

Примеры правил для типовых enterprise-сценариев

1. Блокировка запросов с внутренней документацией. Правило: если промпт содержит ключевые слова из списка конфиденциальных проектов, вызов блокируется, инцидент логируется. Реализация: regex + проверка по словарю.
2. Маскирование email в ответах. Правило: любой шаблон username@domain.tld заменяется на [EMAIL_REDACTED]. Применяется и к промптам, и к ответам.
3. Ограничение длины ответа. Правило: если ответ превышает 10 000 токенов, он обрезается. Предотвращает случайный дамп внутренних данных при ошибке модели.
4. Запрет опасных tool calls. Правило: если агент пытается вызвать функцию sql_execute с паттерном DROP или DELETE, вызов блокируется до выполнения. Реализация: перехват tool call на шлюзе и валидация аргументов.

Тема безопасности AI-агентов шире, чем guardrails. Мы разбирали векторы атак и стратегию защиты в статье про ИИ-агентов как новую внутреннюю угрозу - там есть данные отчёта Thales Group и реальные инциденты с OpenAI и DeepSeek.

Отказоустойчивость LLM gateway: чтобы governance не стал точкой отказа

Централизация управления через шлюз создаёт риск: если шлюз недоступен, агенты теряют возможность вызывать модели. Это неприемлемо для продуктовых систем. Решение - кластеризация и stateless-архитектура.

Типовая схема: несколько экземпляров шлюза за балансировщиком (NGINX, HAProxy, облачный LB). Каждый экземпляр получает конфигурацию из общего хранилища (etcd, Consul) и обрабатывает запросы независимо. Сессии не хранятся - любой инстанс может обслужить любой запрос.

Ключевые метрики правильно настроенного кластера:

• Доступность - 99.9% (8,7 часов простоя в год) при трёх экземплярах в разных зонах.
• Пропускная способность - линейно масштабируется с добавлением инстансов, типовое значение 5 000–10 000 запросов в секунду на узел.
• Latency P99 - дополнительные 50–100 мс к времени ответа модели.

Стратегия graceful degradation: при полной недоступности шлюза агенты переключаются на прямые вызовы API. Это рискованно - теряется контроль и аудит, - но продукт продолжает работать. Переключение должно быть явным действием, а не автоматическим, чтобы избежать случайного обхода политик.

Платформенный подход упрощает развёртывание отказоустойчивой инфраструктуры. В статье про платформенное внедрение GenAI мы разбирали, как единая платформа снимает проблему дублирования интеграций и обеспечивает управляемость из коробки.

Заключение: баланс между автономией агентов и контролем

Governance - не тормоз инноваций, а условие их масштабирования. Без контроля агенты остаются дорогими демо, с контролем - становятся продуктовыми инструментами.

Пошаговый план внедрения:

1. Месяц 1: Видимость. Разверните шлюз в режиме прозрачного прокси, соберите метрики по использованию и затратам. Настройте дашборды и алерты по бюджетам.
2. Месяц 2–3: Контроль. Подключите guardrails для PII и блокировки опасных вызовов. Переведите секреты в vault, выдайте разработчикам внутренние токены. Настройте маршрутизацию для оптимизации затрат.
3. Месяц 4–6: Аудит. Внедрите полное логирование с retention policy, настройте отчёты для compliance. Проведите нагрузочное тестирование и обеспечьте отказоустойчивость кластера.

Шлюз эволюционирует вместе с практиками использования AI в компании. Правила, которые работали при 100 запросах в день, пересматриваются при 10 000. Модели меняются, появляются новые векторы атак, регуляторы ужесточают требования. Governance - непрерывный процесс, а не разовая настройка.

Подписаться на канал