Perplexity explica el funcionamiento de las puertas de enlace para LLM y los riesgos en producción

Perplexity publicó el 27 de octubre de 2026 una guía práctica sobre las puertas de enlace para LLM, en la que explica a los equipos de ingeniería cómo esta capa intermediaria enruta, autentica, almacena en caché y registra las llamadas a modelos, y enumera los riesgos de seguridad y fiabilidad que conlleva concentrar las credenciales de los proveedores en un solo servicio.

Definición y clasificación de las puertas de enlace

La guía define una puerta de enlace para LLM como un proxy inverso para las llamadas a modelos: las aplicaciones envían las solicitudes a la puerta de enlace, en lugar de hacerlo directamente a proveedores como OpenAI, Anthropic o Google, y esta las reenvía aplicando las reglas del operador. Presenta esta categoría como una solución a la proliferación de herramientas y abre con una publicación de septiembre de 2026 en r/LLMDevs de Reddit, en la que un ingeniero describió un lugar de trabajo donde cada persona tenía sus propias claves para Claude, OpenAI, AWS Bedrock y otros proveedores de inferencia.

La tabla comparativa de la guía distingue cuatro tipos de puertas de enlace. Una puerta de enlace de API se sitúa delante de los servicios de backend y determina si un cliente está autenticado y dentro de su límite de solicitudes. Una puerta de enlace para LLM se sitúa delante de los proveedores de modelos y determina qué modelo recibe una solicitud, quién la paga y si obtuvo respuesta. Una puerta de enlace MCP determina si un agente puede llamar a una herramienta determinada con unos argumentos determinados. La guía emplea el término «puerta de enlace de IA» para los productos de proveedores que combinan algunas de estas funciones.

Las seis etapas del ciclo de vida de una solicitud

La guía explica el funcionamiento siguiendo una solicitud desde la aplicación hasta el modelo y de vuelta. Primero, la aplicación envía una solicitud de chat al punto de conexión de la puerta de enlace, a menudo en un formato compatible con OpenAI. La puerta de enlace valida las credenciales, que suelen ser una clave virtual asignada a un equipo o producto, y, si se han configurado controles de entrada, puede analizar las indicaciones para detectar datos sensibles o intentos de anular las instrucciones del modelo. Si el almacenamiento en caché está habilitado, una solicitud coincidente que cumpla los requisitos puede responderse con una respuesta guardada; algunas puertas de enlace ofrecen almacenamiento semántico en caché, que identifica solicitudes consideradas similares, aunque no idénticas. A continuación, la puerta de enlace busca en su configuración la ruta correspondiente y puede recurrir a un proveedor alternativo si el primero agota el tiempo de espera. Convierte la solicitud al formato del proveedor elegido, autentica la llamada saliente y adapta la respuesta al formato que necesita la aplicación. Si el registro está habilitado, anota quién hizo la llamada, qué modelo la atendió, la cantidad de tokens, la latencia y el costo.

Riesgos de seguridad y fiabilidad

La advertencia central de la guía es que la puerta de enlace concentra las credenciales. El equipo de seguridad de Microsoft ha enumerado lo que una implementación de LiteLLM puede almacenar o recuperar: claves de API de proveedores, la clave maestra de LiteLLM, registros de claves virtuales, cadenas de conexión a bases de datos, configuración de enrutamiento y datos de políticas de inquilinos. En esa publicación del 26 de agosto de 2026, Microsoft describió un compromiso de una puerta de enlace LiteLLM que había detectado, en el que los atacantes extrajeron credenciales del entorno de ejecución de la puerta de enlace.

