Semana 1 · Módulo 1 de 11

Fundamentos de IA generativa y selección de modelos en Amazon Bedrock

Aprenderás desde cero cómo funciona un LLM (tokens, contexto, parámetros de inferencia, embeddings) y a analizar requisitos, elegir y configurar modelos fundacionales en Amazon Bedrock con arquitecturas flexibles y resilientes. Es la base de todo el dominio 1 (31 % del examen).

Reparto de la semana

Por qué importa

El dominio 1 (Foundation Model Integration, Data Management, and Compliance) pesa un 31 % del examen, el que más. Los task statements 1.1 y 1.2 son su puerta de entrada: el examen te pondrá escenarios de empresa y te pedirá que elijas qué modelo, con qué modo de inferencia, en qué región o perfil y con qué arquitectura para cumplir a la vez requisitos de calidad, coste, latencia, residencia de datos y disponibilidad.

Casi ninguna pregunta será «¿qué es un token?». Pero todas dan por hecho que lo sabes: si no entiendes por qué una respuesta sale cortada (max_tokens), por qué un modelo se inventa datos (alucinación) o por qué un perfil global. incumple una norma de residencia, no podrás descartar distractores. Por eso este módulo empieza desde cero.

1. La IA generativa en cinco minutos

De la IA al LLM

Piensa en círculos concéntricos:

• Inteligencia artificial (IA): sistemas que hacen tareas que asociamos a la inteligencia humana.
• Machine learning (ML, aprendizaje automático): sistemas que aprenden patrones de los datos en lugar de seguir reglas escritas a mano.
• Deep learning (aprendizaje profundo): ML con redes neuronales de muchas capas.
• IA generativa: modelos que crean contenido nuevo (texto, código, imágenes, audio, vídeo) en lugar de solo clasificar o predecir un número.
• Foundation model (FM, modelo fundacional): un modelo enorme preentrenado con cantidades gigantescas de datos generales que sirve de base para muchísimas tareas distintas sin entrenarlo desde cero. «Fundacional» porque construyes encima.
• Large language model (LLM, modelo grande de lenguaje): un FM especializado en lenguaje (y, cada vez más, en varias modalidades).

La diferencia práctica con el ML «clásico» (por ejemplo, un modelo de detección de fraude entrenado en SageMaker) es enorme:

Qué sabe hacer un FM (y qué no)

Sabe resumir, clasificar, extraer datos estructurados de texto libre, traducir, responder preguntas, redactar, generar y explicar código, razonar paso a paso, describir imágenes, conversar y decidir qué herramienta usar (la base de los agentes).

No sabe por sí solo:

• Lo que no vio al entrenarse: tus documentos internos o cualquier hecho posterior a su knowledge cutoff (fecha de corte de conocimiento). Por ejemplo, la ficha de Claude Haiku 4.5 en Bedrock indica corte en febrero de 2025. La solución es darle ese contexto en el prompt (RAG, módulo 3).
• Garantizar la verdad: genera lo probable, no lo verdadero.
• Ser determinista: la misma pregunta puede dar respuestas distintas.
• Actuar en el mundo: solo genera texto. Para consultar una API o una base de datos necesita herramientas (tool use) que ejecuta tu código (módulos 4 y 5).

2. Cómo funciona un LLM por dentro

Tokens y tokenización

Un LLM no ve letras ni palabras: ve tokens. Un token es un fragmento de texto: una palabra corta, un trozo de palabra, un signo de puntuación o un espacio. El tokenizador (tokenizer) de cada modelo trocea el texto en tokens y los convierte en números (identificadores dentro de un vocabulario de decenas de miles de piezas).

Ejemplo ilustrativo (cada modelo trocea a su manera):

"Desplegamos el chatbot en Fráncfort"
→ ["Des", "pleg", "amos", " el", " chat", "bot", " en", " Fr", "án", "cf", "ort"]

Por qué te importa como arquitecto:

1. Se paga por token. Bedrock factura por tokens de entrada (input tokens: todo lo que envías) y tokens de salida (output tokens: lo que genera). Los de salida cuestan varias veces más: en Nova Micro, cuatro veces más.
2. Los límites se miden en tokens: la ventana de contexto, el máximo de salida y las cuotas (tokens per minute, TPM).
3. La latencia depende sobre todo de los tokens de salida: el modelo los genera uno detrás de otro.
4. El idioma cambia la cuenta. Para Titan Text Embeddings V2, AWS da una media de 4,7 caracteres por token en inglés. Los tokenizadores suelen estar optimizados para inglés, así que el mismo texto en español acostumbra a necesitar algún token más. No lo supongas: mídelo con el campo usage de la respuesta o con la API CountTokens (sin coste, en los modelos que la soportan).

Predecir el siguiente token

Un LLM hace, en esencia, una sola cosa: dada una secuencia de tokens, calcula la probabilidad de cada posible token siguiente, elige uno, lo añade al final y repite. Es la generación autorregresiva.

flowchart LR
  A["Prompt tokenizado"] --> B["Modelo (transformer)"]
  B --> C["Probabilidades del siguiente token"]
  C --> D["Muestreo según temperature, top-p y top-k"]
  D --> E["Token elegido"]
  E -->|"se añade a la secuencia"| B
  E --> F{"¿Stop sequence, fin de turno o maxTokens?"}
  F -->|"sí"| G["Respuesta final"]

La arquitectura que lo hace posible es el transformer, cuyo mecanismo de atención (attention) permite que cada token «mire» a los anteriores para decidir el siguiente. No necesitas más detalle para el examen, pero sí dos consecuencias:

• Procesar la entrada tiene un coste que crece con su longitud: prompts más largos son más caros y algo más lentos.
• El modelo no consulta nada mientras genera: todo lo que «sabe» está en sus parámetros (lo aprendido) o en el contexto que le das.

La ventana de contexto

La context window (ventana de contexto) es el número máximo de tokens que el modelo puede considerar en una llamada. Incluye todo: instrucciones de sistema, historial de la conversación, documentos adjuntos, definiciones de herramientas y la propia respuesta.

Ejemplos de las fichas de modelo de Bedrock (consultadas el 01/10/2026):

Tres ideas que el examen explota:

1. Más contexto no es gratis. Meter un manual entero de 500 páginas en cada prompt «porque cabe» multiplica el coste y la latencia. RAG recupera solo los fragmentos relevantes.
2. Desbordamiento. Si la entrada más la salida pedida no caben, la llamada falla con un error de validación o termina con stopReason igual a model_context_window_exceeded. En chats largos hay que recortar, resumir o seleccionar el historial.
3. Calidad dentro de ventanas largas. Que un dato esté en el contexto no garantiza que el modelo lo aproveche: en contextos muy largos, lo que queda enterrado en medio puede recibir menos atención. Coloca lo importante al principio o al final y no rellenes con texto irrelevante.

Parámetros de inferencia: controlar cómo genera

Los inference parameters cambian el conjunto de tokens candidatos o limitan la respuesta. Los valores por defecto y los rangos dependen de cada modelo. La documentación de Bedrock lo explica con este ejemplo: para el prompt «I hear the hoof beats of “», el modelo propone tres candidatos.

{ "horses": 0.7, "zebras": 0.2, "unicorns": 0.1 }

Algunos modelos admiten además penalizaciones (penalties) por longitud o por repetir tokens.

Guía rápida por tipo de tarea:

En la Converse API de Bedrock, los parámetros comunes a todos los modelos van en inferenceConfig: maxTokens, temperature, topP y stopSequences. Los específicos de un modelo, como top_k en Claude, van en additionalModelRequestFields:

respuesta = cliente.converse(
    modelId="eu.anthropic.claude-haiku-4-5-20251001-v1:0",
    system=[{"text": "Eres un clasificador de tickets. Responde solo con la etiqueta."}],
    messages=[{"role": "user", "content": [{"text": "No puedo acceder a mi cuenta"}]}],
    inferenceConfig={"maxTokens": 10, "temperature": 0, "stopSequences": ["\n"]},
    additionalModelRequestFields={"top_k": 50},
)

La respuesta trae, además del mensaje, un stopReason que debes comprobar en producción:

Embeddings: el significado convertido en números

Un embedding es un vector (una lista de números, por ejemplo 1.024) que representa el significado de un texto, una imagen o un audio. Un modelo de embeddings (como Amazon Titan Text Embeddings V2) no genera texto: recibe contenido y devuelve ese vector.

La propiedad clave: contenidos con significado parecido producen vectores cercanos. «¿Cómo cambio mi contraseña?» y «He olvidado mi clave de acceso» casi no comparten palabras, pero sus embeddings están muy próximos. Eso permite la búsqueda semántica (por significado, no por palabras exactas), que es la base de RAG, de la caché semántica y de la detección de duplicados. El módulo 2 profundiza en dimensiones, métricas de distancia, índices y almacenes vectoriales.

Multimodalidad

Un modelo es multimodal cuando acepta o produce varias modalidades: texto, imagen, vídeo, audio o documentos. Lee siempre la ficha con cuidado, porque entrada y salida son cosas distintas:

En la Converse API, una imagen o un documento viajan como bloques de contenido junto al texto (image, document, video). El módulo 2 detalla formatos y límites.

Razonamiento (reasoning)

Algunos modelos pueden «pensar» antes de responder (extended thinking): generan un razonamiento intermedio que mejora la precisión en matemáticas, planificación o código. Nova 2 Lite admite razonamiento extendido con tres niveles de intensidad; Claude Sonnet 5 lo trae activado por defecto (se puede desactivar). A cambio, más tokens de salida (más coste) y más latencia. Para clasificar tickets no lo necesitas.

Alucinaciones y otras limitaciones

Una alucinación (hallucination) es una respuesta fluida y convincente pero falsa o inventada: una sentencia judicial que no existe, un parámetro de API imaginario. Ocurre porque el modelo optimiza lo probable, no lo verdadero.

Cómo adaptar un modelo a tu caso: la escalera

De menos a más esfuerzo y coste. Sube un peldaño solo si el anterior no basta:

3. Amazon Bedrock: el centro de todo

Qué es

Amazon Bedrock es un servicio totalmente gestionado y serverless que da acceso, mediante una API común, a modelos fundacionales de Amazon y de terceros (Anthropic, Meta, Mistral AI, OpenAI, Qwen, DeepSeek, Cohere, Google, Writer, TwelveLabs, Stability AI y otros). No gestionas servidores ni GPU: envías peticiones y pagas por uso. Alrededor de la inferencia ofrece piezas que verás en todo el curso: Knowledge Bases (RAG), Guardrails, Prompt Management, Flows, evaluación, personalización de modelos, inferencia por lotes y AgentCore para agentes.

Dos propiedades que salen mucho en los enunciados de seguridad:

• Tus datos no entrenan los modelos. La referencia de la API Converse lo dice expresamente: Bedrock no almacena el texto, las imágenes ni los documentos que envías; solo se usan para generar la respuesta. Si necesitas guardarlos (auditoría), activas tú el model invocation logging (módulo 8).
• Funciona como cualquier servicio de AWS: IAM, CloudTrail, CloudWatch, cifrado, VPC endpoints (PrivateLink). Lo que ya sabes del SAA-C03 se aplica tal cual.

Endpoints y familias de API

InvokeModel frente a Converse es una decisión que el examen pregunta:

Acceso a modelos (estado en octubre de 2026)

La página Model access ya no exige «solicitar acceso» modelo a modelo. Hoy:

• El acceso a los modelos está habilitado por defecto en las regiones comerciales si el rol tiene los permisos de AWS Marketplace aws-marketplace:Subscribe, aws-marketplace:Unsubscribe y aws-marketplace:ViewSubscriptions (solo hacen falta la primera vez que se usa un modelo de terceros en la cuenta) y la cuenta tiene un método de pago válido.
• La primera invocación de un modelo de terceros lanza la suscripción en segundo plano (puede tardar hasta 15 minutos). Si falta algún requisito, recibes AccessDeniedException.
• Anthropic exige, una vez por cuenta (o en la cuenta de administración de la organización), un formulario de caso de uso (First Time Use): en la consola o con la API PutUseCaseForModelAccess.
• Los modelos de Amazon, DeepSeek, Mistral AI, Meta y Qwen no tienen ID de producto de Marketplace.
• Para bloquear modelos (por ejemplo, hasta que el departamento legal revise su EULA), no basta con denegar aws-marketplace:Subscribe: hay que denegar bedrock:InvokeModel con una SCP en AWS Organizations o con IAM.

Modos de inferencia y cómo se paga

flowchart TD
  A["¿Cómo invoco el modelo?"] --> B{"¿Necesito la respuesta ya?"}
  B -->|"No: miles de registros, horas de margen"| C["Batch inference (JSONL en S3, ~50 % más barato)"]
  B -->|"Sí"| D{"¿Tráfico alto, estable y crítico?"}
  D -->|"No"| E["On-demand: nivel Standard, Priority o Flex"]
  D -->|"Sí"| F["Capacidad reservada: nivel Reserved o Provisioned Throughput"]
  E --> G{"¿Picos o modelo sin despliegue en mi región?"}
  G -->|"Sí"| H["Perfil de cross-Region inference: geográfico (eu.) o global (global.)"]

On-demand (bajo demanda): pagas por token, sin compromiso. Dentro de on-demand eliges el service tier (nivel de servicio) por petición:

En la Converse API se indica con serviceTier (por ejemplo, {"type": "flex"}). No todos los modelos admiten todos los niveles: compruébalo en la ficha (Nova 2 Lite admite Standard, Priority y Flex; Nova Micro, solo Standard, a 1 de octubre de 2026).

Batch inference (inferencia por lotes): subes un fichero JSONL a S3 (una línea por petición, con recordId y modelInput), lanzas CreateModelInvocationJob y recoges los resultados en S3. Cuesta en torno a un 50 % menos que on-demand. Ideal para clasificar un histórico o generar resúmenes nocturnos. Se detalla en el módulo 9.

Provisioned Throughput: compras Model Units (MU) por horas, sin compromiso o con compromiso de 1 o 6 meses (más descuento cuanto más largo). Da capacidad garantizada. Históricamente era obligatorio para usar modelos personalizados; hoy algunos modelos personalizados admiten despliegue on-demand (CreateCustomModelDeployment) y Custom Model Import también es on-demand. Los perfiles de inferencia entre regiones no admiten Provisioned Throughput.

