Google Cloud AI Solutions and Vertex AI

Resumen

Elegir una solución de inteligencia artificial no es una decisión técnica aislada: es una decisión de inversión con cuatro tensiones que hay que equilibrar conscientemente —velocidad a producción, esfuerzo de datos e ingeniería, diferenciación competitiva y experiencia requerida—. Este tema desarrolla ese marco de decisión y lo aplica a las tres grandes vías que Google Cloud ofrece para resolver un caso de uso con IA: las APIs preentrenadas, los modelos entrenados con AutoML y los modelos personalizados.

Las APIs preentrenadas exponen capacidades ya entrenadas por Google —visión, lenguaje, traducción, voz— como servicios que se consumen por llamada; resuelven en horas un problema que de otra forma exigiría meses, a cambio de operar dentro de una capacidad de propósito general que no se diferencia de la de cualquier otro consumidor. AutoML invierte el equilibrio: entrena un modelo propio con los datos propios y una interfaz de mínimo código, para tareas estándar donde los datos de la organización son la ventaja. El modelo personalizado va más lejos: código, framework y arquitectura a elección, para cuando la capacidad en sí misma es el producto y el requisito de diferenciación justifica el coste de construir y operar el ciclo completo de MLOps.

Vertex AI es el punto de convergencia de las tres vías: una plataforma única donde se preparan datos, se entrena —con AutoML o con código propio—, se registran y comparan modelos, se despliegan en endpoints, se monitorizan, se explican y se gobiernan, con acceso a los modelos fundacionales y de terceros disponibles en Model Garden. Sobre esa base se construye la recomendación que el examen espera: no la respuesta "mejor modelo", sino la respuesta adecuada al caso, con sus trade-offs explícitos.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Enumerar y aplicar los criterios de decisión al seleccionar una solución de IA: velocidad, esfuerzo requerido, diferenciación y experiencia necesaria.
Comparar las tres vías de implementación —API preentrenada, AutoML y modelo personalizado— en cuanto a tiempo, datos, expertise, control y diferenciación.
Seleccionar la vía adecuada para un caso de negocio dado y justificar el trade-off asumido ante un stakeholder.
Identificar las APIs preentrenadas de Google Cloud y describir su patrón de consumo, sus ventajas y sus límites.
Explicar qué ofrece AutoML, qué datos de entrada exige y para qué tipos de problema es adecuado.
Describir cuándo un modelo personalizado es la opción correcta y qué capacidades de MLOps exige sostenerlo.
Describir Vertex AI como plataforma unificada del ciclo de vida del ML: datos, entrenamiento, registro, despliegue, monitorización y explicabilidad.
Situar BigQuery ML dentro del panorama como ruta de menor fricción para equipos con dominio de SQL, y explicar su integración con Vertex AI.
Evaluar un portafolio de iniciativas de IA de una organización y proponer la secuencia de adopción adecuada.

Contenido Principal

Subtema 1: Criterios de decisión y trade-offs al seleccionar una solución de IA

La pregunta "¿qué solución de IA uso?" solo se responde después de cuatro decisiones explícitas. Cada una tiene una tensión, y el arte consiste en aceptar el trade-off correcto en lugar de buscar la opción que maximiza todos los ejes a la vez, que no existe.

Velocidad. ¿Cuánto tarda la primera versión en producir valor? Un prototipo con una API preentrenada puede estar el mismo día; un AutoML puede estar en días según el volumen y la calidad de los datos etiquetados; un modelo personalizado se mide en semanas o meses, incluida la ingeniería de datos. La velocidad no es solo time-to-market: determina la tasa de aprendizaje, porque cada versión pone a prueba la hipótesis de negocio con datos reales.

Esfuerzo. Incluye la preparación y etiquetado de datos, el trabajo de ingeniería, la infraestructura de entrenamiento y despliegue y la operación continua. El esfuerzo de datos suele dominar: etiquetar miles de documentos o imágenes es un trabajo de proceso con personas, y su coste es independiente de la potencia del cómputo. Un caso de uso con datos faltantes es un proyecto de captura de datos con un modelo al final.

Diferenciación. ¿Esta capacidad la ofrecen todos con el mismo servicio, o es propia de la organización? Si la tarea es estándar —detectar texto en una imagen, detectar idioma, transcribir audio—, usar la capacidad preentrenada es correcto porque no hay ventaja en recrearla. Si la capacidad distingue el producto —un modelo de riesgo entrenado con la cartera histórica, un sistema de recomendación sobre el comportamiento propio—, cederla a una capacidad genérica es ceder ventaja.

Expertise requerido. Qué perfiles hacen falta y con qué profundidad: ingenieros de datos, científicos de datos, ingenieros de ML, especialistas en MLOps. Una organización sin equipo de ML puede operar APIs y AutoML con perfiles de datos; un modelo personalizado exige capacidad sostenida de experimentación, evaluación y operación, y esa capacidad no se contrata para un solo proyecto sin coste fijo.

Criterio	Pregunta de decisión	Coste de ignorarlo
Velocidad	¿Cuándo recibe valor el negocio la primera versión?	El proyecto pierde el momento de mercado y el apoyo interno
Esfuerzo	¿Cuánto trabajo de datos, ingeniería y operación implica?	Presupuesto subestimado por centrarse solo en el cómputo
Diferenciación	¿Es esta capacidad un estándar o una ventaja propia?	Capacidad clave cedida a un servicio genérico, o esfuerzo inútil en recrear lo estándar
Expertise	¿Qué perfiles existen y cuáles hay que conseguir?	Proyecto que arranca y se estanca en la operación

Sobre estos cuatro se superponen criterios transversales que también condicionan la elección: coste (modelo por uso frente a capacidad dedicada), latencia (respuesta en línea frente a proceso por lotes), volumen y frecuencia de predicción, y requisitos de gobernanza —explicabilidad, residencia de datos, control de acceso—, que en sectores regulados pueden descartar opciones que técnicamente funcionan.

La recomendación práctica es escribir la matriz antes de elegir. Un caso de uso resuelto con una API preentrenada y documentado como "prototipo que ahora es producto" suele necesitar una revisión: si el volumen crece, si la diferenciación empieza a importar o si la latencia ya no es suficiente, la decisión correcta puede cambiar, y es mejor revisarla por criterio que por agotamiento de la opción original.

Aplicado, el marco da respuestas distintas para escenarios que en superficie se parecen:

Escenario	Criterio que domina	Vía recomendada	Trade-off explícito
Clasificar el sentimiento de miles de reseñas con equipo sin ML	Velocidad	Natural Language API	Precisión genérica aceptable a cambio de salir en días
Detectar defectos de fábrica con fotos e inspectores propios	Diferenciación media con esfuerzo contenido	AutoML sobre imágenes	Coste de etiquetado y operación de modelo propio
Puntuar riesgo de crédito con la cartera histórica y obligación de explicar decisiones	Diferenciación y gobernanza	Modelo personalizado con explicabilidad	Semanas de trabajo y capacidad de MLOps sostenida
Transcribir y buscar en actas de reuniones	Velocidad y coste variable	Speech-to-Text API	Sin adaptación al vocabulario interno
Prever la demanda de 40.000 referencias ya almacenadas	Esfuerzo mínimo sobre dato existente	BigQuery ML	Sin capacidad de inferencia en línea sin registro en Vertex AI

La columna que casi siempre decide es la primera: identificar el criterio dominante elimina la mitad de las opciones antes de discutir métricas. Y si un escenario presenta dos criterios dominantes en tensión —velocidad y diferenciación—, la respuesta madura es secuenciar: empezar por la vía rápida para validar la hipótesis de negocio y comprometer la inversión en modelo propio solo cuando el uso demuestre que la diferenciación vale la pena.

Subtema 2: APIs preentrenadas: capacidades listas para consumir

Las APIs preentrenadas exponen modelos entrenados por Google como servicios web que se invocan con una petición y devuelven una respuesta estructurada. No exigen datos de entrenamiento propios ni experiencia de ML: se habilitan, se autentican y se llaman. Son la vía más rápida de producción y la respuesta habitual cuando la tarea es estándar.

