Se já investiu num AI gateway ou nos Guardrails de um hiperescalador, a primeira coisa honesta a dizer é: mantenha-os, a Olivares AI não pretende substituí-los. O trabalho de um gateway é a chamada ao modelo — encaminhá-la, fazer cache, balanceá-la, orçamentá-la. O trabalho dos Guardrails é a segurança de conteúdo nessa chamada. Ambos são reais, ambos fazem bem o que fazem, e nenhum deles é aquilo que a Olivares é.
TL;DR: A Olivares AI não é um AI gateway. Não encaminha, não faz cache, não faz balanceamento de carga nem se coloca no caminho quente do tráfego de modelos, e nunca o fará. Posiciona-se ao lado e por trás do gateway como o plano de governo e evidência: enforcement em processo dentro do runtime do agente, um registo de evidência à prova de manipulação, ciclo de vida de identidade não humana, e human-in-the-loop / break-glass / kill-switch sobre sessões ativas. O gateway governa o pedido; a Olivares governa o agente e tudo aquilo em que toca, e prova-o perante um auditor.
O que um gateway e os Guardrails fazem bem (utilize-os para isto)
São capacidades consolidadas e bem compreendidas, e os fabricantes descrevem-nas com clareza:
- Os AI gateways são gestores no caminho dos pedidos para chamadas a modelos. O LiteLLM é um “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); o Cloudflare AI Gateway permite “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); o Portkey “records real-time API requests, including cost” (Portkey). Encaminhamento, fallbacks, cache, chaves virtuais, orçamentos por chave, registo de pedidos — essa é a sua função.
- Os Guardrails de hiperescaladores são filtros de segurança de conteúdo. O Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications” que “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — filtros de conteúdo, tópicos negados, filtros de palavras, redação de PII, verificações de grounding contextual e raciocínio automatizado (AWS).
Se o problema é “dar às aplicações um único endpoint para muitos modelos, com orçamentos, cache e filtragem de conteúdo”, essa pilha resolve-o, e não é necessário um plano de controlo para o fazer. A integração faz-se com esse padrão; não se reimplementa.
A lacuna de governo que deixam aberta
Um gateway vê um pedido. Os Guardrails veem conteúdo. Nenhum deles vê o agente — a sua identidade ao longo do tempo, a que acedeu no plano de dados, quem autorizou uma ação de risco, nem se algo disso pode ser provado posteriormente. É essa a lacuna que a Olivares preenche.
| Lacuna que o gateway / Guardrails deixam | Porque importa | O que a Olivares AI oferece |
|---|---|---|
| Enforcement no runtime do agente | Um gateway aplica regras no limite do pedido; não consegue parar uma tool-call local do Claude Code que nunca o atravessa | Um PEP deny-closed em processo no agente: porta de identidade firme, disposição de política, overlay de política em tempo real, tudo antes de a ferramenta ser executada |
| Evidência à prova de manipulação | O gateway e os Guardrails emitem logs — registos de pedidos mutáveis; um auditor exige provas imutáveis | Registo append-only, hash-chained, assinado com Ed25519, verificável fora do servidor, exportável como evidência OSCAL |
| Ciclo de vida de identidade não humana | A “chave virtual” de um gateway é um bucket de orçamento, não uma identidade que é aprovisionada, atribuída, rodada e desativada | Ciclo de vida NHI: obsolescência → bloqueio, cascata de desativação, controlo dual na rotação, vinculado ao mapa de acessos |
| Intervenção em sessão ativa | Os logs e orçamentos são a posteriori; nenhuma destas ferramentas avaliadas detém uma sessão em curso | Aprovações HITL, break-glass e um kill switch que nega toda a atuação governada até uma reativação com controlo dual |
| Ground truth em toda a infraestrutura | Um gateway só vê as chamadas que passam por ele; os agentes também acedem a BDs, object stores, MCP e ficheiros diretamente | O mapa de acessos read-first R/RW e a deriva Permitted-vs-Observed, corroborada contra a auditoria nativa |
| Soberania | Os gateways SaaS e os Guardrails na cloud processam esse tráfego na sua cloud | Self-hosted / air-gapped; o plano de dados nunca sai do perímetro |
Nada disto são funcionalidades de encaminhamento. Esse é o ponto: a lacuna não é melhor encaminhamento, é governo que o caminho dos pedidos nunca foi desenhado para proporcionar.
Sobre os Guardrails em concreto: a segurança de conteúdo é um hook, não um concorrente
O Bedrock Guardrails pode ser aplicado de duas formas — inline durante uma chamada
de inferência no Bedrock, ou “directly through the ApplyGuardrail API without
invoking the foundation models”, que funciona “with any foundation model whether
hosted on Amazon Bedrock or self-hosted models”
(AWS). Isso é genuinamente útil, e
a Olivares trata a segurança de conteúdo como um detetor que se liga, nunca
como uma barreira que se pede para escolher em vez dos Guardrails. Dois factos
honestos e distintos:
- O proxy de inferência inline expõe uma costura de inspeção de conteúdo — um ponto ligável onde um detetor de conteúdo / DLP devolve um veredicto sobre o qual atua o decisor deny-closed. A segurança de conteúdo pertence aí, no pipeline, em vez de ser reimplementada como um filtro concorrente.
- A Olivares lê as decisões dos próprios Guardrails em modo read-first. O
conector de AWS ingere as decisões dos guardrails do Bedrock a partir dos seus
logs no CloudWatch / S3 como postura e evidência; deliberadamente não invoca
o runtime pago
ApplyGuardrail. Os veredictos de conteúdo passam a fazer parte do registo à prova de manipulação.
Assim, a segurança de conteúdo compõe-se com o que já se opera. O que os Guardrails não documentam — e onde a lacuna de governo permanece aberta — é o resto da vida do agente: as páginas do Bedrock não documentam identidade de agente, gestão de sessões, aprovações humanas nem governo de custos (não documentado nessas páginas, verificado em 21-06-2026). A Olivares é exatamente esse complemento: leva a identidade, os controlos de sessão, as aprovações e a evidência; o filtro de conteúdo fica onde já vive.
Como se compõem
Uma disposição saudável mantém cada ferramenta na sua faixa:
- Mantenha o gateway (LiteLLM / Portkey / Kong / Cloudflare) como o plano de chamadas a modelos — encaminhamento, cache, chaves virtuais, orçamentos no pedido.
- Mantenha os Guardrails (Bedrock / Azure Content Safety) como detetor de
segurança de conteúdo — o PEP da Olivares executa um detetor ligável na sua
costura de inspeção de conteúdo e lê as decisões dos próprios Guardrails em modo
read-first como evidência; não invoca
ApplyGuardrail. - Adicione a Olivares ao lado deles como o plano de governo e evidência: o PEP em processo sobre os agentes que nunca passam pelo gateway, o mapa de acessos em toda a infraestrutura, o registo à prova de manipulação e os controlos HITL/break-glass/kill em tempo real.
O único ponto onde a Olivares toca a inferência é estreito e explícito — um
caminho de gateway apenas com API key para chamantes com SDK em bruto ou
curl, descrito em
Governing subscription-authed agents.
Existe para governar tráfego que as outras ferramentas não conseguem alcançar,
nunca para competir com elas no encaminhamento, e nunca transporta uma
credencial de subscrição.
Quando o gateway é suficiente
A honestidade funciona nos dois sentidos. Se os agentes só chamam modelos através do gateway, as necessidades de segurança de conteúdo estão cobertas pelos Guardrails, não existem agentes self-hosted nem em portáteis a aceder a bases de dados / object stores / MCP diretamente, e não existem requisitos de soberania nem de evidência à prova de manipulação — então o gateway com os seus logs e os Guardrails pode ser tudo o que é necessário, e não se deve adicionar um plano de controlo apenas por o ter.
A Olivares ganha o seu lugar quando as perguntas se tornam transversais à infraestrutura e adversariais: que agentes existem e a que acedeu realmente cada um, é possível parar uma ação danosa deny-closed no agente, quem autorizou a arriscada, e é possível entregar a um auditor provas imutáveis — tudo sem enviar esse panorama para a cloud de outrem. Para o tratamento aprofundado de duas comparações adjacentes, consulte vs AI control towers e vs LLM observability.