Si alguna vez quisiste lanzar una aplicación con IA sin tener que administrar GPUs, servidores de modelos o infraestructura de escalado, esta guía es para ti.
Inferencia gestionada significa, simplemente, dejar que un proveedor de nube ejecute el modelo de IA por ti: tú envías una solicitud, la plataforma se encarga del cómputo y recibes una respuesta. En Google Cloud, la forma más limpia de hacerlo hoy es combinar la Gemini Enterprise Agent Platform (antes Vertex AI) con Google Cloud Run, dividiendo responsabilidades entre ambos servicios. La Agent Platform actúa como motor de orquestación e inteligencia, mientras Cloud Run hospeda tu lógica de aplicación, los front-ends o los servidores Model Context Protocol (MCP).
Al terminar este artículo podrás:
- Explicar la arquitectura híbrida y por qué existe cada capa
- Definir un agente de IA en código usando el Agent Development Kit (ADK)
- Desplegar tu capa de aplicación en Cloud Run con un solo comando
- Elegir entre inferencia online y por lotes para tu carga de trabajo
- Asegurar y monitorear todo el setup en producción
¿Nuevo en el concepto? Empieza con la guía introductoria de Google Cloud: ¿Qué es la inferencia de IA?
Prerrequisitos
Para seguir el tutorial en modo práctico necesitarás:
- Un proyecto de Google Cloud con facturación habilitada
- La CLI
gcloudinstalada y autenticada - Python 3.10+ y el ADK instalado (
pip install google-adk)
También puedes leerlo como un recorrido de arquitectura; cada paso está explicado, no solo mostrado.
1. El blueprint arquitectónico

