Se hai già investito in un AI gateway o nei Guardrails di un hyperscaler, la prima cosa onesta da dire è: conservali, Olivares AI non intende sostituirli. Il compito di un gateway è la chiamata al modello — instradarla, memorizzarla nella cache, bilanciarla, pianificarne il budget. Il compito dei Guardrails è la sicurezza dei contenuti su quella chiamata. Entrambi sono reali, entrambi fanno bene il loro lavoro, e nessuno dei due è ciò che Olivares è.
TL;DR: Olivares AI non è un AI gateway. Non instrada, non memorizza nella cache, non bilancia il carico e non si posiziona sulla rotta critica del traffico verso i modelli, e non lo farà mai. Si colloca accanto e dietro al tuo gateway come il piano di governance ed evidenza: enforcement in-process all’interno del runtime dell’agente, un registro di evidenza a prova di manomissione, ciclo di vita dell’identità non umana e human-in-the-loop / break-glass / kill-switch sulle sessioni attive. Il tuo gateway governa la richiesta; Olivares governa l’agente e tutto ciò che tocca, e lo dimostra a un auditor.
Cosa fanno bene un gateway e i Guardrails (usali per questo)
Si tratta di capacità consolidate e ben comprese, e i produttori le descrivono con chiarezza:
- Gli AI gateway sono gestori nel percorso delle richieste per le chiamate ai modelli. LiteLLM è un “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 consente di “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). Instradamento, fallback, cache, chiavi virtuali, budget per chiave, registrazione delle richieste — questa è la loro funzione.
- I Guardrails degli hyperscaler sono filtri di sicurezza dei contenuti. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications” che “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — filtri di contenuto, argomenti negati, filtri lessicali, redazione PII, verifiche di grounding contestuale e ragionamento automatizzato (AWS).
Se il tuo problema è “dare alle mie applicazioni un unico endpoint verso molti modelli, con budget, cache e filtraggio dei contenuti,” quello stack lo risolve e non hai bisogno di un control plane per farlo. Noi ci integriamo con quel pattern; non lo reimplementiamo.
La lacuna di governance che lasciano aperta
Un gateway vede una richiesta. I Guardrails vedono contenuti. Nessuno dei due vede l’agente — la sua identità nel tempo, ciò a cui ha acceduto nel tuo data plane, chi ha autorizzato un’azione rischiosa e se qualcosa di tutto ciò è dimostrabile in seguito. Questa è la lacuna che Olivares colma.
| Lacuna lasciata dal gateway / Guardrails | Perché è importante | Cosa fornisce Olivares AI |
|---|---|---|
| Enforcement nel runtime dell’agente | Un gateway applica le regole al confine della richiesta; non può fermare una tool-call locale di Claude Code che non lo attraversa mai | Un PEP deny-closed in-process nell’agente: gate di identità sicura, disposizione della policy, overlay di policy in tempo reale, tutto prima dell’esecuzione dello strumento |
| Evidenza a prova di manomissione | Il gateway e i Guardrails emettono log — registrazioni di richieste mutabili; un auditor vuole prove immutabili | Registro append-only, concatenato tramite hash, firmato con Ed25519, verificabile off-box, esportabile come evidenza OSCAL |
| Ciclo di vita dell’identità non umana | La “chiave virtuale” di un gateway è un contenitore di budget, non un’identità che viene approvvigionata, attribuita, ruotata e dismessa | Ciclo di vita NHI: obsolescenza → blocco, cascata di dismissione, doppio controllo sulla rotazione, legato alla mappa di accesso |
| Intervento sulla sessione attiva | Log e budget sono a posteriori; nessuno degli strumenti esaminati ferma una sessione in corso | Approvazioni HITL, break-glass e un kill switch che nega ogni azione governata fino alla riattivazione con doppio controllo |
| Ground truth su tutta l’infrastruttura | Un gateway vede solo le chiamate che lo attraversano; gli agenti accedono anche a DB, object store, MCP e file direttamente | La mappa di accesso read-first R/RW e la deriva Permitted-vs-Observed, corroborata con l’audit nativo |
| Sovranità | I gateway SaaS e i Guardrails cloud elaborano quel traffico nel loro cloud | Self-hosted / air-gapped; il data plane non esce mai dal tuo perimetro |
Nulla di questo riguarda funzionalità di instradamento. Questo è il punto: la lacuna non è un instradamento migliore, è governance che il percorso della richiesta non è mai stato progettato per fornire.
Sui Guardrails in particolare: la sicurezza dei contenuti è un hook, non un concorrente
Bedrock Guardrails può essere applicato in due modi — inline durante una
chiamata di inferenza su Bedrock, o “directly through the ApplyGuardrail
API without invoking the foundation models”, che funziona “with any
foundation model whether hosted on Amazon Bedrock or self-hosted models”
(AWS). Questo è genuinamente
utile, e Olivares tratta la sicurezza dei contenuti come un rilevatore che si
inserisce, mai come un muro che chiediamo di scegliere al posto dei
Guardrails. Due fatti onesti e distinti:
- Il proxy di inferenza inline espone una giuntura di ispezione dei contenuti — un punto collegabile dove un rilevatore di contenuti / DLP restituisce un verdetto su cui agisce il decisore deny-closed. La sicurezza dei contenuti appartiene lì, nella pipeline, anziché essere reimplementata come un filtro concorrente.
- Olivares legge le decisioni proprie dei tuoi Guardrails in modalità
read-first. Il connettore AWS acquisisce le decisioni dei guardrail di
Bedrock dai loro log CloudWatch / S3 come postura ed evidenza; deliberatamente
non invoca il runtime a pagamento
ApplyGuardraildirettamente. I tuoi verdetti sui contenuti diventano parte del registro a prova di manomissione.
Così la sicurezza dei contenuti si compone con ciò che già utilizzi. Ciò che i Guardrails non documentano — e dove la lacuna di governance resta aperta — è il resto della vita dell’agente: le pagine di Bedrock non documentano identità dell’agente, gestione delle sessioni, approvazioni umane né governance dei costi (non documentato in quelle pagine, verificato il 21-06-2026). Olivares è esattamente quel complemento: gestisce l’identità, i controlli di sessione, le approvazioni e l’evidenza; il filtro dei contenuti resta dove già risiede.
Come si compongono
Una configurazione sana mantiene ogni strumento nel suo ambito:
- Conserva il tuo gateway (LiteLLM / Portkey / Kong / Cloudflare) come il piano delle chiamate ai modelli — instradamento, cache, chiavi virtuali, budget sulla richiesta.
- Conserva i tuoi Guardrails (Bedrock / Azure Content Safety) come il tuo
rilevatore di sicurezza dei contenuti — il PEP di Olivares esegue un
rilevatore collegabile nella sua giuntura di ispezione dei contenuti e legge le
decisioni proprie dei tuoi Guardrails in modalità read-first come evidenza; non
invoca
ApplyGuardraildirettamente. - Aggiungi Olivares accanto a essi come piano di governance ed evidenza: il PEP in-process sugli agenti che non passano mai per il tuo gateway, la mappa di accesso su tutta l’infrastruttura, il registro a prova di manomissione e i controlli HITL/break-glass/kill in tempo reale.
L’unico punto in cui Olivares tocca l’inferenza è ristretto ed esplicito — un
percorso di gateway solo con API key per i chiamanti SDK diretti o curl,
descritto in
Governing subscription-authed agents.
Esiste per governare traffico che i tuoi altri strumenti non possono
raggiungere, mai per competere con essi sull’instradamento, e non trasporta
mai una credenziale di abbonamento.
Quando il tuo gateway è sufficiente
L’onestà funziona in entrambe le direzioni. Se i tuoi agenti chiamano modelli solo attraverso il tuo gateway, le tue esigenze di sicurezza dei contenuti sono coperte dai Guardrails, non hai agenti self-hosted né su laptop che accedono a database / object store / MCP direttamente, e non hai requisiti di sovranità né di evidenza a prova di manomissione — allora il tuo gateway con i suoi log e i Guardrails possono essere tutto ciò di cui hai bisogno, e non dovresti aggiungere un control plane per il solo gusto di averlo.
Olivares guadagna il suo posto quando le domande diventano trasversali all’infrastruttura e avversariali: quali agenti esistono e a cosa ha realmente acceduto ciascuno, posso fermare un’azione dannosa deny-closed nell’agente, chi ha autorizzato quella rischiosa, e posso consegnare a un auditor prove immutabili — il tutto senza inviare quell’immagine al cloud di qualcun altro. Per il trattamento approfondito di due comparazioni adiacenti, consulta vs AI control towers e vs LLM observability.