Glosario de Arquitectura GCP para Agentes de IA

Los términos que aparecen una y otra vez en el Curso de Arquitectura GCP para Agentes de IA. Este glosario asume el vocabulario común de la serie (los cuatro tiempos, mínimo privilegio, idempotencia, kill switch) definido en el glosario de AWS — aquí vive lo propio de Google Cloud y las equivalencias que evitan traducir mal. Como todo glosario de la academia, crece con cada bloque nuevo.

El mapa: proyectos y jerarquía

Proyecto (project) — La unidad que lo contiene todo en GCP: recursos, permisos, APIs habilitadas y enlace a facturación. Mucho más liviano que la cuenta de AWS — se crea en segundos — y por eso el patrón natural es proyecto por agente o por entorno. Se desarrolla en el mapa de GCP.

Carpeta (folder) — El agrupador de proyectos en la jerarquía organización → carpetas → proyectos. Su superpoder: los permisos y políticas otorgados en una carpeta se heredan a todos sus proyectos, presentes y futuros.

Organization Policy — El techo duro de GCP: restricciones declaradas en la jerarquía (“nada de IPs públicas”, “prohibido crear llaves JSON”) que aplican por herencia. El equivalente de las SCP de AWS.

Habilitación de APIs — En GCP, cada proyecto declara qué APIs puede usar; una API no habilitada no responde, ni con permisos. La lista de APIs habilitadas de un proyecto es una jaula extra y una declaración de superficie que AWS no tiene.

Billing account — La cuenta de facturación a la que los proyectos se enlazan (no pertenecen). Separar quién paga de quién organiza es natural en GCP; el enlace sin dueño es la fuente clásica de sustos.

Identidad

Service account (SA) — La identidad de workload de GCP: el cómputo corre como su service account adjunta. El equivalente funcional del rol de ejecución de AWS — con la diferencia de que se adjunta o se impersona, no se “asume” por sesiones. Una por agente, jamás la default. Se desarrolla en identidad.

Binding — La tripleta que otorga permisos en GCP: esta identidad tiene este rol en este ámbito (recurso, proyecto, carpeta u organización). Los permisos efectivos de una identidad son la suma de los bindings de toda su cadena jerárquica — por eso se audita hacia arriba.

Rol (GCP) — Una lista de permisos con nombre (roles/pubsub.subscriber). Ojo con el falso amigo: el “rol” de AWS es una identidad; el de GCP, un conjunto de permisos. Los roles basic (Owner/Editor/Viewer) son el comodín a evitar; los predefinidos granulares son el camino del mínimo privilegio.

Impersonation — Que una identidad genere tokens de otra service account, con permiso explícito y cada uso auditado. El equivalente funcional del AssumeRole: el mecanismo para saltos de identidad sin llaves.

Workload Identity Federation — El intercambio de una identidad externa verificable (el token OIDC de GitHub Actions, otra nube) por credenciales temporales de GCP. La razón por la que nada externo necesita guardar llaves JSON.

Llave JSON de service account — La credencial exportable y eterna que es el anti-patrón de identidad de GCP: si el agente puede leerla, una inyección puede exfiltrarla. Se prohíbe su creación por organization policy y se vive mejor.

Cómputo

Cloud Run — La apuesta central de cómputo de GCP: contenedores estándar con scale-to-zero, en dos caras — services (atienden peticiones HTTP, escalan por concurrencia incluso a cero) y jobs (tareas que corren hasta terminar, sin puerto, con reintentos y paralelismo). La decisión de cómputo del agente es casi siempre “¿peticiones o tareas?”. Se desarrolla en cómputo.

Cloud Run functions — Funciones-como-servicio montadas sobre el motor de Cloud Run: conveniencia de función sin el muro de 15 minutos de Lambda. La elección function-vs-contenedor queda en empaque, no en duración.

Scale-to-zero — Sin tráfico, cero instancias, cero costo — el default de Cloud Run services que difumina la frontera entre “servicio vivo” y “cómputo efímero”. Su letra chica es el arranque en frío, configurable con instancias mínimas cuando hay humanos esperando.

GKE (Google Kubernetes Engine) — Kubernetes administrado. Como EKS: se elige por razón organizacional, nunca por prestigio.

Redes

VPC global — La diferencia estructural de red de GCP: una sola red lógica mundial con subredes regionales — sin peering ni túneles entre regiones de la misma plataforma. No ahorra decisiones de seguridad, solo plomería. Se desarrolla en redes.

Firewall por service account — Las reglas de firewall de GCP pueden seleccionar origen y destino por service account: “la base acepta solo desde la SA de los agentes”. Red e identidad nombrando al mismo actor — el security group referenciado de AWS, un paso más allá.

Private Google Access — El interruptor de subred que permite a recursos sin IP pública alcanzar las APIs de Google por la red interna. Cubre la mayor parte de lo que en AWS eran VPC endpoints, sin crearlos uno a uno.

Private Service Connect (PSC) — El mecanismo fino: endpoints privados con IP propia hacia APIs de Google, servicios de terceros o servicios tuyos publicados. El PrivateLink de GCP.

Cloud NAT — La salida controlada de las subredes privadas. Junto con las reglas de egress (denegar por defecto, lista corta), cierra la jaula anti-exfiltración de siempre.

Integración

Pub/Sub — El servicio que colapsa SQS y SNS: se publica a un topic, y cada suscripción decide el patrón — una compartida es cola (uno procesa), varias son abanico (todos se enteran) — y la mecánica — pull (el consumidor drena) o push (se empuja como HTTP al consumidor). Entrega al menos una vez; idempotencia obligatoria. Se desarrolla en integración.

Ack deadline — El plazo para confirmar un mensaje de Pub/Sub antes de que reaparezca para reintento. El visibility timeout de esta casa.

Dead-letter topic — El apartadero de los mensajes que fallaron N veces — la DLQ de Pub/Sub, con el mismo argumento no negociable y la misma alarma encima.

Cloud Tasks — La cola sin equivalente directo en AWS: su destino es un endpoint HTTP concreto, con control de ritmo (X peticiones/segundo) y programación por tarea. Para proteger destinos frágiles y para el trabajo diferido puntual. En Pub/Sub manda el consumidor; en Tasks manda la cola.

Eventarc — El bus que enruta eventos de servicios de Google y propios hacia Cloud Run. El EventBridge de GCP.

Cloud Scheduler — El cron administrado: dispara jobs y peticiones a la hora dicha, sin cómputo esperando. El tercer despertador del agente.

Estado y datos

Firestore — La base de documentos serverless que juega el rol de DynamoDB con estructura consultable: sesiones e historial por clave, campos consultables sin diseñar índices con severidad, TTL nativo como política de retención. Se desarrolla en estado y datos.

AlloyDB — El PostgreSQL vitaminado de Google: compatible con Postgres (y pgvector), acelerado con motor columnar propio. El paso intermedio entre Cloud SQL y reescribir.

Vertex AI Vector Search — El índice vectorial dedicado y administrado de GCP: baja latencia a gran escala. El papel de OpenSearch en la decisión vectorial — al que se gradúa con métricas, no con miedo.

GCS (Cloud Storage) — El S3 de GCP, con las mismas reglas: el objeto gordo vive aquí, las bases guardan punteros.

Memorystore — Redis administrado: caché caliente, claves de idempotencia. El ElastiCache de esta casa.

BigQuery — El almacén analítico serverless que en GCP es protagonista: SQL sobre datos masivos pagando por consulta. Recibe lo frío de la plataforma (historial vencido, logs, resultados, facturación) y lo vuelve consultable — con la regla de dirección: lo operacional exporta hacia BigQuery, jamás se sirve desde él.

Modelos y agentes

Vertex AI — El servicio de modelos administrado: catálogo, garantías de datos (no entrenan modelos), y las palancas de precio (batch, context caching, Provisioned Throughput). El Bedrock de GCP. Desde el 22 de abril de 2026 Google lo entrega bajo el paraguas Gemini Enterprise Agent Platform; el nombre Vertex AI sobrevive en endpoints, SDKs y documentación. Se desarrolla en el LLM gateway.

