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

Un gateway de LLM se sitúa entre tus aplicaciones y los proveedores de modelos que conectas a través de él, lo que te ofrece un único lugar desde el que gestionar las credenciales y hacer un seguimiento del uso.

«Ahora mismo, esto es una m****a», escribió en Reddit, en r/LLMDevs, un ingeniero en septiembre de 2026.

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

El artículo de BigGo sobre llm-proxy-tk, un gateway ligero basado en FastAPI, compara esta configuración con convertir los LLM en «agua corriente corporativa», con el gateway como la llave de paso general del edificio.

Pero antes de depositar tanta confianza en las tuberías, veamos qué es exactamente lo que vas a instalar.

¿Qué es un gateway de LLM?

Un gateway de LLM es un proxy inverso para las llamadas a modelos. Tus aplicaciones envían las solicitudes al gateway, en lugar de enviarlas directamente a OpenAI, Anthropic, Google o a los proveedores de LLM que utilices. El gateway reenvía esas solicitudes y aplica tus reglas por el camino.

Cada proveedor de LLM tiene su propia API, con su propio formato de solicitud, su propia autenticación y su propia forma de devolver errores. Además, cada uno tiene sus propios límites de frecuencia y modos de fallo. Si no hay una capa compartida delante de ellos, cada aplicación que llama a un proveedor lo hace todo por su cuenta, y cada una lo hace de una forma ligeramente distinta.

La analogía del agua corriente tiene sus límites, pero nos lleva hasta aquí: los proveedores se conectan a la red una sola vez, en el gateway. A partir de ahí, cada aplicación recibe su propia conexión con contador, de modo que puedes ver quién usa qué y cortar cualquier línea sin tocar las demás.

Gateways de LLM, de IA, de MCP y de API: ¿en qué se diferencian?

¿Cómo funciona un gateway de LLM?

Sigamos el recorrido de ida y vuelta de una solicitud entre tu aplicación y el modelo.

1. La solicitud llega al gateway: tu aplicación envía una solicitud de chat de aspecto normal, a menudo en un formato compatible con OpenAI, al endpoint del gateway. Desde el punto de vista de la aplicación, esta es la dirección a la que llama para llegar al modelo.
2. El gateway comprueba 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 asignada a un equipo o un producto. Si has configurado 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. El gateway comprueba si ya tiene la respuesta: si la caché está activada, una solicitud coincidente que cumpla los requisitos puede responderse con una respuesta guardada, sin otra llamada al proveedor. Algunos gateways también ofrecen caché semántica, que busca solicitudes que se consideran lo bastante parecidas, aunque no sean idénticas. Esto puede venir bien para tráfico del tipo preguntas frecuentes.
4. El gateway elige adónde va la solicitud: la solicitud puede indicar un modelo concreto o un alias. El gateway busca la ruta correspondiente en tu configuración. También puedes configurar una ruta de respaldo: si el proveedor A agota el tiempo de espera, el gateway puede probar con el proveedor B.
5. El gateway prepara la llamada y devuelve la respuesta: el gateway convierte tu solicitud al formato del proveedor elegido y autentica la llamada saliente. En cuanto recibe la respuesta, la convierte al formato que necesita tu aplicación.
6. El gateway registra lo que ha pasado: cuando el registro está activado, el gateway anota detalles como quién hizo la llamada, qué modelo la atendió, el número de tokens, la latencia y el coste. Este es el registro que no tenía el ingeniero de Reddit que citábamos en la introducción.

Las 4 cosas que debes saber antes de poner un gateway en producción

Todo lo descrito en la sección anterior es posible porque el gateway ve todas las solicitudes que pasan por él. 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 debes tener en cuenta al planificar.

El gateway es ahora la pieza más valiosa de tu stack de IA

El gateway centraliza el acceso. Y, por tanto, también pone muchas credenciales al alcance de un único servicio. El equipo de seguridad de Microsoft enumera lo que puede almacenar u obtener un despliegue de LiteLLM: 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 a los usuarios autenticados, incluidos los de solo lectura, acceder a funciones administrativas y hacerse con el control de la instancia.
• CVE-2026-59823 permitía a los usuarios redirigir solicitudes a un servidor bajo su control y capturar las claves de los proveedores.

Ambas se corrigieron en la versión 1.83.9. Una aplicación que utiliza el gateway no debería poder cambiar su configuración.

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

Un análisis de Pillar Security del 4 de octubre de 2026 documenta integraciones de barreras de protección de terceros en los principales gateways, entre ellos 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 de la ruta de la solicitud, normalmente antes de que el prompt llegue al modelo o después de que vuelva la respuesta, en el que el gateway puede pasar el contenido a un escáner externo para que emita un veredicto. Una comprobació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 añade comprobaciones antes y después de las llamadas a herramientas de MCP.

Ahora bien, hay dos cosas que comprobar:

