Google Cloud publicó una guía destinada a orientar a las organizaciones que comenzaron a desarrollar y desplegar agentes de IA. El documento agrupó las principales decisiones técnicas en cuatro etapas relacionadas con construcción, escalamiento, optimización y gobierno, con Gemini Enterprise Agent Platform como base para administrar el ciclo completo.
La propuesta respondió a un problema concreto para las áreas de tecnología. A medida que distintos equipos incorporan agentes, las empresas deben evitar que las herramientas, los datos y los controles de seguridad queden distribuidos entre plataformas desconectadas.
Ivan
Una arquitectura definida desde el primer agente
El primer paso consistió en identificar quién construirá la aplicación y quién utilizará el resultado. Google Cloud diferenció entre usuarios de negocio que trabajan con herramientas sin código, desarrolladores que ensamblan componentes de bajo código e ingenieros que necesitan controlar directamente la lógica, las integraciones y la infraestructura.
La compañía recomendó comenzar con un agente especializado, instrucciones acotadas y acceso limitado a herramientas. Un sistema que intenta cubrir demasiadas funciones puede perder precisión, elevar la latencia y dificultar la identificación de errores, mientras que una arquitectura multiagente debería incorporarse cuando el flujo de trabajo requiera dividir responsabilidades o supere los límites de contexto disponibles.
La elección de la herramienta también dependería del grado de control requerido. La plataforma consideró desde Agent Studio para prototipos de bajo código y Managed Agents API para servicios administrados, hasta Antigravity y Agent Development Kit para desarrollos personalizados y redes multiagente.
Admin
Datos, interoperabilidad y costos de operación
Los agentes empresariales necesitan conectarse con bases de datos, aplicaciones internas, políticas y procesos propios de cada organización. Google Cloud propuso utilizar Model Context Protocol para acceder a esas fuentes, aunque advirtió que la conexión técnica no reemplaza la necesidad de incorporar metadatos, reglas de negocio y contexto que permitan interpretar correctamente la información.
Para comunicar agentes desarrollados con marcos diferentes, la guía destacó el protocolo Agent2Agent. Este estándar permite intercambiar intenciones, estados y resultados entre sistemas independientes, reduciendo la necesidad de crear integraciones específicas para cada combinación de plataformas.
El escalamiento consideró además un entorno administrado capaz de responder a aumentos de demanda, ejecutar dependencias personalizadas y conectarse de forma privada con sistemas corporativos. Agent Runtime cumplió esa función dentro de la propuesta, mientras que la memoria se dividió entre el contexto temporal de una sesión y el almacenamiento persistente de preferencias o resultados anteriores.
El control de costos requirió seleccionar los modelos según la complejidad de cada tarea. Google Cloud recomendó utilizar modelos rápidos o abiertos para operaciones simples, reservar los modelos de razonamiento más costosos para decisiones complejas y limitar el consumo mediante RAG preciso, caché de contexto, topes de iteraciones y código determinista en las etapas previsibles.
Admin
Seguridad y gobierno durante todo el ciclo de vida
Los agentes que ejecutan código, utilizan navegadores o acceden a herramientas externas no deberían operar directamente sobre la red principal de una empresa. La guía planteó aislar estas tareas en entornos temporales y aplicar barreras de seguridad externas al razonamiento del modelo, debido a que las instrucciones escritas en un prompt no constituyen por sí solas un control suficiente para producción.
La identidad fue otro componente central. En los flujos destinados a empleados, Google Cloud propuso utilizar autoridad delegada para que el agente herede los permisos del usuario, respete las restricciones existentes y mantenga un registro auditable de las acciones ejecutadas.
Para controlar la expansión de agentes no supervisados, la arquitectura incorporó un registro central con información sobre responsables, fuentes de datos y herramientas autorizadas. Las políticas de acceso se complementarían con controles semánticos y una puerta de enlace encargada de inspeccionar las interacciones, bloquear infracciones y enviar telemetría a los sistemas de observabilidad.
Model Armor añadió inspección de instrucciones y respuestas para detectar filtraciones de información, inyecciones de prompts, intentos de evasión y contenido restringido. La propuesta cerró el ciclo con evaluación continua, detección de anomalías, control de versiones y despliegues integrados con los procesos de desarrollo existentes, de modo que los agentes puedan administrarse como sistemas empresariales y no como experimentos aislados.