Este patrón divide tu sistema en capas independientes con autoescalado:
[ Cliente / UI Web ] ──> [ Servicio Cloud Run ] (Lógica de App / Front End de Herramientas)
│
▼
[ Gemini Enterprise Agent Platform — Agent Runtime ]
(Orquestación, Análisis de Intención, Memoria)
│
▼
[ Inferencia Gestionada / Model Garden ]
(Modelos Gemini 3.x Pro / Flash)
¿Por qué dividirlo así? Cada capa escala de forma independiente y falla de forma independiente. Tu front-end web puede soportar un pico de tráfico sin tocar la capa de modelos, y puedes cambiar de modelo sin redesplegar tu código de aplicación. También crea un límite de seguridad limpio: los clientes solo se comunican con Cloud Run, nunca directamente con el modelo.
Esto es lo que hace cada capa:
- Cloud Run ejecuta tu lógica de negocio especializada, protege los endpoints orientados al cliente con Identity-Aware Proxy (IAP) y hospeda herramientas externas, servidores MCP y APIs. Piénsalo como todo lo que tú construyes.
- La Agent Platform (Agent Runtime) administra el estado activo del agente, la memoria a largo plazo y los pasos de razonamiento del modelo en un runtime centralizado y totalmente gestionado. Piénsalo como todo lo que Google ejecuta por ti.
2. Construye el código de tu agente con el ADK
Usa el Agent Development Kit (ADK) de código abierto para definir el comportamiento de tu agente en código y vincularlo a un modelo. La idea clave a entender: las herramientas son funciones Python simples. El ADK lee el docstring de cada función para decidir cuándo y cómo llamarla; así que un docstring claro no es un detalle de documentación, es parte de la lógica de tu agente.
# agent.py
from google.adk.agents import Agent
def call_internal_business_system(query: str) -> str:
"""Invoca flujos de negocio seguros desplegados en Cloud Run."""
# Lógica para llamar de forma segura la URL de tu servicio en Cloud Run
return "Datos recuperados del backend interno seguro."
# Define un agente que apunta a un modelo Gemini actual
root_agent = Agent(
name="enterprise_inference_agent",
model="gemini-3.5-flash", # U otro modelo actual de Model Garden
instruction="Eres un asistente de procesamiento de datos que usa inferencia gestionada.",
tools=[call_internal_business_system],
)
Desglosando los cuatro campos:
name— un identificador para tu agente, usado en logs y trazas.model— qué modelo Gemini maneja el razonamiento. Los modelos Flash son más rápidos y baratos; los Pro manejan razonamiento más complejo.instruction— el system prompt del agente, que moldea su comportamiento en cada solicitud.tools— las funciones Python que el modelo puede llamar. Cuando una solicitud del usuario coincide con el docstring de una herramienta, el modelo la invoca.
Nota: Los modelos Gemini 1.0 y 1.5 (incluido
gemini-1.5-pro) han sido retirados y ahora devuelven errores. Apunta siempre a un modelo soportado actualmente, comogemini-3.5-flash,gemini-3.6-flasho una versión Gemini 3.x Pro de Model Garden.
3. Conteneriza y despliega la capa de aplicación en Cloud Run
Al desplegar tu backend de orquestación o tu dashboard front-end, las herramientas pueden empaquetar y subir el contenedor por ti. Dos pasos pequeños te llevan ahí.
Paso A: Configura los permisos de la service account
En Google Cloud, los servicios no confían entre sí por defecto: tu instancia de Cloud Run necesita permiso explícito para invocar los endpoints de la Agent Platform. Este comando le otorga ese permiso a su service account:
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
--member="serviceAccount:YOUR_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/aiplatform.user"
En términos simples: “deja que este servicio de Cloud Run llame a la plataforma de IA”. Este es el paso que la gente más olvida; si tu servicio desplegado devuelve errores de permiso, vuelve aquí primero.
Paso B: Build y deploy
El ADK incluye una ruta de despliegue con un solo comando. Bajo el capó hace tres cosas: construye la imagen del contenedor, la sube a Artifact Registry y crea (o actualiza) el servicio en Cloud Run.
# Despliega tu capa de agente o herramienta directamente en Cloud Run
adk deploy cloud_run \
--project="YOUR_PROJECT_ID" \
--region="us-central1" \
--service_name="agent-inference-backend" \
path/to/your/agent
Alternativamente, la Agents CLI (agents-cli) puede generar la configuración de despliegue para un target de Cloud Run. Por ejemplo, agents-cli scaffold enhance --deployment-target cloud_run funciona desde dentro de tu herramienta de coding con IA favorita. Cualquiera de las dos rutas configura tus variables de entorno, incluidos los modelos objetivo y la URL pública del servicio.
4. Rutinas de inferencia online y por lotes
Una vez que la tubería está lista, hay dos formas principales de disparar inferencia gestionada. Elegir correctamente se reduce a una pregunta: ¿un humano necesita la respuesta ahora mismo?
- Inferencia online (UI de baja latencia): Haz llamadas síncronas a la API desde tu front-end en Cloud Run directamente al endpoint del agente desplegado para chat en tiempo real, llamadas a herramientas o razonamiento paso a paso. Ejemplo: un chatbot de soporte al cliente donde cada segundo de latencia importa.
- Inferencia por lotes (datos de alto volumen): Para trabajos grandes de procesamiento de datos, envía un job asíncrono de predicción por lotes mediante el SDK de la Agent Platform. La plataforma aprovisiona cómputo dedicado, ejecuta las tareas de inferencia, escribe resultados y logs en Cloud Storage y destruye el cómputo automáticamente al terminar. Ejemplo: clasificar 100,000 tickets de soporte durante la noche; nadie espera una respuesta individual, así que el throughput y el costo importan más que la latencia.
Los trabajos por lotes suelen ser mucho más baratos por solicitud, así que una buena regla general es: usa batch por defecto y reserva la inferencia online para experiencias genuinamente interactivas.
5. Asegura y monitorea la arquitectura
Una demo puede saltarse esta sección. La producción no puede.
- Asegura el ingress: Envuelve tus endpoints de Cloud Run en Identity-Aware Proxy (IAP) para proteger dashboards con humanos en el loop; IAP verifica la identidad de Google del usuario antes de que el tráfico llegue a tu código. Para tráfico agente-a-herramienta, Agent Gateway puede dar a cada agente una identidad única con mTLS de extremo a extremo (TLS mutuo, donde ambas partes se verifican entre sí) al llamar servidores MCP en Cloud Run.
- Centraliza el trace logging: Habilita el tracing OpenTelemetry integrado de la plataforma (Cloud Trace está activado por defecto en despliegues vía CLI). Puedes inspeccionar visualmente los grafos acíclicos dirigidos (DAGs) de ejecución: un mapa paso a paso de cada paso de razonamiento, llamada a modelo e invocación de herramienta, para ver exactamente cómo colaboraron tus modelos Gemini y las herramientas de Cloud Run en una tarea de inferencia. Cuando un agente da una respuesta extraña, esta traza es cómo descubres por qué.
Conclusiones clave
- Divide las responsabilidades: Cloud Run para tu código, la Agent Platform para orquestación y modelos. Cada capa escala y falla de forma independiente.
- Las herramientas son solo funciones: el ADK convierte funciones Python bien documentadas en capacidades que tu agente puede llamar.
- Permisos antes del despliegue: otorga
roles/aiplatform.usera la service account de Cloud Run, o nada más funcionará. - Empareja el modo de inferencia con tu carga: online para experiencias interactivas, batch para procesamiento de alto volumen.
- Asegura y traza desde el día uno: IAP en el borde, mTLS entre servicios, OpenTelemetry para visibilidad.
Hacia dónde ir después
Prueba la versión más pequeña posible: define un agente con una sola herramienta usando el ADK, ejecuta adk deploy cloud_run y envíale una solicitud. Una vez que funcione, todo lo demás en este artículo es una adición incremental.
Para los equipos en Latinoamérica que están migrando de soluciones auto-gestionadas a plataformas gestionadas, este patrón es especialmente atractivo: elimina el costo operativo de mantener GPUs y servidores de modelos, algo crítico cuando los presupuestos de infraestructura son limitados. ¿Has probado combinar la Agent Platform con Cloud Run, o sigues con un setup de inferencia auto-gestionado? Me encantaría saber cómo se ve tu arquitectura en los comentarios.