Uno stack self-hosted comune e sensato abbina un LLM gateway (ad esempio LiteLLM) con una piattaforma di osservabilità LLM (ad esempio Langfuse). Se ne possiedi già uno, è ragionevole chiedersi se serve un control plane. Questa pagina risponde con onestà — inclusi i casi in cui la risposta è no.
TL;DR: LiteLLM e Langfuse si occupano delle chiamate ai modelli effettuate dalla tua applicazione: instradarle, tracciarle, gestire i prompt, contabilizzare il costo per chiamata. Olivares AI si occupa di ogni agente del tuo parco e di tutto ciò che legge o scrive — database, object store, server MCP, strumenti, file — e se ciò corrisponde a quanto la policy consente. Altitudine differente. Si compongono; acquisiamo lo stesso segnale OpenTelemetry gen-ai che essi emettono e consumano.
Cosa fa bene quello stack (usalo per questo)
- LiteLLM — un gateway unificato e compatibile con OpenAI davanti a molteplici provider: instradamento, fallback, retry, chiavi virtuali, budget e rate limit per chiave, e contabilizzazione dei costi delle chiamate ai modelli che lo attraversano.
- Langfuse — ingegneria e osservabilità LLM: trace di richiesta/risposta, gestione e versionamento dei prompt, valutazioni, dataset e un’interfaccia orientata agli sviluppatori per il debug delle catene.
Se il problema è “strumentare le chiamate LLM della mia applicazione, fare debug dei prompt e gestire l’accesso ai modelli da un unico endpoint,” questo stack è eccellente e self-hostable. Non serve un control plane per questo, e non pretendiamo il contrario.
Dove Olivares AI è strutturalmente differente
| Dimensione | LLM gateway + osservabilità | Olivares AI |
|---|---|---|
| Unità di interesse | Una chiamata al modello (prompt → completion) | Un agente e ogni risorsa che legge/scrive — DB, object store, MCP, strumenti, file |
| Punto di osservazione | Nel percorso della richiesta (proxy/SDK); vede ciò che l’applicazione invia | Fuori banda, read-first; osserva telemetria, audit nativo e un backstop a livello di kernel — mai nel percorso dei dati |
| Fonte di verità | Ciò che l’applicazione/proxy riporta | Telemetria auto-riportata corroborata con il registro proprio del sistema — pgAudit (lettura vs scrittura), CloudTrail (accesso agli oggetti), backstop eBPF |
| La domanda chiave | ”Cosa ha fatto questo prompt e quanto è costato?" | "Questo agente sta utilizzando accessi che nessuno gli ha concesso?” — Deriva tra Permitted e Observed |
| Enforcement | Il gateway può bloccare chiamate ai modelli (chiavi, budget) | Gate deny-closed su azioni e accesso alle risorse: approvazioni, il Claude Code hooks PEP, gating degli strumenti MCP, kill switch |
| Artefatto di audit | Trace / log per il debug | Ledger append-only, concatenato tramite hash, firmato con Ed25519, verificabile off-box, esportabile come pacchetti di evidenza OSCAL |
| Postura di deployment | Self-hostable | Self-hosted o air-gapped; il data plane non esce mai dal perimetro; AGPL, source-available |
La differenza di fondo è la fonte di verità. Una trace di osservabilità indica ciò che l’applicazione ha dichiarato di aver fatto. Non può rivelare che un agente ha acceduto a una tabella mai menzionata dalla trace. Olivares AI incrocia il segnale cooperativo con il data plane, cosicché “ciò che l’agente ha toccato” è un fatto corroborato, non un auto-report.
È “e”, non “o” — acquisiamo la tua telemetria
Olivares AI non è un sostituto del gateway né dello strumento di tracing, e non intende occupare il percorso della richiesta che essi occupano. Consuma lo stesso segnale: il control plane acquisisce span delle convenzioni semantiche OpenTelemetry GenAI, la stessa telemetria gen-ai che questi strumenti emettono e consumano. Pertanto una configurazione sana è:
- Mantenere LiteLLM come gateway dei modelli e Langfuse per il tracing orientato agli sviluppatori e il lavoro sui prompt.
- Indirizzare il flusso OTel gen-ai verso Olivares AI come fonte di corroborazione, e lasciare che la mappa di accesso, il rilevamento della deriva e il ledger forniscano il livello di governance a scala dell’intero parco.
Quando non dovresti ricorrere a Olivares AI
L’onestà funziona in entrambe le direzioni. Probabilmente non hai bisogno di questo control plane se:
- L’unico obiettivo è tracciare e fare debug delle chiamate LLM in una o due applicazioni, con un playground per i prompt — Langfuse da solo è una scelta più adeguata.
- Serve solo un gateway multi-provider con budget e failover — questo è il compito di LiteLLM, e noi ci integriamo con quel pattern anziché reimplementarlo.
- Non si ha un parco da governare: un singolo servizio, un singolo modello, nessun agente che accede a database/object store/MCP, e nessun obbligo regolamentare o di audit.
Olivares AI si giustifica quando le domande diventano a scala di parco e avversariali: quali agenti esistono, cosa può realmente raggiungere ciascuno, dove l’accesso sta deviando dalla policy, è possibile dimostrarlo a un auditor, e si può fermare un’azione dannosa deny-closed — il tutto senza inviare quell’immagine al cloud di qualcun altro.