IA en producción en Google Cloud: de Vertex AI a Gemini Enterprise Agent Platform

Si últimamente buscaste Vertex AI y acabaste en algo llamado Gemini Enterprise Agent Platform, no te has perdido: Google lo renombró el 22 de abril de 2026. Las piezas para un agente en producción siguen ahí, muchas con nombres nuevos. Esta es la configuración que montaría hoy: proyectos e identidades de agente separados, un perímetro de VPC Service Controls, RAG Engine sobre tus propios datos, Model Armor delante de cada llamada al modelo, evaluaciones sobre trazas reales y capacidad aprovisionada solo cuando lo justifiquen los números. Cada afirmación enlaza con la documentación de Google.

Dominik Heinrich

7 de noviembre de 202611 min de lectura

1. Cuándo encaja Google Cloud y cómo cambiaron los nombres

Google Cloud es un buen hogar para la IA cuando tu analítica ya está en BigQuery, tu empresa trabaja con Google Workspace o quieres modelos Gemini cerca de tus datos con la tecnología de búsqueda de Google para la recuperación. Model Garden ofrece también modelos de terceros y abiertos, por ejemplo Claude de Anthropic y la familia abierta Gemma de Google, así que no quedas atado a una familia de modelos.

El cambio de nombre es lo primero que hay que entender, porque la mitad de los tutoriales de internet usan los nombres antiguos. En las notas de versión del 22 de abril de 2026, Google enumera cada cambio de Vertex AI a Gemini Enterprise Agent Platform: Vertex AI Studio pasó a ser Agent Studio, la Vertex AI API pasó a Agent Platform API, Vertex AI Agent Engine pasó a Agent Runtime, su Memory Bank y Sessions pasaron a Agent Platform Memory Bank y Sessions, y Vertex AI Search pasó a Agent Search. RAG Engine, Vector Search y Model Garden mantienen el nombre. Google indica además que los enlaces guardados siguen funcionando mediante redirecciones.

Técnicamente se rompe poco: la documentación de VPC Service Controls sigue protegiendo el servicio como aiplatform.googleapis.com y los proyectos existentes siguen funcionando. Pero las funciones nuevas salen con los nombres de Agent Platform, así que úsalos desde ahora en tu documentación y runbooks.

What is Gemini Enterprise Agent Platform?, Google Cloud Tech (YouTube). Se carga desde YouTube solo cuando haces clic.

2. Proyectos, IAM y Agent Identity

Usa proyectos de Google Cloud separados para no producción y producción, idealmente en una carpeta con políticas de organización que limiten las regiones y los servicios permitidos. Así las cuotas, el acceso a modelos, los logs y los ajustes de seguridad difieren por proyecto, y una prueba no puede llegar a datos de producción.

Los agentes necesitan su propia identidad, no una cuenta de servicio compartida que lo pueda todo. La visión general de Agent Platform describe Agent Identity como la forma de dar permisos granulares a los agentes, y la documentación cubre la autenticación en Google Cloud con la identidad propia del agente y en servicios externos mediante un auth manager con flujos OAuth. Da a cada agente solo los roles que necesita: leer un bucket de Cloud Storage, consultar un dataset, llamar a los modelos que usa.

Para las personas, usa grupos y roles predefinidos en lugar de permisos individuales, y deja la capacidad de desplegar agentes en producción en un grupo pequeño o en tu pipeline de CI/CD. Revisa los enlaces de IAM antes de salir a producción; los roles demasiado amplios en un agente son el hallazgo más habitual en una revisión de seguridad.

3. Un perímetro privado: VPC Service Controls y Private Service Connect

En Google Cloud, el control más fuerte contra la fuga de datos es un perímetro de VPC Service Controls. Metes dentro los proyectos con tu agente, datos y modelos y enumeras las API como servicios restringidos, por ejemplo aiplatform.googleapis.com y storage.googleapis.com. Las llamadas a esas API desde fuera del perímetro se bloquean salvo que cumplan un nivel de acceso que definas. La documentación de Agent Runtime de Google indica que admite VPC Service Controls y que un agente desplegado mantiene acceso seguro a API de Google como BigQuery dentro del perímetro.

Para la conectividad privada desde tus propias redes, la guía del Google Cloud Architecture Center sobre conectividad privada para aplicaciones de IA generativa con RAG es el plano: un proyecto de enrutamiento con un endpoint de Private Service Connect, conectado a tus redes on-premises o de otra nube por Cloud Interconnect o Cloud VPN, con DNS que apunta a ese endpoint y con los ingenieros de datos subiendo los datos de RAG de forma privada a Cloud Storage.

