La red agencial de Google: cómo Gemini Enterprise, A2A y los agentes de seguridad cambian tu stack de IT
Google no lanzó una herramienta. Lanzó una infraestructura completa para que los agentes IA tengan identidad, permisos, memoria y supervisión. Esto es lo que hay detrás del anuncio.
En este artículo
El problema que nadie quería nombrar
Llevas dos años escuchando que los agentes IA van a cambiar tu empresa. Y llevas dos años viendo lo mismo: demos impresionantes, pilotos que no escalan y una pregunta incómoda que nadie responde en las presentaciones de PowerPoint.
¿Quién controla qué hace cada agente?
No en modo filosófico. En modo concreto: si tienes diez agentes distintos corriendo en tu organización, uno que lee correos, otro que consulta tu CRM, otro que genera informes financieros, ¿sabes qué permisos tiene cada uno? ¿Sabes si alguno está haciendo algo que no debería? ¿Tienes un registro de qué hizo el agente de contabilidad el martes a las 3 de la mañana?
Ese es el problema que Google decidió atacar de frente en Google Cloud Next 26, celebrado entre el 22 y el 24 de abril de 2026. No lanzó una herramienta. Lanzó una infraestructura completa para que los agentes dejen de ser cajas negras autónomas y se conviertan en entidades gestionables, auditables y, sobre todo, controlables.
Gemini Enterprise Agent Platform: el hub central para no perder el control
La Gemini Enterprise Agent Platform es la pieza central del anuncio. Según informó Infosecurity Magazine el 23 de abril de 2026, se trata de un hub centralizado para gestionar tanto agentes fabricados por Google como de terceros, con capacidades nativas de seguridad, registro y pasarela de comunicaciones.
Suena bien en el papel. Pero el detalle que lo hace diferente es uno: cada agente recibe una identidad criptográfica única.
Piénsalo como el DNI de los agentes IA. Hasta ahora, un agente era un proceso que corría en algún servidor y hacía cosas. Punto. No tenía nombre, no tenía historial verificable, no tenía permisos formalmente asignados. Con la Gemini Enterprise Agent Platform, cada agente tiene un ID que mapea directamente a políticas de autorización trazables y auditables. El CEO de Google Cloud, Thomas Kurian, lo presentó como la base del modelo de zero trust para entornos agentivos: verificación en cada paso de la orquestación, sin excepciones.
El Agent Registry: el directorio que tu equipo de seguridad necesitaba
El Agent Registry es el inventario central donde se almacenan todos esos IDs. No es solo una lista de nombres: indexa agentes internos, herramientas y habilidades disponibles en la organización, y da visibilidad real a los equipos de seguridad para rastrear qué está haciendo cada agente en cada momento.
Francis deSouza, COO de Google Cloud, fue directo con el problema que esto resuelve: los equipos de seguridad tienen que identificar tanto los agentes autorizados como los no autorizados que están corriendo en la organización, y gestionar dinámicamente sus derechos de acceso. Y esos derechos pueden cambiar más rápido que los de cualquier empleado humano.
Eso último es importante. Un empleado humano cambia de rol cada pocos años. Un agente puede cambiar de contexto, de herramientas disponibles y de permisos necesarios en cuestión de horas, dependiendo de la tarea que esté ejecutando. Sin un registro central, eso es ingobernable.
El Agent Gateway: una sola puerta para todo el tráfico agentivo
El Agent Gateway es el panel de control unificado para gestionar la flota completa de agentes. Aplica políticas de seguridad consistentes para las interacciones agente-a-agente y agente-a-herramienta, y soporta protocolos abiertos como MCP (Model Context Protocol) y Agent2Agent (A2A).
MCP ya lo conoces si llevas un tiempo siguiendo el sector: es el protocolo que estandariza cómo los agentes acceden a herramientas y fuentes de datos externas. A2A es el complementario: estandariza cómo los agentes se hablan entre sí, independientemente de quién los haya fabricado. Que el Agent Gateway soporte ambos no es un detalle menor, significa que la plataforma no está diseñada para un jardín vallado de Google, sino para entornos empresariales reales donde conviven agentes de Salesforce, SAP, Workday y quien sea.
Model Armor: el guardarraíl que no puedes desactivar
Meter agentes en una empresa sin protección contra ataques adversariales es como conectar un servidor sin firewall. Puedes hacerlo. Pero vas a lamentarlo.
Model Armor es la capa de guardarraíles integrada en la plataforma de seguridad. Protege contra tres vectores concretos: inyección de prompts, filtración de datos sensibles y generación de contenido dañino. No es un add-on opcional que el equipo de IT puede olvidarse de activar; está integrado en la capa de seguridad del agente por defecto.
La inyección de prompts merece un párrafo aparte porque es el ataque más subestimado en entornos agentivos. Funciona así: alguien inyecta instrucciones maliciosas en los datos que el agente va a procesar, un correo, un documento, una entrada de CRM, y el agente las ejecuta como si fueran instrucciones legítimas. Si el agente tiene permisos para enviar correos o modificar registros, el atacante acaba de conseguir exactamente eso sin tocar ningún sistema directamente. Model Armor está diseñado para detectar y bloquear esos patrones antes de que lleguen al modelo.
Detección de anomalías: cuando el agente empieza a actuar raro
La seguridad estática, listas de IPs malas, firmas de malware conocido, no es suficiente para entornos agentivos. Los agentes toman decisiones en tiempo real, encadenan acciones y pueden desviarse de su comportamiento esperado por razones que no están en ninguna lista de amenazas conocidas.
Para eso existe el Agent Anomaly Detection, una de las novedades más técnicamente interesantes del anuncio.
Combina modelos estadísticos con un framework de LLM-as-a-judge. Traducido: hay un LLM que actúa como evaluador del comportamiento de otros agentes. Recibe como input los patrones de razonamiento y acción del agente supervisado, y los evalúa según criterios definidos en un prompt de evaluación. Si el razonamiento del agente empieza a seguir patrones sospechosos, secuencias de acciones inusuales, intentos de acceder a recursos fuera de su scope, cadenas de razonamiento que no corresponden a su función declarada, el sistema lo detecta y lo marca en tiempo real.
Esto se complementa con el Agent Threat Detection existente, que sigue haciendo lo que hacía: monitorizar actividades maliciosas conocidas como reverse shells y conexiones a IPs catalogadas como malas. La combinación de ambas capas cubre tanto amenazas conocidas como comportamientos anómalos no catalogados previamente.
Todo esto se visualiza en el Agent Security Dashboard, integrado en Security Command Center (SCC), que mapea las relaciones entre agentes y modelos, automatiza el descubrimiento de assets y escanea vulnerabilidades en paquetes de OS y lenguajes de programación.
Los números que demuestran que esto no es solo marketing
Google no vino a Cloud Next 26 solo con slides. Vino con un dato concreto que hace difícil argumentar que los agentes de seguridad son todavía cosa del futuro.
El Triage and Investigation agent, lanzado en abril de 2025, procesó más de 5 millones de alertas en el último año. El tiempo medio de análisis manual de una alerta de seguridad era de 30 minutos. Con el agente: 60 segundos.
No es una mejora incremental. Es un cambio de orden de magnitud. Un analista de seguridad que antes podía revisar 16 alertas en una jornada de 8 horas ahora puede supervisar el trabajo del agente sobre cientos. Eso no elimina al analista, alguien tiene que revisar los casos que el agente escala, configurar los criterios de detección y gestionar los falsos positivos, pero cambia radicalmente qué hace ese analista con su tiempo.
A esto se suman tres agentes nuevos para equipos de ciberseguridad, todos integrados en Google Security Operations:
- Threat Hunting agent (en preview): búsqueda proactiva de patrones de ataque nuevos.
- Detection Engineering agent (en preview): identifica gaps de cobertura y automatiza la creación de nuevas detecciones.
- Third-Party Context agent (próximamente): enriquece los workflows con datos externos.
Y para completar el cuadro de inteligencia de amenazas, Google introdujo una funcionalidad de dark web intelligence dentro de Google Threat Intelligence, actualmente en preview, con tests internos que muestran un 98% de precisión analizando millones de eventos externos diarios para identificar amenazas críticas.
El protocolo A2A: por qué importa que los agentes se hablen entre sí
El Agent2Agent (A2A) es quizás el anuncio más estratégico de los que pasaron en Cloud Next 26, aunque sea el que menos titulares generó.
El problema que resuelve es simple: en una empresa real, los agentes no son todos de Google. Tienes agentes de Salesforce, de ServiceNow, de tu proveedor de ERP, de tu equipo interno de IT. Hasta ahora, coordinar esos agentes requería integraciones ad hoc, APIs propietarias y un montón de trabajo de fontanería que alguien tenía que mantener.
A2A define un protocolo estándar para que agentes de distintos fabricantes se comuniquen, deleguen tareas y compartan contexto. Es el complemento natural de MCP: si MCP resuelve cómo un agente accede a herramientas y datos, A2A resuelve cómo un agente le dice a otro agente "ocúpate tú de esta parte del workflow".
"Agents is DeepMind's heritage", dijo Demis Hassabis, CEO de Google DeepMind, citando AlphaGo y MuZero como ejemplos de sistemas agentivos que aprendieron sin reglas explícitas. La infraestructura anunciada en Cloud Next 26 no es un pivot estratégico: es la maduración de una línea de investigación que lleva décadas en marcha.
La existencia de un fondo de 750 millones de dólares para socios de IA agentiva, consultoras y partners de canal para prototipar, construir y desplegar agentes, indica que Google no está apostando solo por el producto, sino por el. Esos 750 millones son para que la gente que vende e implementa tecnología empresarial tenga incentivos concretos para construir sobre esta infraestructura en lugar de sobre la de otro.
Remy: el agente personal que Google tiene en pruebas internas
Mientras todo lo anterior apunta al mercado empresarial, hay un proyecto que apunta directamente al usuario final.
Business Insider filtró la existencia de Remy, un agente personal que Google está probando internamente dentro de la app de Gemini, solo accesible para empleados. Según los documentos internos, Remy es capaz de gestionar tareas de forma proactiva, seguimiento de eventos, aprendizaje de preferencias del usuario, sin que el usuario tenga que pedírselo explícitamente en cada momento.
La diferencia con un asistente de voz convencional es de naturaleza, no de grado. Un asistente responde preguntas. Un agente como Remy toma iniciativa: detecta que tienes una reunión mañana con alguien que no conoces, busca contexto sobre esa persona, prepara un briefing y te lo manda antes de que lo pidas. Usa el protocolo A2A para coordinar con otros agentes y servicios.
La fecha de lanzamiento público no está confirmada. Lo que sí está claro es que su existencia encaja con el cambio estratégico que Google lleva comunicando desde hace meses: pasar de ser un proveedor de información a ser un ejecutor de tareas.
La trampa que nadie menciona en los keynotes
Todo esto suena bien. Demasiado bien, quizás. Y hay un matiz que los keynotes suelen pasar por alto.
La Gemini Enterprise Agent Platform, el Agent Registry, el Agent Gateway, Model Armor, el Anomaly Detection: todo eso es infraestructura. Y la infraestructura solo funciona si alguien la configura, la mantiene y la usa correctamente.
El Agent Registry es tan bueno como el inventario que tu equipo de IT haya construido. Si nadie ha registrado el agente que alguien del departamento de marketing desplegó hace tres meses usando una API key personal, ese agente no existe para el sistema de seguridad. El zero trust funciona cuando todo está en el registro. Si hay agentes fuera del registro, tienes exactamente el mismo problema que antes, solo que ahora con la falsa sensación de que lo tienes controlado.
Francis deSouza lo dijo explícitamente: los equipos de seguridad deben identificar tanto los agentes autorizados como los no autorizados. La herramienta para hacerlo existe ahora. Pero alguien tiene que hacer el trabajo de identificarlos, catalogarlos y mantener ese catálogo actualizado a medida que la organización despliega nuevos agentes.
Los TPU 8t (para entrenamiento) y TPU 8i (para inferencia) que Google también anunció en Cloud Next 26 garantizan que la capacidad de cómputo para escalar estos sistemas está ahí. El cuello de botella no es técnico. Es organizativo.
Lo que cambia en tu stack de IT
Si gestionas tecnología en una empresa mediana o grande, el anuncio de Cloud Next 26 tiene implicaciones concretas que vale la pena entender antes de que tu proveedor favorito te las venda como si fueran nuevas.
Primero, la identidad de los agentes va a convertirse en una extensión natural de la gestión de identidades que ya tienes. IAM (Identity and Access Management) hasta ahora gestionaba personas y aplicaciones. Ahora gestiona también agentes. Eso no es un problema nuevo: es el mismo problema de siempre aplicado a una nueva categoría de entidades. Los equipos que ya tienen madurez en gestión de identidades van a adaptarse más rápido.
Segundo, el soporte para MCP y A2A en el Agent Gateway significa que la apuesta de Google no es por un cerrado. Eso es bueno para las empresas que ya tienen inversiones en herramientas de terceros, pero también significa que la complejidad de integración no desaparece: se estandariza, que no es lo mismo.
Tercero, el dato de los 5 millones de alertas procesadas por el Triage and Investigation agent en un año es el tipo de benchmark que los equipos de seguridad deberían llevar a sus conversaciones presupuestarias. No como argumento para eliminar analistas, sino para justificar la inversión en infraestructura agentiva con números concretos en lugar de promesas de futuro.
El stack de IT no va a cambiar de golpe. Va a cambiar agente por agente, workflow por workflow, hasta que un día mires atrás y te des cuenta de que la mitad de las tareas que antes hacían personas ahora las hacen agentes supervisados por personas. La infraestructura para que eso ocurra de forma controlada es lo que Google acaba de presentar.
