Ya que nos estamos metiendo en todo esto de la IA , por tema del trabajo he estado empapándome de este concepto de AI Gateway o IA Gateway xD y lo primero que lo asociamos realmente es con algo parecido como el API Gateway, proxy etc.. , que en parte lo es, pero cuando empiezas a ver cuántas piezas sueltas hay detrás de “simplemente llamar a la API de un modelo” sobre todo con los modelos en sí y en el ámbito de empresa , la cosa si que cambia la verdad.
Problema a la vista
Imagina que estás en el trabajo y en tu empresa hay cuatro aplicaciones distintas que necesitan hablar con modelos de IA , un agente de Copilot Studio, un agente en Azure AI Foundry, una app interna de RAG y algún script de automatización suelto. Cada una de ellas, si no hay nada de por medio, termina hablando directamente con el modelo configurado , popr ejemplo una con Claude, otra con Azure OpenAI, otra con un modelo local , me lo invento.
Luego el resultado es que cada integración lleva sus propias credenciales, su propio control de límites (o ninguno), y su propio logging (o tampoco). Nadie tiene una vista completa de cuánto se está gastando, quién está mandando qué datos a quién, ni qué pasa el día que un proveedor tiene una caída, por que por ejemplo por mucho que tengas una gestión de costes en azure o lo manejes por suscripciones, por experiencia, te quedas corto.
Me quedé con esa espinita a ver como funciona realmente , y por lo que he indagado esto se llama, sin mucho glamour, el problema de las integraciones N×M , cuya explicacióon realmente es N aplicaciones hablando con M proveedores, sin nada en medio esto funciona bien con una app y un proveedor, no obstante , como podéis llegar a pensar, que esto deje de funcionar bien es cuestión de tiempo si no se contempla como toca.
¿Y qué es exactamente un AI Gateway?
Un AI Gateway es una capa intermedia como hemos dicho al principio no deja de ser un proxy inteligente, básicamente el cuál se coloca entre tus aplicaciones/agentes y los proveedores de modelos. Todo el tráfico de IA pasa por ahí, y es en ese único punto donde se aplican las reglas del juego:
Puntos clave de configuraciones:
- Autenticación y autorización: quién puede llamar a qué modelo, con qué permisos.
- Rate limiting y cuotas: para que un equipo no se coma el presupuesto (o el rate limit) del resto.
- Redacción de PII: interceptar y limpiar datos sensibles antes de que salgan hacia un proveedor externo.
- Enrutado y failover: si el proveedor principal falla o está saturado, desviar tráfico a otro sin que la app se entere.
- Caché semántica: si dos peticiones son casi idénticas, no hace falta pagar dos veces por la misma respuesta.
- Logging y auditoría: un registro único de qué se ha preguntado, a qué modelo, y qué se ha respondido.
Nada de esto es una idea nueva, por cierto. Es literalmente el mismo patrón que un API Gateway tradicional (por ejemplo Azure API Management) aplicado específicamente al tráfico hacia LLM’s , eso sí, con las particularidades de este mundo de la IA como por ejemplo tokens en lugar de requests, coste variable por modelo, y contenido no determinista que hay que inspeccionar de otra manera.
Por qué implantarlo
Aquí es donde hace poco yo hubiera dicho “bueno, es una buena práctica, no es obligatorio” o la de “bueno ya tenemos el APIM y lo tenemos por detrás de él”. Pero cuantos más agentes se despliegan en una organización, más rápido esa frase deja de ser cierta. Esto es lo que, según lo que he ido leyendo y viendo, más peso tiene a la hora de justificar un gateway
(Ojo: esta valoración son de otros post que he visto etc.. mientras iba leyendo sobre el tema, no un dato de ningún estudio en concreto , al final cada organización pesará estas cosas de forma distinta según su sector y madurez.)
Realmente puntos importantes que esto acomete son:
- Nadie sabe cuánto se está gastando hasta que llega la factura. Sin un eje central que etiquete el consumo por equipo o aplicación, el gasto en tokens es una caja negra hasta fin de mes.
- La fuga de datos por IA es distinta a la fuga de datos “de toda la vida”. Un empleado puede pegar sin querer datos sensibles en un prompt que sale hacia un proveedor externo, y si no hay nada inspeccionando ese tráfico, no hay forma de pararlo ni de saber que ha pasado.
- La normativa ya está aquí. Entre el EU AI Act y los marcos de gobernanza que cada sector se está montando, tener trazabilidad centralizada de qué modelo respondió qué y con qué datos.
Conclusiones que saco
Cuanto más leo sobre gobernanza de agentes, más me doy cuenta de que el gateway no es “una pieza más” de la arquitectura, es la pieza que hace que todo lo demás (inventario, gobernanza, respuesta a incidentes) sea posible sin depender de que cada equipo haga los deberes por su cuenta. Sin un punto centralizado, cualquier intento de “correlacionar todos tus agentes” se queda cojo, porque parte de esos agentes simplemente no van a estar donde los estás buscando.
Todavía me quedan dudas sobre cómo se comporta esto en despliegues híbridos (on-prem + varios clouds) y si añadiría latencia en la práctica un gateway bien cargado. Si alguien lo ha medido en producción, me interesa mucho saber más.
Nos vemos en la siguiente!