En junio de 2026, la señal más importante para las empresas no es la llegada de otro LLM ni siquiera la guerra de benchmarks. El verdadero giro, visible en Google Cloud, AWS, Microsoft y Databricks, está en otra parte: el MLOps se convierte en una disciplina de explotación de agentes, con cuatro retos que crecen al mismo tiempo: el contexto de negocio, la gobernanza, la observabilidad y el coste unitario de la inferencia. Cuando todos los grandes actores reorganizan sus anuncios en torno al runtime, la identidad, los gateways, la memoria, la trazabilidad y la evaluación continua, ya no es una moda; es un cambio de capa.
En otras palabras: en 2024, la gran pregunta era qué modelo elegir; en 2026, la cuestión que decide el paso a producción es más bien quién controla el contexto, los permisos, los trazos, los costes y la capacidad de cambiar de proveedor. Microsoft lo dice casi sin rodeos: el cuello de botella ya no es la capacidad de los modelos, sino el contexto compartido de la empresa. Databricks, por su parte, explica que el ciclo agentivo visible es solo una pequeña parte del trabajo y que el resto corresponde a una deuda técnica oculta hecha de seguridad, despliegue, monitoring, coste y calidad. AWS insiste ahora en la mejora continua a partir de los trazos de producción. Google impulsa una plataforma completa para construir, desplegar, gobernar y optimizar agentes.
No es la IA la que entra en el cloud; es el cloud el que vuelve a ser el sistema operativo de la IA.
El giro visible en todos los proveedores
El punto común de los anuncios de esta primavera y de este mes de junio es llamativo. Google Cloud lanzó Gemini Enterprise Agent Platform como una plataforma destinada a construir, escalar, gobernar y optimizar agentes, reuniendo selección de modelos, herramientas de integración, DevOps, orquestación y seguridad en una misma capa. Durante Google Cloud Next ’26, Google también puso en primer plano un Agent Developer Kit basado en grafos, así como Agent Studio para construir, probar y publicar agentes a gran escala.
En Microsoft, el mensaje de Build 2026 es apenas menos explícito. La empresa afirma que el problema ya no es la potencia del modelo, sino la capacidad de ofrecer un contexto de datos coherente a agentes que deben actuar dentro de los sistemas de negocio. La página oficial de Build 2026 destaca, entre sus principales anuncios, piezas que van desde “observability to ROI for AI agents” hasta la gobernanza portable de agentes, pasando por el despliegue y la ejecución a gran escala de Foundry.
AWS, por su parte, ha orientado Bedrock AgentCore hacia una lógica de explotación industrial. Su anuncio del 18 de junio de 2026 sobre las nuevas capacidades de optimización no se centra primero en la creación de agentes, sino en un ciclo en el que los trazos de producción sirven para entender qué ocurre, corregir lo que falla y demostrar que los cambios realmente mejoran el sistema. AWS formula incluso el verdadero riesgo en términos muy claros: las caídas más peligrosas no son las que devuelven un error, sino los fallos silenciosos que solo aparecen después en las quejas de los clientes.
Databricks empuja exactamente la misma lectura, aunque con otras palabras. En su publicación de DAIS 2026, el editor explica que el ciclo agentivo es solo “el 1 %” visible, mientras que el “99 %” restante corresponde al despliegue, la capacidad de tokens, la seguridad, la evaluación, la observabilidad, el contexto y el compartido. Lo más interesante no es tanto el anuncio de producto como el encuadre: para Databricks, el problema del mercado ya no es cómo hacer una demo de agente, sino cómo operar un sistema agentivo fiable.
La lección para un decisor es simple: cuando Google, AWS, Microsoft y Databricks convergen, cada uno con su vocabulario, hacia las mismas piezas —runtime, identidad, memoria, gateways, tracing, scoring, gobernanza— significa que se sale del ciclo “POC + hype” para entrar en un ciclo de arquitectura. El centro de gravedad del MLOps se desplaza, por tanto, del modelo hacia la cadena de explotación.
Por qué el MLOps se convierte en AgentOps
Este desplazamiento cambia la naturaleza misma de la pila técnica. En un MLOps clásico, lo esencial consistía en versionar datos y modelos, desplegar un endpoint, seguir unas pocas métricas y luego relanzar un pipeline de reentrenamiento. En la pila de 2026, además hay que gestionar un runtime de agentes, la memoria a corto y largo plazo, los permisos de acción, las herramientas externas, los trazos de ejecución, la calidad de las respuestas, la conformidad de los comportamientos y la latencia de cadenas multietapa. Google ya documenta esta superposición: Agent Platform ofrece un runtime gestionado, sesiones, una Memory Bank, funciones de logging, tracing y monitoring, además de una identidad por agente.
El detalle más interesante es, sin duda, el auge de la identidad agentiva. En la documentación de Google, Agent Identity se basa en una identidad criptográficamente acreditada, apoyada en el estándar SPIFFE, para autenticar un agente frente a servidores MCP, recursos cloud, endpoints y otros agentes. Dicho de otro modo, el problema ya no es solo “¿quién llama a la API?”, sino “¿qué agente actúa, en nombre de quién y con qué perímetro de derechos?”. Es un cambio importante: la seguridad sube al nivel del comportamiento automatizado.
AWS avanza en la misma dirección con AgentCore Gateway, que transforma APIs, funciones Lambda y servicios existentes en herramientas compatibles con Model Context Protocol, con autenticación de entrada y salida, integraciones listas para usar y control de acceso granular. Esta capa es estratégica porque conecta el mundo de los agentes con el del SI real: CRM, mensajería, tickets, documentación, bases de datos, workflows. El MLOps deja entonces de ser un tema puramente “de modelo” para convertirse en un asunto de plataforma + integración + seguridad.
El otro gran giro es la observabilidad cualitativa. MLflow 3 en Databricks unifica ya el seguimiento, la evaluación y la observabilidad de aplicaciones y agentes GenAI con trazas en tiempo real, scorers, feedback humano y versionado. En producción, Databricks propone un monitoring que ejecuta automáticamente scorers sobre muestras de trazas para evaluar la calidad de forma continua, señal de que ya no se evalúa solo una versión antes del despliegue, sino el comportamiento real después de su puesta en circulación. AWS dice lo mismo de otra forma: AgentCore Observability ofrece métricas en tiempo real sobre el número de sesiones, la latencia, la duración, el uso de tokens y las tasas de error, con filtrado por metadatos para la investigación.
Por último, la propia infraestructura de inferencia se vuelve más “plataforma” que “simple alojamiento GPU”. La CNCF recuerda que el Inference Gateway basado en Gateway API ya está en GA y permite enrutar el tráfico según el nombre del modelo, los adaptadores LoRA y el estado de los endpoints, para compartir mejor los pools de servidores y aumentar la utilización de los aceleradores. Google refuerza este movimiento con la integración de NVIDIA Dynamo en GKE Inference Gateway, al tiempo que anuncia VM G4 fraccionables para dimensionar mejor las cargas. De nuevo, la cuestión ya no es solo dónde encontrar GPUs, sino cómo usar la capacidad de inferencia con disciplina, mutualización y arbitraje fino.
Lo que esto cambia en el plano organizativo es decisivo: el MLOps debe trabajar ahora con seguridad, la plataforma cloud, el data engineering, los equipos IAM, los equipos FinOps y, en ocasiones, el área jurídica. El “AgentOps” no es una nueva palabra de moda; es la prueba de que la explotación de la IA sale del silo de data science para entrar en el núcleo operativo del SI.
El coste oculto que acaba volviendo al presupuesto
Aquí es donde el asunto se vuelve realmente decisivo. Según el State of the Cloud 2026 de Flexera, el 58 % de las organizaciones ya utiliza servicios GenAI de cloud público, el 45 % dice utilizarlos de forma intensiva, el 73 % opera en híbrido, el 49 % recurre ya a unit economics para vincular el gasto cloud a resultados de negocio, y la parte estimada de desperdicio IaaS/PaaS vuelve a situarse en el 29 %. Flexera también señala que el 64 % de las organizaciones mide ahora el cloud más por el valor entregado a negocio que por la mera eficiencia de costes. No es anecdótico: la conversación pasa de “¿cuánto cuesta?” a “¿qué coste por servicio, por uso, por workflow, por equipo, por cliente?”.
Esta evolución es coherente con lo que ya ven las empresas europeas sobre el terreno. Reuters informa de que grupos como Siemens, Renault, Orange o ChapsVision multiplican proveedores para limitar el riesgo de dependencia, pero también porque el coste por token se vuelve cada vez más sensible a medida que los agentes automatizan más tareas. El artículo cita explícitamente el aumento de esta obsesión por el coste unitario y el ejemplo de un presupuesto de tokens consumido mucho más rápido de lo previsto. Incluso los mercados financieros se preocupan ya por el nivel de gasto en infraestructura IA de los hyperscalers, señal de que la cuestión del retorno económico ha salido del círculo técnico.
Conviene añadir un punto a menudo mal entendido: la factura de un sistema agentivo no se reduce al precio de la API del modelo. AWS muestra, en su propia página de pricing de AgentCore, que se añaden costes alrededor del modelo —llamadas al gateway, memoria a corto plazo, almacenamiento de memoria a largo plazo, recuperación de recuerdos, observabilidad— con líneas de coste separadas. Los ejemplos de tarificación publicados por AWS ilustran precisamente esa granularidad: incluso fuera del coste del modelo en sí, la capa de explotación agentiva genera su propia economía.
El buen enfoque presupuestario para un CIO o un CFO ya no es, por tanto, “¿cuánto me cuesta un prompt?”, sino “¿cuál es mi coste completo por agente útil?”. Ese coste completo incluye, como mínimo, el modelo, las herramientas externas, la memoria, el logging, el tracing, la seguridad, los guardrails, el almacenamiento, los datos de contexto y el tiempo humano necesario para la evaluación y la remediación. Si la empresa no sigue esta unidad económica, puede constatar fácilmente adopción sin saber si está creando valor o solo carga cloud.
Por eso el FinOps cambia de naturaleza. Flexera ya no anuncia simplemente funciones clásicas de cloud cost management, sino una capa de AI Cost Management que cubre aplicaciones, agentes, modelos, plataformas de datos y compute. El mensaje implícito es claro: el gasto en IA ya no es un apéndice del gasto cloud; se convierte en una partida de pilotaje distinta, lo bastante compleja como para necesitar herramientas dedicadas.
El cloud IA vuelve a ser una cuestión de soberanía
El otro error de lectura sería tratar el cloud IA como un simple arbitraje técnico entre AWS, Azure y Google Cloud. En Europa, en junio de 2026, el tema también se ha convertido en un problema de continuidad de negocio y de soberanía operativa. La Comisión Europea adoptó el 3 de junio una propuesta de Cloud and AI Development Act, presentada como una palanca para reforzar el ecosistema europeo de cloud e IA, sus inversiones y sus infraestructuras. Al mismo tiempo, el calendario oficial recuerda que el AI Act será plenamente aplicable a partir del 2 de agosto de 2026, con normas de transparencia que entran en vigor en agosto de 2026 y un marco general que refuerza las responsabilidades de proveedores y desplegadores.
Esta dimensión política ya se refleja en las arquitecturas empresariales. Reuters explica que grupos europeos aceleran la diversificación de sus modelos y proveedores tras restricciones de acceso a ciertos servicios estadounidenses, precisamente porque un servicio propietario remoto puede verse limitado por su proveedor y no ser necesariamente operable en los propios servidores del cliente. En este contexto, soberanía no significa autarquía: Siemens, Orange o Renault hablan sobre todo de flexibilidad, mix de proveedores y capacidad de respaldo si un actor corta el acceso o modifica sus condiciones.
Es en este contexto donde hay que leer el anuncio de OVHcloud. Reuters informa de que el grupo francés quiere entrenar modelos de frontera para convertirse en un segundo gran actor europeo del LLM, con un coste estimado de 150 a 200 millones de euros para este nuevo ciclo tecnológico, muy lejos de los mil millones de euros que se mencionaban a menudo antes. Que la iniciativa triunfe o no comercialmente, dice algo importante: la soberanía cloud IA ya no es un discurso institucional abstracto; baja a la estrategia de producto e infraestructura de grandes actores europeos.
Para una empresa, la traducción de negocio de esta tensión es concreta. Una arquitectura “soberana” no es solo una arquitectura alojada en Europa. Es una arquitectura capaz de identificar qué componentes deben ser operables por cuenta propia, qué herramientas deben seguir siendo sustituibles, qué datos de contexto no deben quedar cautivos de un runtime propietario y en qué plazo un agente crítico puede cambiar de modelo o de proveedor. En el momento en que el agente actúa sobre procesos de negocio, la dependencia del proveedor se convierte en una variable de riesgo, no en una simple elección de desarrollo.
La guía útil para decidir ahora
La cuestión, por tanto, no es “¿hay que hacer MLOps para la IA generativa?”, sino qué tipo de explotación se quiere estandarizar. La siguiente guía sintetiza lo que realmente cambian las señales de junio de 2026 para una empresa. Sirve para arbitrar un presupuesto, una hoja de ruta de arquitectura o una elección de proveedor.
| Eje de decisión | Qué cambia en 2026 | Pregunta para el comité |
|---|---|---|
| Arquitectura | La base ya no es un endpoint de modelo, sino un conjunto runtime + memoria + gateway + identidad + trazas + evaluación. | ¿Queremos estandarizar un runtime de agentes único o mantener una capa portable entre varios clouds y frameworks? |
| Gobernanza | La observabilidad se vuelve conductual: tokens, latencia, sesiones, herramientas invocadas, trazas, feedback, scoring continuo. | ¿Qué indicadores debemos exigir antes de cualquier paso a producción: coste, calidad, groundedness, seguridad, tiempo de resolución? |
| Presupuesto | El gasto en IA se vuelve compuesto: modelo, memoria, herramientas, logs, tracing, seguridad, datos, capacidad GPU. Flexera observa el aumento de los unit economics y del desperdicio cloud. | ¿Conocemos el coste completo por agente útil, por recorrido de usuario o por ámbito de negocio? |
| Contexto de negocio | Microsoft insiste en que el cuello de botella ya no es el modelo sino el contexto compartido; Databricks convierte la calidad del contexto y la gobernanza del conocimiento en un pilar de su plataforma. | ¿Qué conjuntos de datos, ontologías, documentos y permisos constituyen nuestra “fuente de verdad” para los agentes? |
| Soberanía | En Europa, la resiliencia pasa por la diversidad de proveedores, la sustituibilidad y la capacidad de operar ciertas piezas localmente; el marco regulatorio se endurece de aquí a agosto de 2026. | Si un proveedor cambia sus reglas de acceso, ¿en cuántos días podemos migrar un agente crítico? |
La consecuencia más práctica es que las compras de cloud IA ya no deberían evaluarse primero por el “mejor modelo disponible”, sino por cinco criterios menos espectaculares y más decisivos: portabilidad del contexto, calidad de la observabilidad, granularidad de los controles, visibilidad de los costes y capacidad de repliegue. Un proveedor puede ser excelente en demostración y débil en industrialización. Ese desfase es precisamente el que empieza a estructurar el mercado.
Lo que ya han entendido los actores más adelantados
La señal que hay que leer con antelación es esta: la próxima batalla de la IA empresarial no girará principalmente en torno al acceso a un mejor modelo, sino a la capacidad de hacer vivir agentes dentro de un marco económico y jurídico sostenible. Las organizaciones que toman ventaja no son solo las que despliegan más rápido; son las que hacen que los agentes sean medibles, cambiables y gobernables. Tratan el contexto como un activo estratégico, el coste como una métrica de producto y la seguridad como una política de acción, no como una lista de accesos.
Conviene, por supuesto, mantener una reserva metodológica. Una parte importante de la señal procede de anuncios de proveedores y documentación de producto; algunas funciones siguen en beta o en preview, como el monitoring de producción de MLflow 3 en Databricks. Eso significa que la adopción real será más lenta y desigual de lo que sugieren los keynotes. Pero esa limitación no cambia el diagnóstico de fondo: cuando los cuatro grandes ecosistemas cloud y data convergen hacia las mismas primitivas técnicas, el movimiento tiene muchas posibilidades de durar.
La frase tesis que merece ser retenida es, por tanto, la siguiente: el verdadero tema del MLOps y del Cloud IA en 2026 ya no es servir un modelo, sino explotar agentes con contexto, pruebas y guardrails. Las empresas que lean esto como un simple asunto de herramientas llegarán tarde. Las que lo vean como una reconfiguración del pilotaje cloud, del control financiero y de la gobernanza operativa estarán mejor posicionadas para absorber la próxima ola.