Если вы уже инвестировали в AI gateway или в Guardrails гиперскейлера, первое, что стоит сказать честно: оставьте их — Olivares AI не пытается их заменить. Задача gateway — вызов модели: маршрутизировать, кешировать, балансировать, бюджетировать. Задача Guardrails — безопасность контента в этом вызове. Оба реальны, оба хорошо делают своё дело, и ни один из них не является тем, что представляет собой Olivares.
TL;DR: Olivares AI — это не AI gateway. Он не маршрутизирует, не кеширует, не балансирует нагрузку и не находится на горячем пути вашего модельного трафика, и никогда не будет. Он располагается рядом и позади вашего gateway как плоскость управления и evidence: enforcement в процессе внутри runtime агента, tamper-evident evidence ledger, жизненный цикл non-human identity и human-in-the-loop / break-glass / kill-switch над активными сессиями. Ваш gateway управляет запросом; Olivares управляет агентом и всем, к чему он обращается, и доказывает это аудитору.
Что gateway и Guardrails делают хорошо (используйте их для этого)
Это устоявшиеся, хорошо понятные возможности, и вендоры описывают их ясно:
- AI gateways — это менеджеры пути запроса для вызовов моделей. LiteLLM — это “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); Cloudflare AI Gateway позволяет “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); Portkey “records real-time API requests, including cost” (Portkey). Маршрутизация, fallbacks, кеширование, виртуальные ключи, бюджеты на ключ, логирование запросов — это их область.
- Guardrails гиперскейлеров — это фильтры безопасности контента. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications”, которые “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — фильтры контента, запрещённые темы, фильтры слов, редактирование PII, проверки contextual grounding и automated reasoning (AWS).
Если ваша задача — «дать моим приложениям один endpoint ко многим моделям, с бюджетами, кешированием и фильтрацией контента», этот стек её решает, и вам не нужен control plane для этого. Мы интегрируемся с этим паттерном; мы не переимплементируем его.
Пробел в управлении, который они оставляют
Gateway видит запрос. Guardrails видят контент. Ни один из них не видит агента — его identity во времени, к чему он обращался в вашем data plane, кто одобрил рискованное действие и можно ли это доказать потом. Это тот пробел, который закрывает Olivares.
| Пробел, который оставляет gateway / Guardrails | Почему это важно | Что даёт Olivares AI |
|---|---|---|
| Enforcement в runtime агента | Gateway применяет правила на границе запроса; он не может остановить локальный tool-call Claude Code, который его не проходит | Deny-closed PEP в процессе в агенте: шлюз твёрдой identity, policy disposition, overlay живой политики — всё до запуска инструмента |
| Tamper-evident evidence | Gateway и Guardrails генерируют логи — мутабельные записи запросов; аудитору нужны неизменяемые доказательства | Append-only, hash-chained, Ed25519-signed ledger, верифицируемый off-box, экспортируемый как OSCAL evidence |
| Жизненный цикл non-human identity | «Виртуальный ключ» gateway — это бюджетная корзина, а не identity, которая provisioning, attribution, rotation и offboarding | Жизненный цикл NHI: устаревание → блокировка, каскад offboarding, dual-control при rotation, привязка к access map |
| Вмешательство в активную сессию | Логи и бюджеты — это постфактум; ни один из рассмотренных инструментов не останавливает сессию на лету | HITL-одобрения, break-glass и kill switch, который запрещает все управляемые действия до dual-control re-enable |
| Ground truth по всей инфраструктуре | Gateway видит только вызовы, проходящие через него; агенты также обращаются к БД, object stores, MCP, файлам напрямую | Read-first R/RW access map и drift Permitted-vs-Observed, подтверждённый native audit |
| Суверенитет | SaaS gateways и облачные Guardrails обрабатывают этот трафик в своём облаке | Self-hosted / air-gapped; data plane никогда не покидает ваш периметр |
Ничто из этого не является функцией маршрутизации. В этом и суть: пробел — это не лучшая маршрутизация, это управление, которое путь запроса никогда не был предназначен обеспечивать.
О Guardrails конкретно: безопасность контента — это hook, а не конкурент
Bedrock Guardrails может применяться двумя способами — inline во время вызова
inference в Bedrock, или “directly through the ApplyGuardrail API without
invoking the foundation models”, что работает “with any foundation model
whether hosted on Amazon Bedrock or self-hosted models”
(AWS). Это действительно полезно,
и Olivares рассматривает безопасность контента как детектор, который вы
подключаете, а не стену, которую мы просим выбрать вместо Guardrails. Два
честных и отдельных факта:
- Inline inference proxy предоставляет шов инспекции контента — подключаемую точку, где детектор контента / DLP возвращает вердикт, по которому действует deny-closed decider. Безопасность контента принадлежит туда, в pipeline, а не реимплементируется как конкурирующий фильтр.
- Olivares читает собственные решения ваших Guardrails в режиме read-first.
AWS-коннектор принимает решения Bedrock guardrails из их логов
CloudWatch / S3 как posture и evidence; он намеренно не вызывает платный
runtime
ApplyGuardrailсамостоятельно. Ваши вердикты по контенту становятся частью tamper-evident record.
Таким образом, безопасность контента компонуется с тем, что вы уже используете. Чего Guardrails не документируют — и где пробел управления остаётся открытым — это остальная часть жизни агента: страницы Bedrock не документируют identity агента, управление сессиями, человеческие одобрения и управление стоимостью (не документировано на этих страницах, проверено 2026-06-21). Olivares — это именно тот дополнительный компонент: он несёт identity, контроли сессий, одобрения и evidence; фильтр контента остаётся там, где он уже живёт.
Как они компонуются
Здоровая конфигурация оставляет каждый инструмент в своей полосе:
- Оставьте ваш gateway (LiteLLM / Portkey / Kong / Cloudflare) как плоскость вызовов моделей — маршрутизация, кеширование, виртуальные ключи, бюджеты на запросе.
- Оставьте ваши Guardrails (Bedrock / Azure Content Safety) как детектор
безопасности контента — PEP Olivares запускает подключаемый детектор в своём
шве инспекции контента и читает собственные решения ваших Guardrails в режиме
read-first как evidence; он не вызывает
ApplyGuardrailсамостоятельно. - Добавьте Olivares рядом как плоскость управления и evidence: PEP в процессе на агентах, которые никогда не проходят через ваш gateway, access map по всей инфраструктуре, tamper-evident ledger и live-контроли HITL/break-glass/kill.
Единственное место, где Olivares касается inference, узкое и явное — путь
gateway только с API key для прямых вызовов SDK/curl, описанный в
Управление агентами с аутентификацией по подписке.
Он существует для управления трафиком, который ваши другие инструменты не могут
охватить, никогда — для конкуренции с ними в маршрутизации, и он никогда не
переносит credential подписки.
Когда вашего gateway достаточно
Честность работает в обе стороны. Если ваши агенты вызывают модели только через ваш gateway, ваши потребности в безопасности контента покрыты Guardrails, у вас нет self-hosted или работающих на ноутбуках агентов, обращающихся к базам данных / object stores / MCP напрямую, и у вас нет требований к суверенитету или tamper-evident evidence — тогда вашего gateway вместе с его логами и Guardrails может быть достаточно, и вам не стоит добавлять control plane ради самого control plane.
Olivares оправдывает своё место, когда вопросы становятся инфраструктурно-масштабными и состязательными: какие агенты существуют и к чему каждый из них реально обращался, могу ли я остановить плохое действие deny-closed в агенте, кто одобрил рискованное, и могу ли я передать аудитору неизменяемое доказательство — всё без отправки этой картины в чужое облако. Для более глубокого рассмотрения двух смежных сравнений см. vs AI control towers и vs LLM observability.