Якщо ви вже інвестували в AI gateway або в Guardrails гіперскейлера, перше, що чесно слід сказати: залишайте їх, Olivares AI не намагається їх замінити. Завдання gateway — виклик до моделі: маршрутизувати, кешувати, балансувати, бюджетувати. Завдання Guardrails — безпека контенту під час цього виклику. Обидва рішення реальні, обидва добре виконують свою роботу, і жодне з них не є тим, чим є Olivares.
TL;DR: Olivares AI не є загальним AI-шлюзом: він не кешує й не балансує трафік моделей і не заявляє жодної універсальної матриці постачальників, моделей чи маршрутизації. Він розв’язує політики маршрутизації в упорядкований ланцюг резервних варіантів і має один виміряний шлях виконання — deny-closed, що діє лише через налаштований вами клієнт, сумісний із Claude Messages, напряму або з ендпоінтом вашого шлюзу як базовою URL Messages. Поза цим шляхом це площина врядування та доказів: внутрішньопроцесне застосування в середовищі агента, захищений від підробки журнал, життєвий цикл нелюдських ідентичностей і human-in-the-loop / break-glass / kill-switch над активними сесіями. Він доповнює шлюз, який ви вже використовуєте, а не замінює його.
Що 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, перевірки контекстуального grounding та автоматизованого reasoning (AWS).
Якщо ваша проблема — «надати моїм додаткам єдину точку входу до багатьох моделей із бюджетами, кешуванням і фільтрацією контенту», цей стек її вирішує, і вам не потрібна площина управління для цього. Ми інтегруємося з цим паттерном, а не реімплементуємо його.
Що кожен продукт документує сьогодні
Прочитано 2026-09-12 на власних сторінках постачальників. Це межі прочитаних сторінок, а не твердження про продукт загалом, і жоден рядок не є рейтингом.
| Продукт | Документована поверхня для агентів | Чого сторінка не охоплює |
|---|---|---|
| LiteLLM | У документації проксі є розділ “Agent & MCP Gateway”, а також Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | Прочитана сторінка документує поверхню проксі; застосування правил усередині середовища агента, яке його не проходить, лишається поза нею |
| Portkey | У переліку продуктів зазначено Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | Прочитана сторінка — огляд можливостей; вона не описує карту доступу «дозволено проти спостережуваного» по всьому парку |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | Прочитана сторінка — огляд продукту; самостійне розміщення чи ізольована експлуатація цього рівня там не описані |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, застосовні вбудовано або “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Це сторінки про безпеку контенту; життєвий цикл ідентичності агента, втручання в сесію та погодження не є їхньою темою і там не документовані |
Тому попереднє формулювання було хибним. «Шлюзи не бачать агента» не витримує перевірки наведеними сторінками: LiteLLM і Portkey документують поверхні для агентів і MCP, а Cloudflare називає свій шлюз площиною керування. Різниться те, де застосовуються правила і якого роду запис виходить, — це порівняння архітектур, а не твердження про відсутність.
У чому архітектури досі різняться
Умовно, а не універсально: кожен рядок чинний, коли виконується умова ліворуч.
| Якщо ваші агенти… | Тоді продукт на шляху запиту | Тоді Olivares AI |
|---|---|---|
| …звертаються до моделей лише через проксі | керує кожним викликом, який бачить, на рівні запиту | мало що додає на самому шляху запиту |
| …також працюють локально і звертаються напряму до БД, об’єктних сховищ, MCP або файлів | не бачить викликів, які його не проходять | застосовує deny-closed усередині процесу на агенті, до запуску інструмента |
| …потребують запису, який аудитор перевірить поза системою | видають логи запитів — змінювані записи | журнал лише на додавання, зчеплений хешем, підписаний Ed25519, перевірний поза системою |
| …мають зупинятися посеред сесії | це не місце, де зупиняють активну сесію | погодження HITL, break-glass і kill switch з повторним увімкненням за подвійним контролем |
| …мають бути ідентифіковані впродовж усього життя | virtual key — це бюджетний кошик | життєвий цикл нелюдських ідентичностей: блокування за застарінням, каскад відключення, ротація за подвійним контролем |
| …мають лишатися всередині вашого периметра | SaaS-площини обробляють цей трафік у своїй хмарі | самостійне розміщення або ізоляція; площина даних не залишає ваш периметр |
Шлях виконання Olivares та його реальні межі
Olivares справді торкається інференсу — в одному виміряному місці, і чесний опис той, який несе його власне поточне вимірювання:
- Маршрут
POST /routing-policies/{id}/executedeny-closed за побудовою і діє лише через клієнт, сумісний із Claude Messages, напряму або з розв’язаним ендпоінтом шлюзу як базовою URL Messages — тобто ваш наявний шлюз може бути цим ендпоінтом. - Розв’язання політик створює упорядкований ланцюг резервних варіантів. Модуль завжди розв’язує маршрут і діє лише через порт виконавця; виконавець за замовчуванням не під’єднаний, тож маршрутизація розв’язується без жодного виклику постачальника, доки оператор його не складе.
- Два deny-closed шлюзи області та стоп-шлюз kill-switch виконуються перед бюджетним шлюзом FinOps, який виконується перед виконавцем.
І чого він явно не встановлює, словами того самого запису:
- жодної універсальної матриці постачальників чи моделей — протокол Claude Messages встановлює один налаштований маршрут, а не матрицю;
- жодного централізованого зберігання ключів — поля ключів постачальника є посиланнями;
- жодного виконання з консолі — консоль розв’язує та перевіряє політики і не має виклику виконання.
Це вимірювання поточних джерел, а не прийняття можливості: чинний запис claims тримає цю та всі інші можливості як реалізовані й неприйняті, без жодної квитанції про виконання. Читайте це як форму шляху, а не як сертифіковану функцію.
Щодо Guardrails конкретно: безпека контенту — це hook, а не конкурент
Bedrock Guardrails можна застосувати двома способами — inline під час виклику
інференсу в 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
як дані про стан та доказову базу; він навмисно не викликає платний
runtime
ApplyGuardrailсамостійно. Ваші вердикти щодо контенту стають частиною реєстру, захищеного від підробки.
Таким чином, безпека контенту компонується з тим, що ви вже використовуєте. Те, чого Guardrails не документують — і де прогалина в управлінні залишається відкритою — це решта життєвого циклу агента: сторінки Bedrock не документують ідентичність агента, управління сесіями, людські затвердження та управління витратами (не документовано на цих сторінках, перевірено 2026-09-12). Olivares — це саме той доповнювальний елемент: він забезпечує ідентичність, контроль сесій, затвердження та доказову базу; фільтр контенту залишається там, де він уже працює.
Як вони компонуються
Здорова архітектура тримає кожен інструмент у своїй зоні відповідальності:
- Залишайте ваш gateway (LiteLLM / Portkey / Kong / Cloudflare) як площину викликів до моделей — маршрутизація, кешування, віртуальні ключі, бюджети на запит.
- Залишайте ваші Guardrails (Bedrock / Azure Content Safety) як ваш
детектор безпеки контенту — PEP Olivares запускає підключуваний детектор у
своєму шві інспекції контенту і зчитує власні рішення ваших Guardrails у
режимі read-first як доказову базу; він не викликає
ApplyGuardrailсамостійно. - Додайте Olivares поряд із ними як площину управління та доказів: PEP у процесі на агентах, які ніколи не проходять через ваш gateway, карта доступу по всій інфраструктурі, реєстр, захищений від підробки, та live HITL/break-glass/kill контроль.
Єдине місце, де Olivares торкається інференсу, є вузьким і явним — шлях
gateway тільки з API key для викликів через SDK або curl, описаний у
Governing subscription-authed agents.
Він існує для управління трафіком, який ваші інші інструменти не можуть
охопити, ніколи для конкуренції з ними в маршрутизації, і ніколи не
транспортує облікові дані підписки.
Коли вашого gateway достатньо
Чесність працює в обидва боки. Якщо ваші агенти викликають моделі тільки через ваш gateway, ваші потреби в безпеці контенту задоволені Guardrails, у вас немає self-hosted агентів або агентів на ноутбуках, які звертаються до баз даних / об’єктних сховищ / MCP напряму, і у вас немає вимог до суверенітету чи доказової бази, захищеної від підробки — тоді ваш gateway із його логами та Guardrails може бути всім, що вам потрібно, і вам не варто додавати площину управління заради самого факту її наявності.
Olivares здобуває своє місце, коли питання стають інфраструктурними та адверсаріальними: які агенти існують і до чого кожен реально мав доступ, чи можу я зупинити негативну дію deny-closed на агенті, хто авторизував ризикову, і чи можу я надати аудитору незмінні докази — все це без надсилання цієї картини в чужу хмару. Для поглибленого розгляду двох суміжних порівнянь дивіться vs AI control towers та vs LLM observability.