Despliega primero el perímetro en modo dry-run. Registra lo que se bloquearía sin bloquearlo, así encuentras la cuenta de servicio olvidada en un pipeline de CI antes de que rompa una release.

bash

# Dry-run perimeter around the AI project (POLICY_ID = your access policy)
gcloud access-context-manager perimeters dry-run create ai_perimeter \
  --policy=POLICY_ID \
  --perimeter-title="AI production perimeter" \
  --perimeter-type=regular \
  --perimeter-resources=projects/PROJECT_NUMBER \
  --perimeter-restricted-services=aiplatform.googleapis.com,storage.googleapis.com,bigquery.googleapis.com

# After the dry-run logs are clean, enforce it
gcloud access-context-manager perimeters dry-run enforce ai_perimeter --policy=POLICY_ID

Consejo práctico

Comprueba que cada servicio que necesita tu agente es compatible con VPC Service Controls antes de prometer un perímetro hermético. Google mantiene una lista de productos compatibles con las limitaciones de cada servicio.

Configuración de referencia en Gemini Enterprise Agent Platform (antes Vertex AI): todo dentro de un perímetro de VPC Service Controls, Model Armor en el camino de cada petición y evaluaciones sobre datos de Cloud Trace.

4. Modelos y capacidad: primero pago por uso, después Provisioned Throughput

Model Garden da acceso a los modelos Gemini de Google, a modelos de terceros y a modelos abiertos; la visión general de Agent Platform habla de más de 200 modelos fundacionales. Como en cualquier nube, elige por paso: un modelo rápido y barato para enrutar y extraer, uno más potente para respuestas complejas y un modelo de embeddings para la recuperación.

En capacidad, lo predeterminado es el pago por uso. Provisioned Throughput es una suscripción de coste fijo que reserva rendimiento para modelos de IA generativa compatibles en las ubicaciones que elijas. Se mide en generative AI scale units (GSU), y Google lo orienta a aplicaciones de producción en tiempo real como chatbots y agentes, donde importan una experiencia predecible y costes fijos. Si una petición supera la cuota reservada, se procesa como pago por uso; si configuras solo Provisioned Throughput, esas peticiones devuelven en cambio un error HTTP 429.

Esa elección entre desbordamiento y límite estricto es una decisión de arquitectura, no un detalle de facturación. El desbordamiento protege la experiencia del usuario pero hace el coste menos predecible; un límite estricto protege el presupuesto pero exige reintentos y un plan alternativo en la aplicación.

5. Tus datos: RAG Engine, Vector Search y Agent Search

Google ofrece varias formas de basar un agente en tus propios datos. RAG Engine conecta datos privados de la empresa con los modelos para mejorar la precisión de las respuestas y reducir las alucinaciones, y puede usar distintos almacenes vectoriales. Vector Search es el motor de búsqueda nativo de IA para guardar y buscar embeddings a escala. Agent Search, antes Vertex AI Search, ofrece búsqueda con calidad de Google sobre tus documentos y webs como servicio gestionado.

El Architecture Center enumera diseños de referencia para varias combinaciones, por ejemplo infraestructura RAG con Agent Platform y Vector Search, con AlloyDB o con Spanner Graph para recuperación basada en grafos. Mi opción por defecto para una primera versión es la más gestionada que cumpla tus requisitos de residencia de datos y acceso, porque lo difícil del RAG rara vez es el índice. Lo difícil es mantener los documentos al día, respetar quién puede ver cada documento y probar con preguntas en las que conoces la fuente correcta.

Guarda los documentos originales en Cloud Storage dentro del perímetro, cifra con claves propias donde lo exija la política (RAG Engine documenta compatibilidad con CMEK) y da al trabajo de ingesta su propia identidad, que solo pueda leer los buckets de origen.

6. Construir y ejecutar el agente: ADK, Agent Studio y Agent Runtime

Para construir, Google ofrece dos caminos. Agent Studio es un lienzo low-code para diseñar agentes y sus flujos. El Agent Development Kit (ADK) es un framework modular e independiente del modelo para agentes basados en código con razonamiento y uso de herramientas. La documentación cubre también otros frameworks sobre el runtime, como LangChain, LangGraph, AG2 y LlamaIndex, y el protocolo Agent2Agent para agentes que hablan entre sí.

