Generative AI, Foundation Models and LLMs in Enterprise

Resumen

La IA generativa introduce un cambio de patrón en la adopción de inteligencia artificial: en lugar de entrenar un modelo por tarea con datos etiquetados, se parte de un modelo fundacional amplio y se lo adapta a múltiples casos de uso mediante instrucciones, contexto recuperado o ajuste fino. Este tema explica qué son los modelos fundacionales, qué es un gran modelo de lenguaje (LLM), cómo se adaptan a un proceso de empresa y qué decisiones —de coste, seguridad, calidad y gobernanza— hay que tomar antes de llevarlos a producción.

El valor de negocio de la IA generativa se concentra donde el trabajo textual o creativo es el cuello de botella: atención al cliente, conocimiento interno, productividad, desarrollo de software, procesamiento documental y contenido. En todos ellos la propuesta es similar —reducir el tiempo de una tarea o elevar su calidad de forma medible— y en todos aparece el mismo riesgo estructural: el modelo produce texto plausible con apariencia de certeza aunque la respuesta sea falsa. Por eso la adopción empresarial madura se define por sus controles, no por sus demos.

Google Cloud pone a disposición esta capacidad a través de Vertex AI, donde Gemini —la familia de modelos fundacionales de Google— y otros modelos de socios y de código abierto se prueban, comparan, personalizan y despliegan con los mismos controles de identidad, red y coste que el resto de la plataforma. Sobre esa base, el tema recorre el marco de consideraciones empresariales: cómo se factura el uso (por tokens), cómo se protegen los datos enviados, cómo se gobierna el contenido generado y cómo se secuencia la adopción desde la instrucción más simple hasta el modelo afinado con datos propios.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Definir modelo fundacional y diferenciarlo de un modelo entrenado para una tarea concreta.
Explicar qué es un gran modelo de lenguaje (LLM) y cómo genera y evalúa una respuesta.
Describir los niveles de adaptación de un modelo fundacional —prompting, examples en contexto, RAG o grounding, fine-tuning— y elegir el adecuado según la necesidad.
Situar a Gemini dentro de la oferta de IA generativa de Google Cloud y describir el acceso a través de Vertex AI.
Identificar casos de uso de IA generativa con valor de negocio y asociar a cada uno su indicador de éxito.
Reconocer los riesgos de la generación —alucinación, sesgo de contenido, inyección de instrucciones— y proponer sus mitigaciones.
Analizar el coste de una solución de IA generativa por tokens y las palancas de control disponibles.
Describir los controles de seguridad y privacidad aplicables al dato enviado para inferencia.
Proponer un marco de gobernanza operativa: uso aceptable, revisión humana, evaluación previa, trazabilidad y responsables.
Secuenciar una adopción desde el prototipo a la producción con evaluación continua y métricas de negocio.

Contenido Principal

Subtema 1: Modelos fundacionales: un modelo, múltiples tareas

Un modelo fundacional es un modelo entrenado a gran escala con una colección amplia y heterogénea de datos, diseñado para servir de base a muchas tareas distintas mediante adaptación. El cambio frente al ML tradicional es económico y operativo: antes, cada capacidad nueva —clasificar documentos, resumir, extraer entidades— exigía reunir etiquetas, entrenar un modelo propio y operarlo; ahora se parte de un modelo que ya incorpora capacidad general de lenguaje, visión o audio, y el esfuerzo se concentra en adaptarlo al caso.

La adaptación ocurre en niveles con distinto coste y distinta profundidad, y reconocerlos es la base de cualquier decisión de implementación:

Instrucción directa (prompting): se describe la tarea y se dan restricciones en cada llamada. Coste mínimo, sin datos propios; la calidad depende de la claridad de la instrucción.
Ejemplos en contexto (few-shot): se añaden pocos ejemplos de la respuesta deseada dentro de la instrucción. Mejora consistencia sin entrenar nada, a costa de longitud de la instrucción.
Contexto recuperado (RAG o grounding): se recuperan fragmentos de fuentes propias —documentación, contratos, base de conocimiento— y se entregan al modelo con la pregunta, para que responda sobre evidencia y no sobre su memoria. Es la vía estándar para respuestas sobre datos privados y actualizables.
Ajuste fino (fine-tuning): se recalibran los pesos del modelo con ejemplos propios. Es la vía más profunda y más costosa, justificada por formatos, estilos o comportamientos muy específicos y repetidos.

