Agent Compute Engine: Google da a cada agente de Gemini su propia micro VM aislada por hardware

Google ha puesto encima de la mesa el elefante que llevaba dos años en la habitación de los agentes IA: dónde se ejecuta exactamente el código que genera un LLM y quién lo aísla del resto de tu sistema. Agent Compute Engine da a cada agente de Gemini su propia micro máquina virtual aislada por hardware. No es una capa de permisos más ni un sandbox de juguete: es un cambio del modelo de ejecución. Y, si lees solo el titular, te pierdes la mitad de la noticia.

TL;DR: Google lanza Agent Compute Engine: cada agente de Gemini corre en su propia micro VM aislada por hardware, no en un contenedor compartido. La noticia real no es el aislamiento, es la gobernanza extendida a cloud, híbrido y on-premises. Para un CTO, esto convierte a los agentes en activos auditables y desplegables fuera de Google Cloud. El coste por agente sube; la superficie de ataque, baja.

Aislamiento por hardware: qué significa de verdad y qué no

Una micro VM no es un contenedor con más flags de seguridad. Un contenedor comparte kernel con el resto de vecinos del nodo; si el kernel tiene un fallo —y los tiene, todos los meses—, el aislamiento se cae como un castillo de naipes. Un hipervisor no. Cuando Google dice "aislada por hardware", está diciendo que el agente y sus vecinos no comparten espacio de kernel, lo que en la práctica reduce drásticamente la clase de exploits que puede encadenar un agente comprometido o simplemente alucinado.

Esto importa porque los agentes IA no son funciones deterministas: ejecutan código generado en tiempo real, con acceso a herramientas, credenciales y APIs. Un prompt injection que consiga que el agente lance un curl a un endpoint interno ya no es un problema teórico de seguridad; es una exfiltración con fecha y hora. La micro VM no impide el injection, pero sí limita el radio de explosión a la máquina virtual de ese agente concreto.

A diferencia de lo que sugiere el anuncio, esto no es nuevo en la industria. AWS lleva años usando Firecracker para funciones y contenedores serverless, y gVisor lleva tiempo en el ecosistema de Google. La novedad es el empaquetado: Google está diciendo que el aislamiento fuerte pasa de ser una decisión de infraestructura que tú montas a ser una propiedad por defecto del runtime de agentes. Y eso, para el 90% de los equipos que hoy despliegan agentes autónomos con contenedores compartidos, es la diferencia entre un diseño defendible ante un comité de riesgos y uno que no lo es.

El coste oculto: la densidad se cae y tu factura sube

Seamos claros, porque nadie en el anuncio lo va a decir: una micro VM por agente es más caro que un contenedor por agente. Punto. El overhead de memoria por instancia es mayor, los tiempos de arranque en frío son peores y la densidad por nodo cae. Si tu arquitectura actual corre 200 agentes en 8 pods, prepárate para replanificar la capacidad.

Hay una tabla que todo CTO debería tener en la cabeza antes de firmar la migración:

Modelo de aislamiento	Aislamiento real	Overhead por instancia	Densidad	Coste relativo	Cuándo usarlo
Proceso compartido	Nulo	Muy bajo	Muy alta	€	Prototipos, nunca producción
Contenedor (kernel compartido)	Medio	Bajo	Alta	€€	Agentes internos de bajo riesgo
Micro VM (Firecracker/gVisor-style)	Alto	Medio	Media	€€€	Agentes con herramientas y credenciales
VM dedicada	Muy alto	Alto	Baja	€€€€	Agentes regulados, multi-tenant sensible

La pregunta que un product lead debería hacer a Google no es "¿cuánto aísla?", sino "¿cuánto cuesta el agente inactivo?". Un agente que espera eventos 20 horas al día no debería facturar como una VM encendida. Si Agent Compute Engine resuelve el arranque en frío con snapshots o pausa la micro VM entre invocaciones, el coste se puede contener; si no, el TCO de un despliegue mediano se te va a multiplicar por dos o tres sin que el negocio vea una función nueva. Ese es el tipo de detalle que separa una arquitectura de agentes sostenible de una demo carísima.

La gobernanza es la noticia de verdad: híbrido y on-prem

Léelo otra vez: el resumen de The Decoder menciona que Google amplía las capacidades de gobernanza para gestionar agentes en entornos cloud, híbridos y on-premises. Ahí está la jugada estratégica, no en la micro VM.

Durante 2025 y buena parte de 2026, el despliegue serio de agentes IA en banca, seguros y salud ha estado bloqueado por una pregunta simple: ¿puedo tener el plano de control de mis agentes dentro de mi perímetro? Si el runtime solo existe en el cloud del proveedor, la respuesta era no, y el proyecto moría en el comité de seguridad. Que Google extienda la gobernanza a on-premises implica aceptar que el valor no está en encerrar el cómputo, sino en controlar el ciclo de vida del agente: identidad, políticas, auditoría, revocación.

Esto reposiciona a Google frente a Microsoft y AWS en un terreno incómodo para todos: el agente como objeto de IT, con inventario, propietario y bitácora, igual que un servidor o una service account. Y explica por qué el anuncio llega justo cuando los grandes bancos de EE. UU. están empezando a bloquear agentes que acceden con credenciales de clientes. El problema no es que el agente sea tonto; es que no hay forma de distinguir un agente legítimo de una sesión robada. Un runtime con identidad propia por agente y aislamiento por hardware es la respuesta técnica a ese agujero, aunque llegue después de que el agujero haya sido noticia.

Qué debería cambiar en tu arquitectura a partir de mañana

