Arquitectura de Puertas de Enlace de IA: Proxying de Flujos de Trabajo Agenticos y Tráfico MCP

Las puertas de enlace API tradicionales fallan cuando agentes autónomos inician 50 llamadas en cascada a herramientas al mismo tiempo. Aquí se explica cómo desplegar proxies inversos nativos de IA para cachear cadenas de razonamiento, enrutar tráfico MCP y limitar agentes descontrolados — y por qué la historia de seguridad se ha vuelto mucho más compleja de lo que el pitch original de la puerta de enlace anticipaba.

---

Para 2026, el panorama de IA ha cambiado definitivamente de chatbots estáticos de prompt-respuesta a flujos de trabajo agenticos autónomos y de múltiples pasos. Los modelos de lenguaje grandes ahora actúan como motores de razonamiento que consultan bases de datos, activan APIs externas y ejecutan código complejo de forma independiente. Este salto arquitectónico ha puesto en evidencia una falla crítica en la infraestructura de red empresarial tradicional: las puertas de enlace API heredadas estaban diseñadas para tráfico REST lineal, predecible, 1:1 request-response. No están preparadas para manejar el tráfico errático, de alto volumen y con tokens pesados generado por agentes de IA autónomos.

Cuando un solo prompt de usuario puede desencadenar docenas de llamadas en cascada a modelos y herramientas, el perímetro de la red requiere un intermediario especializado. Aquí entra el proxy de puerta de enlace IA: un proxy inverso nativo de IA situado en el borde de la red para gestionar cache semántico, enrutar tráfico inteligente de LLM y el creciente volumen de tráfico del Model Context Protocol (MCP), además de bloquear una clase completamente nueva de ataques a la cadena de suministro que las puertas heredadas nunca fueron diseñadas para entender.

---

El Catalizador del Cambio: El Protocolo de Contexto del Modelo

Para entender por qué las puertas de enlace IA se han vuelto imprescindibles, hay que comprender cómo fluye el tráfico agentico en 2026. El principal impulsor es MCP.

Anthropic introdujo MCP el 25 de noviembre de 2024, liberando la especificación (versión 2024-11-05) junto con SDKs en Python y TypeScript. El protocolo abordó un problema fundamental de escalabilidad: antes de MCP, los desarrolladores tenían que crear conectores personalizados y específicos de cada proveedor para cada herramienta que un LLM necesitaba acceder. MCP resolvió esto ofreciendo una interfaz universal y de estándar abierto para que los sistemas de IA se integren con fuentes de datos externas — descrito en la prensa como un “USB-C para IA”.

La curva de adopción fue rápida. En tres meses, el ecosistema produjo más de 1,000 servidores MCP construidos por la comunidad. Para abril de 2025, las descargas superaban los 8 millones mensuales, desde unas 100,000 en el lanzamiento. A finales de 2025, había más de 5,800 servidores MCP y 300+ clientes MCP disponibles, con soporte de plataformas empresariales como SAP, Oracle y Docker, junto a los patrocinadores originales en Google, OpenAI y Microsoft.

La gobernanza siguió a la adopción. En diciembre de 2025, Anthropic donó MCP a la Fundación de IA Agentica (AAIF), un fondo dirigido bajo la Linux Foundation, cofundado por Anthropic, Block y OpenAI. Este movimiento formalizó MCP como infraestructura neutral de proveedores en lugar de un protocolo de un solo vendedor. La iniciativa también recibió una actualización importante en su especificación en el aniversario de un año, introduciendo flujos de trabajo asincrónicos, el modo URL para flujos OAuth seguros y muestreos en el servidor MCP con herramientas — permitiendo que los servidores MCP ejecuten sus propios bucles agenticos bajo el presupuesto de tokens del usuario sin exponer credenciales al cliente.

La capa de transporte del protocolo usa JSON-RPC 2.0 sobre dos canales: entrada/salida estándar (stdio) para ejecución local, y Eventos enviados por el servidor (SSE) o HTTP en streaming para conexiones remotas. La arquitectura está explícitamente desacoplada en tres roles:

• MCP Host — la aplicación que ejecuta el LLM (un IDE, una interfaz conversacional o un servicio backend automatizado).
• MCP Client — un enrutador en el host que traduce solicitudes del LLM al formato de MCP.
• MCP Server — el servicio externo que expone capacidades (herramientas, recursos o prompts) al LLM.

Gracias a MCP, un agente autónomo puede descubrir y conectarse dinámicamente a sistemas empresariales en tiempo real. Esta facilidad de conectividad es una espada de doble filo. Hace rutinarias operaciones multi-sistema muy complejas, pero también significa que un solo prompt puede extenderse en un árbol masivo de llamadas API interdependientes — y en una superficie de ataque no trivial.

---

La Anatomía de un Colapso Agentico: Un Estudio de Caso IIoT

Para visualizar la tensión que los flujos de trabajo agenticos ejercen en la infraestructura de red, consideremos una implementación empresarial basada en la duplicación industrial y el tunelado de sensores locales a gemelos digitales en la nube.

Un agente de IA especializado tiene la tarea de monitorear una red de sensores del Internet Industrial de las Cosas (IIoT). El agente escucha un flujo continuo de telemetría tunelado directamente desde la planta. Al detectar una anomalía en los datos vibratorios, el LLM del agente razona que necesita más contexto — y, sin intervención humana, ejecuta la siguiente cascada mediante llamadas a herramientas MCP:

1. Consulta una base de datos de series temporales para 72 horas de lecturas históricas.
2. Invoca un LLM de resumen ligero para digerir registros de mantenimiento.
3. Activa una herramienta de simulación física a través de un servidor MCP.
4. Llama a un pipeline de renderizado NVIDIA Omniverse para actualizar y visualizar el gemelo digital de la maquinaria afectada en tiempo real.
5. Redacta y envía una carga útil de alerta a un canal de Slack empresarial.

En una fracción de segundo, un disparador de anomalía ha producido más de 50 llamadas API distintas, múltiples invocaciones de LLM que consumen cientos de miles de tokens, y una tarea pesada de renderizado computacional.

Si este tráfico pasa por una puerta de enlace API estándar, el sistema se vuelve ciego. Una puerta heredada solo ve tráfico HTTP, pero no entiende tokens. No puede diferenciar entre una lectura trivial de base de datos y un paso de razonamiento intensivo en LLM. El resultado es agotamiento de límites de tasa, picos en facturación por llamadas redundantes y fallos en la pipeline, ya que el agente queda bloqueado por los proveedores de LLM upstream por inundación de solicitudes.

---

Entrada del Proxy de la Puerta de Enlace IA

Un proxy de puerta de enlace IA es una capa middleware diseñada para gobernar el tráfico de IA. Situado como un proxy inverso entre el MCP Host y los diversos LLM y Servidores MCP, intercepta, analiza y gestiona cada etapa del flujo de trabajo agentico.

La generación actual de puertas de enlace nativas de IA — incluyendo Bifrost (de Maxim AI, Apache 2.0, en Go), LiteLLM (MIT, en Python, más de 33,000 estrellas en GitHub), Portkey (que lanzó su versión completa de código abierto en marzo de 2026), Kong AI Gateway (ahora en versión 3.14), y el proyecto agentgateway de la Linux Foundation — todos son fluidos en el lenguaje de IA. Rastrean el uso en tokens en lugar de bytes, inspeccionan los payloads de prompts y aplican políticas basadas en la intención semántica en lugar de solo la URL.

La elección arquitectónica entre estos gateways tiene consecuencias reales en rendimiento. Los gateways en Python como LiteLLM añaden aproximadamente 8–50 ms de sobrecarga por solicitud, aceptable para cargas moderadas, pero que empieza a acumularse bajo cargas sostenidas por encima de ~250–300 RPS por instancia. Los gateways en Go como Bifrost publican una sobrecarga de aproximadamente 11 µs a 5,000 RPS — una diferencia de varias órdenes de magnitud que importa en pipelines sensibles a la latencia como el escenario IIoT mencionado.

Al desplegar un gateway de IA en el borde de la red, las empresas recuperan control mediante tres pilares fundamentales: Cacheo Semántico, Enrutamiento Inteligente y Limitación de Agentes Descontrolados. Un cuarto pilar — seguridad contra clases de ataques específicos de MCP — ha adquirido igual importancia y se explica en detalle a continuación.

---

Pilar 1: Cacheo Semántico en el Borde de la Red

En flujos de trabajo agenticos, los LLMs entran frecuentemente en bucles cognitivos donde repiten las mismas preguntas o consultan los mismos datos mientras resuelven un problema de múltiples pasos. Pagar a un proveedor comercial de LLM por consultas idénticas o casi idénticas es un gasto innecesario en cómputo y costo — y añade latencia inaceptable en sistemas en tiempo real. Un estudio de caso publicado encontró que implementar cacheo semántico redujo los costos de LLM en un sistema de soporte al cliente en un 69%.

El cacheo semántico resuelve esto sirviendo solicitudes agenticas idénticas o lógicamente similares directamente desde la caché del gateway. A diferencia del cacheo tradicional — que requiere una coincidencia byte por byte perfecta — el cacheo semántico entiende el significado de un prompt.

Los gateways de IA modernos despliegan una arquitectura de cacheo de doble capa:

Capa 1 — Coincidencia exacta por hash. El gateway hashéa el prompt entrante. Si el agente pregunta, “¿Cuál es la temperatura actual de la Turbina 4?”, el gateway devuelve instantáneamente la respuesta cacheada sin sobrecarga.

Capa 2 — Búsqueda por similitud vectorial. Si el agente reformula ligeramente la misma consulta en un ciclo posterior — “Dame la lectura de temperatura de la cuarta turbina” — el gateway genera una incrustación del nuevo prompt y la compara con consultas previamente cacheadas en un almacén vectorial de alta velocidad (Redis, Qdrant o Milvus). Si la puntuación de similitud semántica supera un umbral configurado (típicamente 0.85 o más), el gateway evita el LLM por completo y sirve la respuesta cacheada.

LiteLLM soporta modos de cache redis-semantic y qdrant-semantic. Portkey ofrece una de las implementaciones de cacheo semántico más maduras en la categoría de gateways gestionados. Cloudflare AI Gateway actualmente cubre cacheo exacto en su borde global, con TTL configurable vía encabezados HTTP; el cacheo semántico completo (similitud vectorial) aún no está en la oferta gestionada a mediados de 2026.

Para tráfico MCP de alto volumen, el cacheo semántico marca la diferencia entre una aplicación en tiempo real funcional y un prototipo insostenible.

---

Pilar 2: Enrutamiento de Tráfico LLM y Planes de Respaldo

Los agentes autónomos no están ligados a un solo modelo. Una arquitectura agentica madura usa un conjunto de LLMs, cada uno adecuado para una subtarea específica. Codificar esa lógica de enrutamiento en el propio agente crea un sistema frágil: si un proveedor se cae, el agente falla.

Un gateway de IA abstrae esta complejidad. El agente envía todas las solicitudes a un único endpoint unificado (normalmente una API compatible con OpenAI), y el gateway toma decisiones de enrutamiento dinámico en milisegundos.

Enrutamiento dinámico de modelos. El gateway inspecciona el payload y lo envía al destino óptimo. Tareas de clasificación simples — como categorizar la gravedad de una alerta de sensor — se enrutan a modelos rápidos y económicos. Tareas complejas de razonamiento o generación de código se dirigen a modelos pesados. Kong AI Gateway 3.10 y posteriores implementan enrutamiento semántico mediante el plugin AI Proxy Advanced, que puede distribuir solicitudes según la similitud semántica entre el prompt y una descripción configurada del dominio de especialidad de cada modelo. Portkey soporta enrutamiento a más de 200 proveedores de LLM desde un solo panel de control.

Resiliencia y cadenas de respaldo. Las caídas y limitaciones de tasa en las APIs de LLM son una realidad en producción — OpenAI tuvo tres caídas mayores en 2025; Anthropic experimentó periodos de limitación de tasa en horas pico. Los gateways de IA implementan seguimiento continuo de salud y cadenas de respaldo automáticas. Cuando el proveedor primario devuelve un timeout o un 429 Too Many Requests, el gateway redirige de forma transparente a un proveedor secundario. El agente no se entera de la falla; recibe los datos solicitados y continúa su flujo.

Tráfico agente a agente (A2A). Para abril de 2026, el problema de enrutamiento se había expandido más allá de llamadas a LLM. Kong’s AI Gateway 3.14 introdujo Kong Agent Gateway, convirtiéndose en el primer gateway de producción que gestiona nativamente los tres tipos de tráfico en un control unificado: llamadas a LLM, llamadas a herramientas MCP y comunicación A2A mediante el protocolo A2A (lanzado inicialmente por Google en abril de 2024). El Emerging Tech Adoption Radar de Gartner 2026 señala que “a medida que las interacciones agente a agente se vuelven más prevalentes, los gateways de IA se convierten en la columna vertebral de una adopción segura y escalable de IA.” La iniciativa agentgateway de la Linux Foundation — respaldada por contribuyentes de Microsoft, AWS, Cisco, Adobe, Huawei y Apple — busca el mismo objetivo desde un diseño de código abierto y política de gobernanza basada en Open Policy Agent (OPA) para autorización granular.

---

Pilar 3: Limitación de Agentes Descontrolados y Enforzamiento de Guardrails

El aspecto más peligroso de los flujos de trabajo agenticos es la potencial espiral fuera de control. Un agente descontrolado ocurre cuando un LLM malinterpreta un mensaje de error, hallucina una solución y activa repetidamente herramientas MCP en un ciclo rápido. En un entorno no gestionado, un agente descontrolado puede hacer miles de llamadas API costosas en minutos, o ejecutar operaciones destructivas contra bases de datos empresariales.

Los gateways de IA actúan como un sistema de respaldo mediante gobernanza granular y consciente de tokens.

Limitación de tasa basada en tokens. Los límites estándar de solicitudes por minuto no sirven cuando una sola solicitud puede consumir entre 100 y 100,000 tokens. Los gateways de IA aplican límites de Tokens por Minuto (TPM) por clave virtual, por persona del agente o por proyecto. Bifrost implementa una jerarquía de presupuestos de cuatro niveles: Cliente → Equipo → Clave Virtual → Configuración del Proveedor, aplicando límites de gasto en cada nivel. Si el agente de diagnóstico IIoT aumenta repentinamente su consumo de tokens, el gateway limita la pipeline antes de agotar el presupuesto empresarial.

Control de acceso a herramientas MCP. Los gateways implementan Control de Acceso Basado en Roles (RBAC) a nivel de herramientas MCP. Aunque un agente puede tener acceso de descubrimiento a varios servidores MCP, el gateway aplica principios de menor privilegio — permitiendo consultas SELECT para leer telemetría de sensores y bloqueando activamente comandos DROP o UPDATE en bases de datos de producción. Kong AI Gateway 3.12 (lanzado en octubre de 2025) añadió MCP ACLs y genera automáticamente servidores MCP a partir de definiciones REST API existentes, facilitando la exposición rápida de servicios internos a agentes con OAuth centralizado.

Modo Código de Bifrost. Es una optimización notable en esta capa: reduce el consumo de tokens por turno agentico en más del 50%, al simplificar las definiciones de herramientas a esquemas esenciales antes de incluirlas en el contexto del LLM, disminuyendo el radio de explosión de cualquier ciclo descontrolado.

---

Pilar 4: Seguridad contra Clases de Ataques Específicos de MCP

Esta sección no existía en el pitch original de la puerta de enlace. Ahora sí, porque el alcance de ataque de MCP ha sido mapeado metódicamente en los últimos 18 meses, y lo que se ha encontrado es serio.

Envenenamiento de herramientas. Los servidores MCP pueden incrustar instrucciones maliciosas directamente en los metadatos de las herramientas — los campos JSON Schema, descripciones de herramientas y metadatos estructurados recuperados al arrancar. Como el modelo lee estos como instrucciones, un atacante que controle o comprometa un servidor MCP puede escribir directivas en los descriptores que el agente pasará a su LLM, sin sanitización y con plena autoridad ambiental. Esto fue catalogado como una clase distinta a la inyección de prompts en CVE-2025-54136 (MCPoison) y CVE-2025-54135 (CurXecute), ambas divulgadas en 2025. OWASP las clasifica como LLM01 (inyección de prompts) y LLM05 (manejo inadecuado de salida).

