Um stack self-hosted habitual e sensato combina um LLM gateway (por exemplo LiteLLM) com uma plataforma de observabilidade LLM (por exemplo Langfuse). Se já se dispõe de um, é razoável questionar se é necessário um control plane. Esta página responde a essa questão com honestidade — incluindo os casos em que a resposta é não.
TL;DR: LiteLLM e Langfuse tratam das chamadas a modelos que a aplicação faz: encaminhá-las, rastreá-las, gerir prompts, contabilizar o custo por chamada. Olivares AI trata de cada agente no parque e de tudo o que lê ou escreve — bases de dados, object stores, servidores MCP, ferramentas, ficheiros — e de verificar se isso corresponde ao que a política permite. Altitude diferente. Complementam-se; ingerimos o mesmo sinal OpenTelemetry gen-ai que eles emitem e consomem.
O que esse stack faz bem (utilize-o para isto)
- LiteLLM — um gateway unificado e compatível com OpenAI à frente de múltiplos fornecedores: encaminhamento, fallbacks, retentativas, chaves virtuais, orçamentos e rate limits por chave, e contabilização de custos das chamadas a modelos que passam por ele.
- Langfuse — engenharia e observabilidade LLM: traces de pedido/resposta, gestão e versionamento de prompts, avaliações, datasets e uma interface orientada a programadores para depuração de cadeias.
Se o problema é «instrumentar as chamadas LLM da minha aplicação, depurar prompts e gerir o acesso a modelos a partir de um único endpoint», este stack é excelente e self-hostable. Não é necessário um control plane para isso, e não se pretende afirmar o contrário.
Onde o Olivares AI é estruturalmente diferente
| Dimensão | LLM gateway + observabilidade | Olivares AI |
|---|---|---|
| Unidade de interesse | Uma chamada a modelo (prompt → completion) | Um agente e cada recurso que lê/escreve — BDs, object stores, MCP, ferramentas, ficheiros |
| Ponto de observação | Na rota do pedido (proxy/SDK); vê o que a aplicação envia | Fora de banda, read-first; observa telemetria, auditoria nativa e um backstop ao nível do kernel — nunca na rota de dados |
| Fonte de verdade | O que a aplicação/proxy reporta | Telemetria auto-reportada corroborada contra o próprio registo do sistema — pgAudit (leitura vs escrita), CloudTrail (acesso a objetos), backstop eBPF |
| A pergunta-chave | «O que fez este prompt e quanto custou?» | «Este agente está a utilizar acessos que ninguém lhe concedeu?» — Deriva entre o permitido e o observado |
| Enforcement | O gateway pode bloquear chamadas a modelos (chaves, orçamentos) | Gates deny-closed sobre ações e acesso a recursos: aprovações, o Claude Code hooks PEP, gating de ferramentas MCP, kill switches |
| Artefacto de auditoria | Traces / logs para depuração | Ledger append-only, encadeado por hash, assinado com Ed25519, verificável off-box, exportável como pacotes de evidência OSCAL |
| Postura de implantação | Self-hostable | Self-hosted ou air-gapped; o plano de dados nunca sai do perímetro; AGPL, source-available |
A diferença fundamental é a fonte de verdade. Um trace de observabilidade indica o que a aplicação disse ter feito. Não consegue revelar que um agente acedeu a uma tabela que o trace nunca mencionou. O Olivares AI cruza o sinal cooperativo com o plano de dados, de modo que «o que o agente tocou» é um facto corroborado, não um auto-relato.
É «e», não «ou» — ingerimos a telemetria
O Olivares AI não é um substituto do gateway nem da ferramenta de rastreamento, e não pretende ocupar a rota de pedido que eles ocupam. Consome o mesmo sinal: o control plane ingere spans de convenções semânticas OpenTelemetry GenAI, a mesma telemetria gen-ai que estas ferramentas emitem e consomem. Assim, uma disposição saudável é:
- Manter o LiteLLM como gateway de modelos e o Langfuse para o rastreamento orientado a programadores e o trabalho com prompts.
- Apontar o fluxo OTel gen-ai para o Olivares AI como uma fonte corroboradora, e deixar que o mapa de acessos, a deteção de deriva e o ledger proporcionem a camada de governação à escala de todo o parque por cima.
Quando não se deve recorrer ao Olivares AI
A honestidade funciona nos dois sentidos. Provavelmente não é necessário este control plane se:
- O único objetivo é rastrear e depurar chamadas LLM numa ou duas aplicações, com um playground de prompts — o Langfuse sozinho é uma opção mais adequada.
- Apenas se necessita de um gateway multi-fornecedor com orçamentos e failover — essa é a função do LiteLLM, e a integração com esse padrão é preferível a reimplementá-lo.
- Não existe um parque para governar: um único serviço, um único modelo, nenhum agente a aceder a bases de dados/object stores/MCP, e nenhuma obrigação regulatória ou de auditoria.
O Olivares AI justifica-se quando as questões passam a ser de escala de parque e adversariais: que agentes existem, o que pode cada um efetivamente alcançar, onde se está o acesso a desviar-se da política, é possível demonstrá-lo perante um auditor, e é possível deter uma ação maliciosa deny-closed — tudo sem enviar essa imagem para a cloud de outrem.