• ¿Qué ocurre si falla el propio escáner? Si bloqueas la solicitud, detienes el tráfico sin comprobar, pero puedes interrumpir tu aplicación. Si la dejas pasar, tu aplicación puede seguir funcionando sin esa comprobación. El registro de fallos te muestra después que faltó la comprobación, lo cual es útil, pero no equivale a haberla hecho.
• ¿Puedes sustituir el escáner? Si no se admite otro proveedor, puede que tengas que actualizar tu aplicación o usar otro proxy para conectarte.

Los hooks de MCP de TrueFoundry amplían el alcance del gateway desde las solicitudes a modelos hasta las llamadas a herramientas. Pero el gateway solo puede inspeccionar el tráfico que pasa por él. Un agente de programación que ejecuta un comando en el equipo de un desarrollador puede quedar fuera de su campo de visión.

Numbat, la herramienta de código abierto de Perplexity, se ocupa de ese lado. Numbat se conecta a los agentes compatibles mediante hooks locales y puede inspeccionar las acciones previstas, 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. El gateway ve el tráfico de modelos que pasa a través de él. Numbat aporta visibilidad sobre lo que hace el agente con la respuesta.

Necesitas saber dónde termina el control del gateway

Forkast News identifica tres familias de productos que llegan al gateway desde direcciones distintas:

• Gateways centrados en LLM: LiteLLM y Portkey empezaron con las llamadas a modelos: traducir entre proveedores, enrutar solicitudes y hacer un seguimiento de los tokens. Ahora están añadiendo controles para las llamadas a herramientas.
• Plataformas de gestió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 añadieron 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, también mediante MCP y A2A.

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

• ¿Solo llamadas a modelos? Un gateway centrado en LLM es un buen punto de partida.
• ¿Llamadas a modelos dentro de una empresa que ya está llena de reglas de API? Empieza por la plataforma que ya tienes.
• ¿Agentes que llaman a herramientas que llaman a modelos? Comprueba que esas conexiones también estén cubiertas.

Introduces un punto de fallo compartido

Imagina que tu chatbot de soporte usa OpenAI y tu herramienta de investigación usa Anthropic, y que ambos se conectan a través del mismo gateway. Si ese gateway deja de funcionar, las dos herramientas pierden el acceso a sus modelos, aunque OpenAI y Anthropic funcionen con normalidad.

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

Si gestionas el gateway tú mismo, mantén otra copia en ejecución que pueda tomar el relevo si una falla. Si otra empresa aloja tu gateway, pregúntale cómo lo mantiene en funcionamiento durante los fallos y qué pasa con tus solicitudes durante la recuperación.

Las funciones clave que debes buscar en un gateway de LLM

Vas a dar al gateway acceso a las credenciales de todo el mundo, así que deberías ser exigente con lo que te ofrece a cambio.

• Una única API delante de varios proveedores: tu código habla un solo formato, a menudo uno compatible con OpenAI, y el gateway 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 Responses API de OpenAI, de modo que los equipos pueden reutilizar las bibliotecas cliente de OpenAI que ya tienen.
• Claves virtuales con reglas asociadas: cada equipo o producto recibe su propia clave, con reglas que determinan los modelos permitidos, los límites de solicitudes y el gasto.
• Enrutamiento y respaldo: el gateway envía las solicitudes a los modelos según tu configuración, que puede priorizar el coste, la velocidad o un proveedor concreto. Si una llamada falla, puede probar con otro. La Agent API de Perplexity te permite indicar hasta cinco modelos, incluidos modelos de distintos proveedores, en tu orden de preferencia.
• Caché: una respuesta guardada puede ahorrarte otra llamada al proveedor. Algunos gateways buscan solicitudes idénticas; otros también pueden encontrar solicitudes con un significado parecido. Comprueba si las respuestas en caché pueden separarse por usuario o equipo, y si puedes desactivar la caché para respuestas personalizadas o que dependan del momento.
• Streaming y errores coherentes: las respuestas llegan a medida que se generan, y los errores de los proveedores se traducen a un formato que tu aplicación puede gestionar. Comprueba qué ocurre cuando añades barreras de protección de IA.
• Registro y atribución de costes: el gateway registra quién hizo una llamada, qué modelo la atendió, cuántos tokens usó, cuánto tardó y su coste estimado. Comprueba si los registros incluyen los prompts y las respuestas, y durante cuánto tiempo se conservan.
• Hooks para barreras de protección: son puntos de la ruta de la solicitud en los que el gateway puede enviar contenido a un escáner externo para que emita un veredicto. Suelen situarse antes de la solicitud al modelo o después de su respuesta. Comprueba si las solicitudes se detienen o continúan cuando falla el escáner, y si puedes conectar un escáner distinto.
• Una interfaz de administración que puedas blindar: el gateway gestiona el acceso a las credenciales de los proveedores y las reglas que usa todo el mundo. Comprueba que puedes restringir el acceso de administración por separado del tráfico de las aplicaciones y que los usuarios de solo lectura no pueden cambiar la configuración. La llave de paso general necesita un candado.

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