El patrón rug-pull. Las definiciones de herramientas MCP pueden mutar tras la instalación. Una herramienta aprobada como segura en despliegue puede redefinirse silenciosamente — redirigiendo claves API, cambiando comandos o interceptando llamadas a herramientas confiables adyacentes — sin que la monitorización superficial detecte cambios. Simon Willison documentó este patrón en abril de 2025 como uno de los riesgos estructurales más insidiosos en el protocolo.

Compromiso de la cadena de suministro vía registros. CVE-2025-6514, un bug crítico de inyección de comandos en mcp-remote (CVSS 9.6), demostró la dimensión de la amenaza en la cadena de suministro. La vulnerabilidad — descubierta por JFrog Security Research y parcheada en mcp-remote versión 0.1.16 — permitía a un servidor MCP malicioso pasar un authorization_endpoint con código malicioso directamente a la shell del sistema, logrando ejecución remota de código en el cliente. Con más de 437,000 descargas y adopción en guías de integración de Cloudflare, Hugging Face y Auth0, una instalación sin parchear era efectivamente una puerta trasera en la cadena de suministro. CVE-2025-49596 (MCP Inspector) fue una vulnerabilidad CSRF separada que permitía RCE simplemente visitando una página web manipulada.

Robo cruzado de herramientas en múltiples servidores. Análisis empírico en siete clientes MCP principales encontró que, con múltiples servidores conectados a un mismo agente, uno malicioso puede anular o interceptar llamadas hechas a uno confiable. Un agente Cursor con acceso privilegiado service-role en Supabase procesó tickets de soporte que contenían SQL incrustado, filtrando tokens de integración en un hilo público. La validación estática insuficiente y el manejo invisible de parámetros fueron causas raíz en la mayoría de los clientes probados.

Qué hace el gateway. Un gateway de IA funciona como la interfaz donde un equipo puede desplegar una única mitigación a miles de agentes simultáneamente. Manteniendo un registro validado y fijado de definiciones de servidores MCP aprobados e interceptando el registro dinámico de herramientas — la vía de registro de mayor riesgo — el gateway limita el radio de explosión incluso cuando un cliente es vulnerable. No reemplaza parches en el cliente ni la higiene del proveedor, pero es la capa donde se puede aplicar escaneo de inyección de prompts, validación de definiciones de herramientas y detección de anomalías conductuales de forma centralizada antes de que las llamadas a herramientas lleguen a sistemas downstream. La ejecución en sandbox (ejecutando clientes y servidores MCP en contenedores Docker) combinada con la aplicación de menor privilegio por parte del gateway es la línea base de defensa en profundidad recomendada por la Cloud Security Alliance.

---

Observabilidad: Reconstrucción de la Cadena de Razonamiento

Depurar un flujo de trabajo agentico fallido es notoriamente difícil porque la lógica no es determinista. Los logs tradicionales muestran que ocurrieron solicitudes HTTP. No muestran por qué el agente tomó esas decisiones.

OpenTelemetry se ha convertido en el estándar de facto para la observabilidad en IA. El Grupo de Interés Especial en GenAI (GenAI SIG), formado en abril de 2024, ha expandido constantemente las convenciones semánticas desde el rastreo básico de llamadas a LLM hasta cobertura completa de agentes. La versión 1.39 de las convenciones semánticas de OTel introdujo atributos específicos de MCP — mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name — que llevan contexto que las convenciones RPC genéricas no capturan. Esto cerró la brecha previamente documentada donde el agente generaba el Trace A y el servidor MCP generaba el Trace B sin propagación entre ellos.

Las convenciones semánticas gen_ai.* ahora estandarizan la captura de atributos del modelo, uso de tokens, latencia, invocaciones de herramientas y pasos de razonamiento del agente en toda la árbol de llamadas. El producto de observabilidad de LLM de Datadog añadió soporte nativo para OTel GenAI SemConv (v1.37) en diciembre de 2025. New Relic lanzó soporte de monitoreo MCP en 2025. Múltiples proveedores de identidad — Auth0, Okta, WorkOS — ofrecen integraciones de autenticación empresarial específicamente para despliegues MCP.

