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. No enruta, cachea, balancea carga ni se sitúa en la ruta caliente de tu tráfico de modelos, y nunca lo hará. Se sitúa junto y detrás de tu gateway como el plano de gobierno y evidencia: enforcement en proceso dentro del runtime del agente, un registro de evidencia a prueba de manipulaciones, ciclo de vida de identidad no humana, y human-in-the-loop / break-glass / kill-switch sobre sesiones activas. Tu gateway gobierna la petición; Olivares gobierna al agente y todo lo que toca, y lo demuestra ante un auditor.
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.
El hueco de gobierno que dejan abierto
Un gateway ve una petición. Los Guardrails ven contenido. Ninguno ve al agente — su identidad a lo largo del tiempo, a qué ha accedido en tu plano de datos, quién autorizó una acción de riesgo, ni si algo de ello se puede demostrar después. Ese es el hueco que Olivares cubre.
| Hueco que deja el gateway / Guardrails | Por qué importa | Qué aporta Olivares AI |
|---|---|---|
| Enforcement en el runtime del agente | Un gateway aplica las reglas en el límite de la petición; no puede detener una tool-call local de Claude Code que nunca lo atraviesa | Un PEP deny-closed en proceso en el agente: puerta de identidad firme, disposición de política, overlay de política en vivo, todo antes de que la herramienta se ejecute |
| Evidencia a prueba de manipulaciones | El gateway y los Guardrails emiten logs — registros de peticiones mutables; un auditor quiere pruebas inmutables | Registro append-only, encadenado por hash, firmado con Ed25519, verificable fuera del servidor, exportable como evidencia OSCAL |
| Ciclo de vida de identidad no humana | La “clave virtual” de un gateway es un bucket de presupuesto, no una identidad que se aprovisiona, atribuye, rota y da de baja | Ciclo de vida NHI: obsolescencia → bloqueo, cascada de baja, control dual en rotación, vinculado al mapa de acceso |
| Intervención en sesión activa | Los logs y presupuestos son a posteriori; ninguna de estas herramientas evaluadas detiene una sesión en vuelo | Aprobaciones HITL, break-glass y un kill switch que deniega toda actuación gobernada hasta una reactivación con control dual |
| Ground truth a lo largo de toda la infraestructura | Un gateway solo ve las llamadas que pasan por él; los agentes también tocan BDs, almacenes de objetos, MCP y ficheros directamente | El mapa de acceso read-first R/RW y la deriva Permitted-vs-Observed, corroborada contra la auditoría nativa |
| Soberanía | Los gateways SaaS y los Guardrails en la nube procesan ese tráfico en su nube | Self-hosted / air-gapped; el plano de datos nunca sale de tu perímetro |
Nada de esto son funciones de enrutamiento. Ese es el punto: el hueco no es mejor enrutamiento, es gobierno que la ruta de peticiones nunca fue diseñada para proporcionar.
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 21-06-2026). 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.