Las APIs relevantes para este dominio y la función que cumple cada una:

API	Qué hace	Entrada típica	Caso de negocio
Natural Language API	Sentimiento, entidades, clasificación de contenido, sintaxis y moderación	Texto	Reseñas, tickets, informes
Vision API	Etiquetado de imágenes, OCR, detección de logotipos y contenidos inapropiados	Imagen	Inspección, archivo visual, moderación
Cloud Translation API	Traducción automática y detección de idioma	Texto	Soporte y contenido multiridioma
Speech-to-Text API	Transcripción de audio a texto, con identificación de hablantes y marcas de tiempo	Audio	Grabaciones, llamadas, reuniones
Text-to-Speech API	Síntesis de voz natural con voces neuronales y SSML	Texto	IVR, asistentes, lectura automática
Video Intelligence API	Etiquetado y detección de objetos y scenas en vídeo	Vídeo	Catalogación, seguridad, cumplimiento

El patrón de consumo es siempre el mismo: petición JSON con el contenido (texto, bytes de imagen codificados o referencia al archivo) y respuesta JSON con las anotaciones. Desde el punto de vista de negocio, las tres características que definen la propuesta son el tiempo de puesta en marcha (días o menos), el modelo de coste ligado al uso (se paga por operación, sin capacidad reservada) y la ausencia de operación de modelos (sin entrenamiento, despliegue ni reentrenamiento a cargo del cliente).

Sus límites también son estructurales y conviene declararlos. El modelo responde dentro de una capacidad de diseño fijo: admite las categorías y los formatos que expone, y no aprende del contenido propio del consumidor. En tareas donde la terminología, los productos o los criterios son específicos de la organización, la precisión genérica puede quedar corta; ahí la respuesta no es "usar mejor la API", sino AutoML o un modelo propio. A eso se añaden las restricciones operativas habituales de cualquier API: límites de tamaño y de frecuencia de llamada, y el requisito de enviar el contenido al servicio para su procesamiento, algo que hay que contrastar con los requisitos de privacidad del caso de uso.

Ejemplo Práctico

La promesa de las APIs preentrenadas se comprueba con una sola llamada. Este ejemplo analiza el sentimiento de un texto de atención al cliente sin haber entrenado nada:

# Habilitar la API y autenticar la petición
gcloud services enable language.googleapis.com --project=PROJECT_ID

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  --data '{"document":{"type":"PLAIN_TEXT","content":"La entrega llegó tarde, pero el agente resolvió todo en la llamada."}}' \
  "https://language.googleapis.com/v1/documents:analyzeSentiment"

Lectura de la salida en términos de negocio. La respuesta incluye el sentimiento del documento (documentSentiment con score y magnitude) y el sentimiento por frase, lo que permite distinguir un comentario globalmente positivo con una queja concreta de uno negativo de punta a punta. El tiempo entre habilitar la API y obtener métricas de sentimiento sobre miles de reseñas se mide en horas, frente a las semanas de construir y etiquetar un modelo propio: ese es el trade-off de velocidad a cambio de diferenciación, y en tareas estándar la apuesta es la correcta. El siguiente paso de negocio no es técnico, sino de proceso: definir qué se hace con la señal —alerta cuando el sentimiento cae por debajo de un umbral, enrutado prioritario, medición semanal por producto—.

Subtema 3: AutoML: un modelo propio con mínimo código

AutoML entrena un modelo con los datos de la organización mediante una interfaz de bajo código, asumiendo tareas de preparación, selección de algoritmo y ajuste de hiperparámetros que normalmente exigen un equipo de ML. Es la respuesta para cuando la capacidad genérica de una API no basta —los datos y los criterios son propios— pero el equipo no quiere (ni debe) construir un modelo desde cero.