Para ejecutar, Agent Runtime (antes Agent Engine) es el entorno gestionado y escalable para desplegar y operar agentes, incluidos los de larga duración. A su alrededor están Agent Platform Sessions para el estado dentro de una interacción, Memory Bank para la memoria entre sesiones y Code Execution, que ejecuta en un sandbox el código Python generado. Para el gobierno, Google describe Agent Gateway junto con Model Armor como la capa que asegura las interacciones de los agentes y aplica políticas en tiempo de ejecución.

Mi recomendación: escribe el agente con ADK si tienes desarrolladores, porque el código se puede probar y revisar, y deja Agent Studio para prototipos con los equipos de negocio. Despliega en Agent Runtime desde tu pipeline, con revisiones y reparto de tráfico para un despliegue prudente, no desde un portátil.

Consejo práctico

Usa las revisiones y el reparto de tráfico de Agent Runtime como un canary: envía una pequeña parte del tráfico a la nueva revisión, compara sus puntuaciones de evaluación online con la anterior y después mueve el resto.

7. Model Armor delante de cada llamada al modelo

Model Armor revisa prompts y respuestas antes de que lleguen al modelo o al usuario. Google enumera los casos principales: ocultar datos sensibles como datos personales o propiedad intelectual con Sensitive Data Protection, bloquear inyecciones de prompt e intentos de jailbreak, filtrar URL maliciosas y aplicar filtros de IA responsable para categorías como discurso de odio, acoso o contenido sexual explícito. Funciona para aplicaciones en Google Cloud y en otras nubes, lo que ayuda si tus agentes están repartidos entre proveedores.

Model Armor se configura con plantillas: una por perfil de riesgo, por ejemplo una estricta para un agente de cara al cliente y otra más ligera para un asistente interno de investigación. Cada plantilla fija los filtros, sus niveles de confianza y el código y mensaje de error que recibe tu aplicación cuando algo se bloquea, para que la app pueda responder con amabilidad en lugar de fallar.

Trata las plantillas como código. Créalas desde tu pipeline, revisa los cambios como cualquier otra regla de seguridad y mantén por plantilla un conjunto de prompts de ataque, incluidas instrucciones escondidas en documentos que tu agente recupera.

bash

# Strict template for a customer-facing agent (values from Google's example)
gcloud model-armor templates create support-agent-strict \
  --project=PROJECT_ID --location=LOCATION \
  --rai-settings-filters='[
    {"filterType": "HATE_SPEECH", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "HARASSMENT", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "SEXUALLY_EXPLICIT", "confidenceLevel": "MEDIUM_AND_ABOVE"}
  ]' \
  --basic-config-filter-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=HIGH \
  --malicious-uri-filter-settings-enforcement=enabled

8. Evaluar sobre trazas reales, observar, controlar costes y comparar las nubes

Las evaluaciones de agentes y modelos en Gemini Enterprise Agent Platform están disponibles de forma general desde el 31 de julio de 2026, según el anuncio de Google. El servicio trae más de 20 métricas predefinidas de calidad, seguridad, fundamentación, uso de herramientas y trayectoria, además de rúbricas adaptativas y métricas propias basadas en código o en un LLM como juez. La evaluación offline mide agentes con datos históricos y requiere que el agente exporte señales de OpenTelemetry; con Agent Runtime hay que activar Cloud Trace. Los monitores online toman muestras de trazas y logs en vivo, ejecutan las métricas, escriben los resultados en Cloud Logging y las puntuaciones numéricas en Cloud Monitoring, donde puedes crear alertas.

Es una gran ventaja práctica: las mismas trazas que usas para depurar se convierten en tus datos de calidad. Configura el trazado desde el primer día, ejecuta la evaluación offline como puerta en CI y mantén monitores online en producción con una alerta cuando baje una puntuación.

Para los costes, etiqueta los recursos por agente y equipo, vigila el consumo de tokens por modelo, pasa a Provisioned Throughput solo con una carga constante demostrada y revisa la configuración cada trimestre. Los fallos que más veo: un agente que corre con una cuenta de servicio amplia, ningún perímetro, Model Armor solo en el prompt del usuario y no en el contenido recuperado, y trazado activado solo después del primer incidente. La misma configuración en Microsoft Azure está en /blog/azure-ai-foundry, y en AWS en /blog/aws-bedrock.

Conclusión
En Google Cloud, la receta para producción es un perímetro de VPC Service Controls, agentes con identidad propia, RAG sobre tus propios datos, Model Armor como capa de seguridad y el servicio de evaluación leyendo las mismas trazas con las que depuras.

Proyectos reales relacionados

Pruébalo tú mismo

Listo para producción

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos