Un LLM gateway es una capa intermedia entre tu aplicación y los proveedores de modelos (OpenAI, Anthropic, Google, xAI, Groq…) que unifica el acceso a todos ellos, enruta cada petición al modelo más adecuado, aplica fallbacks cuando un proveedor falla y centraliza coste, trazabilidad y cumplimiento. En 2026 dejó de ser una comodidad para convertirse en infraestructura crítica: según una encuesta de Parallels, el 94% de las organizaciones está preocupado por el vendor lock-in de IA.
La respuesta corta a "¿cómo evito depender de un solo proveedor?" es directa: nunca llames a los proveedores de IA desde el cliente y centraliza toda la lógica de modelos en un gateway dentro de tu backend. El resto de este artículo explica cuándo esa decisión merece la pena, dónde encaja en la arquitectura de una app y —esto es lo importante— cuándo todavía no la necesitas.
Qué es (y qué no es) un LLM gateway
Un gateway de LLMs es un proxy que se sitúa entre tu aplicación y los modelos. Toda petición de IA pasa por él y allí ocurren cuatro cosas:
- API unificada: tu código habla un único formato; el gateway traduce a cada proveedor.
- Enrutado: decide a qué modelo va cada petición según coste, latencia o tipo de tarea.
- Fiabilidad: reintentos y fallback automático a un proveedor secundario si el primario cae o degrada.
- Gobierno: límites de gasto, logging, control de PII y auditoría.
Lo que un gateway no es: no es un framework de agentes, no es un orquestador multi-agente (para eso están protocolos como MCP o A2A) y no sustituye a tu lógica de negocio. Es fontanería: la capa aburrida y fiable por la que pasa el dinero y el riesgo.
Por qué 2026 lo convirtió en infraestructura crítica
Hasta hace poco, integrar IA significaba elegir un proveedor y programar contra su SDK. Eso funciona hasta que ocurre una de estas cosas, y en 2026 ocurren todas:
- Los precios y modelos cambian cada trimestre. Un modelo que era caro hace seis meses hoy tiene una alternativa un 80% más barata. Sin una capa de abstracción, cambiar implica tocar código de producción.
- La disponibilidad no está garantizada. Un proveedor con una caída de una hora es una hora de tu producto sin IA si no tienes plan B.
- El coste se dispara en silencio. Enrutar todas las peticiones al modelo más potente es el error más caro y más común. Muchos equipos reducen hasta un 30% la factura de tokens simplemente mandando los prompts sencillos a un modelo pequeño.
- El cumplimiento aprieta. Con el EU AI Act ya en aplicación, necesitas registro y trazabilidad de qué modelo procesó qué dato. Eso se hace en un punto central, no en cada llamada dispersa por el código.
El gateway concentra estos cuatro problemas en un solo sitio que puedes cambiar sin redeplegar la app entera.
Dónde vive el gateway en una app (Flutter + backend)
Este es el punto donde más equipos se equivocan, así que conviene ser explícito.
El cliente —tu app Flutter— nunca debe hablar con un proveedor de IA directamente. Hacerlo obliga a incrustar claves de API en el binario (extraíbles con diez minutos de ingeniería inversa), impide controlar el gasto y expone tu lógica de prompts. La aparición en julio de 2026 de paquetes que permiten llamar a varios proveedores desde una sola API en Flutter es cómoda para prototipos, pero no cambia esta regla: en producción, la app llama a tu backend, y tu backend llama al gateway.
El flujo correcto es:
App Flutter ──HTTPS──► Tu backend (Go / Cloud Run) ──► LLM Gateway ──► Proveedores
│
├─ routing por coste/tarea
├─ fallback multi-proveedor
└─ budget + logging + PII
En el backend, el gateway es apenas una función de despacho. Un esbozo conceptual en Go:
func (g *Gateway) Complete(ctx context.Context, req Request) (Response, error) {
// 1. Enrutado: tareas simples a un modelo barato, complejas al potente
providers := g.route(req.Complexity)
// 2. Fallback: intenta en orden hasta que uno responda
var lastErr error
for _, p := range providers {
resp, err := p.Call(ctx, req)
if err == nil {
g.audit(req, p.Name(), resp) // 3. Gobierno: traza para cumplimiento
return resp, nil
}
lastErr = err
}
return Response{}, fmt.Errorf("todos los proveedores fallaron: %w", lastErr)
}
La clave no es el código —es trivial— sino que exista un único punto donde cambiar de proveedor, ajustar el routing o cortar el gasto sin tocar ni la app ni la lógica de negocio.
Enrutado por coste y tarea
No todas las peticiones necesitan el modelo más caro. Una clasificación de sentimiento o una extracción de campos de un formulario las resuelve un modelo pequeño por una fracción del precio. Reserva el modelo grande para razonamiento de cadena larga o generación de código. Es la palanca de ahorro más grande y la más ignorada.
Fallback sin caídas
Define un orden de proveedores por capacidad equivalente. Si el primario devuelve error o supera un timeout, el gateway reintenta en el secundario. Cuida la idempotencia: un reintento no debe duplicar un efecto (un cobro, un envío). Para streaming, el fallback solo es limpio antes del primer token; una vez empezada la respuesta, degradar con elegancia es más honesto que fingir que no pasó nada.
Build vs buy: el mapa de 2026
No hace falta construir el gateway desde cero. El ecosistema está maduro y la decisión real es build vs buy:
| Solución | Modelo | Cuándo encaja |
|---|---|---|
| LiteLLM (proxy) | Open source, self-host | Quieres control total y ya operas tu infra |
| Portkey | SaaS o self-host | Necesitas observability y governance de serie |
| Cloudflare AI Gateway | Gestionado | Ya estás en Cloudflare; caché y analítica sin fricción |
| Vercel AI Gateway | Gestionado | Stack en Vercel; despliegue rápido |
| OpenRouter | Enrutado gestionado | Acceso a muchos modelos sin contratos individuales |
| Kong AI Gateway | Enterprise | Ya usas Kong como API gateway; gobierno corporativo |
| Propio (p. ej. en Go) | Self-host | Requisitos de latencia, soberanía de datos o routing muy específico |
La regla honesta: compra o adopta open source por defecto; construye solo si tienes un requisito que ninguna opción cubre (soberanía de datos estricta, latencia extrema, un routing propietario que sea ventaja competitiva). Montar y mantener un gateway propio tiene un coste operativo real que rara vez compensa antes de cierta escala.
Cuándo NO necesitas un gateway todavía
Aquí es donde la mayoría de artículos sobre este tema fallan: te venden la abstracción como si siempre fuera gratis. No lo es.
No montes un gateway si:
- Tienes un MVP con un solo proveedor y bajo volumen. Un
ify una variable de entorno resuelven el cambio de modelo. Abstraer aquí es over-engineering. - Estás en fase de prototipo o descubrimiento. Primero valida que la IA aporta valor; la infraestructura viene después.
- El coste de operar el gateway supera el ahorro que genera. Con pocas peticiones al día, no hay factura que optimizar.
Y un matiz técnico que se paga caro: la abstracción empuja a programar contra el mínimo común denominador de todos los proveedores. Si lo haces demasiado pronto, renuncias a características específicas que sí te convienen —prompt caching de Anthropic, structured outputs, herramientas nativas de un proveedor concreto—. Un buen gateway deja escapar esas capacidades cuando las necesitas; una abstracción ingenua las esconde. Empieza fino y abstrae cuando el dolor sea real, no antes.
Checklist de decisión
Antes de introducir un gateway, responde:
- ¿Llamas ya a más de un proveedor, o prevés hacerlo en los próximos meses?
- ¿La factura de tokens es lo bastante alta como para que enrutar por coste importe?
- ¿Una caída de un proveedor deja tu producto sin una función crítica?
- ¿Tienes obligaciones de trazabilidad o cumplimiento sobre qué modelo procesa qué dato?
Con dos "sí", un gateway ya se justifica. Con cero, guarda esta decisión para más adelante.
Conclusión
El vendor lock-in de IA no se evita eligiendo "el proveedor correcto" —no existe— sino diseñando para que cambiar de proveedor sea barato. Un LLM gateway en tu backend es la forma probada de conseguirlo: unifica el acceso, enruta por coste, sobrevive a caídas y centraliza el gobierno. Pero como toda abstracción, tiene un momento oportuno. Introdúcelo cuando llames a más de un modelo, cuando el coste o la fiabilidad empiecen a doler, o cuando el cumplimiento lo exija; no como reflejo desde la primera línea de código.
En Dribba diseñamos backends en Go sobre Cloud Run y apps en Flutter donde la capa de IA es un componente más de la arquitectura, no un parche. Si estás decidiendo cómo integrar modelos sin atarte a un proveedor, hablemos de tu integración de IA o revisa cómo abordamos la integración de LLMs y RAG en apps empresariales.
