AI Gateway
Un límite para el tráfico AI
AI Gateway es un límite de infraestructura que media el acceso de una aplicación a proveedores, modelos y capacidades AI, y que puede aplicar políticas comunes sobre ese tráfico. Puede centralizar acceso a proveedores, credenciales, selección, fallback, controles de solicitud, telemetría y visibilidad de uso. No es obligatorio para toda aplicación AI ni convierte por sí solo esas decisiones en correctas.
La pregunta es qué boundary necesita una organización para que muchas aplicaciones no implementen de manera inconsistente las mismas reglas de acceso a modelos. Un gateway puede ofrecer una interfaz común y una ubicación operativa para políticas compartidas, pero también agrega una dependencia y un salto de red. Una aplicación pequeña puede llamar directamente a un proveedor; una plataforma con varios equipos puede necesitar mediación centralizada. El patrón debe justificarse por las responsabilidades que concentra, no por adoptar una etiqueta de producto.
La documentación de Azure API Management para escenarios generativos y la de Cloudflare AI Gateway muestran productos que reúnen algunas de estas capacidades. Son ejemplos de implementación. No fijan una taxonomía universal ni implican que todo gateway ofrezca las mismas garantías.
AI Gateway no es API Gateway
API Gateway es una frontera general para APIs: puede mediar autenticación, encaminamiento, composición, límites y políticas para muchos tipos de servicios. AI Gateway especializa esa frontera para tráfico cuyo comportamiento depende de modelos, proveedores, prompts, tokens, streaming, herramientas o resultados probabilísticos.
Un AI Gateway puede implementarse sobre un API Gateway existente o reutilizar sus mecanismos. La tecnología compartida no elimina la diferencia conceptual. API Gateway no necesita entender tokens, capacidades de modelos o fallback semántico; AI Gateway sí puede necesitar hacerlo. A la inversa, una aplicación AI puede usar un API Gateway general sin materializar un AI Gateway separado. La responsabilidad asumida, y no el producto que la hospeda, determina la identidad del concepto.
Intermediación y responsabilidades
Un gateway puede:
- presentar una interfaz común para varios proveedores;
- proteger credenciales upstream y aplicar autorización de caller;
- restringir modelos, proveedores, herramientas o tenants;
- dirigir tráfico según capacidades, contexto o políticas;
- seleccionar un fallback cuando falla la ruta preferida;
- aplicar cuotas, límites de tokens, concurrencia y tamaño;
- producir telemetría de solicitudes, uso, errores y latencia.
Estas funciones pueden existir en componentes distintos. Una plataforma no necesita reunirlas todas para ser un gateway. Tampoco basta con poner un proxy delante de un endpoint y atribuirle automáticamente cada responsabilidad de gobierno. El alcance debe declarar qué decisiones toma, qué sólo transporta y qué delega a otros componentes.
AI Gateway y Reverse Proxy
Reverse Proxy es un mecanismo general: recibe solicitudes en nombre de un servidor y las reenvía, pudiendo ocultar topología o terminar conexiones. AI Gateway es un rol especializado de mediación sobre tráfico AI. Un reverse proxy puede ser el mecanismo de transporte de un gateway, pero reenviar bytes no equivale a comprender políticas de modelo, tokens, herramientas o fallback. El Proxy Pattern de diseño de objetos conserva otra identidad y no es el destino conceptual de Reverse Proxy.
La distinción evita prometer capacidades inexistentes. Un proxy que sólo cambia el destino no está aplicando una política de proveedor. Un gateway puede incorporar proxy, pero su identidad depende de la responsabilidad AI que ejerce y de la evidencia de enforcement, no de la posición de red.
AI Gateway y Load Balancer
Load Balancing distribuye carga o capacidad entre destinos. Un AI Gateway puede distribuir tráfico, pero además puede decidir con base en capacidad del modelo, privacidad, tenant, modalidad, límite de contexto o política. Una distribución round-robin no es routing semántico. Un balanceador puede vivir detrás del gateway y resolver capacidad sin conocer la finalidad de la solicitud.
La misma infraestructura puede desempeñar ambos papeles, pero las preguntas son diferentes: el balanceador pregunta dónde hay capacidad disponible; el gateway puede preguntar qué destino está permitido y qué comportamiento se necesita. No deben presentarse como sinónimos.
Abstracción de proveedores
Un gateway puede ofrecer un contrato común para que una aplicación no integre directamente cada SDK. Esa abstracción reduce acoplamiento en algunos caminos, pero no borra diferencias de:
- capacidades y modalidades disponibles;
- schemas de entrada y salida;
- tool calling y structured outputs;
- streaming y eventos parciales;
- límites, latencia y disponibilidad;
- privacidad, retención y condiciones de uso;
- semántica de errores y de contenido.
Por eso una interfaz común debe conservar una forma de expresar capacidades, incompatibilidades y errores. Convertir todas las respuestas en un tipo aparentemente idéntico puede ocultar diferencias que cambian el resultado. Portabilidad sintáctica no es portabilidad comportamental.
Credenciales y autorización
El gateway puede separar a los llamadores de las credenciales de proveedores. Puede mantener secretos en un boundary controlado, rotarlos, asociarlos con una política y registrar el uso autorizado. Esto reduce la dispersión de secretos, pero centralización no equivale automáticamente a seguridad. El gateway sigue necesitando controles de acceso, almacenamiento apropiado, rotación, aislamiento entre tenants y manejo cuidadoso de logs.
Autenticar al caller tampoco decide qué puede hacer el caller. Autorización de una aplicación, modelo permitido, herramienta disponible y operación con efectos son decisiones relacionadas pero distintas. El gateway puede aplicar parte de ellas y delegar otras a Agent Permissions and Approval Boundaries o al servicio de destino. No materializa aquí un canonical de AI Security.
Routing y fallback
Model Routing responde a la selección normal: qué modelo o configuración conviene para una solicitud según criterios declarados. AI Gateway puede ejecutar o hacer cumplir esa decisión, pero el routing también puede vivir dentro de una aplicación sin gateway.
Fallback responde a una contingencia: qué hacer cuando la ruta preferida no puede utilizarse o deja de ser adecuada. Cambiar de proveedor no es transparente por defecto. Puede cambiar calidad, contexto, herramientas, formato, latencia, costo, privacidad o cumplimiento de políticas. Un fallback correcto declara si reintenta, degrada, rechaza o deriva, y qué evidencia permite distinguir un resultado alternativo de uno normal.
Routing y fallback pueden compartir un catálogo de destinos, pero no deben confundirse. La selección prevista no es una recuperación ante fallo. Tampoco todo reintento es fallback: Retry puede repetir la misma ruta, mientras fallback cambia la alternativa o la política.
Políticas de runtime
Las políticas pueden limitar proveedores, modelos, regiones, tenants, herramientas, modalidades, contextos o tipos de solicitud. También pueden definir cuándo un fallback está permitido y qué respuesta se entrega cuando ninguna alternativa cumple. Declarar una política no demuestra enforcement: la plataforma necesita rechazar, transformar, registrar o aislar la operación de manera verificable.
El gateway no debe inventar una política general para cada aplicación. Algunas reglas pertenecen al dominio, otras al sistema de permisos y otras a requisitos del proveedor. Una política compartida es útil cuando el criterio y su enforcement deben ser consistentes; es riesgosa cuando borra diferencias legítimas entre productos.
Token y controles de solicitud
Los controles de solicitud pueden incluir tamaño de entrada, límite de salida, ventana de contexto, concurrencia, rate limit, cuotas por tenant, límites de tiempo y controles de carga. Rate Limiting conserva el concepto general; el gateway puede aplicarlo sin crear un canonical de AI Rate Limiting. Backpressure, timeouts y circuit breakers siguen siendo tácticas generales de resiliencia.
Tokens son una unidad operativa relevante para capacidad y uso, pero un token limit no es necesariamente un presupuesto económico. Un gateway puede rechazar una solicitud que excede contexto, reservar concurrencia o limitar output sin decidir cuánto dinero debe gastar el producto. Las decisiones de costo y trade-off pertenecen a AI Economics, no a esta definición de control de flujo.
Caching, MCP y serving
Semantic Caching puede vivir detrás o dentro de un gateway, pero sigue siendo un patrón de aplicación. La ubicación física de una caché no cambia que su pregunta sea cuándo dos solicitudes pueden compartir una respuesta semánticamente equivalente y qué riesgos introduce. El gateway puede alojarla sin convertirse en el dueño conceptual de la caché.
Model Context Protocol es un protocolo de interoperabilidad para exponer herramientas, recursos o prompts. Un gateway puede gobernar acceso a endpoints MCP, pero controlar ese acceso no convierte al gateway en MCP. Protocolo y boundary de infraestructura resuelven problemas diferentes.
Model Serving expone inferencia desde un modelo o runtime. AI Gateway media el acceso a uno o más endpoints de serving o proveedores. El gateway puede seleccionar, autorizar y observar una llamada; no ejecuta por eso la inferencia. Serving y gateway pueden desplegarse juntos o separados.
Telemetría y límites operativos
Un gateway es una fuente posible de señales: proveedor, modelo, ruta, fallback, estado, tokens, latencia y errores. No es la única fuente y no debe registrar prompts o respuestas indiscriminadamente. AI / LLM Observability conserva la pregunta más amplia de reunir evidencia runtime, con redacción, retención, muestreo y correlación apropiados.
La telemetría del gateway puede omitir fallos ocurridos dentro de la aplicación, una herramienta o una recuperación. Puede también atribuir latencia al upstream cuando el costo real estuvo en una cola local. Por eso una posición central ayuda a correlacionar, pero no garantiza observabilidad completa. Esa especialización se desarrolla en AI / LLM Observability.
Costes y trade-offs
El gateway puede contar tokens, etiquetar solicitudes y estimar costos por proveedor. Esas señales permiten análisis posteriores, pero medir no es decidir. Agregar un gateway introduce operación, disponibilidad, latencia, compatibilidad y posible concentración de blast radius. Un fallback mejora disponibilidad en algunos casos y cambia semántica en otros. Una abstracción reduce integración repetida y puede ocultar capacidades.
La decisión de adoptarlo debe comparar responsabilidades, escala, riesgo, límites de confianza y evidencia disponible. «Todos los sistemas AI deben pasar por un gateway» no es una definición durable ni una recomendación universal.
Límites
AI Gateway no es:
- API Gateway general, aunque pueda reutilizarlo;
- Reverse Proxy o Load Balancer por el solo hecho de reenviar o distribuir;
- Model Routing, aunque pueda ejecutarlo;
- Model Serving, porque no equivale a inferencia;
- Semantic Caching, aunque pueda alojar una caché;
- MCP, aunque pueda gobernar herramientas MCP;
- AI Security o AI Economics.
El patrón es el boundary que media y gobierna tráfico AI. Sus garantías dependen de las decisiones que realmente aplica, de los componentes que quedan fuera y de la evidencia operativa que conserva.