El módulo de gateway de AWS dejó el marco completo: el gateway es una función de arquitectura (punto único, routing, fallback, presupuesto, auditoría) que a veces se implementa con el servicio administrado y a veces exige un proxy delante — y el árbol de tres preguntas que decide. Nada de eso se rehace. Este módulo puebla el marco con Vertex AI y marca las diferencias que pesan.

Concepto	En AWS	En GCP
Servicio de modelos administrado	Bedrock	Vertex AI
Catálogo	Multi-proveedor (Anthropic, Meta, Nova…)	Model Garden: Gemini + Claude + Llama + 200+
API unificada	Converse API	API de Vertex (+ SDKs; OpenAI-compatible endpoints)
Capacidad reservada	Provisioned throughput	Provisioned Throughput
Lotes con descuento	Batch (~50%)	Batch predictions (descuento similar)
Caché de contexto	Prompt caching	Context caching
Proxy propio si hace falta	LiteLLM en ECS	LiteLLM en Cloud Run

Ojo — el nombre cambió en 2026: en Google Cloud Next, el 22 de abril de 2026, Google presentó Gemini Enterprise Agent Platform como “la evolución de Vertex AI”: Vertex AI Agent Builder, el Model Garden y el resto de Vertex se entregan ahora bajo ese paraguas. Este curso sigue diciendo Vertex AI porque así siguen apareciendo los endpoints (aiplatform.googleapis.com), las rutas de la documentación y los SDKs — y porque el módulo 9 explica por qué anclamos en piezas y no en paraguas. Si la consola te muestra otro nombre, es el mismo servicio.

La tesis del módulo

Vertex AI juega el papel exacto de Bedrock — catálogo administrado, datos que no entrenan modelos, IAM y red de los módulos 2 y 4 aplicando enteros — y el árbol de decisión del proxy se responde igual: si todo tu consumo vive en el Model Garden, Vertex + IAM + etiquetado ES el gateway; el proxy en Cloud Run entra por modelos externos, multi-tenant o routing propio. La diferencia de fondo no es de arquitectura sino de catálogo y casa: en GCP, el modelo estrella es de la casa — y eso trae integraciones más profundas y el mismo deber de vigilar el acoplamiento.

Vertex AI en cinco líneas útiles

Model Garden: el catálogo — Gemini como primera parte, más Claude, Llama, Mistral y compañía como ciudadanos de primera clase. La amplitud real del multi-proveedor dentro del administrado es comparable a Bedrock; la pregunta 1 del árbol (“¿modelos fuera del catálogo?”) se responde contra esta lista, no contra el folleto.
Garantías de datos: tus prompts y salidas no entrenan los modelos fundacionales — la misma garantía contractual de Bedrock, con la misma tarea de verificarla contra tu clasificación de datos (módulo 10).
Las palancas de precio que la economía del caso sabe evaluar existen todas: batch predictions con descuento para lo no interactivo (el analizador nocturno), context caching para el prefijo repetido (las instrucciones del clasificador), y Provisioned Throughput para volumen alto sostenido — con la regla eterna: on-demand hasta que la curva de uso medida diga otra cosa.
Endpoints compatibles: Vertex expone superficies compatibles con el SDK de OpenAI para varios modelos — un detalle práctico que abarata migraciones y proxies.
La regionalidad: el catálogo y las cuotas varían por región, y existe la misma tensión residencia-vs-capacidad de Bedrock. Verificar antes de prometer, como siempre.

¿Vertex ES el gateway?

El árbol del curso de AWS, ejecutado contra GCP:

Función del gateway	¿Vertex la cubre?	Nota
Normalización	✅ dentro del Garden	API/SDKs de Vertex sobre el catálogo
Credenciales	✅	Sin API keys: service accounts (módulo 2)
Auditoría	✅	Cloud Audit Logs (módulo 10)
Atribución de costos	✅ con trabajo	Etiquetas + facturación a BigQuery (módulo 8)
Routing con lógica propia	⚠️	La cascada barato→caro sigue siendo tuya
Modelos fuera del Garden	❌	Los GPT de la API de OpenAI u otro modelo que no esté en el Garden (los gpt-oss de pesos abiertos sí están): proxy
Multi-tenant con cuotas por equipo	⚠️	Cuotas por proyecto ayudan; keys virtuales, no

La lectura es un calco deliberado: solo-Garden + un equipo + routing simple = Vertex es el gateway (y en GCP hay un empujón extra: si cada agente vive en su proyecto — módulo 1 — las cuotas y el gasto ya vienen partidos por proyecto, cubriendo gratis parte de lo que en AWS pedía perfiles). El proxy — el mismo LiteLLM, ahora en Cloud Run con su service account — entra por las mismas tres puertas: modelos externos, multi-tenant fino, routing propio. Y la decisión barata de siempre aplica: aunque no haya proxy, el acceso a Vertex se centraliza en una librería interna única — el punto único lógico antes que físico.

   ¿NECESITO PROXY DELANTE DE VERTEX?

START ──► ┌────────────────────┐
          │ ¿modelos fuera del │ ──► sí: proxy propio
          │ Model Garden?      │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ ¿multi-tenant fino │ ──► sí: proxy propio
          │ (keys, cuotas por  │
          │ equipo)?           │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ ¿routing con       │ ──► sí: proxy propio
          │ lógica propia?     │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ Vertex + IAM +     │
          │ proyecto por agente│
          │ ES el gateway      │
          └────────────────────┘

  proxy propio = LiteLLM en Cloud Run, con su SA

Ojo — el acoplamiento con cara amable: que Gemini sea de la casa significa integraciones más profundas (con BigQuery, con el stack de agentes del módulo 9) y también el incentivo de diseñar para el modelo de la casa. La disciplina de arquitectura: el routing declarado por capacidad y precio (gama económica / media / alta, como en todo el catálogo de cursos), no por marca — de modo que cambiar el modelo detrás de una gama sea una línea de configuración. El día que quieras A/B entre Gemini y Claude para el clasificador, esa línea es la diferencia entre un experimento y un proyecto.

Routing y fallback: la política de una página

Sin cambios de fondo — se re-declara con las piezas locales: ruta por defecto por gama según tipo de tarea; escalada con tope (el freno del módulo 8 vigila); fallback de capacidad (otra región del Garden → modelo alternativo → encolar en Pub/Sub y esperar — el fallback digno del agente autónomo); degradación honesta a humano al final de la cadena. Si pusiste proxy, es infraestructura crítica: multi-instancia en Cloud Run, con la salud vigilada por el módulo 11 — el precio del punto único físico no cambia de nube.

Errores comunes

Poner proxy “porque en AWS lo teníamos”. El árbol se re-ejecuta por nube: con proyecto-por-agente, parte del multi-tenant que justificaba el proxy ya lo dan las cuotas por proyecto. Decisión nueva, no herencia.
Veinte servicios llamando a Vertex por su cuenta. La librería interna única no era una peculiaridad de AWS: era el punto único lógico. Sin ella, el día del proxy son veinte PRs — en cualquier nube.
Routing por marca en vez de por gama. “Esto va a Gemini, esto a Claude” acopla la política al proveedor. Gamas por capacidad/precio, modelos como implementación intercambiable detrás.
Ignorar batch y context caching. Las dos palancas fáciles del stack, con los mismos descuentos de siempre esperando al analizador nocturno y al prefijo repetido. FinOps negativo si se quedan sin usar.
Provisioned Throughput el día uno. Capacidad reservada comprada con optimismo en vez de curva medida. La regla no cambió de nube ni va a cambiar.

La frase para llevarse

“Vertex es Bedrock con otro catálogo y el modelo estrella en casa: el árbol del proxy se re-ejecuta (y el proyecto-por-agente te regala parte del multi-tenant), el acceso se centraliza aunque no haya proxy, y el routing se declara por gama — nunca por marca — para que cambiar de modelo sea configuración y no proyecto.”

Qué viene

Módulo 8: FinOps. Los cuatro eslabones — atribuir, ver, alertar, frenar — con las herramientas de GCP: labels en vez de tags, la exportación de facturación a BigQuery (donde el análisis del gasto se vuelve SQL, la fortaleza diferencial de GCP), presupuestos cuyas alertas disparan Pub/Sub — es decir, acciones programables —, y las cuotas de API como freno duro que en GCP viene de fábrica.

Arquitectura GCP — Módulo 7: el LLM gateway y Vertex AI