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: O Olivares AI não é um AI gateway geral: não faz cache nem balanceamento do tráfego de modelos e não reivindica qualquer matriz universal de fornecedores, modelos ou encaminhamento. Resolve políticas de encaminhamento numa cadeia ordenada de fallback e tem um caminho de execução medido — deny-closed, que atua apenas através de um cliente compatível com Claude Messages que você configura, diretamente ou com o seu endpoint de gateway como base URL do Messages. Para além desse caminho é o plano de governo e evidência: enforcement em processo no runtime do agente, registo à prova de adulteração, ciclo de vida de identidades não humanas e human-in-the-loop / break-glass / kill-switch sobre sessões ativas. Compõe-se com o gateway que já opera, em vez de o substituir.
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.
O que cada produto documenta hoje
Lido a 2026-09-12 na página do próprio fabricante. São limites das páginas lidas, não afirmações sobre um produto inteiro, e nenhum é uma classificação.
| Produto | Superfície para agentes que documenta | O que a página não cobre |
|---|---|---|
| LiteLLM | A documentação do proxy inclui uma secção “Agent & MCP Gateway”, além de Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | A página lida documenta a superfície do proxy; o enforcement dentro de um runtime de agente que nunca o atravessa fica de fora |
| Portkey | A sua lista de produtos inclui Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | A página lida é uma visão geral de funcionalidades; não descreve um mapa de acesso permitido-versus-observado em todo o parque |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | A página lida é uma apresentação de produto; não descreve operação self-hosted nem air-gapped desse plano |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, utilizáveis inline ou “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | São páginas de segurança de conteúdo; o ciclo de vida da identidade do agente, a intervenção em sessão e as aprovações não são o seu objeto e não estão aí documentados |
O enquadramento anterior estava, portanto, errado. «Os gateways nunca veem o agente» não resiste às páginas acima: LiteLLM e Portkey documentam superfícies de agentes e MCP, e a Cloudflare chama ao seu gateway um plano de controlo. O que continua diferente é onde se aplica o enforcement e que tipo de registo sai daí: uma comparação de arquitetura, não uma afirmação de ausência.
Onde as arquiteturas ainda diferem
Condicional, não universal — cada linha vale quando a condição da esquerda se verifica:
| Se os seus agentes… | Então um produto no caminho do pedido | Então o Olivares AI |
|---|---|---|
| …só chegam aos modelos através do proxy | governa cada chamada que vê, no pedido | acrescenta pouco no próprio caminho do pedido |
| …também correm localmente e chegam diretamente a bases de dados, object stores, MCP ou ficheiros | não consegue ver chamadas que nunca o atravessam | aplica enforcement deny-closed em processo no agente, antes de a ferramenta correr |
| …precisam de um registo que um auditor possa verificar fora da caixa | emitem logs de pedidos, que são registos mutáveis | registo append-only, encadeado por hash, assinado com Ed25519, verificável fora da caixa |
| …têm de ser parados a meio da sessão | não é onde uma sessão ativa é parada | aprovações HITL, break-glass e um kill switch com reativação em controlo duplo |
| …têm de ser identificados durante toda a sua vida | uma virtual key é uma rubrica de orçamento | ciclo de vida de identidades não humanas: bloqueio por obsolescência, cascata de saída, rotação em controlo duplo |
| …têm de permanecer dentro do seu perímetro | os planos SaaS tratam esse tráfego na sua nuvem | self-hosted ou air-gapped; o plano de dados não sai do seu perímetro |
O caminho de execução do Olivares e os seus limites reais
O Olivares toca de facto na inferência, num único ponto medido, e a descrição honesta é a que a sua própria medição atual carrega:
- A rota
POST /routing-policies/{id}/executeé deny-closed by construction e atua apenas através de um cliente compatível com Claude Messages, diretamente ou com um endpoint de gateway resolvido como base URL do Messages — por isso o seu gateway atual pode ser esse endpoint. - A resolução de políticas produz uma cadeia ordenada de fallback. O módulo resolve sempre uma rota e atua apenas através de uma porta executor; o executor por omissão não está ligado, pelo que o encaminhamento se resolve sem qualquer chamada a fornecedor até um operador compor um.
- Dois gates de âmbito deny-closed e o gate de paragem do kill-switch correm antes do gate de orçamento FinOps, que corre antes do executor.
E o que explicitamente não estabelece, nas palavras do mesmo registo:
- nenhuma matriz universal de fornecedores ou modelos — o protocolo Claude Messages estabelece uma rota configurada, não uma matriz;
- nenhuma custódia centralizada de chaves — os campos de chave do fornecedor são referências;
- nenhuma execução a partir da consola — a consola resolve e testa políticas e não tem chamada de execução.
Isto é uma medição das fontes atuais, não uma aceitação de capacidade: o registo de claims em vigor mantém esta e todas as outras capacidades como implementadas e não aceites, sem qualquer recibo de execução por trás. Leia-o como a forma do caminho, não como uma funcionalidade certificada.
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 2026-09-12). 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.