LLM Gateway для бизнеса: не прокси, а контрольная плоскость

Пилот корпоративного ИИ часто начинается с одного API-ключа в переменной окружения. Через полгода ключ живёт в пяти сервисах, отдел безопасности не знает, какие данные уходят наружу, финансы видят только общий счёт, а команда боится сменить модель, потому что никто не понимает последствия.

В этот момент компании нужен не ещё один SDK. Ей нужна контрольная плоскость для AI-трафика.

Yandex B2B Tech анонсировала универсального бизнес-агента, способного работать с CRM, базами знаний и документооборотом. В официальном описании особенно важны не проценты автоматизации, а три механизма: ограничение доступа к внутренним системам, подтверждение важных действий человеком и возможность восстановить всю цепочку решений агента.

Именно вокруг этих требований следует проектировать корпоративный LLM Gateway.

Почему обычного reverse proxy недостаточно

Технически Gateway принимает OpenAI-compatible запрос и отправляет его провайдеру. Но бизнесу важен не только маршрут пакета. Нужно ответить:

· какое приложение и какой сотрудник инициировали запрос;

· какой класс данных попал в Prompt;

· почему выбрана конкретная модель и регион обработки;

· какие инструменты были вызваны;

· сколько стоила вся цепочка, включая повторы;

· какая политика разрешила или заблокировала действие;

· можно ли воспроизвести событие при расследовании.

Корпоративный Gateway — место, где запрос превращается из HTTP-вызова в управляемую бизнес-операцию.

Три AI-сценария, три профиля риска

Данные нужно классифицировать до вызова модели

Фраза «мы не отправляем чувствительные данные» бесполезна без машинного правила. Gateway должен получать Data Class вместе с запросом или вычислять его до маршрутизации:

PUBLIC       → разрешённые внешние модели
INTERNAL     → провайдеры с корпоративным договором
CONFIDENTIAL → утверждённый регион, no-retention, DLP
RESTRICTED   → локальная модель или запрет генерации

DLP после ответа слишком поздний: Prompt уже покинул систему. Секреты, номера документов и персональные данные редактируются до отправки. При этом Audit хранит факт редактирования, но не обязан дублировать само чувствительное значение.

Identity должна пройти через всю цепочку

Общий API-ключ уничтожает контекст ответственности. Корпоративный запрос должен сохранять идентичность пользователя, приложения, подразделения и Service Account.

Если сотрудник не имеет доступа к договору в корпоративном хранилище, Agent не должен получить его через Tool. Если у пользователя есть право читать CRM, это ещё не означает право экспортировать её содержимое в модель.

Хорошая схема разделяет:

· Authentication: кто делает запрос;

· Authorization: какие источники и инструменты ему доступны;

· Model policy: каким моделям разрешён этот класс данных;

· Action policy: какие изменения Agent может выполнить;

· Approval: какие редкие операции требуют человека.

Audit — это не сохранённый чат

В описании бизнес-агента Yandex B2B Tech компании могут проверять цепочку решений, использованные инструменты и обращения к внутренним системам. Для расследования этого всё равно недостаточно без технического контекста.

Полезный Trace связывает Request ID, пользователя, версию политики, модель, System Prompt, вызовы Tool, источники Retrieval, Token, задержку, повторные попытки и итоговое действие. Доступ к самому содержимому Trace должен быть ограничен: журнал безопасности легко превращается во вторую базу чувствительных данных.

Бюджет — часть безопасности

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

Лимиты задаются не только в Token:

· максимальная стоимость одной задачи и подразделения за день;

· число Tool Calls и внешних адресатов;

· глубина агентного цикла;

· объём данных, извлечённых из источников;

· время выполнения и число повторов;

· число необратимых операций.

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

Fallback: доступность без обхода политики

Типичная ошибка — при сбое основной модели отправить запрос любому доступному провайдеру. Так Availability незаметно обходит Data Residency, no-retention или требования к Tool Calling.

Резерв выбирается только из того же Policy Class. Для CONFIDENTIAL-запроса отсутствие допустимой модели означает контролируемый отказ, а не расширение списка получателей.

Как выглядит минимальная политика

policy: security_incident_summary
data_class: confidential
models: [approved_reasoning_primary, approved_reasoning_backup]
redaction: [credentials, personal_data]
tools:
  read: [siem_events, asset_inventory]
  write: []
limits:
  max_cost_usd: 0.40
  max_tool_calls: 12
  max_runtime_seconds: 90
output:
  schema: incident_summary_v2
  require_citations: true
  human_approval: true

Конкретный формат вторичен. Важно, что политика версионируется отдельно от Prompt и проверяется до исполнения.

Единый интерфейс моделей — только начало

OdiRouter.ai и другие OpenAI-compatible gateways помогают централизовать доступ к моделям, маршрутизацию и учёт. Для компании это удобная точка, на которой можно строить Policy Engine, бюджеты и Fallback без интеграции отдельного SDK в каждый сервис.

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

Что проверять перед production

1. Может ли приложение вызвать модель напрямую в обход Gateway?

2. Что происходит, если Prompt содержит API-ключ или персональные данные?

3. Сохраняется ли Identity после нескольких Tool Calls?

4. Не нарушает ли Fallback требования к данным?

5. Можно ли восстановить решение по Request ID?

6. Кто имеет доступ к Prompt и Trace?

7. Остановится ли Agent при исчерпании бюджета?

8. Есть ли Eval для новой версии модели до переключения трафика?

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

LLM Gateway становится полезным, когда перестаёт быть переходником между форматами. Его задача — провести Identity, применить политику данных, ограничить стоимость, сохранить Trace и не позволить отказоустойчивости отменить безопасность.