¿Cómo funciona un gateway de LLM? Guía práctica para equipos de ingeniería

Una puerta de enlace de LLM se ubica entre tus aplicaciones y los proveedores de modelos que conectas a través de ella, y te da un solo lugar para administrar credenciales y dar seguimiento al uso.

“En este momento, es un caos de m****a”, escribió en r/LLMDevs de Reddit un ingeniero en septiembre de 2026.

“Cada quien tiene su propio juego de claves para Claude, OpenAI, AWS Bedrock y todos los demás proveedores de inferencia que usamos”.

La cobertura de BigGo sobre llm-proxy-tk, una puerta de enlace ligera basada en FastAPI, compara esta configuración con convertir los LLM en “agua de la llave corporativa”, con la puerta de enlace como la llave de paso general del edificio.

Pero antes de depositar tanta confianza en la plomería, veamos qué es lo que estás instalando.

¿Qué es una puerta de enlace de LLM?

Una puerta de enlace de LLM es un proxy inverso para las llamadas a modelos. Tus aplicaciones envían las solicitudes a ella en lugar de enviarlas directamente a OpenAI, Anthropic, Google o los proveedores de LLM que uses. La puerta de enlace reenvía esas solicitudes y aplica tus reglas en el camino.

Cada proveedor de LLM tiene su propia API, con su propia estructura de solicitudes, su propia autenticación y su propia forma de devolver errores. Además, cada uno tiene límites de frecuencia y modos de falla distintos. Si no hay una capa compartida frente a ellos, cada aplicación que llama a un proveedor lo hace todo por su cuenta, y cada una lo hace de forma un poco distinta.

La analogía del agua de la llave tiene sus límites, pero llega hasta aquí: los proveedores se conectan una sola vez, en la puerta de enlace. A partir de ahí, cada aplicación tiene su propia conexión con medidor, así que puedes ver quién usa qué y cerrar cualquier línea sin tocar las demás.

Puertas de enlace de LLM, IA, MCP y API: ¿cuál es la diferencia?

¿Cómo funciona una puerta de enlace de LLM?

Sigue una solicitud desde tu aplicación hasta el modelo y de regreso.

1. La solicitud llega a la puerta de enlace: Tu aplicación envía una solicitud de chat de apariencia normal, a menudo en un formato compatible con OpenAI, al endpoint de la puerta de enlace. Desde el punto de vista de la aplicación, esa es la dirección a la que llama para llegar al modelo.
2. La puerta de enlace verifica quién hace la solicitud y qué tiene permitido hacer: Antes de reenviar la solicitud, valida las credenciales. A menudo, se trata de una clave virtual emitida para un equipo o un producto. Si configuraste barreras de protección de entrada, también se pueden analizar los prompts en busca de datos sensibles o de intentos de anular las instrucciones del modelo.
3. La puerta de enlace verifica si ya tiene la respuesta: Si la caché está habilitada, una solicitud coincidente que cumpla los requisitos puede responderse con una respuesta guardada, sin hacer otra llamada al proveedor. Algunas puertas de enlace también ofrecen caché semántica, que busca solicitudes que se consideren lo bastante similares, en lugar de idénticas. Eso puede funcionar bien para tráfico tipo preguntas frecuentes.
4. La puerta de enlace elige a dónde va la solicitud: La solicitud puede indicar un modelo específico o un alias. La puerta de enlace busca la ruta correspondiente en tu configuración. También puedes configurar una ruta de respaldo: si se agota el tiempo de espera del proveedor A, la puerta de enlace puede intentar con el proveedor B.
5. La puerta de enlace prepara la llamada y devuelve la respuesta: La puerta de enlace convierte tu solicitud al formato del proveedor elegido y autentica la llamada saliente. En cuanto recibe la respuesta, la convierte al formato que requiere tu aplicación.
6. La puerta de enlace registra lo que pasó: Cuando el registro está habilitado, la puerta de enlace guarda detalles como quién hizo la llamada, qué modelo la atendió, el conteo de tokens, la latencia y el costo. Este es el registro que no tenía el ingeniero de Reddit que citamos en la introducción.