Para las empresas que buscan una agencia de IA en Madrid para llevar agentes a producción, este anuncio simplifica una conversación que hasta ahora era incómoda: ya no hay que justificar por qué el aislamiento fuerte es un requisito, porque viene en el runtime. Para el ecosistema de agencias de IA en Barcelona, el efecto es el contrario: sube el listón. Montar un agente con LangChain y un contenedor ya no impresiona a nadie; lo que se paga es saber diseñar políticas de gobernanza, límites de credenciales y trazas auditables.

Tres implicaciones concretas que yo metería en el roadmap de cualquier equipo con agentes en producción:

1. Identidad por agente, no por servicio. Si tu agente comparte la API key del backend, el aislamiento por hardware no te salva de nada. Cada agente debería tener su propia identidad con permisos mínimos y rotación.
2. Presupuesto de capacidades antes de presupuesto de tokens. El coste del cómputo aislado se planifica por agente activo, no por millón de tokens. Los equipos de finanzas van a preguntar por esto y la respuesta "depende" no cuela.
3. Auditoría como producto, no como logs. Si Google te da gobernanza, exige trazabilidad exportable a tu SIEM. Un panel bonito en la consola del proveedor no pasa una auditoría externa.

El detalle que separa a un equipo maduro de uno que va de compras: preguntar qué pasa cuando el agente se porta mal. ¿Se puede congelar una micro VM sospechosa y hacer forense? ¿Se puede revocar sin matar el resto del enjambre? Si la respuesta es "sí, pero solo en la consola de Google", no tienes gobernanza, tienes dependencia.

El mercado español: dónde está la ventaja real

Aquí hay que ser honesto con el contexto local. La mayoría de empresas españolas que están desplegando agentes IA no tienen un problema de hipervisor; tienen un problema de casos de uso y de datos. Dicho eso, la presión regulatoria —AI Act, NIS2, requisitos de terceros en banca— va a hacer que el aislamiento por hardware deje de ser un "nice to have" y se convierta en una línea del cuestionario de proveedores. Cuando eso pase, quien tenga el runtime resuelto podrá firmar contratos que otros no podrán ni licitar.

Ahí es donde la consultoría IA con criterio técnico va a marcar diferencia frente al integrador que solo revende licencias. Y donde muchas agencias de IA en Valencia y el resto del arco mediterráneo van a encontrar un nicho: migrar agentes que hoy viven en contenedores compartidos a arquitecturas con identidad y aislamiento fuertes, con precio cerrado y sin reescribir el prompt engineering. Es trabajo poco glamuroso y muy facturable.

Mi predicción: el aislamiento se convierte en commodity y la gobernanza, en el negocio

En doce meses, "micro VM por agente" será una casilla más en la tabla comparativa de los tres hiperescaladores. Nadie ganará contratos por eso. Lo que sí decidirá las renovaciones es si el cliente puede demostrar ante su auditor que sabe qué agente hizo qué, con qué credenciales y durante cuánto tiempo, en un entorno que puede estar a medio camino entre su CPD y el cloud. Google ha movido primero en el plano del runtime, pero la partida real se juega en el plano de control.

Y ahí hay una pregunta incómoda para todos los que hoy venden agentes IA como si fueran chatbots con esteroides: si el aislamiento y la identidad se vuelven gratis por defecto, ¿qué queda de tu propuesta de valor? La respuesta, para bien o para mal, es el criterio. El código lo escribe cualquiera; la arquitectura que aguanta una auditoría, no.

Preguntas frecuentes sobre Agent Compute Engine

¿Qué es Agent Compute Engine de Google?

Es un entorno de ejecución presentado por Google para agentes de IA, en el que cada agente de Gemini se ejecuta en su propia micro máquina virtual aislada por hardware. Incluye además capacidades de gobernanza ampliadas para gestionar agentes en cloud, entornos híbridos y on-premises.

¿En qué se diferencia una micro VM de un contenedor para agentes IA?

Un contenedor comparte kernel con el resto de procesos del nodo, por lo que un fallo de kernel o un exploit encadenado puede saltar entre vecinos. Una micro VM introduce una capa de hipervisor: el agente y el resto del sistema no comparten espacio de kernel, lo que reduce el radio de impacto si el agente ejecuta código malicioso o es víctima de un prompt injection.

¿Puedo ejecutar Agent Compute Engine on-premises?

Según el anuncio recogido por The Decoder, Google amplía la gobernanza para gestionar agentes en cloud, híbrido y on-premises. Eso no significa necesariamente que el runtime completo viva en tu CPD, pero sí que el plano de control y las políticas pueden operar dentro de tu perímetro, que es lo que exigen los comités de seguridad de sectores regulados.

¿Cuánto encarece esto el coste por agente?

No hay cifras públicas en el anuncio, pero por diseño una micro VM por agente implica mayor overhead de memoria, peor densidad por nodo y arranques en frío más lentos que un contenedor. La variable crítica no es el coste por hora, sino cuánto cuesta un agente inactivo: si el runtime no pausa o suspende instancias ociosas, el TCO de un despliegue mediano puede duplicarse o triplicarse.

¿Merece la pena migrar mis agentes actuales a este modelo?

Depende del riesgo del caso de uso. Si tus agentes solo leen datos públicos, el contenedor sigue siendo razonable. Si manejan credenciales, ejecutan herramientas con acceso a sistemas internos o tocan datos personales, el aislamiento por hardware y la identidad por agente dejan de ser un lujo y pasan a ser un requisito defendible ante auditoría. El coste de la migración se compara contra el coste de un incidente, no contra la factura mensual actual.

Temas relacionados en agentes.ai

Si quieres aplicar lo que lees en tu empresa, estos son puntos de partida útiles dentro de agentes.ai:

• Directorio de agencias de agentes autónomos
• Agencias de IA en Málaga y en Bogotá
• Explora el directorio completo de agencias de IA
• Sigue las últimas noticias de IA en tiempo real