El gateway de IA se volvió infraestructura obligatoria: lo que dice el reporte de tendencias cloud/DevOps 2026 de InfoQ

El 12 de agosto, InfoQ publicó su reporte anual de tendencias de Cloud y DevOps, un ejercicio que arma cada año con un panel de editores y colaboradores frecuentes discutiendo qué tecnologías subieron de categoría en su gráfico de adopción (basado en el modelo de Crossing the Chasm de Geoffrey Moore) y cuáles siguen siendo apuestas tempranas. La edición de este año tiene un eje claro: la IA dejó de ser una herramienta que cada desarrollador instala por su cuenta y pasó a ser, para las organizaciones que participaron del panel, un problema de arquitectura empresarial que hay que gobernar centralmente. Vale la pena revisar de cerca dos de los movimientos que describe el reporte, porque no son predicciones abstractas: son decisiones que cualquier equipo de plataforma o de arquitectura ya está tomando, con o sin un nombre formal para el problema.

De asistentes individuales a gateways centralizados

El primer cambio que el panel ubicó en la categoría "Innovadores" —la más temprana del gráfico de adopción— es el paso de que cada equipo conecte sus propios modelos a que la organización levante una plataforma de IA interna con un gateway centralizado, un catálogo de modelos aprobados y espacios de trabajo provisionados por equipo. Steef-Jan Wiggers, uno de los editores de InfoQ que participó del panel, lo describió como un modelo hub-and-spoke: "Es básicamente tu gestión de API, pero aplicada a la IA. Apigee lo tiene, Microsoft tiene su API management, pero se puede posicionar como gateway de IA. Detrás tenés el catálogo centralizado de modelos permitidos, y después cada equipo se conecta como un 'spoke' sobre esa plataforma."

La lógica es la misma que ya se aplicó a la gestión de APIs hace una década: si cien equipos negocian cada uno su propio acceso a un proveedor de modelos, la organización pierde control sobre costo, seguridad y cumplimiento al mismo tiempo. Un gateway centralizado permite enrutar pedidos hacia el modelo más barato que cumpla el trabajo, alojar ciertos modelos on-prem por razones de soberanía de datos, y evitar que cada equipo tome su propia decisión de qué proveedor usar. El reporte es honesto en que el patrón todavía es incipiente: cómo se reparte exactamente el modelo hub-and-spoke en la práctica sigue siendo una pregunta abierta para la mayoría de las organizaciones que lo están probando.

El problema de FinOps que nadie resolvió todavía

El segundo hallazgo es más incómodo, y es el que más vale la pena que un equipo técnico se lleve de este reporte: la disciplina de FinOps, ya madura para costos de nube tradicionales (storage, transferencia de datos, cómputo), no tiene todavía una respuesta seria para el gasto en tokens de IA. Matt Saunders, otro de los panelistas, lo puso en términos concretos: "Las herramientas de FinOps te pueden decir cuánto gastó una persona en tokens de Opus, de Fable, de Sonnet. Pero ninguna que yo conozca puede relacionar ese gasto con resultados reales."

Renato Losio agregó un matiz importante: el gasto en IA suele ser un proxy de otra cosa —tiempo de ingeniero ahorrado, velocidad de entrega, calidad de código— lo que lo hace mucho más difícil de optimizar que una partida determinística como una clase de almacenamiento. Y hay una incertidumbre de fondo que el reporte no resuelve pero sí nombra: nadie sabe con certeza si los precios actuales de los modelos están subsidiados para generar dependencia del proveedor, o si reflejan el costo real de largo plazo. Shweta Vohra, que representa a la FinOps Foundation en el panel, describió la escala del problema con una comparación útil: "El caos de los agentes ahora es más grande que el de los microservicios en su momento. Ya resolvimos las piedras grandes del desperdicio en IA y nube. Ahora tenemos muchas piedras chiquitas —tantos agentes— que hay que juntar y ordenar." Según Vohra, esa presión es la razón por la que la FinOps Foundation escindió una Tokenomics Foundation dedicada específicamente a esto, en paralelo a la creación de la Agentic AI Foundation bajo la Linux Foundation.

Un ejemplo de cómo se ve esto en la práctica

Pensemos en una aseguradora mediana —el mismo tipo de organización que suele correr su núcleo transaccional sobre sistemas empresariales consolidados— donde seis equipos distintos empezaron, cada uno por su cuenta, a integrar asistentes de código y agentes de soporte con distintos proveedores de modelos a lo largo del último año. Hoy esa aseguradora tiene seis facturas de IA separadas, seis configuraciones de permisos distintas para los servidores MCP que cada equipo conectó a sus repositorios, y ningún dato que le permita responder si el gasto en tokens del equipo de suscripción de pólizas generó más valor que el del equipo de atención al cliente. Ese es exactamente el escenario que el reporte describe como punto de partida para migrar a un gateway centralizado: no para prohibir que los equipos usen IA, sino para que el costo y los permisos pasen por un solo punto de control antes de escalar a cien equipos en vez de seis.

El propio reporte señala un problema de gobernanza asociado y muy concreto: durante buena parte de 2025 y principios de 2026, el Model Context Protocol (MCP) no tenía autenticación centralizada, así que un agente conectado a un servidor MCP heredaba los permisos de quien lo configuró, sin pasar por el control de identidad y accesos que la organización ya tenía para todo lo demás. Saunders señaló que esa falla fue una de las razones por las que MCP no se adoptó tan rápido como podría haberlo hecho en entornos regulados, y que recién este año empezó a aparecer autenticación centralizada como plugin del protocolo.

Conclusión práctica

Si tu organización tiene más de dos o tres equipos usando asistentes o agentes de IA con proveedores de modelos distintos, el reporte de InfoQ deja tres tareas concretas para esta semana. Primero, hacé un inventario real de qué modelos y qué servidores MCP está usando cada equipo hoy, con qué credenciales y con qué alcance de permisos —es la misma auditoría que ya hiciste alguna vez para accesos de base de datos, y probablemente esté igual de desordenada. Segundo, si tu equipo de plataforma todavía no tiene un gateway de IA ni un catálogo de modelos aprobados, no hace falta levantar la solución completa de una vez: alcanza con empezar por ruteo y logging centralizados, aunque el catálogo de modelos siga siendo permisivo, porque eso ya te da visibilidad sobre gasto y uso real. Tercero, no le pidas a tu herramienta de FinOps algo que hoy no puede darte: relacionar gasto en tokens con resultado de negocio sigue siendo, según el propio panel, un problema sin resolver en la industria — así que en vez de perseguir ese número perfecto, medí algo más simple y verificable, como tokens consumidos por pull request mergeado o por ticket cerrado, y usalo como proxy imperfecto pero honesto mientras la disciplina madura.

Fuente: InfoQ, "InfoQ Cloud and DevOps Trends Report - 2026", por Steef-Jan Wiggers, Matt Saunders, Shweta Vohra, Daniel Bryant, Mark Silvester y Renato Losio, publicado el 12 de agosto de 2026.