flowchart LR
a1["App 1"] --> gw["Gateway"]
a2["App 2"] --> gw
a3["Agente"] --> gw
gw --> p1["Proveedor A"]
gw --> p2["Proveedor B"]
gw --> p3["Modelo propio"]
gw --> tr["Trazas y coste"]
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
classDef control fill:#d7eddc,stroke:#4a9463,stroke-width:1.5px,color:#1c4a2e
classDef externo fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
class a1,a2,a3 modelo
class gw,tr control
class p1,p2 externo
class p3 modelo
17 Gateways
Los gateways de IA nos ofrecen un medio centralizador para gestionar los distintos recursos a los que accede un agente. O mejor dicho, el flujo de interacciones que define su comportamiento.
La idea no es nueva: es la misma que llevó a poner un API gateway delante de un montón de servicios. Lo que cambia es qué hay que centralizar, porque el tráfico hacia un modelo tiene propiedades que el tráfico HTTP corriente no tiene.
17.1 Por qué aparece siempre
Un equipo empieza con una clave de API en una variable de entorno. Después son cuatro equipos, tres proveedores y nadie sabe cuánto se gasta ni en qué. El gateway es lo que ocurre cuando esa situación se vuelve insostenible, y ocurre antes de lo que uno espera.
Lo que resuelve, por orden de urgencia real:
Las claves. Una credencial por proveedor, guardada en un sitio, rotable sin tocar diez aplicaciones. Las aplicaciones reciben una clave del gateway, no la del proveedor.
La visibilidad del gasto. Quién consume, cuánto y en qué. Sin esto, la factura del proveedor es un número sin desglose que nadie puede atribuir a nada. Es el requisito que suele traer al gateway a la conversación, normalmente después de un sobresalto.
Los límites. Cuota por equipo, por aplicación y por usuario. Un bucle de un agente mal cerrado puede quemar el presupuesto del trimestre en una tarde, y el sitio para cortarlo es este.
La abstracción del proveedor. Una sola interfaz para todos los modelos, de modo que cambiar de modelo sea configuración. Es lo que hace real la recomendación de aislar la decisión de modelo.
La resiliencia. Reintentos, tiempos de espera y sobre todo conmutación a otro proveedor cuando uno degrada. Los proveedores de modelos tienen incidencias con una frecuencia a la que la mayoría de organizaciones no está acostumbrada.
17.2 Lo que aporta de más
Además de lo anterior, que es lo básico, hay tres capacidades que justifican por sí solas la pieza.
Caché. La exacta (misma petición, misma respuesta) es gratis de implementar y sorprendentemente eficaz en cargas con repetición. La semántica, que devuelve la respuesta guardada cuando la pregunta se parece lo bastante, tiene mejores tasas de acierto y un riesgo evidente: dos preguntas parecidas pueden merecer respuestas distintas. Conviene activarla con umbrales conservadores y solo donde una respuesta ligeramente desviada no haga daño.
Enrutado por dificultad. La palanca de ahorro más potente que existe, mencionada ya en inferencia: mandar el grueso del tráfico a modelos pequeños y reservar el caro para lo que lo necesita. Una distribución típica (la mayor parte a modelos baratos, una fracción al intermedio y una minoría a la frontera) recorta el coste medio por consulta de forma drástica sin que se note en la calidad percibida, siempre que el criterio de enrutado se haya validado contra el conjunto de evaluación.
Guardarraíles centralizados. Filtrado de entrada y salida, detección de datos personales, bloqueo de patrones. Ponerlos en el gateway garantiza que se aplican a todo el tráfico y no solo a las aplicaciones cuyo equipo se acordó. Con el matiz de siempre: un filtro reduce el riesgo, no lo elimina, y no sustituye al diseño de permisos del que habla defensas.
17.3 El panorama
Sin entrar en comparativas que caducan, las categorías son estables:
| Categoría | Ejemplos | Encaja cuando |
|---|---|---|
| Proxy abierto autogestionado | LiteLLM | Se quiere control y no importa operarlo |
| Producto gestionado | Portkey y similares | Se quiere gobierno y guardarraíles ya hechos |
| Extensión del API gateway | Kong, Apigee | Ya se estandarizó la gestión de API en esa plataforma |
| De borde / cloud | Cloudflare, gateways de los cloud | La caché y el análisis de uso son lo prioritario |
| Agregador de modelos | OpenRouter y similares | Se quiere acceso a muchos modelos sin contratos |
El criterio de elección más sensato no es la lista de funcionalidades sino quién lo va a operar. Un proxy abierto es una pieza más en producción, con su alta disponibilidad, sus actualizaciones y su guardia. Si el equipo de plataforma no puede asumirla, un producto gestionado sale más barato aunque su precio de lista parezca mayor.
AdvertenciaUn punto único de fallo en el camino crítico
Todo el tráfico de IA pasa por aquí. Eso significa que su caída es la caída de todo lo que dependa de un modelo, y que su latencia se suma a cada llamada.
Lo mínimo: alta disponibilidad real, un modo degradado que permita a las aplicaciones críticas ir directas al proveedor, y vigilar la latencia que añade el propio gateway. Merece la pena medirlo antes de creerse el folleto: la caché semántica, por ejemplo, añade una llamada de embeddings a cada petición.
TipPonedlo antes de necesitarlo
Es una de las pocas piezas de infraestructura que es más barato adoptar pronto. Introducirlo cuando ya hay quince aplicaciones con claves repartidas significa tocar quince aplicaciones y negociar con quince equipos.
Introducirlo cuando hay una significa cambiar una URL base. Y a partir de ahí, todo lo que venga nace con visibilidad de coste y trazas desde el primer día.
Precisamente de eso va el capítulo de observabilidad, aunque antes toca la pregunta que lo condiciona todo: ¿esto funciona?