Якщо ви вже інвестували в AI gateway або в Guardrails гіперскейлера, перше, що чесно слід сказати: залишайте їх, Olivares AI не намагається їх замінити. Завдання gateway — виклик до моделі: маршрутизувати, кешувати, балансувати, бюджетувати. Завдання Guardrails — безпека контенту під час цього виклику. Обидва рішення реальні, обидва добре виконують свою роботу, і жодне з них не є тим, чим є Olivares.
TL;DR: Olivares AI — це не AI gateway. Він не маршрутизує, не кешує, не балансує навантаження і не перебуває на гарячому шляху вашого трафіку до моделей, і ніколи не буде. Він розташований поряд і позаду вашого gateway як площина управління та доказів: enforcement у процесі всередині runtime агента, реєстр доказів, захищений від підробки, життєвий цикл нелюдської ідентичності та 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, перевірки контекстуального grounding та автоматизованого reasoning (AWS).
Якщо ваша проблема — «надати моїм додаткам єдину точку входу до багатьох моделей із бюджетами, кешуванням і фільтрацією контенту», цей стек її вирішує, і вам не потрібна площина управління для цього. Ми інтегруємося з цим паттерном, а не реімплементуємо його.
Прогалина в управлінні, яку вони залишають відкритою
Gateway бачить запит. Guardrails бачать контент. Жоден не бачить агента — його ідентичність у часі, до чого він отримав доступ у вашій площині даних, хто авторизував ризикову дію, і чи можна будь-що з цього довести пізніше. Це і є прогалина, яку Olivares закриває.
| Прогалина, яку залишає gateway / Guardrails | Чому це важливо | Що забезпечує Olivares AI |
|---|---|---|
| Enforcement у runtime агента | Gateway забезпечує правила на межі запиту; він не може зупинити локальний tool-call Claude Code, який ніколи через нього не проходить | Deny-closed PEP у процесі на агенті: перевірка firm-identity, диспозиція політики, live-policy overlay — все до виконання інструменту |
| Доказова база, захищена від підробки | Gateway і Guardrails генерують логи — змінювані записи запитів; аудитору потрібні незмінні докази | Append-only реєстр із хеш-ланцюжком, підписаний Ed25519, верифікований off-box, експортований як OSCAL evidence |
| Життєвий цикл нелюдської ідентичності | «Віртуальний ключ» gateway — це бюджетний кошик, а не ідентичність, яка створюється, атрибутується, ротується та виводиться | Життєвий цикл NHI: застарілість → блокування, каскад виведення, dual-control при ротації, прив’язаний до карти доступу |
| Втручання в активну сесію | Логи та бюджети фіксують факти постфактум; жоден із цих інструментів не зупиняє сесію в реальному часі | Затвердження HITL, break-glass та kill switch, що блокує всю керовану актуацію до повторного ввімкнення з dual-control |
| Ground truth по всій інфраструктурі | Gateway бачить лише виклики, що проходять через нього; агенти також звертаються до БД, об’єктних сховищ, MCP та файлів напряму | Read-first R/RW карта доступу та дрифт Permitted-vs-Observed, підтверджений нативним аудитом |
| Суверенітет | SaaS-gateways і хмарні Guardrails обробляють цей трафік у своїй хмарі | Self-hosted / air-gapped; площина даних ніколи не залишає ваш периметр |
Нічого з цього не є функціями маршрутизації. Саме в цьому суть: прогалина — це не краща маршрутизація, це управління, яке шлях запиту ніколи не був призначений забезпечувати.
Щодо 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 не документують ідентичність агента, управління сесіями, людські затвердження та управління витратами (не документовано на цих сторінках, перевірено 21-06-2026). 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.