Las 4 cosas que necesitas saber antes de poner una puerta de enlace en producción

Todo lo que se describe en la sección anterior es posible porque la puerta de enlace ve cada solicitud que pasa por ella. Ese es el argumento de venta. Pero también es una descripción de la superficie de ataque y de la dependencia del proveedor que tienes que prever.

La puerta de enlace es ahora la pieza más valiosa de tu stack de IA

La puerta de enlace centraliza el acceso y, por lo tanto, también deja muchas credenciales al alcance de un solo servicio. El equipo de seguridad de Microsoft enumera lo que una implementación de LiteLLM puede almacenar u obtener: claves de API de proveedores, su propia clave maestra, registros de claves virtuales, cadenas de conexión a bases de datos, configuraciones de enrutamiento y políticas de inquilinos.

En octubre de 2026, Check Point Research reveló dos vulnerabilidades de alto riesgo en LiteLLM:

• CVE-2026-35029 permitía que usuarios autenticados, incluidos los de solo lectura, accedieran a funciones administrativas y tomaran el control de la instancia.
• CVE-2026-59823 permitía que los usuarios redirigieran solicitudes a un servidor bajo su control y capturaran claves de proveedores.

Ambas se corrigieron en la versión 1.83.9. Una aplicación que usa la puerta de enlace no debería poder cambiar su configuración.

Tus barreras de protección necesitan una política ante fallas

Una revisión de Pillar Security del 4 de octubre de 2026 documenta las integraciones de barreras de protección de terceros en las principales puertas de enlace, como LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management y Apigee. (Pillar vende barreras de protección, así que tenlo en cuenta al leer sus recomendaciones).

Un hook es un punto en la ruta de la solicitud, por lo general antes de que el prompt llegue al modelo o después de que vuelva la respuesta, donde la puerta de enlace puede pasar el contenido a un analizador externo para que emita un veredicto. Una verificación bloqueante espera ese veredicto antes de dejar que el tráfico continúe. La documentación de Portkey los llama before_request_hooks y after_request_hooks; TrueFoundry ejecuta cuatro, ya que agrega verificaciones antes y después de las llamadas a herramientas de MCP.

Ahora bien, hay dos cosas que revisar:

• ¿Qué pasa si falla el propio analizador? Si bloqueas la solicitud, detienes el tráfico sin verificar, pero puedes interrumpir tu aplicación. Si la dejas pasar, tu aplicación puede seguir funcionando sin esa verificación. Después, el registro de fallas te muestra que faltó la verificación, lo cual es útil, pero no es lo mismo que haberla ejecutado.
• ¿Puedes reemplazar el analizador? Si otro proveedor no es compatible, es posible que tengas que actualizar tu aplicación o usar otro proxy para conectarte.

Los hooks de MCP de TrueFoundry amplían el alcance de la puerta de enlace de las solicitudes a modelos a las llamadas a herramientas. Pero la puerta de enlace solo puede inspeccionar el tráfico que pasa por ella. Un agente de programación que ejecuta un comando en la máquina de un desarrollador puede quedar fuera de esa visibilidad.

Numbat, la herramienta de código abierto de Perplexity, se encarga de ese lado. Numbat se conecta a los agentes compatibles mediante hooks locales y puede inspeccionar las acciones planeadas, como comandos de shell o escrituras de archivos, antes de que se ejecuten. La función de bloqueo es opcional y está desactivada de forma predeterminada. La puerta de enlace ve el tráfico de modelos que se enruta a través de ella. Numbat agrega visibilidad sobre lo que hace el agente con la respuesta.

Necesitas saber dónde termina el control de la puerta de enlace

Forkast News identifica tres corrientes que llegan a la puerta de enlace desde direcciones distintas:

• Puertas de enlace centradas en LLM: LiteLLM y Portkey empezaron con las llamadas a modelos: traducir entre proveedores, enrutar solicitudes y dar seguimiento a los tokens. Ahora están agregando controles para las llamadas a herramientas.
• Plataformas de administración de API: Kong, Apigee de Google y Azure API Management empezaron con la autenticación, los permisos y la gestión del tráfico, y después agregaron compatibilidad con modelos y reglas específicas para IA.
• Infraestructura nativa para agentes: agentgateway, por ejemplo, se diseñó en torno a agentes que se comunican con modelos, herramientas y otros agentes, incluso a través de MCP y A2A.

La pregunta clave para decidir es qué estás enrutando:

• ¿Solo llamadas a modelos? Una puerta de enlace diseñada principalmente para LLM es un buen punto de partida.
• ¿Llamadas a modelos dentro de una empresa que ya está llena de reglas de API? Empieza con la plataforma que ya tienes.
• ¿Agentes que llaman a herramientas que llaman a modelos? Verifica que esas conexiones también estén cubiertas.

Introduces un punto de falla compartido

Supongamos que tu chatbot de soporte usa OpenAI y tu herramienta de investigación usa Anthropic, y que ambos se conectan a través de la misma puerta de enlace. Si esa puerta de enlace deja de funcionar, ambas herramientas pierden acceso a sus modelos, aunque OpenAI y Anthropic estén funcionando con normalidad.

Esto ya ha pasado. La tasa de errores de AI Gateway de Cloudflare alcanzó un máximo del 97% durante la interrupción del 12 de junio de 2025. La puerta de enlace dependía del servicio de almacenamiento Workers KV de Cloudflare para su configuración, y ese servicio estaba fallando.

Si administras la puerta de enlace por tu cuenta, mantén otra instancia en ejecución que pueda tomar el relevo si una falla. Si alguien más aloja tu puerta de enlace, pregúntale cómo la mantiene funcionando durante las fallas y qué pasa con tus solicitudes durante la recuperación.

Las funciones clave que debes buscar en una puerta de enlace de LLM

Le vas a dar a la puerta de enlace acceso a las credenciales de todos, así que deberías ser exigente con lo que te ofrece a cambio.

• Una sola API frente a varios proveedores: Tu código usa un solo formato, a menudo uno compatible con OpenAI, y la puerta de enlace se encarga de traducir. Los proveedores de LLM también ponen de su parte. Por ejemplo, la Agent API de Perplexity es compatible con la interfaz de la Responses API de OpenAI, así que los equipos pueden reutilizar las bibliotecas cliente de OpenAI que ya tienen.
• Claves virtuales con reglas asociadas: Cada equipo o producto obtiene su propia clave, con reglas que rigen los modelos permitidos, los límites de solicitudes y el gasto.
• Enrutamiento y respaldo: La puerta de enlace envía las solicitudes a los modelos según tu configuración, que puede priorizar el costo, la velocidad o un proveedor en particular. Si una llamada falla, puede intentar con otro. La Agent API de Perplexity te permite indicar hasta cinco modelos, incluso de distintos proveedores, en el orden que prefieras.
• Caché: Una respuesta guardada puede ahorrarte otra llamada al proveedor. Algunas puertas de enlace detectan solicitudes idénticas; otras también pueden detectar solicitudes con significados similares. Verifica si las respuestas en caché se pueden separar por usuario o equipo, y si puedes desactivar la caché para respuestas personalizadas o que dependen del momento.
• Streaming y errores uniformes: Las respuestas llegan a medida que se generan, y los errores de los proveedores se traducen a un formato que tu aplicación puede manejar. Verifica qué pasa cuando agregas barreras de protección de IA.
• Registro y atribución de costos: La puerta de enlace registra quién hizo una llamada, qué modelo la atendió, cuántos tokens usó, cuánto tardó y su costo estimado. Verifica si los registros incluyen prompts y respuestas, y cuánto tiempo se conservan.
• Hooks de barreras de protección: Son puntos en la ruta de la solicitud donde la puerta de enlace puede enviar contenido a un analizador externo para que emita un veredicto. Suelen ubicarse antes de una solicitud al modelo o después de su respuesta. Verifica si las solicitudes se detienen o continúan cuando falla el analizador, y si puedes conectar un analizador distinto.
• Una interfaz de administración que puedas restringir: La puerta de enlace administra el acceso a las credenciales de los proveedores y a las reglas que todos usan. Verifica que puedas restringir el acceso de administración por separado del tráfico de las aplicaciones y que los usuarios de solo lectura no puedan cambiar la configuración. La llave de paso general necesita un candado.