Las listas de funciones se solapan en todo el mercado. En un hilo de Reddit sobre el acceso interno a modelos, el autor preguntaba: ¿qué gateway no va a requerir un ingeniero dedicado?

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

Desarróllalo tú mismo

Un gateway mínimo se encarga de una lista corta de tareas: aceptar solicitudes, comprobar la clave de quien llama, añadir la credencial del proveedor, reenviar la llamada y registrar el resultado. Pero admitir distintos formatos de proveedores supone más trabajo. Y lo mismo ocurre con mantenerlo todo en funcionamiento.

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

En un hilo de r/LLMDevs sobre si un gateway reduce costes, 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.

«...arreglar eso valió más de lo que habría valido cualquier capa de enrutamiento».

Es la experiencia de un usuario, y un buen punto de partida. Averigua qué estás pagando antes de crear sistemas de enrutamiento sofisticados.

Aloja tú mismo un gateway de código abierto

LiteLLM es una opción habitual en este caso: es compatible con OpenAI, admite una amplia variedad de proveedores y cuenta con una gran comunidad. Bifrost es una alternativa diseñada para tener una sobrecarga baja por solicitud. Merece la pena echar 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 desarrollar uno propio, u/Own_Bar_920 contó que LiteLLM gestionaba bien el enrutamiento, pero se quedaba corto en el versionado de prompts entre equipos y en las evaluaciones continuas al cambiar de modelo, lo que le llevó a usar una herramienta aparte.

Esas funciones van más allá del enrutamiento básico de un gateway, y de eso se trata: si lo principal es el enrutamiento, a este usuario LiteLLM le funcionó bien.

Obtienes una lista de funciones lista para usar, algunas de las cuales dependen de la edición, y mantienes el gateway dentro de tu red. También te encargas de aplicar los parches, algo que las vulnerabilidades reveladas por Check Point que vimos antes dejaron muy claro, y de la disponibilidad del gateway, como mostró la sección sobre el punto de fallo único.

Pero reserva presupuesto para que alguien se haga responsable. Una de las preocupaciones en un hilo de r/LLMDevs sobre gateways para acceso interno era el mantenimiento. u/Informal-Writer9685 quería algo que «no requiera un ingeniero dedicado a mantenerlo» y preguntaba si la inestabilidad en las actualizaciones de LiteLLM de la que se hablaba era un problema real a su escala o algo que solo afectaba a producción.

Usa un gateway gestionado

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter y el gateway alojado de Portkey gestionan el servicio por ti. En una aplicación compatible, conseguir que pase la primera solicitud puede requerir poco más que cambiar una URL y añadir una clave de API.

La contrapartida es que ahora cada prompt pasa por un tercero antes de llegar al proveedor. Es un encargado del tratamiento de datos más para tu documentación de cumplimiento normativo, y una interrupción del gateway es un incidente del proveedor: no te corresponde a ti solucionarlo.

Por ejemplo, los días 17 y 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 «User not found» y dedicaron tiempo a depurar claves de API perfectamente válidas. El fallo estaba en la infraestructura del gateway.

Pero hay que reconocer que OpenRouter publicó un análisis posincidente detallado y añadió protecciones para evitar que un fallo de la caché saturara su base de datos. Un gateway gestionado como OpenRouter puede simplificar el acceso, pero, como señala u/QuanTradin en r/LLMDevs, unificar las facturas no reduce automáticamente el gasto.

Amplía el gateway de API que ya tienes

Si Kong, Apigee o Azure API Management ya están delante de tus servicios, cada uno ofrece funciones específicas para IA: Kong AI Gateway, las políticas de gateway de IA de Apigee y el gateway de IA de Azure API Management. Puedes aprovechar la autenticación, las reglas de red y los procedimientos operativos que ya tienes, y añadir controles para los modelos mediante plugins o políticas.

En una gran empresa, este puede ser el camino que menos resistencia organizativa encuentre. Las funciones de IA son más recientes que las de los gateways 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 vayas a usar.

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

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

Preguntas frecuentes sobre gateways de LLM

¿Es gratuito el gateway de LLM?

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 a partir de unos 50 $ al mes, con precios personalizados para implementaciones empresariales. Y algunos cobran un porcentaje en su lugar: por ejemplo, el plan Standard de OpenRouter añade 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 autoalojarlo y controlar la configuración.
• Una opción gestionada como OpenRouter o Vercel AI Gateway encaja con los equipos que prefieren que sea otro quien se encargue de operar el servicio.
• Si ya usas Kong o Azure API Management, revisa primero sus capacidades de IA.

Pon a prueba tus opciones preseleccionadas con tus propias solicitudes, incluido lo que ocurre cuando falla un proveedor.

¿Tiene AWS un gateway de LLM?

Sí. Amazon Bedrock AgentCore Gateway admite llamadas a modelos mediante lo que AWS denomina «destinos de inferencia». Estos permiten que las aplicaciones usen un único 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.