El alcance de AutoML cubre los principales tipos de dato y tarea: clasificación y detección de objetos sobre imágenes, clasificación y sentimiento sobre texto, clasificación y detección de elementos sobre vídeo, y clasificación, regresión y previsión sobre datos tabulares. AutoML Translation permite además entrenar modelos de traducción adaptados al vocabulario propio, un caso muy frecuente en catálogos y documentación técnica.

Lo que AutoML exige es el trabajo que no puede automatizarse: un dataset etiquetado con calidad. En visión, la práctica habitual es del orden de decenas a cientos de ejemplos por categoría como mínimo para que el entrenamiento sea útil, y en tabular el volumen depende de la señal disponible; la regla de negocio es que el coste de etiquetar suele superar al coste de entrenar. Por eso el proyecto real de AutoML empieza siempre por una auditoría del origen y de la calidad de las etiquetas, no por la consola de entrenamiento.

El flujo de trabajo es estable sea cual sea el tipo de dato: crear el dataset, importar y revisar los datos (con revisión humana de etiquetas en casos críticos), entrenar, evaluar contra el conjunto de prueba, interpretar resultados y desplegar en endpoint para predicción en línea o como predicción por lotes. Vertex AI acompaña cada paso con métricas comparables entre versiones, y la evaluación es el momento en que se decide si el modelo es aceptable para el proceso de negocio, con los umbrales acordados de antemano.

Decisión	API preentrenada	AutoML
Datos propios de entrenamiento	No se usan	Son el insumo esencial
Etiquetado	Innecesario	Necesario y crítico
Especificidad de la tarea	Genérica, compartida	Adaptada al caso propio
Expertise ML	Ninguno	Bajo: interfaz guiada, métricas guiadas
Tiempo hasta primera versión	Horas o días	Días o semanas, dominado por la preparación
Diferenciación	Nula	Media: el modelo usa la ventaja de los propios datos
Operación del modelo	No existe (se consume)	Existe: versiones, despliegue, evaluación periódica

Subtema 4: Modelos personalizados: cuando la capacidad es la ventaja

El entrenamiento personalizado (custom training) da control total: se elige el framework (TensorFlow, PyTorch, scikit-learn, XGBoost y otros), se escribe el código de entrenamiento, se diseña la arquitectura, se ajustan los hiperparámetros y se decide el hardware, incluidos aceleradores GPU o TPU cuando el tamaño del modelo lo exige. Vertex AI ejecuta ese entrenamiento como trabajo gestionado, sin que el equipo gestione servidores.

Es la vía correcta cuando concurren varias de estas condiciones: la tarea no está cubierta por AutoML (arquitecturas específicas, objetivos de negocio no estándar, requisitos de rendimiento muy exigentes); la diferenciación de la capacidad justifica el coste; existe ya un equipo de datos capaz de construir y mantener el ciclo; o el problema exige control fino sobre datos de entrenamiento, explicabilidad profunda o integración particular en el producto.

El trade-off es el más exigente de los tres. El esfuerzo no termina con el primer modelo decente: incluye experimentación reproducible, evaluación rigurosa, despliegue versionado, monitorización de deriva y reentrenamiento, que es el cuerpo de la disciplina de MLOps. Un modelo personalizado sin operación es un activo que se degrada en silencio, y el coste de mantenimiento suele ser varias veces el coste del primer entrenamiento.

Una ruta intermedia que conviene dominar: BigQuery ML permite entrenar modelos de regresión, clasificación, clustering, series temporales y más con SQL, sobre los datos ya gobernados en el warehouse. Es ideal cuando el equipo domina SQL pero no tiene perfil de ML, y su integración con Vertex AI permite registrar el modelo en el Model Registry y servirlo desde endpoints de Vertex AI sin exportarlo manualmente.

Dimensión	API preentrenada	AutoML	Modelo personalizado
Velocidad a producción	Horas a días	Días a semanas	Semanas a meses
Datos de entrenamiento propios	No necesarios	Necesarios y etiquetados	Necesarios, grandes y limpios
Etiquetado	No aplica	Requerido	Requerido (y a mayor escala)
Expertise ML	Ninguno	Bajo	Alto, con perfiles especializados
Esfuerzo de ingeniería	Mínimo	Medio	Alto, incluido MLOps
Diferenciación	Baja: capacidad compartida	Media: ventaja en los datos	Alta: ventaja en datos y diseño
Control del modelo	Ninguno	Parcial	Total
Operación a cargo	No existe	Gestión de versiones y despliegue	Ciclo completo de MLOps
Cuándo elegirlo	Tarea estándar y velocidad	Datos propios, tarea estándar	Capacidad clave con requisitos propios

Subtema 5: Vertex AI como plataforma unificada

Vertex AI es la plataforma de IA y ML de Google Cloud que reúne el ciclo de vida completo bajo un mismo modelo de identidad, de datos y de gobernanza. Su valor de negocio no está en un componente aislado, sino en que la organización opera todas sus iniciativas de IA con las mismas herramientas, los mismos permisos y la misma trazabilidad, en lugar de una colección de scripts, cuadernos y entornos heterogéneos.

Sus componentes, por etapa del ciclo de vida:

Datos: datasets tabulares, de imagen, de texto, de vídeo y de documento, con vinculación a BigQuery y Cloud Storage; Vertex AI Feature Store para servir características de forma consistente entre entrenamiento e inferencia.
Entrenamiento: AutoML, entrenamiento personalizado gestionado, ajuste de hiperparámetros y trabajos de afinado de modelos fundacionales; Vertex AI Workbench aporta cuadernos gestionados para exploración y experimentación.
Catálogo de modelos: Model Garden como biblioteca de modelos de Google, de socios y de código abierto listos para descubrir, probar y desplegar; Vertex AI Model Registry para versionar, comparar y seguir los modelos de la organización con sus métricas y linaje.
Despliegue: endpoints con escalado gestionado, predicción por lotes, y despliegue canario o por versiones para reducir el riesgo de cada cambio.
Operación: monitorización de modelos (deriva de datos, deriva de predicciones, sesgo entre características), explicabilidad con Explainable AI, evaluación de modelos y Vertex AI Pipelines para orquestar y reproducir el ciclo.
IA generativa: herramientas de prototipado y uso de modelos fundacionales, con controles de seguridad y evaluación, que se detallan en el tema siguiente.

Vertex AI no sustituye a las APIs preentrenadas ni a BigQuery ML: los integra. Las APIs de Google Cloud siguen siendo la vía más rápida para tareas estándar, y BigQuery ML sigue siendo la más ágil para equipos de SQL; Vertex AI es la capa donde ambas —y los modelos propios— se registran, se gobern y se operan de forma conjunta. Para un Digital Leader, la afirmación de valor es que la plataforma convierte la IA de proyectos aislados en una capacidad gestionada de la organización.

Hay un beneficio operativo que suele subestimarse en las decisiones de compra: al correr sobre la misma plataforma que el resto de los servicios, la IA hereda los controles que la organización ya tiene —permisos de IAM por proyecto y por recurso, cuotas, registros de auditoría, segmentación de red y etiquetado de costes— en lugar de exigir un sistema de permisos y de gasto paralelo. Cuando el equipo de seguridad pregunta quién puede invocar un modelo en producción, la respuesta se resuelve con la misma política que se usa para cualquier otro recurso, y cuando finanzas pregunta cuánto cuesta la iniciativa de IA, la respuesta se atribuye con las mismas etiquetas que el resto del consumo.

Ejemplo Práctico

El punto de partida de cualquier decisión sobre portafolio de IA es saber qué existe hoy y en qué estado está:

# Habilitar la plataforma y ver los activos de IA del proyecto
gcloud services enable aiplatform.googleapis.com --project=PROJECT_ID

gcloud ai datasets list --region=us-central1 \
  --format="table(name,displayName,createTime)"

gcloud ai models list --region=us-central1 --sort-by=~createTime \
  --format="table(name,displayName,createTime)"

gcloud ai endpoints list --region=us-central1 \
  --format="table(name,displayName,createTime)"

# Trabajos fallidos: el indicador de salud del ciclo de entrenamiento
gcloud ai custom-jobs list --region=us-central1 \
  --filter="state=JOB_STATE_FAILED" \
  --format="table(name,displayName,state)"

Lectura de la salida en términos de negocio. La lista de datasets y modelos responde a la pregunta que hace todo responsable de inversión: ¿cuántos modelos tenemos, cuándo se crearon y cuántos están realmente desplegados? La brecha entre models y endpoints es informativa: muchos modelos registrados con pocos endpoints significa que se entrena más de lo que se sirve, y que hay coste de experimentación sin producto asociado. Los trabajos en JOB_STATE_FAILED no son ruido técnico: cada uno representa tiempo de cómputo y de equipo perdido, y su frecuencia es el mejor predictor del coste real de mantener un programa de ML; si se repiten sin que nadie los revise, el programa carece de operación, que es la primera carencia que hay que corregir antes de añadir nuevos modelos.

Temas relacionados: AI, Machine Learning and Generative AI Fundamentals, Contact Center AI, Document AI and Specialized APIs, Responsible AI Principles and Model Governance, BigQuery and Enterprise Data Warehousing

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
API preentrenada	Servicio que invoca un modelo ya entrenado sin datos ni expertise propios	Tarea estándar donde la velocidad y la simplicidad priman
AutoML	Entrenamiento de un modelo propio con datos etiquetados mediante interfaz de mínimo código	Cuando los datos propios son la ventaja y no hay equipo de ML profundo
Entrenamiento personalizado	Entrenamiento con código, framework y arquitectura propios, ejecutado de forma gestionada	Capacidad clave con requisitos no cubiertos por las vías anteriores
Vertex AI	Plataforma unificada de datos, entrenamiento, registro, despliegue y operación de modelos	Para operar el ciclo de vida del ML con gobierno y trazabilidad
Model Garden	Biblioteca de modelos de Google, socios y código abierto listos para probar y desplegar	Para descubrir y evaluar modelos sin construir desde cero
Vertex AI Model Registry	Registro versionado de modelos con métricas y linaje	Para saber qué modelo está en producción y con qué rendimiento
Endpoint	Interfaz gestionada de predicción en línea con escalado automático	Cuando la aplicación necesita respuestas en milisegundos
Predicción por lotes	Inferencia masiva asíncrona sobre datos almacenados	Puntuaciones nocturnas, procesamiento histórico, clasificaciones masivas
Vertex AI Pipelines	Orquestación reproducible del ciclo de datos, entrenamiento y evaluación	Cuando el proceso debe repetirse y auditarse
Explainable AI	Atribución de la contribución de cada característica a la predicción	En decisiones sobre personas y en auditoría de modelos
Monitorización de modelos	Detección de deriva de datos, de predicciones y de sesgo en producción	Siempre que un modelo sirve decisiones reales
BigQuery ML	Modelos creados y evaluados con SQL dentro del warehouse	Equipos de datos con dominio de SQL y sin perfil de ML
MLOps	Prácticas de automatización, versionado, evaluación y monitorización del ciclo de ML	Para sostener modelos en producción más allá del piloto

Comparaciones

Eje	API preentrenada	AutoML	Modelo personalizado
Velocidad	Máxima: horas o días	Media: días o semanas	Baja: semanas o meses
Esfuerzo de datos	Ninguno	Etiquetado propio	Etiquetado e ingeniería a gran escala
Expertise requerido	Ninguno	Bajo	Alto, con MLOps
Diferenciación	Nula	Media (datos propios)	Alta (datos y diseño propios)
Control	No hay modelo propio	Parcial	Total
Operación	Se consume el servicio	Versiones y despliegue	Ciclo completo de MLOps
Coste de entrada	Bajo y variable	Medio	Alto, con coste fijo de equipo
Riesgo principal	Precisión genérica insuficiente	Calidad del etiquetado	Deriva y falta de operación
Caso típico	OCR, sentimiento, traducción, voz	Clasificación de defectos con fotos propias	Modelo de riesgo o recomendación diferencial

