En el momento en que tu producto llama a más de un modelo de lenguaje grande, te enfrentas a una decisión de infraestructura que la mayoría de los equipos posponen hasta que empieza a costar dinero. La disyuntiva es si cada servicio habla directamente con cada proveedor, o si todo se enruta a través de una única capa que tú controlas.
Un AI gateway es un proxy inverso que se sitúa entre tus aplicaciones y cada proveedor de LLM que usas, y te da un único lugar donde gestionar el failover, el seguimiento de costos, los rate limits y las claves de API. Las empresas que ejecutan más de un modelo recurren a él por la misma razón que ponen un balanceador de carga delante de los servidores web: para dejar de resolver el mismo problema en diez bases de código distintas. Nuestro propio trabajo de desarrollo de modelos de lenguaje grandes confirma una y otra vez el mismo patrón: en cuanto una funcionalidad de LLM crece más allá de una única integración, la pregunta del gateway aparece por sí sola.
La presión es real y reciente. La encuesta State of AI in the Enterprise de Deloitte de enero de 2026, realizada a 3235 líderes, encontró que solo el 25 por ciento había llevado a producción el 40 por ciento o más de sus pilotos de IA, y la distancia entre una demo y un sistema de producción fiable es exactamente donde esta capa demuestra su valor. Los analistas de IDC describen una “constelación de modelos” que se está convirtiendo en la nueva norma, lo que significa que la integración con un único proveedor con la que empezaron la mayoría de los equipos ya va por detrás.
Tres problemas que un AI gateway realmente resuelve
Un gateway justifica su existencia cuando elimina trabajo que hoy repites a mano en varios lugares. Tres problemas superan esa prueba con claridad, porque cada uno empeora cada vez que agregas un modelo, un equipo o un cliente. Las siguientes secciones detallan con precisión qué maneja bien esta capa.
Failover entre proveedores: OpenAI, Anthropic y Google
Cuando un único proveedor tiene una mala hora, todas las funcionalidades construidas sobre él se apagan en el mismo instante. ChatGPT y la API de OpenAI dejaron de funcionar para miles de usuarios en diciembre de 2025, una de varias interrupciones ese año, y los equipos sin alternativa simplemente esperaron mientras su cola de soporte se llenaba. Un gateway te permite registrar OpenAI, Anthropic y Google Gemini detrás de un único endpoint y desviar el tráfico automáticamente cuando uno de ellos empieza a devolver errores o a agotar el tiempo de espera.
Más allá del uptime, la ventaja práctica es poder cambiar de proveedor sin un deploy. La regla de enrutamiento vive en el gateway en lugar de estar codificada en cada servicio que llama a un modelo, de modo que sustituir el modelo principal por uno más barato o más rápido se convierte en un cambio de configuración en vez de en un release.
Gobernanza de costos y atribución por equipo
La mayoría de las sorpresas en el costo de la IA se remontan a una única causa raíz: nadie puede ver quién gastó el dinero. Cuando una docena de servicios comparten una única clave de API, la factura mensual llega como una sola cifra sin desglose, y nadie puede decir qué funcionalidad o qué cliente provocó el aumento. Un gateway etiqueta cada solicitud con un equipo, un entorno y un caso de uso, de modo que el gasto se convierte en un informe sobre el que puedes actuar.
Esta es la misma disciplina que ya aplicas al resto de la producción. Tratar el gasto en tokens como algo que instrumentas y monitoreas de forma continua, en lugar de conciliar a fin de mes, es lo que convierte un presupuesto de IA de una conjetura en una previsión. Una práctica seria de AI FinOps, que rastree el costo por solicitud y el costo por cliente, depende de que esa atribución por equipo exista ya en el gateway.
Rate limiting unificado y consciente de los tokens
Los límites de los proveedores se miden en tokens por minuto, no en solicitudes por minuto, por lo que un limitador ingenuo basado en solicitudes o bien actúa demasiado pronto, o bien deja que un trabajo pesado prive de recursos a todos los demás. Un enrutador de LLM consciente de los tokens aplica los límites en la misma unidad en la que factura el proveedor, y lo hace en todas las aplicaciones a la vez en lugar de un servicio a la vez. Ese único punto de observación es lo que hace que los límites realmente se sostengan bajo carga.
En la práctica, un gateway agrupa tres controles que resultan dolorosos de construir y coordinar por separado. Cada uno es estándar en una configuración madura:
- Presupuestos de tokens por equipo o clave, para que un job por lotes descontrolado no pueda agotar la cuota de todo un departamento.
- Niveles de prioridad, para que las solicitudes orientadas al cliente se atiendan antes que la sumarización en segundo plano.
- Backpressure controlado, que encola o descarta carga con un error claro en lugar de dejar que los timeouts se propaguen en cascada.
Dos problemas que no resuelve (y qué necesitas en su lugar)
Un gateway es plomería, y la plomería tiene límites. Dos capacidades se comercializan como funciones del gateway y luego decepcionan en producción, porque cada una requiere criterio o aislamiento que una capa de proxy no puede ofrecer por sí sola. Entender ese límite antes de comprar te ahorra un trimestre entero de retrabajo doloroso.
El enrutamiento por calidad como problema de clasificación
A los proveedores les encanta la promesa de enviar prompts fáciles a un modelo barato y prompts difíciles a uno caro, de forma automática. El problema es que decidir que un prompt es “fácil” es en sí mismo una predicción, así que el enrutamiento de modelos de IA basado en calidad es en realidad un problema de clasificación disfrazado de infraestructura. Un proxy puede enrutar según señales estáticas como el nombre del modelo, una cabecera o una ruta, pero no tiene forma fiable de juzgar qué modelo responderá mejor a un prompt dado.
Hacerlo bien significa entrenar o ajustar un pequeño clasificador con tu propio tráfico y tu propia definición de una buena respuesta, y luego medirlo frente a ejemplos reservados para la evaluación. Eso es un esfuerzo de machine learning con datos etiquetados y evaluación, y es el tipo de trabajo que nuestros ingenieros de IA y ML planifican como un proyecto propio en lugar de tratarlo como una casilla más del gateway.
Aislamiento de inquilinos antes del modelo
Si atiendes a varios clientes, los datos de un inquilino nunca deben filtrarse al prompt, la caché o los registros de otro inquilino. Un gateway solo ve una solicitud después de que tu aplicación ya la ha ensamblado, lo que lo convierte en la capa equivocada para decidir quién puede ver qué. El aislamiento tiene que ocurrir aguas arriba, en cómo delimitas los datos, construyes el contexto y separas las cachés de cada inquilino.
El gateway sigue aportando valor al mantener registros por inquilino y claves separadas, y ese rastro de auditoría es realmente útil. Sin embargo, el aislamiento real es una decisión de arquitectura de aplicación y de datos que vive en tu propio código. Cuando asumimos una construcción multiinquilino a medio terminar, esto está entre las primeras cosas que auditamos, porque una filtración descubierta después del lanzamiento es cara de deshacer.
Construir vs. comprar vs. código abierto
Una vez que aceptas que necesitas un gateway, la verdadera pregunta es cómo conseguir uno sin convertirlo en un proyecto paralelo que compita con tu roadmap. Hay tres caminos, y el adecuado depende de cuánto control necesites sobre los datos y de cuánto trabajo de plataforma puedas dotar de personal. Muchos equipos empiezan con LiteLLM, de código abierto, y luego buscan una alternativa a LiteLLM cuando necesitan inicio de sesión único, registros de auditoría y presupuestos por equipo que un proxy ligero nunca fue diseñado para gestionar.
Tiempo hasta el primer despliegue
Semanas a meses; ingeniería es responsable de cada integración
Días para ponerlo en marcha, pero tú te encargas del uptime y de las actualizaciones
Horas; el proveedor se encarga del uptime y de las actualizaciones
Control de los datos
Control total; todo permanece dentro de tu infraestructura
Control total; alojado por ti mismo en tu propia infraestructura
Depende de la residencia y las condiciones de retención de datos del proveedor
Mantenimiento continuo
Tu equipo lo parchea, escala y monitorea indefinidamente
Núcleo mantenido por la comunidad, pero tú sigues ejecutándolo, parcheándolo y actualizándolo
El proveedor lo parchea, escala y monitorea
Modelo de costos
Solo tiempo de ingeniería, sin costo de licencia
Licencia gratuita; persisten los costos de infraestructura y de personal
Precio por solicitud o por asiento, sumado a los costos del proveedor
Mejor opción para
Empresas reguladas con un equipo de plataforma dedicado
Equipos con capacidad de DevOps que quieren evitar el vendor lock-in
Equipos que quieren funciones de gateway ya, sin dotar de personal a un equipo de plataforma
Ninguno de estos caminos es incorrecto por sí solo. El error costoso es ir a la deriva hacia un gateway artesanal por accidente, añadiendo una función a la vez hasta que, sin darte cuenta, terminas siendo dueño de una plataforma que nadie planeó mantener.
El gateway como tu nuevo límite de secretos
Este es el cambio que la mayoría de los equipos pasa por alto hasta que una revisión de seguridad los obliga a verlo. Una vez que cada llamada a un modelo pasa por una única capa, esa capa contiene todas las claves de los proveedores y se convierte en el servicio más sensible que operas. Tratado con ese respeto, un gateway de LLM reduce tu problema de secretos de docenas de claves dispersas a un único límite protegido.
La concentración solo cuenta como una mejora si el gateway está reforzado como el límite que ahora es. Las claves de los proveedores deben vivir en el almacén de secretos del gateway y nunca en el código de la aplicación ni en archivos de entorno; los servicios de aplicación deben autenticarse ante el gateway con sus propias credenciales de corta duración, y cada solicitud debe quedar registrada con la identidad que la realizó. Rotar una clave filtrada se convierte entonces en un único cambio en un único lugar, en lugar de una búsqueda por todos los repositorios.
El modo de fallo que vale la pena señalar es un gateway que registra prompts y respuestas completos en texto plano, lo que recrea silenciosamente el riesgo de exposición de datos que se pretendía contener. Registra metadatos por defecto, y redacta o muestrea los payloads de forma deliberada, no por accidente.
De claves dispersas a un único gateway
La mayoría de las empresas no parten de cero. Llegan a este punto con claves ya copiadas en una docena de servicios, y cada equipo ha integrado el modelo que necesitaba según su propio calendario. Consolidar eso de forma segura, sin romper las funcionalidades que ya atienden a los clientes, es el verdadero trabajo.
La migración que tiene éxito es incremental, no una reescritura. Un orden de operaciones práctico es el siguiente:
- Revisa cada lugar donde se llama a un modelo y cada clave en circulación en tus servicios.
- Pon en marcha el gateway y dirige hacia él primero una funcionalidad interna de bajo riesgo.
- Traslada el tráfico servicio por servicio, manteniendo la ruta directa antigua como respaldo hasta que cada corte se haya validado.
- Una vez que todo se enruta a través del gateway, revoca las claves antiguas dispersas y emite credenciales por servicio.
Un AI gateway en el que los equipos empresariales puedan confiar rara vez es la parte difícil aquí. La disciplina de trasladar el tráfico en vivo sin una congelación es donde estos proyectos se estancan, y es donde un socio que ya haya llevado a cabo este corte antes se gana su tarifa. Como primer paso más ligero en el borde, una opción alojada como el AI Gateway de Cloudflare para caché y control de costos puede cubrir las necesidades iniciales antes de invertir en una capa autoalojada.
Redwerk ha construido y consolidado capas de integración de modelos en stacks de .NET y Python, y nuestros equipos están acostumbrados a guiar a las partes interesadas no técnicas por exactamente qué cambia y por qué, que es normalmente lo que mantiene tranquila una migración como esta. Si estás evaluando si construir, comprar o consolidar lo que ya operas, contáctanos y trazaremos tu configuración actual y el camino seguro más corto hacia un único gateway.
Preguntas frecuentes
¿Qué es un AI gateway?
Es un proxy inverso que se sitúa entre tus aplicaciones y los proveedores de modelos de lenguaje grandes que usas, como OpenAI, Anthropic y Google. Te da un único lugar donde gestionar claves de API, hacer failover entre proveedores, rastrear el gasto por equipo y aplicar rate limits, en lugar de resolver cada una de esas cosas por separado en cada servicio.
¿Cuándo necesitas un gateway de LLM?
Lo necesitas cuando más de un equipo o servicio llama a un modelo, cuando dependes de más de un proveedor, o cuando una única clave de API compartida hace imposible ver quién está gastando qué. Por debajo de esa escala, una integración directa es más simple y un proxy añade latencia con poco beneficio.
LiteLLM vs. Portkey: ¿cuál deberías elegir?
LiteLLM es de código abierto y autoalojado, por lo que encaja con equipos que quieren control total sobre los datos y la infraestructura y pueden dotar de personal su mantenimiento. Portkey es un servicio gestionado que sacrifica algo de control a cambio de velocidad y dashboards, guardrails y analítica integrados. Elige LiteLLM cuando la residencia de datos y el control de costos guíen tu decisión, y Portkey cuando el tiempo hasta producción y el bajo mantenimiento importen más.
¿Cómo se enruta entre múltiples modelos de IA?
Empieza con reglas estáticas que el proxy pueda evaluar de forma económica, por nombre de modelo, ruta de la solicitud, cabecera o equipo, lo que cubre la mayoría de las necesidades. Para el enrutamiento basado en calidad, es decir, enviar prompts fáciles a un modelo barato y los difíciles a un modelo más potente, entrenas un pequeño clasificador con tu propio tráfico, porque esa decisión es una predicción y no una regla fija. Mantén configurado un modelo de respaldo para que una caída de un proveedor no detenga la funcionalidad.
Descubre cómo desarrollamos una app de reclutamiento impulsada por IA adquirida por un gigante del sector de personal en EE. UU.