Cross-Region inference: perfiles geográficos y globales

Un inference profile (perfil de inferencia) es un recurso que define a qué regiones puede enviar Bedrock tu petición. Lo usas como modelId. Hay dos tipos de perfiles «de sistema»:

Detalles verificados que caen en el examen:

• Sin coste de enrutado. Se paga el precio de la región de origen.
• Los datos se almacenan solo en la región de origen, pero los prompts y resultados pueden procesarse fuera de ella (dentro de la geografía, si el perfil es geográfico).
• CloudTrail registra la llamada en la región de origen; el campo additionalEventData.inferenceRegion indica dónde se procesó.
• Muchos modelos recientes solo se ofrecen mediante perfiles: por ejemplo, en bedrock-runtime Claude Haiku 4.5 exige un perfil geográfico o global (no admite el ID «pelado» para on-demand). En eu-central-1, Nova Micro, Nova Lite y Nova 2 Lite se usan con el perfil eu..

Además existen los application inference profiles: perfiles que creas tú (CreateInferenceProfile) a partir de un modelo o de un perfil de sistema para etiquetar y medir el uso y el coste por aplicación, equipo o cliente (etiquetas de asignación de costes y métricas de CloudWatch).

Cuotas (quotas) y throttling

Bedrock limita el uso on-demand por modelo y por región con cuotas de peticiones por minuto (RPM) y tokens por minuto (TPM), más un límite de tokens por día a nivel de cuenta. Los perfiles entre regiones tienen cuotas propias (con nombres como «Cross-region model inference tokens per minute for …»). Los modelos de embeddings se limitan por RPM, no por TPM. Al superarlas recibes ThrottlingException (HTTP 429).

Un detalle fino que diferencia a quien ha leído la documentación: la tasa de consumo (burndown rate) de tokens de salida. En algunos modelos, cada token de salida consume varios tokens de cuota: por ejemplo, 5 en los modelos de Anthropic hasta la versión 4.7, 10 en Claude Sonnet 5 y Opus 5 y 15 en los Claude de la versión 4.8 (1:1 en el resto, según la página de cuotas a 1 de octubre de 2026). Además, al empezar la petición se reservan tokens de entrada + max_tokens, y al terminar se ajusta al consumo real. Consecuencia práctica: un maxTokens exagerado reduce tu capacidad efectiva aunque la respuesta sea corta. Se factura solo lo realmente consumido.

Las ampliaciones se piden en Service Quotas (a nivel de cuenta y en la región de origen). El examen espera que combines: reintentos con backoff exponencial y jitter (el SDK en modo standard o adaptive), cross-Region inference, aumento de cuota y, si la carga es estable, capacidad reservada.

Ciclo de vida de los modelos

Cada modelo pasa por tres estados, visibles en el campo modelLifecycle de ListFoundationModels:

Ejemplos reales: Amazon Nova Premier (Legacy desde el 13/03/2026, EOL el 14/09/2026) y Nova Canvas y Nova Reel (Legacy desde el 30/03/2026, EOL el 30/09/2026). A 1 de octubre de 2026 siguen apareciendo en la tabla de modelos Legacy de la documentación, pero con la fecha de EOL ya cumplida: en un diseño nuevo no los elijas, y si un enunciado los propone, recuerda que un modelo Legacy no admite clientes nuevos. Lo mismo pasa con Claude 3 Haiku (EOL el 10/09/2026) y Claude Sonnet 4 (Legacy, EOL el 14/10/2026). Para los modelos lanzados desde el 7 de septiembre de 2026, cada ficha indica una fecha de «EOL no antes de» y un periodo Legacy de 6 meses (o 45 días en algunos casos). Lección de arquitecto: nunca cablees un modelId en el código, vigila las fechas y ten un proceso de evaluación para validar el sustituto.

4. Familias de modelos en Bedrock

El catálogo cambia cada mes; el examen pregunta patrones, no catálogos. Aun así, necesitas saber qué ofrece cada familia. Datos de las fichas oficiales y de la API de precios de AWS, consultados el 01/10/2026; precios on-demand Standard en eu-central-1, en USD por millón de tokens (entrada / salida). Son estimaciones: confírmalos en la página de precios.

Cómo leer la tabla para el examen:

• Amazon Nova es la familia propia de Amazon para comprender y generar: Micro (solo texto, la más barata y rápida), Lite y Pro (multimodales), Premier (la más capaz de la generación 1; Legacy con EOL el 14/09/2026) y la generación Nova 2 (Nova 2 Lite con razonamiento y contexto de 1M, Nova 2 Sonic para voz en tiempo real, Nova Multimodal Embeddings, esta última no disponible en la UE). Nova Canvas y Nova Reel generaban imagen y vídeo; ambos están en Legacy con EOL el 30/09/2026.
• Amazon Titan es la familia anterior de Amazon. Hoy su papel en el examen está en los embeddings (Titan Text Embeddings V2 y Titan Multimodal Embeddings G1) y en la generación de imágenes (Titan Image Generator G1 v2). Titan Text Embeddings V2 es el modelo de embeddings por defecto en muchas soluciones de Knowledge Bases.
• Modelos de terceros con licencia comercial (Anthropic, Cohere, Writer…) se facturan a través de AWS Marketplace y aparecen en la factura bajo el proveedor. Los modelos de pesos abiertos (gpt-oss, Llama, Gemma, Qwen, Mistral en parte) tienen licencias propias que debes revisar.
• La disponibilidad regional es un criterio de selección tan importante como la calidad: Llama 4 solo está en perfiles de EE. UU., así que no sirve si la norma exige la UE.

5. Más allá de Bedrock serverless: SageMaker JumpStart y compañía

Amazon SageMaker AI (el antiguo SageMaker) es la plataforma de ML de AWS. Para IA generativa te interesan:

• SageMaker JumpStart: un catálogo de modelos preentrenados de código abierto (y soluciones de ejemplo) que puedes desplegar en un endpoint de SageMaker, ajustar (fine-tune) y evaluar desde Studio o con el SDK de Python. Admite hubs privados para curar qué modelos pueden usar tus equipos.
• Endpoints de SageMaker AI: real-time (instancias siempre encendidas; con inference components pueden escalar a cero), serverless (escala a cero, hasta 6 GB de memoria, sin GPU), asynchronous (cargas de hasta 1 GB y hasta 1 hora, escala a cero) y batch transform.

Y dentro de Bedrock hay dos vías para modelos que no están en el catálogo serverless:

• Amazon Bedrock Marketplace: más de 100 modelos especializados que se despliegan en un endpoint gestionado por SageMaker AI y se invocan con las APIs de Bedrock (el ARN del endpoint hace de modelId), compatibles con Knowledge Bases y Guardrails.
• Custom Model Import: importas pesos propios (formato Hugging Face safetensors en S3) de arquitecturas abiertas (Llama, Mistral, Mixtral, Qwen, GPT-OSS…) y los sirves serverless en Bedrock. Se factura por unidades de modelo en ventanas de 5 minutos y escala a cero (la primera llamada tras la inactividad puede devolver ModelNotReadyException mientras se restaura: reintenta). En la UE solo está en eu-central-1.

6. Cómo elegir un modelo fundacional (Skill 1.2.1)

El examen quiere que elijas con datos: performance benchmarks (pruebas de rendimiento), capability analysis (análisis de capacidades) y limitation evaluation (evaluación de limitaciones).

Los criterios

Un cálculo de coste como los del examen

Un centro de soporte clasifica 2 millones de tickets al mes. Cada petición lleva unos 400 tokens de entrada (instrucciones + ticket) y genera 5 tokens de salida (la etiqueta).

• Tokens al mes: 800 millones de entrada y 10 millones de salida.
• Con Nova Micro (0,046 / 0,184): 800 × 0,046 + 10 × 0,184 ≈ 38,6 USD/mes.
• Con Claude Sonnet 5 perfil eu. (2,20 / 11,00): 800 × 2,20 + 10 × 11,00 = 1.870 USD/mes.

Si ambos alcanzan la calidad exigida, la diferencia es de casi 50 veces. Por eso la estrategia habitual es empezar por el modelo más pequeño que cumpla el umbral de calidad y reservar los grandes para lo que lo necesite (model cascading y enrutado, módulos 6 y 9). Y si los tickets pueden esperar a la noche, batch o Flex reducen el coste a la mitad.

Cómo evaluar las limitaciones

• Prueba casos límite: textos muy largos, idiomas mezclados, preguntas trampa, entradas maliciosas.
• Mide la tasa de formato válido (¿el JSON parsea siempre?) y de stopReason = max_tokens.
• Compara en igualdad: mismo prompt, mismos parámetros, mismos datos (lo haces en el lab-02-comparar-modelos).
• No te fíes solo de benchmarks públicos: son una primera criba; la decisión se toma con tus datos.

7. Arquitecturas flexibles y resilientes (Skills 1.2.2 y 1.2.3)

Cambiar de modelo sin tocar código

El patrón de referencia:

flowchart LR
  U["Clientes"] --> AG["Amazon API Gateway"]
  AG --> L["AWS Lambda: capa de abstracción"]
  L -->|"lee modelo, parámetros y reglas"| AC["AWS AppConfig (extensión de Lambda con caché)"]
  L -->|"Converse"| BR["Amazon Bedrock: modelo A"]
  L -.->|"fallback"| BR2["Amazon Bedrock: modelo B más pequeño"]