¿Qué herramientas puedes usar para crear tu puerta de enlace de LLM?

Las listas de funciones se superponen en todo el mercado. En un hilo de Reddit sobre el acceso interno a modelos, quien lo publicó preguntó: ¿qué puerta de enlace no va a requerir un ingeniero dedicado?

En nuestra opinión, esa es la pregunta correcta, y tiene cuatro respuestas, según qué tanto del trabajo estés dispuesto a asumir.

Desarróllala por tu cuenta

Una puerta de enlace mínima se encarga de una lista corta de tareas: aceptar solicitudes, verificar la clave de quien llama, agregar la credencial del proveedor, reenviar la llamada y registrar el resultado. Pero admitir los distintos formatos de los proveedores implica más trabajo. Y lo mismo pasa con mantener todo funcionando.

Si ya usas Envoy, su filtro de procesamiento externo te permite conectar un servicio que inspecciona y modifica solicitudes y respuestas. Aun así, tienes que crear y operar ese servicio.

En un hilo de r/LLMDevs sobre si una puerta de enlace reduce costos, u/QuanTradin contó que registrar los tokens y un indicador de acierto de caché en cada llamada le ayudó a encontrar dos procesos que pagaban el precio completo por prompts idénticos.

“...corregir eso valió más de lo que habría valido cualquier capa de enrutamiento”.

Es una experiencia reportada, y un buen punto de partida. Averigua qué estás pagando antes de crear formas elaboradas de enrutarlo.

Aloja por tu cuenta una puerta de enlace de código abierto

LiteLLM es una opción común en este caso: es compatible con OpenAI, admite una amplia gama de proveedores y tiene una gran comunidad. Bifrost es una alternativa diseñada para tener poca sobrecarga por solicitud. Vale la pena echarle un vistazo a Helicone si la observabilidad encabeza tu lista de funciones.

LiteLLM, como cualquier producto, tiene limitaciones para algunos equipos. En un hilo de r/aiagents sobre alternativas a crear una solución propia, u/Own_Bar_920 dijo que LiteLLM manejaba bien el enrutamiento, pero se quedaba corto en el control de versiones de prompts entre equipos y en las evaluaciones continuas al cambiar de modelo, por lo que terminaron usando una herramienta aparte.

Esas necesidades van más allá del enrutamiento básico de una puerta de enlace, y ese es justamente el punto: si el enrutamiento es la necesidad principal, LiteLLM les funcionó bien.

Obtienes una lista de funciones lista para usar, algunas de las cuales dependen de la edición, y mantienes la puerta de enlace dentro de tu red. También te haces responsable de aplicar parches, algo que dejaron claro las vulnerabilidades reveladas por Check Point que mencionamos antes, y de la disponibilidad de la puerta de enlace, como mostró la sección sobre el punto único de falla.

Pero incluye en tu presupuesto a alguien que se haga responsable de ella. En un hilo de r/LLMDevs sobre puertas de enlace para acceso interno, una de las preocupaciones era el mantenimiento. u/Informal-Writer9685 quería algo que “no requiriera un ingeniero dedicado a darle mantenimiento” y preguntó si la inestabilidad en las actualizaciones de LiteLLM que otros reportaban era un problema real a su escala o algo que solo importaba en producción.