El 13 de octubre de 2026, Check Point Research divulgó dos vulnerabilidades de alto riesgo en LiteLLM: CVE-2026-35029, un fallo de control de acceso que permitía a usuarios autenticados, incluso con permisos de solo lectura, acceder a funciones administrativas y tomar el control de la puerta de enlace; y CVE-2026-59823, una vulnerabilidad de falsificación de solicitudes del lado del servidor que permitía a los usuarios redirigir las solicitudes de la puerta de enlace a un servidor controlado por un atacante y capturar claves de API de proveedores de IA. Ambas se corrigieron en la versión 1.83.9 de LiteLLM. Check Point informó que LiteLLM registraba 97 millones de descargas al mes y más de 59.000 estrellas en GitHub, y señaló que su proceso de divulgación coordinada a LiteLLM comenzó en octubre de 2025.

La guía también recomienda a los equipos establecer una política de actuación ante fallos para los controles de seguridad. Explica que los hooks son puntos del recorrido de una solicitud en los que la puerta de enlace entrega el contenido a un analizador externo para que emita un dictamen. Señala que la documentación de Portkey menciona before_request_hooks y after_request_hooks, y que TrueFoundry ejecuta cuatro hooks, añadiendo comprobaciones antes y después de las llamadas a herramientas MCP.

En cuanto a la fiabilidad, la guía remite a informes de interrupciones publicados. El relato de Cloudflare sobre la interrupción del 12 de junio de 2025 señala que las tasas de error de su AI Gateway llegaron a alcanzar el 97 % de las solicitudes, porque AI Gateway depende de Workers KV para las configuraciones de clientes y las internas; la interrupción general duró 2 horas y 28 minutos. El análisis posterior de OpenRouter sobre las interrupciones del 17 y el 19 de febrero de 2026 indica que los incidentes duraron 38 y 35 minutos después de que fallara una dependencia de almacenamiento en caché de terceros, generaron errores 401 de «Usuario no encontrado» y dieron lugar a medidas correctivas como los interruptores de circuito y la devolución de errores 503, en lugar de errores 401, cuando los problemas de infraestructura impiden consultar la autorización.

Opciones de implementación, precios y características de los proveedores

La guía presenta cuatro opciones de implementación. Los equipos pueden desarrollar una puerta de enlace mínima internamente —que acepte solicitudes, compruebe la clave de quien las envía, añada la credencial del proveedor, reenvíe la llamada y registre el resultado— o alojar por su cuenta una puerta de enlace de código abierto; entre las opciones menciona LiteLLM, Bifrost y Helicone. Entre las puertas de enlace gestionadas figuran Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter y la puerta de enlace alojada de Portkey. Una cuarta opción consiste en ampliar una puerta de enlace de API que la empresa ya utilice; entre los ejemplos se incluyen Kong AI Gateway, las políticas de puertas de enlace de IA de Apigee y la puerta de enlace de IA de Azure API Management.

En cuanto al costo, la guía señala que los gateways de LLM van desde software de código abierto gratuito hasta planes de pago que comienzan en torno a los 50 dólares al mes, con precios personalizados para empresas, y que algunos cobran un porcentaje en su lugar: según indica, el plan Estándar de OpenRouter añade un 5,5 % a las compras de crédito.

La guía concluye con respuestas específicas sobre cada proveedor. Señala que Amazon Bedrock AgentCore Gateway admite llamadas a modelos mediante lo que AWS denomina «objetivos de inferencia», lo que permite a las aplicaciones usar un único endpoint para acceder a proveedores como Amazon Bedrock, OpenAI y Anthropic. Indica que la propia Agent API de Perplexity es compatible con la interfaz Responses API de OpenAI, por lo que los equipos pueden reutilizar las bibliotecas cliente de OpenAI que ya tienen, y que Agent API permite a los usuarios enumerar hasta cinco modelos, incluidos modelos de distintos proveedores, en el orden que prefieran. La guía también menciona Numbat, el proyecto de código abierto de Perplexity, que se conecta con agentes compatibles mediante hooks locales y puede inspeccionar las acciones previstas, como comandos de shell o escrituras de archivos, antes de que se ejecuten; el bloqueo es opcional y está desactivado de forma predeterminada.