Cuatro propiedades condicionan el uso empresarial. La multimodalidad: los modelos actuales trabajan de forma conjunta con texto, imagen, audio y vídeo, lo que habilita casos como analizar un plano junto a su incidencia o resumir una grabación con su transcripción. El conocimiento paramétrico: el modelo incorpora patrones y hechos aprendidos durante el entrenamiento, con una fecha de corte; lo que no sabe, o lo que debe salir de documentos privados, se resuelve con contexto recuperado. La ventana de contexto: la cantidad de texto que admite cada instrucción, que fija cuánto material se puede entregar de una vez. Y la naturaleza probabilística: el modelo predice la continuación más probable, no consulta una base de verdad, de donde surge tanto su fluidez como su riesgo de alucinación.

El efecto económico de fondo es que el coste de desarrollo se amortiza sobre muchas capacidades. En el modelo anterior, cada tarea nueva repetía el ciclo completo de recolección de etiquetas, entrenamiento y operación; con un modelo fundacional, ese ciclo solo se paga cuando la adaptación por instrucción o por contexto resulta insuficiente. La consecuencia para la planificación es que el portafolio de casos de uso deja de ser una suma de proyectos de ML independientes y pasa a ser una cartera de adaptaciones sobre una base común, con un coste marginal por caso de uso mucho menor y una operación que, por tratarse de un servicio gestionado, también se centraliza.

Nivel de adaptación	Qué implica	Datos propios	Coste y esfuerzo	Cuándo usarlo
Prompting	Instrucción bien escrita con rol, tarea y restricciones	No	Muy bajo	Tarea general, prototipo, uso esporádico
Few-shot	Ejemplos de respuesta incluidos en la instrucción	Pocos ejemplos	Bajo	Formato de salida concreto y estable
RAG / grounding	Recuperación de fuentes propias entregadas como contexto	Documentos indexados	Medio: indexación, búsqueda y actualización	Respuestas sobre datos privados o que cambian
Fine-tuning	Recalibración de los pesos con ejemplos propios	Conjunto de ejemplos significativo	Alto: entrenamiento, evaluación y ciclos	Estilo, formato o comportamiento muy específico

Subtema 2: Grandes modelos de lenguaje (LLM) y Gemini

Un gran modelo de lenguaje (LLM) es un modelo fundacional orientado al lenguaje: se entrena para predecir la continuación de texto y, de esa tarea aparentemente simple, emergen capacidades de redacción, resumen, traducción, extracción, razonamiento estructurado y generación de código. Para el negocio conviene retener su mecánica esencial: el texto se procesa en tokens (unidades que equivalen con frecuencia a fragmentos de palabra), el modelo genera los tokens de forma sucesiva, y la ventana de contexto delimita cuánto cabe en la instrucción —documento, historial y pregunta— en cada llamada.

Tres parámetros explican la mayor parte del comportamiento observable. El equilibrio entre instrucción y contexto determina si la respuesta proviene de la tarea o del material entregado. El tamaño máximo de salida fija el límite de la respuesta y, con él, una parte directa del coste. Y la temperatura gobierna la diversidad de muestreo: valores conservadores producen respuestas estables y deterministas, adecuadas para clasificación, extracción y resúmenes; valores más altos admiten variación, útil en ideación. A ello se añade la posibilidad de exigir salidas estructuradas (JSON conforme a un esquema) cuando el destino es una aplicación y no una persona.

Gemini es la familia de modelos fundacionales de Google, con capacidades multimodales sobre texto, imagen, audio y vídeo, y es el producto de IA generativa de referencia dentro de Google Cloud. Se utiliza desde Vertex AI —donde se prueban, comparan y despliegan junto a otros modelos disponibles en Model Garden— y desde herramientas de Google orientadas al usuario final; en el ámbito empresarial, el acceso relevante es el de la plataforma, porque es el que trae permisos, ubicación de datos, monitorización y facturación por proyecto. La documentación del catálogo describe el modelo disponible en cada región, de modo que la identificación concreta de versión es una comprobación de operación, no un dato que convenga memorizar.

El riesgo central de los LLM es la alucinación: el modelo puede producir una respuesta fluida y convincente cuyo contenido no se sostiene en ninguna fuente. No se elimina por completo; se gestiona. Las palancas son exigir fuentes (grounding con documentos propios), limitar el alcance de la respuesta a lo que el contexto permite, usar estructuras de salida verificables, mantener evaluación con conjuntos de prueba propios y conservar la revisión humana en las decisiones externas o de alto impacto.

La calidad de un LLM tampoco se resume en una métrica única. Conviene separar cuatro evaluables: corrección factual (lo que afirma se sostiene en la fuente o en la realidad), cumplimiento de la instrucción (formato pedido, campos exigidos, tono, idioma), utilidad (si el resultado ahorra trabajo real a quien lo recibe) y seguridad (si resiste entradas hostiles y no produce contenido inaceptable). Cada una admite su propia prueba: pares pregunta-respuesta revisados por personas, verificación automática de estructura de salida, medición de edición posterior y baterías de entradas adversas. Un modelo puede aprobar en corrección y suspender en cumplimiento de formato, de modo que un único "porcentaje de aciertos" esconde el fallo que después rompe la integración con la aplicación.

Ejemplo Práctico

# Habilitar la plataforma y preparar la llamada al modelo
gcloud services enable aiplatform.googleapis.com --project=PROJECT_ID

MODEL="gemini-2.5-flash"   # ID publicado en Model Garden; comprobar el disponible en tu región
LOCATION="us-central1"

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://$LOCATION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/$LOCATION/publishers/google/models/$MODEL:generateContent" \
  -d '{
    "contents": [{
      "role": "user",
      "parts": [{"text": "Extrae en JSON los campos cliente, fecha y vigencia de este contrato: <texto del contrato>"}]
    }],
    "generationConfig": {"maxOutputTokens": 500, "responseMimeType": "application/json"}
  }'

Lectura de la salida en términos de negocio. La respuesta contiene el texto generado y la configuración con la que se produjo; la petición muestra las dos perillas de coste y de calidad que hay que gobernar: maxOutputTokens limita el gasto por llamada y el tamaño de la respuesta, y la solicitud de salida estructurada hace que el resultado sea consumible por un sistema (por ejemplo, para cargar los campos en BigQuery) en lugar de solo por una persona. El fragmento de ejemplo en el prompt es además la semilla del caso de uso real: para contratos completos, entregar el texto entero en cada llamada resulta caro y supera la ventana de contexto, y la respuesta natural es recuperar los pasajes relevantes con búsqueda —grounding— sobre el repositorio documental.

Subtema 3: Casos de uso de IA generativa con valor de negocio

El valor no aparece donde el modelo es más sofisticado, sino donde una tarea textual consume tiempo humano de forma repetitiva o donde la calidad del texto limita el resultado. Estos son los patrones con retorno más directo y la métrica que los hace medibles:

Caso de uso	Problema que resuelve	Valor de negocio	Métrica típica	Control imprescindible
Atención al cliente	Resúmenes de conversación, sugerencias al agente, borradores de respuesta	Menos tiempo por interacción y mejor calidad	Tiempo medio de atención, satisfacción, contención	Fuentes de conocimiento y revisión de respuestas
Conocimiento interno	Preguntas en lenguaje natural sobre documentación dispersa	Menos tiempo buscando y menos dependencia de personas clave	Tiempo de resolución, adopción	Indexación gobernada y permisos heredados
Productividad	Redacción, resumen, traducción y corrección de borradores	Ciclos más cortos en tareas de oficina	Horas por entregable, tiempo de ciclo	Revisión humana y estilo corporativo
Desarrollo de software	Generación, explicación y migración de código	Mayor velocidad de entrega técnica	Tiempo por tarea, defectos por entrega	Revisión de código y políticas de seguridad
Back-office documental	Extracción, clasificación y resumen de documentos	Menos procesamiento manual	Coste y tiempo por documento	Validación de campos y trazabilidad
Marketing y comunicación	Variantes de copy y adaptación de mensajes	Más pruebas por ciclo, producción más rápida	Tiempo de producción, conversión por variante	Aprobación editorial y revisión de marca

Dos reglas transversales sostienen estos casos. Primero, la atribución del ahorro: si la tarea no se medía antes de la IA generativa, no se podrá demostrar el después; conviene capturar la línea base de tiempo o coste antes de desplegar. Segundo, la posición del humano: en contenidos externos, decisiones contractuales y comunicaciones con clientes, el modelo propone y una persona aprueba; el ahorro proviene de que el humano revisa un borrador sólido en lugar de partir de cero, no de eliminar la revisión.

También conviene reconocer dónde la IA generativa no es la respuesta: cuando se necesita una cifra exacta y auditable (los agregados siguen siendo consulta de datos), cuando la verificación es más costosa que la tarea (resúmenes de documentos cuya omisión es un riesgo legal sin revisión) y cuando una regla determinista resuelve el proceso con la misma calidad. Aplicar generación donde basta una regla añade coste por token y un nuevo modo de fallo sin contrapartida.

Los casos de uso se materializan en tres patrones de implantación con distinto nivel de autonomía, y elegirlo mal es una fuente frecuente de fricción:

Patrón	Quién ejecuta	Ejemplo	Requisito de control
Asistente que sugiere	El humano aprueba cada resultado	Borrador de respuesta al cliente en la consola de soporte	Edición rápida y fuentes a la vista
Proceso acotado autónomo	El modelo ejecuta sin aprobación, dentro de límites	Resumen automático de la conversación tras la llamada	Salida de impacto bajo y registro de la ejecución
Característica de producto	El modelo alimenta una función que usan clientes o usuarios	Búsqueda conversacional sobre la base de conocimiento	Evaluación continua, límites de uso y experiencia de fallo definida

El criterio de elección es el coste del error, no la comodidad técnica: a mayor daño potencial del resultado, más cerca debe estar el humano del paso final. Un error en un resumen interno es molestía; un error en una respuesta enviada al cliente es incidencia reputacional; y un error en una decisión sobre una persona es un problema de cumplimiento.

Subtema 4: Consideraciones empresariales: coste, seguridad y gobernanza

Coste. El consumo de los modelos de lenguaje se factura por tokens de entrada y de salida, con tarifas que varían según el modelo y la ubicación, de modo que el coste es proporcional al volumen de texto procesado y a la frecuencia de llamada. La consecuencia de gestión es que la demo barata no garantiza producción barata: un proceso que genera cientos de miles de interacciones diarias con instrucciones largas y salidas ilimitadas cambia de escala de coste. Las palancas de control son elegir el modelo adecuado a la tarea (los modelos más capaces no son necesarios para clasificar o extraer), recortar instrucciones a lo necesario, limitar el tamaño de salida, caché o reutilizar el contexto fijo, procesar por lotes cuando no hay latencia exigible y monitorizar el consumo por proyecto y por proceso. No hay cifras útiles que memorizar: lo que sí hay que hacer es medir el coste por interacción y compararlo con el coste de la tarea humana que sustituye o complementa.

El método para dimensionarlo sin datos históricos es simple y no requiere fórmulas secretas: tomar un caso de uso representativo, medir la longitud típica de su instrucción y de su contexto, estimar el tamaño de la respuesta que se aceptaría como correcta, contar las interacciones esperadas por día y multiplicar. Con esas tres cantidades —entrada, salida y volumen— se obtiene un rango de coste por proceso que se compara con las horas humanas equivalentes. La comparación rara vez es "la IA es más barata": suele ser "la IA es más rápida y constante a un coste conocido", y el argumento que convence es el de escala —qué ocurre con ese coste cuando las interacciones se multiplican por diez—, no el del ahorro unitario en el piloto.

Seguridad y privacidad. El modelo necesita ver el texto, de modo que el dato sensible que se envía en una instrucción es dato en tránsito hacia un servicio. Los controles de la plataforma son los habituales: identidad y permisos por proyecto, segmentación de red y controles de acceso a servicios de Google, ubicación de los recursos y registro de auditoría de las llamadas. Sobre el tratamiento de los datos, Google Cloud publica que los datos que sus clientes envían a sus servicios de IA generativa no se emplean para entrenar sus modelos compartidos sin permiso; conviene verificar el tratamiento aplicable al contrato y a la región de uso. En la práctica, la primera medida es de diseño: minimizar la información personal en los prompts, enmascarar lo que no aporta a la tarea y separar proyectos entre entornos de prueba y producción.

Un riesgo nuevo propio de esta tecnología es la inyección de instrucciones: si el modelo procesa texto de origen no controlado —formulario público, correo entrante, documento de tercero—, ese texto puede contener instrucciones dirigidas al modelo. La mitigación combina diseño (el texto no confiable se trata como dato, no como instrucción), limitación del alcance de la herramienta que el modelo puede invocar y revisión de resultados.

Gobernanza. Tres decisiones definen el marco antes del primer despliegue: qué usos están permitidos y cuáles no (política de uso aceptable), quién aprueba la salida en cada flujo (revisión humana y niveles de impacto), y cómo se evalúa y se registra (conjunto de pruebas de calidad, versión de modelo y de prompt, registro de cambios y trazabilidad de los contenidos generados cuando el contexto lo exige). A esto se suman los principios de IA responsable —equidad, responsabilidad, transparencia, privacidad y seguridad— tratados en Responsible AI Principles and Model Governance.

Un marco mínimo de gobernanza operativa se concreta en cinco decisiones documentadas:

Alcance permitido: qué tareas pueden delegarse y cuáles quedan reservadas a personas, con ejemplos explícitos de ambos lados.
Dueño de cada flujo: una persona responsable de la calidad, del coste y de la retirada del uso cuando deje de ser adecuado.
Umbral de aceptación: el nivel de calidad medido en las pruebas propias por debajo del cual el flujo no se publica ni se mantiene.
Registro de uso: qué modelo, qué instrucción y qué fecha produjeron una salida, habilitado por la plataforma y revisado en incidentes.
Condiciones de uso del modelo: qué permite y qué no el modelo y sus datos de entrenamiento para el caso concreto, verificadas en la documentación del catálogo antes de publicar.
Revisión periódica: fecha de reevaluación de fuentes, de modelo y de coste, para que la gobernanza no dependa de que alguien se acuerde.

Sin dueño y sin fecha de revisión, cualquier marco de gobernanza se degrada en cuanto cambia el modelo disponible o la presión por reducir coste.

Ejemplo Práctico

# 1. Quién puede invocar modelos de IA generativa en el proyecto
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)" | grep -E "aiplatform|roles/owner"

# 2. Tamaño de las instrucciones de producción (primera aproximación al consumo por token)
wc -c prompts/*.txt

# 3. Servicios de IA habilitados: qué está realmente activo en el entorno
gcloud services list --enabled --filter="name:aiplatform.googleapis.com"

Lectura de la salida en términos de negocio. El primer comando responde a la pregunta de seguridad y de rotación: quién tiene permiso para invocar modelos, y si hay identidades individuales con permisos amplios que deban pasar a grupos con dueño. El recuento de bytes de las instrucciones es una aproximación (no una conversión exacta) al volumen de tokens enviados por llamada: si una plantilla de contexto fijo multiplica por cinco la longitud de cada petición, ese multiplicador se aplica a cada interacción y es la primera palanca de ahorro, junto con el límite de salida. La lista de servicios habilitados muestra la brecha entre lo que se prueba y lo que se opera: servicios habilitados en proyectos de prueba que nadie deshabilita generan superficie de exposición y rastro de configuración que conviene revisar con el mismo criterio que el resto de la plataforma.

Subtema 5: Del prototipo a producción: evaluación y secuencia de adopción

La ruta que funciona en la práctica empieza por la instrucción más simple y solo sube de nivel cuando la evidencia lo exige. La secuencia típica es: prototipar con prompting sobre un caso de uso acotado y con métrica definida; incorporar grounding cuando la respuesta deba apoyarse en documentos propios o estar actualizada; añadir fine-tuning solo si persisten requisitos de estilo o comportamiento que el contexto no resuelve; y finalmente industrializar con despliegue, límites de tasa, reintentos, registro y supervisión.

La pieza que separa el piloto de la producción es la evaluación. "Se ve bien" no es un criterio de aceptación: hace falta un conjunto de pruebas propio —preguntas y respuestas de referencia, casos límite y casos de rechazo— que se ejecuta de forma repetida, tanto al cambiar de modelo como al cambiar de prompt. La evaluación combina una revisión humana inicial, que establece la línea base de calidad, y una medición automática posterior que permita comparar versiones sin volver a revisarlo todo. Los cambios de prompt se gestionan con la misma disciplina que los cambios de código: versionados, probados y reversibles.

La integración técnica también plantea decisiones de negocio encubiertas. En la vía en línea, la aplicación espera la respuesta del modelo y la latencia forma parte de la experiencia de usuario: hay que fijar presupuesto de tiempo, límites de tasa y reintentos, y definir cómo se degrada el servicio cuando el modelo no responde a tiempo —caer a una opción humana o a un mensaje de espera—. En la vía por lotes, la respuesta no tiene prisa y se prioriza coste y cobertura: resúmenes nocturnos, clasificaciones masivas, enriquecimiento de expedientes. Un tercer patrón combina ambos: la generación rápida en el flujo del usuario y la revisión diferida por muestreo, que aporta control sin frenar la operación. En los tres, el registro de llamadas —qué se envió, qué se devolvió, con qué modelo y versión— es lo que permite después auditar un incidente, medir el coste por proceso y reproducir un caso de evaluación.

En la operación, la caja de instrumentos es de negocio tanto como de técnica: uso y coste por proceso, latencia y tasa de error, tasa de aceptación de sugerencias humanas (cuánto se edita antes de aprobar), tasa de escalado o de revisión, y calidad percibida por los usuarios. Y el ciclo se cierra con reentrenamiento del contexto —actualizar la base documental— y reevaluación periódica, porque tanto las fuentes como los modelos cambian.

Esos indicadores se leen juntos, porque cada uno responde a una pregunta distinta que por separado no basta: aceptación (¿se usa lo que el modelo produce o se descarta?), coste por interacción (¿el proceso se sostiene cuando se multiplique?), latencia (¿la experiencia aguanta el tiempo de respuesta?) y cobertura (¿qué consultas reales quedan sin resolver?). Cuando uno se mueve en la dirección equivocada, el cambio se atribuye antes de decidir: una caída de aceptación con coste estable apunta a la calidad de la instrucción, no al modelo; un coste que se dispara con aceptación estable apunta al diseño del flujo, no a la tarifa.

Fase	Objetivo	Criterio de salida
Prototipo con prompt	Validar que la tarea admite generación útil	Calidad aceptable en pruebas propias y métrica de negocio definida
Grounding	Respuestas sobre fuentes privadas y actualizables	Citas o respuestas verificables y cobertura suficiente de la base
Evaluación automatizada	Comparar cambios sin coste de revisión total	Suite de pruebas estable y ejecutable en cada cambio
Producción	Operar con coste, límites y supervisión	Coste por interacción, latencia y calidad dentro de umbrales acordados
Mejora continua	Actualizar fuentes, prompts y modelo	Revisión periódica con dueño asignado

Un último punto organizativo: cada fase requiere perfiles distintos y el fallo clásico es cubrirlas solo con el equipo de innovación. El prototipo lo suele llevar un equipo de producto o de datos; el grounding exige a los dueños de la documentación definir qué es fuente autorizada y quién la mantiene; la producción exige ingeniería para integración, límites y registro; y la revisión periódica exige al proceso dueño de su métrica. Cuando una iniciativa de IA generativa no avanza, la causa más frecuente no es el modelo: es que ninguna de esas responsabilidades estaba asignada a un rol concreto y con fecha.

Temas relacionados: AI, Machine Learning and Generative AI Fundamentals, Google Cloud AI Solutions and Vertex AI, Responsible AI Principles and Model Governance

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Modelo fundacional	Modelo entrenado a gran escala que sirve de base a múltiples tareas mediante adaptación	Como punto de partida en lugar de entrenar por tarea
LLM	Modelo fundacional de lenguaje que genera texto prediciendo la continuación más probable	Resúmenes, redacción, extracción, conversación y código
Multimodalidad	Capacidad de procesar de forma conjunta texto, imagen, audio y vídeo	Cuando el caso combina fuentes de distinto tipo
Prompting	Diseño de la instrucción: rol, tarea, restricciones y formato de salida	Primera vía de adaptación; base de toda mejora posterior
Few-shot	Ejemplos de respuesta incluidos en la instrucción	Para fijar formato y estilo sin entrenar
Token	Unidad de texto facturable y procesable por el modelo	Para dimensionar coste y ventana de contexto
Ventana de contexto	Cantidad de texto admitida en una instrucción	Al decidir si el documento entra entero o requiere recuperación
RAG / grounding	Entrega de fragmentos de fuentes propias como contexto de la respuesta	Cuando la respuesta debe apoyarse en documentos privados o actualizados
Fine-tuning	Recalibración de los pesos del modelo con ejemplos propios	Para comportamiento o formato muy específico y repetido
Alucinación	Respuesta fluida y convincente sin sustento en las fuentes	Riesgo central a mitigar con grounding, límites y revisión
Inyección de instrucciones	Texto no controlado que intenta dirigir el comportamiento del modelo	Al procesar contenido externo: formularios, correo, documentos de terceros
Gemini	Familia de modelos fundacionales de Google, con capacidades multimodales	Como opción de modelo en Google Cloud a través de Vertex AI
Vertex AI	Plataforma de Google Cloud para probar, personalizar y desplegar modelos con gobernanza	Cuando la IA generativa pasa de experimento a servicio con permisos y coste
Tokens de entrada y salida	Unidades por las que se factura el uso de los modelos	Para calcular y gobernar el coste por interacción
Human-in-the-loop	Revisión o aprobación humana antes de que el resultado tenga efecto	En contenidos externos y decisiones de impacto

Comparaciones

Eje	Modelo entrenado por tarea	Modelo fundacional adaptado
Preparación	Datos etiquetados y entrenamiento propios	Instrucción, contexto o ajuste fino
Alcance	Una tarea	Muchas tareas desde la misma base
Tiempo hasta el primer valor	Semanas a meses	Días o menos con prompting
Coste por capacidad nueva	Alto: se repite el ciclo	Bajo: se adapta
Control	Total sobre el modelo	Depende del nivel de adaptación
Fallo característico	Pocos datos, sobreajuste	Alucinación y respuesta no verificada

Eje	Prompting	RAG / grounding	Fine-tuning
Qué se modifica	La instrucción	El contexto entregado	Los pesos del modelo
Datos propios	No necesarios	Repositorio documental indexado	Conjunto de ejemplos de entrenamiento
Coste	Muy bajo	Medio (indexación y actualización)	Alto (entrenamiento y evaluación)
Frescura de la respuesta	Limitada por el conocimiento del modelo	Alta: depende de la fuente actualizada	Depende del reentrenamiento
Cuándo subir de nivel	Cuando la calidad no llega con instrucción	Cuando hay que responder sobre datos propios	Cuando persisten estilo y formato específicos

Riesgo	Señal típica	Mitigación principal
Alucinación	Cita o dato que no existe en la fuente	Grounding, límites de alcance y revisión humana
Inyección de instrucciones	Comportamiento inesperado con entrada externa	Tratar texto no confiable como dato, limitar herramientas
Coste descontrolado	Factura por proceso fuera de previsión	Límite de salida, instrucción recortada, monitorización por proceso
Pérdida de confianza	Usuarios que rehúsen usar la salida	Evaluación publicada, trazabilidad y edición humana

Errores Comunes

Error: Llevar el modelo a producción porque la demo funcionó bien con tres ejemplos seleccionados. → Solución: Construir un conjunto de pruebas propio con casos límite y casos de rechazo, definir el umbral de calidad con el dueño del proceso y ejecutarlo antes y después de cada cambio de modelo o de instrucción. La demo mide la mejoribilidad de la idea; la evaluación mide la idoneidad para operar.
Error: Usar un modelo de alta capacidad para tareas simples de extracción o clasificación, por comodidad de usar uno solo para todo. → Solución: Asignar el modelo a la complejidad real de la tarea y reservar los modelos más capaces para razonamiento y generación complejos; para extracción estructurada bastan modelos más ligeros o APIs preentrenadas. El ahorro es directo sobre el token de salida y sobre la latencia.
Error: Inyectar datos sensibles completos en las instrucciones porque "el modelo necesita verlo". → Solución: Minimizar y enmascarar la información personal que no contribuye a la tarea, separar entornos, aplicar los controles de identidad y red de la plataforma y revisar el tratamiento de datos aplicable. Si el caso exige datos sensibles, el diseño del flujo y la aprobación de seguridad van antes del despliegue, no después.
Error: Desplegar respuestas del modelo directamente a clientes o en documentos contractuales sin revisión ni verificación de fuentes. → Solución: Reservar la publicación externa para flujos con revisión humana, exigir grounding sobre las fuentes autorizadas y registrar el origen del contenido generado. La revisión no anula el valor: el ahorro real está en partir de un borrador ya construido y verificado en sus datos.
Error: Gobernar el coste de la IA generativa solo a nivel de proyecto, sin atribuirlo a los procesos que lo generan. → Solución: Etiquetar por proceso, medir el coste por interacción y compararlo con el coste de la tarea humana que se sustituye o complementa; revisar los límites de salida y la longitud de las instrucciones como palancas habituales. Sin atribución por proceso, la decisión de escalar se toma sin saber qué caso de uso consume el presupuesto.

Puntos para el Examen

🎯 Punto clave 1: Un modelo fundacional es un modelo amplio que sirve a múltiples tareas mediante adaptación, y un LLM es su vertiente de lenguaje. La diferencia con el ML por tarea es económica: se adapta en lugar de reentrenar, y el coste y el riesgo se desplazan de los datos de entrenamiento a la calidad de la instrucción y del contexto.

🎯 Punto clave 2: Los niveles de adaptación se eligen por evidencia, no por prestigio: prompting para empezar, grounding/RAG cuando la respuesta debe apoyarse en documentos propios o estar actualizada, y fine-tuning para comportamiento muy específico. Si un escenario habla de "respuestas basadas en nuestra documentación", la respuesta es recuperación de contexto.

🎯 Punto clave 3: El riesgo estructural de la generación es la alucinación: fluidez sin sustento. Las mitigaciones que el examen espera reconocer son exigir fuentes verificables, limitar el alcance, mantener evaluación con pruebas propias y conservar la revisión humana en los usos de impacto.

🎯 Punto clave 4: El coste de la IA generativa se factura por tokens de entrada y de salida, con tarifas que varían por modelo y ubicación. Las palancas son el tamaño del modelo, la longitud de la instrucción, el límite de salida y el volumen de llamadas; por eso el consumo se goberna por proceso, no solo por proyecto.

🎯 Punto clave 5: La adopción empresarial se define por controles: política de uso aceptable, evaluación previa con criterios acordados, revisión humana donde el resultado es externo o decisivo, protección del dato enviado y trazabilidad de versiones de modelo e instrucción. Gemini es la familia de modelos fundacionales de Google disponible en Google Cloud a través de Vertex AI; lo que determina el éxito no es la elección del modelo, sino el marco con el que se opera.

Recursos Externos

Generative AI on Vertex AI documentation — Visión general de la oferta de IA generativa: modelos, prototipado, personalización y despliegue.
Understanding generative AI models — Cómo funcionan los modelos generativos, sus entradas y sus límites.
Prompt design strategies — Técnicas de instrucción: rol, formato, ejemplos y restricciones de salida.
Model Garden — Catálogo de modelos de Google, socios y código abierto disponibles para probar y desplegar.
Responsible AI documentation — Prácticas de IA responsable aplicables a la generación y a su gobernanza.

Autoevaluación Rápida

Pregunta: Un equipo responde preguntas frecuentes de clientes con instrucciones genéricas y obtiene respuestas inventadas sobre precios. ¿Qué nivel de adaptación corresponde y por qué? Respuesta: Corresponde grounding o RAG. El fallo no está en la redacción de la instrucción sino en que el modelo responde de su memoria paramétrica, que no contiene —o ya no contiene— los precios reales. La solución es indexar la fuente autorizada de precios y entregar los pasajes relevantes con cada pregunta, de modo que la respuesta se apoye en evidencia actualizada; además conviene limitar la respuesta a ese contexto y ofrecer el enlace a la fuente para verificación.
Pregunta: ¿Por qué el coste de una solución de IA generativa no se puede estimar solo con el precio del modelo? Respuesta: Porque el consumo depende de la interacción entre modelo y diseño del flujo: tokens de entrada (instrucción, contexto recuperado, historial), tokens de salida (limitados o no), frecuencia de llamada y número de procesos que la usan. Una instrucción con un documento largo reutilizado en cada llamada puede superar el coste del propio modelo en tareas simples, y por eso las palancas de control son recortar el contexto fijo, limitar la salida, elegir modelo según complejidad y atribuir el consumo a procesos concretos.
Pregunta: La dirección quiere publicar contenido generado automáticamente en la web corporativa. ¿Qué controles exiges? Respuesta: Revisión humana obligatoria antes de publicar, evaluación previa con ejemplos propios, fuentes verificables para cualquier afirmación factual, alineación con estilo y políticas de marca, y registro de qué modelo e instrucción produjeron cada pieza. El objetivo no es frenar la adopción: es que el ahorro provenga de partir de un borrador sólido, porque el riesgo reputacional y legal de una publicación sin revisar supera con creces el tiempo ahorrado.
Pregunta: ¿Cuándo tiene sentido invertir en fine-tuning en lugar de mejorar la instrucción o el RAG? Respuesta: Cuando el requisito es de comportamiento o formato muy específico, repetido en muchas interacciones, y ni una instrucción bien escrita ni el contexto recuperado lo resuelven de forma consistente: formatos de salida idiosincráticos, estilo corporativo muy marcado o tareas especializadas del dominio. Antes de llegar ahí, conviene agotar las vías más baratas, porque el fine-tuning añade entrenamiento, evaluación, mantenimiento de versiones y riesgo de sobreajuste; la decisión se toma con evidencia de que el nivel inferior no alcanza.
Pregunta: ¿Por qué sigue siendo necesaria la revisión humana si el modelo responde con grounding sobre documentos internos? Respuesta: Porque el grounding reduce la alucinación, no elimina el juicio. El modelo puede seleccionar el pasaje equivocado, omitir una excepción relevante, o responder correctamente al texto pero mal al contexto de negocio (una cláusula válida que no conviene aplicar en este caso). La revisión humana aporta la validación del criterio y la responsabilidad sobre el efecto, y es especialmente necesaria cuando el resultado afecta a clientes, a contratos o a decisiones sobre personas; el grounding lo que hace es que esa revisión sea rápida y esté bien informada.