Usa una puerta de enlace administrada

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter y la puerta de enlace alojada de Portkey operan el servicio por ti. En una aplicación compatible, lograr que pase la primera solicitud puede requerir poco más que cambiar una URL y agregar una clave de API.

La contrapartida es que ahora cada prompt pasa por un tercero antes de llegar al proveedor. Es un encargado más del tratamiento de datos en tu documentación de cumplimiento, y una interrupción de la propia puerta de enlace es un incidente del proveedor: no te toca a ti resolverlo.

Por ejemplo, el 17 y el 19 de febrero de 2026, OpenRouter sufrió interrupciones de 38 y 35 minutos, respectivamente, después de que fallara una dependencia de caché. Algunos clientes recibieron errores de “User not found” y perdieron tiempo depurando claves de API perfectamente válidas. La falla estaba en la infraestructura de la puerta de enlace.

Pero hay que reconocer que OpenRouter publicó un análisis post mortem detallado y agregó protecciones para evitar que una falla de la caché saturara su base de datos. Una puerta de enlace administrada como OpenRouter puede simplificar el acceso, pero, como señala u/QuanTradin en r/LLMDevs, consolidar las facturas no reduce automáticamente el gasto.

Amplía la puerta de enlace de API que ya tienes

Si Kong, Apigee o Azure API Management ya están al frente de tus servicios, cada uno ofrece capacidades específicas para IA: Kong AI Gateway, las políticas de puerta de enlace de IA de Apigee y la puerta de enlace de IA de Azure API Management. Puedes aprovechar la autenticación, las reglas de red y los procedimientos operativos que ya tienes, y agregar controles de modelos mediante plugins o políticas.

En una empresa grande, este puede ser el camino con menos resistencia organizacional. Las funciones de IA son más recientes que las de las puertas de enlace independientes. Asegúrate de probar la limitación de frecuencia basada en tokens y el streaming con todo el conjunto de plugins o políticas que planeas usar.

Así que, por supuesto, instala la válvula maestra: el todopoderoso gateway. Aun así, el ingeniero de la introducción tiene razón. El acceso de una empresa a los modelos no debería depender de quien, por casualidad, tenga la llave correcta guardada en un cajón.

Un gateway resuelve eso al poner esas llaves bajo control centralizado, lo que hace aún más arriesgado dejar el cajón abierto. Tienes que saber de quién es el cajón.

Preguntas frecuentes sobre gateways de LLM

¿El gateway de LLM es gratuito?

Si te refieres a la categoría, algunos gateways de LLM tienen versiones gratuitas.

Los gateways de LLM van desde software de código abierto gratuito hasta planes de pago que empiezan en alrededor de 50 USD al mes, con precios personalizados para implementaciones empresariales. Y algunos, en cambio, cobran un porcentaje; por ejemplo, el plan Standard de OpenRouter agrega un 5.5% a las compras de créditos.

¿Cuál es el mejor gateway de LLM?

¿Qué parte del trabajo estás dispuesto a asumir?

• Echa un vistazo a Bifrost o Helicone si quieres alojarlo tú mismo y controlar la configuración.
• Una opción administrada como OpenRouter o Vercel AI Gateway es ideal para los equipos que prefieren que alguien más opere el servicio.
• Si ya usas Kong o Azure API Management, revisa primero sus capacidades de IA.

Prueba tus opciones preseleccionadas con tus propias solicitudes, incluido qué sucede cuando falla un proveedor.

¿AWS tiene un gateway de LLM?

Sí. Amazon Bedrock AgentCore Gateway admite llamadas a modelos mediante lo que AWS denomina “destinos de inferencia” (inference targets). Estos permiten que las aplicaciones usen un solo endpoint para acceder a proveedores como Amazon Bedrock, OpenAI y Anthropic, y el gateway se encarga de las credenciales de los proveedores y del enrutamiento.