Eje	BigQuery ML	Vertex AI
Punto de partida	SQL sobre datos ya presentes en el warehouse	Plataforma completa de ML y IA
Perfil que lo hace viable	Analista o ingeniero de datos sin perfil de ML	Equipos de datos, ML y MLOps
Ciclo cubierto	Entrenamiento y evaluación por SQL	Datos a producción, monitorización y explicabilidad
Despliegue	Inferencia por SQL; registro en Vertex AI para endpoint	Endpoints, lotes, escalado y versiones
Cuándo usarlo	Modelos clásicos donde ya vive el dato	Cuando el modelo requiere operación completa o modelos no clásicos

Errores Comunes

Error: Elegir siempre la vía más avanzada —modelo personalizado— porque "lo propio es mejor", sin sopesar velocidad, esfuerzo ni expertise. → Solución: Aplicar los cuatro criterios por caso de uso y justificar la vía elegida. Para tareas estándar, la API preentrenada es técnicamente inferior y estratégicamente correcta; reservar el entrenamiento personalizado para las capacidades que realmente diferencian y para las que AutoML no cubre.
Error: Presupuestar un proyecto de AutoML sin contar el coste de preparar y etiquetar los datos. → Solución: Hacer la auditoría de etiquetas antes de comprometer la fecha: volumen, calidad, definición de la categoría y proceso de revisión. En la práctica, la preparación de datos domina el esfuerzo, y un dataset mal etiquetado produce un modelo malo con coste de entrenamiento pagado.
Error: Considerar el primer modelo entrenado como el final del proyecto. → Solución: Planear desde el inicio la operación: registro en el Model Registry, monitorización de deriva y rendimiento, responsables, métricas de negocio y calendario de reentrenamiento. Un modelo en producción sin supervisión degrada su calidad de decisión sin que el sistema señale ningún error.
Error: Tratar las APIs preentrenadas y Vertex AI como opciones excluyentes. → Solución: Diseñar el portafolio como un recorrido: API para validar el caso de uso con rapidez, AutoML cuando los datos propios aportan ventaja, modelo propio donde la diferenciación lo justifique, y Vertex AI como capa común de registro, despliegue y gobierno de todos ellos. La plataforma integra las vías, no compite con ellas.
Error: Medir el éxito de una iniciativa de IA por la métrica del modelo y no por el impacto en el proceso de negocio. → Solución: Acordar antes de entrenar el indicador de negocio y el umbral de aceptación, instrumentar el proceso que consume la predicción y verificar después el cambio real —coste, tiempo de ciclo, ingreso—. Si el modelo mejora y el proceso no cambia, la inversión no ha generado retorno.

Puntos para el Examen

🎯 Punto clave 1: Las cuatro tensiones de toda decisión de solución de IA son velocidad, esfuerzo, diferenciación y expertise requerido. Casi todas las preguntas de caso se resuelven identificando cuál de ellas domina el escenario: prisa de mercado → API; datos propios como ventaja → AutoML; capacidad diferencial con equipo disponible → modelo personalizado.

🎯 Punto clave 2: La comparación API preentrenada / AutoML / modelo personalizado es la matriz central del tema: a mayor control y diferenciación, mayor esfuerzo de datos, expertise y tiempo. La respuesta correcta nunca es la que maximiza todos los ejes, sino la que declara el trade-off asumido.

🎯 Punto clave 3: Las APIs preentrenadas —Natural Language, Vision, Translation, Speech-to-Text, Text-to-Speech, Video Intelligence— se consumen por llamada, sin entrenamiento ni operación de modelos, y son la respuesta a tareas estándar con necesidad de rapidez. Su límite estructural es que no aprenden del caso propio.

🎯 Punto clave 4: Vertex AI es la plataforma unificada del ciclo de vida: datos, entrenamiento (AutoML y custom), Model Garden, Model Registry, endpoints, monitorización y explicabilidad. Reconocer en qué etapa está cada componente —y que BigQuery ML se integra con él— permite resolver las preguntas de arquitectura de IA.