Model Garden — El catálogo de Vertex: Gemini como primera parte más Claude, Llama, Mistral y 200+ modelos como ciudadanos de primera clase. La pregunta “¿modelos fuera del catálogo?” del árbol del proxy se responde contra esta lista.

Context caching — El caché del prefijo repetido del prompt en Vertex — el prompt caching de esta casa, con el mismo cliente ideal: las instrucciones largas que van en todas las llamadas.

ADK (Agent Development Kit) — El framework open source y multi-lenguaje (Python, Go, Java, TypeScript y Kotlin; la versión 2.0, de 2026, suma flujos basados en grafos) de Google para escribir agentes. La pieza sin equivalente en AgentCore: compite con LangGraph como framework, no con AWS como nube — corre donde quieras. Se desarrolla en Agent Engine y ADK.

Agent Runtime (hasta abril de 2026, Agent Engine) — El runtime administrado que hospeda agentes (típicamente ADK): despliegue, escalado, sesiones y Memory Bank. El AgentCore Runtime de GCP — con billete de salida incluido, porque el código ADK también corre en tu Cloud Run.

Agent Identity — Identidad criptográfica propia de cada agente, atada a su ciclo de vida y con rastro auditable de cada acción; Google la presenta como un principal más seguro que la service account para agentes. El AgentCore Identity de GCP.

Agent Sandbox — El entorno endurecido y administrado para ejecutar código generado por el agente. La pieza “peligrosa de hacer bien” que se compra en todas las nubes; el Code Interpreter de AgentCore.

A2A (Agent2Agent) — El protocolo abierto de Google para que agentes se descubran y hablen entre organizaciones. Relevante para ecosistemas multi-agente grandes; prematuro para tres agentes en un embudo.

Gemini Enterprise / Gemini Enterprise Agent Platform — Dos paraguas comerciales: Gemini Enterprise es la aplicación para usuarios finales (heredera de Agentspace, licenciada por asiento); Gemini Enterprise Agent Platform es la plataforma de desarrollo que desde el 22 de abril de 2026 reemplaza el nombre Vertex AI Agent Builder — y absorbe Vertex AI — y se cobra por consumo. Regla del curso: ancla tus decisiones en las piezas de ingeniería (ADK, Agent Runtime, Model Armor) — los paraguas de marketing cambian sin migración.

Seguridad y operación

Model Armor — El guardrail declarativo de GCP: inyección de prompt y jailbreak, filtros de contenido, detección y enmascaramiento de PII — aplicable por API a cualquier modelo desde tu capa de acceso (la integración transparente dentro de la API de Gemini es solo para Gemini, por proyecto y en pocas regiones), con plantillas y floor settings centrales. Una capa entre seis, como todos los guardrails. Se desarrolla en seguridad.

CMEK (customer-managed encryption keys) — Tus llaves en Cloud KMS cifrando los datos sensibles: doble puerta y auditoría de cada uso. El CMK de esta casa; el honeypot del historial las lleva.

VPC Service Controls (VPC-SC) — La joya defensiva de GCP: un perímetro que encierra proyectos y servicios de datos, cuyas APIs solo responden desde adentro — la exfiltración con credenciales robadas se vuelve estructuralmente inviable. La tercera jaula, independiente de IAM y red. Se adopta por etapas (dry-run primero).

Cloud Audit Logs — La caja negra: admin activity siempre encendido, data access activable para lo sensible (actívalo). Fluyen al proyecto central de seguridad — evidencia que el comprometido no puede borrar.

Security Command Center — El vigilante organizacional: postura (configuraciones peligrosas) y amenazas activas, incluida la anomalía conductual de una service account — la firma del agente comprometido.

Log-based metrics — El truco operativo de GCP: cualquier patrón en Cloud Logging convertido en métrica alertable sin tocar código. Con logging estructurado, las métricas de trabajo del agente (distribución de salidas, escaladas) están a minutos. Se desarrolla en operación autónoma.

Workflows — La máquina de estados administrada de GCP; con callbacks implementa la aprobación asíncrona: crea un endpoint, notifica, espera dormida sin facturar, y el timeout conservador decide. El Step Functions (waitForTaskToken) de esta casa — con la misma doctrina: el silencio jamás aprueba.