Si ya has invertido en un AI gateway o en los Guardrails de un hiperescalador, lo primero honesto que hay que decir es: consérvalos, Olivares AI no pretende sustituirlos. El trabajo de un gateway es la llamada al modelo — enrutarla, cachearla, balancearla, presupuestarla. El trabajo de los Guardrails es la seguridad de contenido en esa llamada. Ambos son reales, ambos hacen bien lo suyo, y ninguno es lo que Olivares es.
TL;DR: Olivares AI no es un AI gateway general: no cachea ni balancea el tráfico de modelos, y no afirma ninguna matriz universal de proveedores, modelos o enrutado. Sí resuelve políticas de enrutado en una cadena ordenada de fallback, y tiene una ruta de ejecución medida — deny-closed, que actúa solo a través de un cliente compatible con Claude Messages que tú configuras, directamente o con tu propio endpoint de gateway como base URL de Messages. Más allá de esa ruta es el plano de gobierno y evidencia: enforcement en proceso en el runtime del agente, registro a prueba de manipulaciones, ciclo de vida de identidad no humana y human-in-the-loop / break-glass / kill-switch sobre sesiones activas. Se compone con el gateway que ya operas en lugar de sustituirlo.
Qué hacen bien un gateway y los Guardrails (úsalos para esto)
Son capacidades bien entendidas y consolidadas, y los fabricantes las describen con claridad:
- Los AI gateways son gestores en la ruta de peticiones para llamadas a modelos. LiteLLM es 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 permite “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). Enrutamiento, fallbacks, caché, claves virtuales, presupuestos por clave, registro de peticiones — esa es su función.
- Los Guardrails de hiperescaladores son filtros de seguridad de contenido. 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 contenido, temas denegados, filtros de palabras, redacción de PII, comprobaciones de grounding contextual y razonamiento automatizado (AWS).
Si tu problema es “dar a mis aplicaciones un único endpoint a muchos modelos, con presupuestos, caché y filtrado de contenido”, esa pila lo resuelve y no necesitas un plano de control para hacerlo. Nos integramos con ese patrón; no lo reimplementamos.
Qué documenta hoy cada producto
Leído el 2026-09-12 en la página propia de cada fabricante. Son límites de las páginas leídas, no afirmaciones sobre un producto entero, y ninguno es un ranking.
| Producto | Superficie para agentes que documenta | Qué no cubre la página |
|---|---|---|
| LiteLLM | La documentación del proxy incluye una sección “Agent & MCP Gateway”, además de Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | La página leída documenta la superficie del proxy; el enforcement dentro de un runtime de agente que nunca pasa por el proxy queda fuera |
| Portkey | Su lista de productos incluye Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | La página leída es un resumen de funciones; no describe un mapa de acceso permitido-frente-a-observado en todo el 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) | La página leída es una descripción de producto; no describe operación self-hosted ni air-gapped de ese plano |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, utilizable en línea o “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Son páginas de seguridad de contenido; el ciclo de vida de identidad de agente, la intervención en sesión y las aprobaciones no son su objeto y no están documentados en ellas |
Por eso el planteamiento anterior era incorrecto. «Los gateways nunca ven al agente» no se sostiene ante las páginas anteriores: LiteLLM y Portkey documentan superficies de agentes y MCP, y Cloudflare llama a su gateway un plano de control. Lo que sigue siendo distinto es dónde se aplica el enforcement y qué tipo de registro sale de ahí: una comparación arquitectónica, no una afirmación de ausencia.
En qué siguen difiriendo las arquitecturas
Condicional, no universal — cada línea vale cuando se cumple la condición de la izquierda:
| Si tus agentes… | Entonces un producto de ruta de petición | Entonces Olivares AI |
|---|---|---|
| …solo llegan a los modelos a través del proxy | gobierna cada llamada que ve, en la petición | aporta poco en la propia ruta de petición |
| …también se ejecutan localmente y llegan directamente a bases de datos, almacenes de objetos, MCP o ficheros | no puede ver llamadas que nunca lo atraviesan | aplica enforcement deny-closed en proceso en el agente, antes de que se ejecute la herramienta |
| …necesitan un registro que un auditor pueda verificar fuera de la caja | emiten logs de peticiones, que son registros mutables | registro append-only, encadenado por hash, firmado con Ed25519, verificable fuera de la caja |
| …deben detenerse a mitad de sesión | no es donde se detiene una sesión activa | aprobaciones HITL, break-glass y un kill switch con reactivación de control dual |
| …deben identificarse durante toda su vida | una virtual key es una partida de presupuesto | ciclo de vida de identidad no humana: bloqueo por obsolescencia, cascada de baja, rotación con control dual |
| …deben permanecer dentro de tu perímetro | los planos SaaS procesan ese tráfico en su nube | self-hosted o air-gapped; el plano de datos no sale de tu perímetro |
La ruta de ejecución de Olivares y sus límites reales
Olivares sí toca la inferencia, en un único punto medido, y la descripción honesta es la que lleva su propia medición actual:
- La ruta
POST /routing-policies/{id}/executees deny-closed por construcción y actúa solo a través de un cliente compatible con Claude Messages, directamente o con un endpoint de gateway resuelto como base URL de Messages — así que tu gateway actual puede ser ese endpoint. - La resolución de políticas produce una cadena ordenada de fallback. El módulo siempre resuelve una ruta y actúa solo a través de un puerto ejecutor; el ejecutor por defecto no está cableado, así que el enrutado se resuelve sin ninguna llamada a proveedor hasta que un operador compone uno.
- Dos puertas de alcance deny-closed y la puerta de parada del kill-switch se ejecutan antes de la puerta de presupuesto de FinOps, que se ejecuta antes del ejecutor.
Y lo que explícitamente no establece, en palabras del mismo registro:
- ninguna matriz universal de proveedores o modelos — el protocolo Claude Messages establece una ruta configurada, no una matriz;
- ninguna custodia centralizada de claves — los campos de clave de proveedor son referencias;
- ninguna ejecución desde la consola — la consola resuelve y prueba políticas y no tiene llamada de ejecución.
Esto es una medición de las fuentes actuales, no una aceptación de capacidad: el registro de claims vigente mantiene esta y todas las demás capacidades como implementadas y no aceptadas, sin ningún recibo de ejecución detrás. Tómalo como la forma de la ruta, no como una función certificada.
Sobre los Guardrails en concreto: la seguridad de contenido es un hook, no un competidor
Bedrock Guardrails puede aplicarse de dos formas — en línea durante una llamada de
inferencia en Bedrock, o “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). Eso es genuinamente útil, y
Olivares trata la seguridad de contenido como un detector que enchufas, nunca
como un muro que te pedimos que elijas en lugar de los Guardrails. Dos hechos
honestos y distintos:
- El proxy de inferencia en línea expone una costura de inspección de contenido — un punto conectable donde un detector de contenido / DLP devuelve un veredicto sobre el que actúa el decisor deny-closed. La seguridad de contenido pertenece ahí, en el pipeline, en vez de reimplementarse como un filtro competidor.
- Olivares lee las decisiones propias de tus Guardrails en modo read-first.
El conector de AWS ingesta las decisiones de los guardrails de Bedrock desde
sus logs de CloudWatch / S3 como postura y evidencia; deliberadamente no
llama al runtime de pago
ApplyGuardrailpor sí mismo. Tus veredictos de contenido pasan a formar parte del registro a prueba de manipulaciones.
Así, la seguridad de contenido se compone con lo que ya tienes en marcha. Lo que los Guardrails no documentan — y donde el hueco de gobierno sigue abierto — es el resto de la vida del agente: las páginas de Bedrock no documentan identidad de agente, gestión de sesiones, aprobaciones humanas ni gobierno de costes (no documentado en esas páginas, verificado el 2026-09-12). Olivares es exactamente ese complemento: lleva la identidad, los controles de sesión, las aprobaciones y la evidencia; el filtro de contenido se queda donde ya vive.
Cómo se componen
Una disposición sana mantiene cada herramienta en su carril:
- Conserva tu gateway (LiteLLM / Portkey / Kong / Cloudflare) como el plano de llamadas a modelos — enrutamiento, caché, claves virtuales, presupuestos en la petición.
- Conserva tus Guardrails (Bedrock / Azure Content Safety) como tu detector
de seguridad de contenido — el PEP de Olivares ejecuta un detector conectable
en su costura de inspección de contenido y lee las decisiones propias de tus
Guardrails en modo read-first como evidencia; no invoca
ApplyGuardrailpor sí mismo. - Añade Olivares junto a ellos como el plano de gobierno y evidencia: el PEP en proceso sobre los agentes que nunca pasan por tu gateway, el mapa de acceso a lo largo de toda la infraestructura, el registro a prueba de manipulaciones y los controles HITL/break-glass/kill en vivo.
El único punto donde Olivares toca la inferencia es estrecho y explícito — una
ruta de gateway solo con API key para llamantes con SDK crudo o curl,
descrita en
Governing subscription-authed agents.
Existe para gobernar tráfico que tus otras herramientas no pueden alcanzar, nunca
para competir con ellas en enrutamiento, y nunca transporta una credencial de
suscripción.
Cuándo tu gateway es suficiente
La honestidad funciona en ambas direcciones. Si tus agentes solo llaman a modelos a través de tu gateway, tus necesidades de seguridad de contenido están cubiertas por los Guardrails, no tienes agentes self-hosted ni en portátiles accediendo a bases de datos / almacenes de objetos / MCP directamente, y no tienes requisitos de soberanía ni de evidencia a prueba de manipulaciones — entonces tu gateway con sus logs y los Guardrails puede ser todo lo que necesitas, y no deberías añadir un plano de control por el mero hecho de tenerlo.
Olivares gana su lugar cuando las preguntas se vuelven transversales a la infraestructura y adversariales: qué agentes existen y a qué ha accedido realmente cada uno, puedo detener una mala acción deny-closed en el agente, quién autorizó la arriesgada, y puedo entregar a un auditor pruebas inmutables — todo sin enviar esa imagen a la nube de otro. Para el tratamiento en profundidad de dos comparativas adyacentes, consulta vs AI control towers y vs LLM observability.