🎯 Punto clave 5: El trabajo que ninguna vía automatiza es el de los datos: etiquetar, validar y mantener representativos los ejemplos de entrenamiento. Cuando un escenario describa problemas de calidad, de volumen de etiquetas o de representatividad, la respuesta está en la preparación de datos, no en la elección del algoritmo.

Recursos Externos

Vertex AI documentation — Punto de entrada de la plataforma: conceptos, flujos de trabajo y componentes del ciclo de vida.
Train and use your own models — Comparación entre AutoML, entrenamiento personalizado y Ray on Vertex AI dentro de la plataforma.
AutoML beginner's guide — Flujo completo de un modelo AutoML: dataset, entrenamiento, evaluación y uso.
Overview of Model Garden — Catálogo de modelos de Google, socios y código abierto, con patrón de despliegue unificado.
Natural Language API documentation — Ejemplo representativo de API preentrenada: análisis de sentimiento, entidades y clasificación.

Autoevaluación Rápida

Pregunta: Un equipo quiere detectar objetos defectuosos en fotos de la línea de producción, tiene 8.000 imágenes etiquetadas por sus propios inspectores y necesita que el criterio se ajuste a sus definiciones internas. ¿Qué vía eliges y por qué? Respuesta: AutoML. Hay datos propios etiquetados (condición esencial), la tarea es estándar —clasificación o detección de objetos— y el criterio propio exige un modelo entrenado con esas etiquetas; una API preentrenada no conocería sus categorías internas, y un modelo personalizado añadiría expertise y tiempo que el caso no justifica. El trade-off asumido es aceptar la operación de un modelo propio con el mínimo de MLOps posible.
Pregunta: La misma organización necesita traducir su catálogo técnico a doce idiomas con vocabulario propio. ¿Cambia la recomendación? Respuesta: Sí, y el matiz está en la especificidad del lenguaje. Para traducción general, la Cloud Translation API es la respuesta por velocidad. Con terminología propia de producto, la opción intermedia es el entrenamiento de traducción adaptada (AutoML Translation) con ejemplos de traducción del dominio; y solo si la calidad exigida lo justifica y existe equipo, un modelo de traducción dedicado. El criterio de decisión sigue siendo el mismo: especificidad de la capacidad frente a esfuerzo y tiempo.
Pregunta: ¿Cuál es la diferencia de negocio principal entre una API preentrenada y AutoML, más allá de la técnica? Respuesta: La propiedad de la ventaja. La API consume una capacidad genérica compartida, paga por uso y no opera modelos: máxima velocidad y mínima responsabilidad, pero tampoco diferenciación. AutoML produce un modelo propio entrenado con los datos de la organización, lo que incorpora ventaja específica y, con ella, la responsabilidad de etiquetar bien, desplegar, monitorizar y reentrenar. La decisión es cuánta propiedad sobre la capacidad se quiere y se puede operar.
Pregunta: ¿Qué papel juega Vertex AI si ya se usan APIs preentrenadas y BigQuery ML? Respuesta: Es la capa de unificación y gobierno. Los modelos de BigQuery ML pueden registrarse en el Vertex AI Model Registry y desplegarse en endpoints de Vertex AI, y las capacidades de la plataforma —monitorización, explicabilidad, pipelines, permisos y trazabilidad— se aplican al conjunto del portafolio. No sustituye a ninguna de las dos vías: convierte su uso disperso en un portafolio operable, con versiones comparables y una misma disciplina de operación.
Pregunta: El comité aprueba un modelo personalizado y pregunta cuándo verá retorno. ¿Qué respondes? Respuesta: Que el retorno depende de dos fechas distintas: cuándo la primera versión sustituye la decisión actual y cuándo el proceso mide el cambio. El entrenamiento personalizado es la vía más lenta —semanas o meses— porque incluye preparación de datos a escala, experimentación y la construcción del ciclo de operación; conviene secuenciar en versiones, entregar valor con una primera versión acotada y medir el impacto sobre el indicador de negocio acordado. Si el escenario admite empezar con una API o un AutoML para aprender antes, hacerlo reduce el riesgo total del programa.