• API Gateway expone una API estable a los clientes (autenticación, throttling, validación de peticiones).
• Lambda es la capa de abstracción: traduce la petición de negocio a una llamada Converse (mismo formato para todos los modelos).
• AWS AppConfig guarda el modelId, los parámetros y, si quieres, reglas de enrutado, como configuración freeform (JSON) o feature flags. Aporta validadores (JSON Schema o Lambda), estrategias de despliegue graduales (por ejemplo AppConfig.Linear20PercentEvery6Minutes o AppConfig.Canary10Percent20Minutes) y rollback automático si salta una alarma de CloudWatch durante el tiempo de «horneado» (bake time). En Lambda se lee con la extensión de AWS AppConfig, que cachea la configuración en local (endpoint en localhost:2772).

Resultado: cambiar de Claude a Nova, o de un proveedor a otro, es desplegar configuración, no código. Es lo que pide la Skill 1.2.2 («dynamic model selection and provider switching without requiring code modifications»).

Resiliencia: que el servicio sobreviva a los fallos

La Skill 1.2.3 cita cuatro técnicas; conviene combinarlas:

1. Cross-Region inference para modelos con disponibilidad regional limitada y para absorber picos (sección 3).
2. Despliegue del modelo en varias regiones: si usas modelos propios (SageMaker o Custom Model Import), despliégalos en dos regiones y enruta con Route 53 o desde la capa de abstracción.
3. Circuit breaker con AWS Step Functions: el patrón publicado por AWS usa una tabla de DynamoDB con el estado del circuito. Antes de llamar al servicio, el flujo comprueba si hay un registro vigente de circuito abierto; si lo hay, no llama y va directo a la alternativa. Si las llamadas fallan tras agotar los reintentos con backoff, escribe el registro de circuito abierto con una marca de caducidad (TTL de DynamoDB) para que, pasado ese tiempo, se vuelva a intentar. En los estados Task, Step Functions ofrece Retry (ErrorEquals, IntervalSeconds, MaxAttempts, BackoffRate, MaxDelaySeconds, JitterStrategy) y Catch para desviar a la rama alternativa. Step Functions tiene integración optimizada con Bedrock (arn:aws:states:::bedrock:invokeModel).
4. Degradación elegante (graceful degradation): cuando el modelo principal no responde, ofrecer algo útil en lugar de un error: un modelo más pequeño, una respuesta en caché, una plantilla predefinida o la derivación a un agente humano. La Generative AI Lens lo recoge en la buena práctica GENREL03-BP01 (plantillas de prompt de reserva, circuit breakers, reintentos con backoff).

stateDiagram-v2
  [*] --> CompruebaCircuito
  CompruebaCircuito --> Alternativa: circuito abierto
  CompruebaCircuito --> InvocaModelo: circuito cerrado
  InvocaModelo --> Exito: respuesta correcta
  InvocaModelo --> AbreCircuito: fallos tras reintentos
  AbreCircuito --> Alternativa
  Alternativa --> [*]
  Exito --> [*]

8. Personalización y ciclo de vida de modelos (Skill 1.2.4)

A veces el prompt y RAG no bastan y la empresa decide personalizar un modelo. La Skill 1.2.4 no te pide entrenar, sino desplegar y gestionar el ciclo de vida del modelo personalizado.

Técnicas de adaptación eficiente: LoRA y adaptadores

Reentrenar todos los parámetros de un modelo de miles de millones de parámetros es carísimo. Las técnicas PEFT (parameter-efficient fine-tuning) congelan el modelo base y entrenan muy pocos parámetros extra:

• LoRA (low-rank adaptation): añade pares de matrices pequeñas («de rango bajo») a ciertas capas. Solo se entrenan esas matrices. El resultado es un adaptador de pocos MB frente a los GB del modelo.
• Adaptadores (adapters): módulos pequeños que se insertan en el modelo y se entrenan para una tarea.

Ventajas: menos GPU y tiempo de entrenamiento, y muchos adaptadores sobre un mismo modelo base (uno por cliente o por tarea). En SageMaker AI esto se implementa con adapter inference components: un inference component con el modelo base y otros componentes ligeros que apuntan a cada adaptador LoRA (en S3) y comparten los recursos de cómputo del base; al invocar, indicas qué componente (adaptador) usar. Los contenedores LMI (Large Model Inference) con motores como vLLM sirven estos modelos. En JumpStart, el ajuste fino con LoRA se configura con hiperparámetros como peft_type (por defecto lora) y lora_r.

Dónde desplegar el modelo personalizado

Versionado, aprobación y despliegue automatizado

SageMaker Model Registry es el catálogo versionado de modelos:

• Los modelos se agrupan en model package groups; cada entrenamiento registra una versión (1, 2, 3…).
• Cada versión tiene un estado de aprobación (ModelApprovalStatus): PendingManualApproval, Approved o Rejected.
• El cambio de estado emite un evento a Amazon EventBridge («SageMaker Model Package State Change»): una regla que detecte Approved puede lanzar el pipeline de despliegue (CodePipeline o SageMaker Projects). Rechazar la versión aprobada vuelve a desplegar la última aprobada.
• Admite modelos fundacionales y LLM ajustados, y se enlaza con las model cards (documentación del modelo, módulo 8).

flowchart LR
  T["Fine-tuning (LoRA)"] --> R["Model Registry: versión N (PendingManualApproval)"]
  R -->|"evaluación + revisión humana"| A["Approved"]
  A -->|"evento de EventBridge"| P["Pipeline de despliegue"]
  P --> BG["Endpoint: blue/green con canary y alarmas"]
  BG -->|"alarma de CloudWatch"| RB["Rollback automático a la versión anterior"]

Estrategias de despliegue y rollback en endpoints de SageMaker AI (deployment guardrails):

• Blue/green, con desplazamiento del tráfico all at once, canary (una porción pequeña y después el resto) o linear (por escalones iguales).
• Periodo de horneado (baking period) en el que se vigila la flota nueva y rollback automático si salta una alarma de CloudWatch.
• Shadow tests: copiar tráfico real a una variante «sombra» sin afectar al usuario, para comparar.
• Variantes de producción con pesos para pruebas A/B.

Retirar y sustituir modelos (lifecycle management): los modelos base de Bedrock pasan a Legacy y EOL (sección 3); los tuyos, a versiones archivadas en el registro. En ambos casos: inventario de qué aplicación usa qué modelo, evaluación del sustituto con el conjunto de referencia, despliegue gradual y plan de marcha atrás.

9. Analizar requisitos y diseñar la solución (Task 1.1)

Del problema de negocio a la arquitectura (Skill 1.1.1)

Antes de elegir servicios, clasifica los requisitos:

Y elige el patrón de integración:

Y la estrategia de despliegue: on-demand, niveles de servicio, reservado, perfiles entre regiones o endpoints propios (secciones 3 y 5).

La prueba de concepto (Skill 1.1.2)

Una PoC (proof of concept) con Amazon Bedrock sirve para validar, antes de invertir en producción, tres cosas: viabilidad (¿la calidad llega?), características de rendimiento (latencia, throughput, cuotas) y valor de negocio (¿ahorra tiempo o dinero?). Cómo hacerla bien:

1. Criterios de éxito medibles antes de empezar: «≥ 90 % de respuestas correctas sobre 200 preguntas reales», «p95 < 3 s», «< 0,01 USD por consulta».
2. Datos reales y representativos (anonimizados si hace falta), no ejemplos inventados.
3. Varios modelos comparados con el mismo conjunto (Playground de Bedrock para explorar; código con Converse para medir).
4. Instrumentación: tokens (usage), latencia (metrics.latencyMs), stopReason, coste estimado.
5. Evaluación sistemática: Amazon Bedrock Evaluations (automática, LLM como juez o humana).
6. Proyección a escala: coste mensual con el volumen real, cuotas necesarias y si habrá que pedir aumentos.
7. Decisión documentada: seguir, ajustar (otro modelo, RAG, prompt) o parar.

Componentes estandarizados y Well-Architected (Skill 1.1.3)

Cuando varios equipos construyen aplicaciones de IA generativa, hay que evitar que cada uno reinvente la rueda (y los riesgos). La guía cita el AWS Well-Architected Framework y la Generative AI Lens de la AWS Well-Architected Tool.

AWS Well-Architected Tool (WA Tool) es un servicio gratuito de la consola para revisar cargas de trabajo contra buenas prácticas:

• Defines una carga de trabajo (workload) y respondes las preguntas de cada lente (lens). La lente del Framework se aplica por defecto; puedes añadir otras (hasta 20 por carga de trabajo).
• Obtienes riesgos altos y medios (HRI y MRI) y un plan de mejora (improvement plan).
• Guardas hitos (milestones): instantáneas del estado en un momento dado.
• Puedes crear lentes personalizadas (custom lenses) con las preguntas de tu organización y compartirlas con otras cuentas: así estandarizas revisiones entre equipos.
• El catálogo de lentes incluye la lente Generative AI.

La Generative AI Lens (publicada el 19/11/2025) cubre cargas de trabajo con Amazon Bedrock, SageMaker AI y Amazon Q (el ML tradicional va en la Machine Learning Lens). Organiza el trabajo según el ciclo de vida de una solución de IA generativa: definición del alcance (scoping), selección del modelo, personalización, desarrollo e integración, despliegue y mejora continua. Sus principios de diseño:

Y sus temas por pilar:

Para estandarizar componentes técnicos entre escenarios de despliegue, combina la lente con piezas reutilizables: una capa de abstracción común (Lambda + AppConfig), plantillas de prompt gobernadas (Bedrock Prompt Management, módulo 4), guardrails corporativos compartidos, módulos de infraestructura como código (CDK o CloudFormation) y un catálogo de productos aprobados (AWS Service Catalog, módulo 6).

10. Prepara tu cuenta y controla el coste

Resumen de lo que harás en el lab-01-cuenta-y-bedrock:

• Región: eu-central-1 (Fráncfort) o eu-west-1 (Irlanda). Tienen más modelos y funciones que eu-south-2 (España); por ejemplo, los rerankers en la UE solo están In-Region en Fráncfort, y Custom Model Import solo en Fráncfort.
• Presupuesto con alertas en AWS Budgets antes del primer token.
• Acceso a modelos: los de Amazon funcionan de inmediato; para los de terceros hacen falta permisos de Marketplace y método de pago, y para Anthropic, el formulario de caso de uso.
• Credenciales: roles de IAM (CloudShell usa las de tu sesión). Las API keys de Bedrock de largo plazo son, según AWS, solo para exploración; en producción, credenciales temporales.
• Modelos baratos: Nova Micro para texto y Titan Text Embeddings V2 para embeddings.

Trampas típicas del examen

• «Sin reentrenar», «documentos que cambian», «citar la fuente» → RAG, no fine-tuning.
• «Cambiar de modelo o de proveedor sin modificar código» → Converse API + configuración externa (AppConfig) detrás de una capa de abstracción (API Gateway + Lambda). Una variable de entorno de Lambda obliga a redesplegar la función: peor opción.
• «Los datos no pueden salir de la UE» → perfil eu. o In-Region. global. es más barato, pero no cumple.
• «ThrottlingException en picos» → backoff con jitter, cross-Region inference y aumento de cuota antes que Provisioned Throughput (que exige compromiso y es para tráfico estable).
• «Respuestas inconsistentes en una tarea de extracción» → bajar temperature. «Respuestas cortadas» → stopReason = max_tokens: subir maxTokens.
• top_k en la Converse API → va en additionalModelRequestFields, no en inferenceConfig.
• Bloquear un modelo → denegar bedrock:InvokeModel con SCP o IAM. Denegar solo la suscripción de Marketplace no basta.
• «Validar viabilidad y valor antes de invertir» → PoC en Bedrock con criterios de éxito medibles.
• «Estandarizar revisiones entre equipos» → Well-Architected Tool con la Generative AI Lens (y lentes personalizadas compartidas).
• Modelo personalizado con rollback → Model Registry (versiones y aprobación) + despliegue blue/green con canary y alarmas de CloudWatch.
• LoRA → técnica eficiente de ajuste; muchos adaptadores ligeros sobre un modelo base (adapter inference components en SageMaker).
• Endpoint de SageMaker para tráfico esporádico → coste por hora encendido; Bedrock on-demand suele ser MOST cost-effective.
• Modelos en Legacy → no admiten nuevos Provisioned Throughput ni fine-tuning; hay que planificar la migración antes del EOL.

Resumen

• Un LLM genera texto token a token según probabilidades; todo se mide y se paga en tokens.
• La ventana de contexto incluye instrucciones, historial, documentos y la respuesta; desbordarla corta o falla la llamada.
• temperature, topP, topK, maxTokens y stop sequences controlan la generación; en Converse, top_k va en additionalModelRequestFields. Revisa siempre stopReason.
• Bedrock es serverless, no guarda tus prompts y ofrece Converse para cambiar de modelo sin cambiar código.
• Modos de inferencia: on-demand (Standard, Priority, Flex), Reserved, batch (~50 % más barato) y Provisioned Throughput; perfiles geográficos (residencia) y globales (~10 % más baratos, sin residencia).
• Las cuotas (RPM y TPM por modelo) se piden en Service Quotas; maxTokens exagerado consume cuota.
• Elige modelo con datos: calidad en tu tarea, coste, latencia, contexto, modalidades, idioma, región, licencia y ciclo de vida.
• Flexibilidad = API Gateway + Lambda + Converse + AppConfig. Resiliencia = cross-Region inference + circuit breaker con Step Functions + degradación elegante.
• Personalización: LoRA y adaptadores; ciclo de vida con Model Registry, pipelines automáticos y rollback.
• Diseña con la Generative AI Lens y la Well-Architected Tool, y valida con una PoC en Bedrock.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• ¿Qué es Amazon Bedrock?
• Converse API
• Parámetros de inferencia
• Modelos de Bedrock de un vistazo (fichas de modelo)
• Cross-Region inference
• Service tiers de Bedrock
• Cuotas de Amazon Bedrock
• Generative AI Lens (AWS Well-Architected)
• Amazon SageMaker JumpStart
• SageMaker Model Registry