Los gateways de IA que exportan telemetría vía OTel permiten a los desarrolladores reconstruir exactamente por qué un agente eligió una secuencia de llamadas a herramientas, qué fue servido desde caché, qué proveedor se usó en un respaldo y dónde se detuvo el flujo — toda la cadena de razonamiento en lugar de un montón de logs HTTP desconectados.

---

Selección de Gateway en la Práctica

Ningún gateway único es la opción correcta en todos los perfiles de despliegue:

Gateway	Arquitectura	Mejor uso
Bifrost (Maxim AI)	Go, Apache 2.0, ~11 µs de sobrecarga a 5k RPS	Latencia sensible, industrias reguladas, en-VPC / aislado
LiteLLM	Python, MIT, 100+ proveedores, 33k+ estrellas en GitHub	Mayor cobertura de proveedores; prototipado a cargas moderadas
Portkey	SaaS gestionado (código abierto completo marzo 2026), 200+ proveedores	Equipos que desean operaciones gestionadas, redacción de PII madura + guardrails
Kong AI Gateway 3.14	Nginx + plugins; precio empresarial ~$500–2,500/mes	Organizaciones ya usando Kong en su infraestructura API; LLM + MCP + A2A unificados
Cloudflare AI Gateway	Totalmente gestionado, borde global	Sin infraestructura propia; cacheo exacto; 350+ modelos
agentgateway (Linux Foundation)	Código abierto, motor de políticas OPA, contribuyentes multi-vendor	Gobernanza, estándar abierto, A2A y MCP; comunidad activa

Para equipos que procesan menos de 250 RPS por instancia y necesitan múltiples proveedores, LiteLLM es un punto de partida práctico. Para cargas de producción de alto rendimiento donde cada milisegundo de sobrecarga del gateway se acumula en miles de turnos agenticos concurrentes, una solución en Go o gestionada en el borde es la opción arquitectónica correcta. Para organizaciones que ya usan Kong en toda su infraestructura API y necesitan un único control para tráfico LLM, MCP y A2A, Kong Agent Gateway (GA en 3.14, abril de 2026) cubre toda la ruta de datos sin agregar infraestructura nueva.

---

Conclusión: El Nuevo Perímetro

A medida que MCP supera los 97 millones de descargas mensuales de SDK y los agentes se integran en entornos críticos — desde pronósticos financieros hasta tunelado de sensores industriales en tiempo real — el perímetro de la red debe evolucionar.

La puerta de enlace API tradicional es un artefacto de la era web 2.0. Carece de controles a nivel de tokens, cacheo semántico y — lo más importante — de comprensión de las nuevas clases de ataques que MCP ha introducido. Desplegar agentes autónomos sin un proxy inverso nativo de IA es como conectar una manguera de alta presión a un aspersor de jardín: la infraestructura explotará, y lo hará de formas que la monitorización estándar no detectará hasta que sea demasiado tarde.

Al diseñar sistemas con gateways de IA dedicados, las organizaciones obtienen cuatro ventajas que no ofrecen las infraestructuras heredadas: cacheo semántico que mantiene solventes los pipelines en tiempo real; enrutamiento inteligente que mantiene alta disponibilidad en un panorama de proveedores de LLM volátil; limitación estricta de tokens que evita que sistemas autónomos se vuelvan centros de costos descontrolados; y una capa de intercepción centralizada que aplica validación de definiciones de herramientas y detección de anomalías conductuales antes de que cualquier llamada MCP llegue a sistemas downstream.

En 2026, la puerta de enlace IA ya no es una capa de optimización añadida a una pila API existente. Es el plano de control fundamental para la empresa agentica — y cada vez más, la línea de defensa principal contra clases de ataques que no existían hace dieciocho meses.

---

Registro de Cambios

Correcciones y adiciones fácticas al borrador original:

• Gobernanza de MCP corregida. El borrador indicaba que MCP fue donado a la “Fundación de IA Agentica.” Es correcto, pero incompleto: la AAIF es un fondo dirigido bajo la Linux Foundation, cofundado por Anthropic, Block y OpenAI. La donación ocurrió en diciembre de 2025, no en una fecha anterior no especificada.
• Fecha de lanzamiento de MCP confirmada. 25 de noviembre de 2024; versión de especificación 2024-11-05. Confirmado mediante documentación de lanzamiento de Anthropic.
• Transporte MCP añadido. El borrador omitió el transporte en streaming HTTP añadido en la actualización del aniversario de noviembre de 2025 junto con SSE y stdio. La actualización también introdujo flujos de trabajo basados en tareas, el modo URL para el obtención de OAuth seguro y muestreos en el servidor MCP, todos relevantes para la sección de seguridad.
• Métricas de adopción fundamentadas. “Más de 1,000 servidores MCP construidos por la comunidad” era el estado en febrero de 2025; el borrador implicaba que era la situación actual (2026). La cifra actual es de más de 5,800 servidores, 97 millones+ de descargas mensuales de SDK y 300+ clientes.
• Corrección del panorama de gateways. El borrador solo mencionaba “Bifrost, Cequence o Kong AI Gateway.” Cequence es una plataforma de seguridad API, no un gateway de IA — eliminado. Se añadieron LiteLLM, Portkey, Cloudflare AI Gateway y el proyecto agentgateway de la Linux Foundation.
• Figuras de latencia en Python vs Go. LiteLLM: ~8–50 ms de sobrecarga. Bifrost: ~11 µs a 5,000 RPS. Estas cifras provienen de benchmarks publicados (Maxim AI, marzo 2026) y son relevantes para el caso de uso en tiempo real IIoT.
• Referencias a versiones de modelos actualizadas. El borrador citaba “Claude 3.7 Haiku” y “Claude 3.5 Sonnet.” No son nombres de producto; se reemplazaron por lenguaje neutral de arquitectura.
• Corrección de versiones de Kong AI Gateway. El borrador implicaba que la versión de Kong era la actual; ahora se refleja el cronograma de lanzamientos: 3.8 (diciembre 2025, cacheo semántico + MCP ACLs), 3.10 (abril 2025, RAG automatizado + balanceo de carga basado en tokens), 3.12 (octubre 2025, MCP ACLs + soporte para código de Claude), 3.14 (14 de abril de 2026, Kong Agent Gateway con soporte A2A, GA).
• Precio de Kong añadido. Kong Konnect: aproximadamente $500–2,500/mes; enterprise bajo solicitud.
• Sección del protocolo A2A añadida. El protocolo A2A, lanzado por Google en abril de 2024 y ahora implementado en producción en Kong 3.14 y agentgateway, es un avance material ausente en el borrador original.
• Pilar de seguridad completo (Pilar 4). El borrador no discutía vulnerabilidades específicas de seguridad en MCP. Se añadió: envenenamiento de herramientas (CVE-2025-54136, CVE-2025-54135), mutación rug-pull, compromiso en la cadena de suministro en CVE-2025-6514 en mcp-remote (CVSS 9.6), y el incidente de inyección de prompts en Cursor/MongoDB (mediados de 2025). Fuentes: Elastic Security Labs, JFrog, authzed.com, arXiv 2603.22489 (marzo 2026), practical-devsecops.com y TrueFoundry.
• Sección de OpenTelemetry ampliada. El borrador mencionaba “OpenTelemetry” sin detalles. Se añadió: formación del SIG de GenAI (abril 2024), convenciones semánticas específicas de MCP en OTel v1.39 (mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name), soporte de Datadog para OTel GenAI SemConv (diciembre 2025), y el problema de desconexión Trace A / Trace B que v1.39 resolvió.
• Fuente del umbral de cacheo semántico. El umbral de similitud coseno 0.85 descrito en el borrador original es coherente con configuraciones publicadas para cacheo semántico en LiteLLM; se mantiene.
• Figura de ahorro de costos añadida. La reducción del 69% en costos por cacheo semántico citada en un estudio de caso en soporte al cliente (MindStudio, febrero 2026).
• Modo Código de Bifrost añadido. El modo código elimina definiciones de herramientas a esquemas esenciales, reduciendo el uso de tokens en más del 50% por turno agentico; relevante para la discusión sobre limitación de agentes descontrolados.