Ciclo de vida de ML de extremo a extremo en AWS

Los proyectos de machine learning rara vez fracasan porque un modelo no se pueda entrenar. Fracasan porque nadie decidió qué etapa del ciclo de vida es dueña de qué servicio, porque un prototipo en un notebook se convirtió en un endpoint permanente, o porque nadie notó que los datos de entrada cambiaron seis meses después del lanzamiento. El examen AIF-C01 se construye justo alrededor de ese vacío: la Tarea 1.3 te pide situar la recogida de datos, el análisis exploratorio (EDA), el preprocesamiento, la ingeniería de atributos, el entrenamiento, el ajuste de hiperparámetros, la evaluación, el despliegue y la monitorización frente a los servicios AWS, y la Tarea 1.1 te pide distinguir la inferencia por lotes, tiempo real, asincrónica y serverless.

Al terminar esta lección sabrás:

• situar cada una de las nueve etapas del ciclo de vida frente a la función de SageMaker y al servicio no-SageMaker que la respalda;
• aplicar el marco de selección de tres preguntas de AWS (construir frente a personalizar frente a llamar a una API, modalidad, control) antes de escribir código alguno;
• configurar los almacenes online y offline de Feature Store y explicar por qué un modelo de fraude necesita ambos;
• dimensionar un endpoint serverless, calcular la concurrencia del batch transform y conocer el techo exacto de cada una de las cuatro opciones de inferencia;
• construir el bucle deriva → CloudWatch → EventBridge → reentrenamiento en Pipelines y explicar qué monitor detecta qué deriva;
• defender un veredicto comparativo: SageMaker frente a construir en EC2, frente a plataformas no-AWS, frente a un proceso manual;
• detectar las trampas de mantenimiento y retirada (Ground Truth, Model Monitor, Clarify, Studio Lab, Mechanical Turk) que aparecen en los ítems del examen de 2026;
• responder diez preguntas tipo examen escritas con la voz oficial de las preguntas de práctica.

---

1. Las nueve etapas del ciclo de vida de ML en AWS

1.1 Mapa de servicios etapa por etapa

Esta tabla es el artefacto más examinable de toda la Tarea 1.3. La columna izquierda es el propio vocabulario de la guía del examen; las columnas centrales son los servicios que debes poder nombrar bajo presión.

1.2 Los conceptos de MLOps que prueba el examen

La Tarea 1.3 no se detiene en las etapas. También nombra siete fundamentos de MLOps: cada uno se mapea a un mecanismo AWS concreto:

1.3 El ciclo de vida es un bucle, no una línea

La flecha que vuelve de Monitorización a Entrenamiento es el sentido mismo de MLOps. Un equipo que despliega y nunca vuelve a la etapa 5 tiene un proyecto, no un sistema, y eso es exactamente el lenguaje de «deuda técnica» y «prontitud de producción» que usa el examen.

Ordena el ciclo de vida antes de memorizar los servicios:

---

2. Elegir la ruta en AWS: el marco de tres preguntas

Antes de elegir un servicio, AWS quiere que respondas tres preguntas en orden. Saltar directamente a «SageMaker» es el antipatrón arquitectónico más común del examen.

2.1 Pregunta 1: ¿llamar a una API, personalizar un modelo fundacional o construir el tuyo?

2.2 Pregunta 2: ¿cuál es la modalidad de los datos?

2.3 Pregunta 3: ¿cuánto control necesitas?

AWS documenta una escalera de control que sube de sin código a código completo:

AWS también advierte en su propia guía que Studio es el punto de partida equivocado para un equipo sin experiencia en ML: empieza con Canvas.

2.4 Arquitectura de referencia: una cuenta, de extremo a extremo

📚 ¿Sabías que…? Los SageMaker Pipelines son literalmente un DAG JSON. Los tipos de paso documentados son Processing, Training, Tuning, AutoML, RegisterModel, DeployModel, Transform, Condition, Callback, Lambda, ClarifyCheck, QualityCheck, EMR, Notebook Job y Fail, y las salidas de un paso alimentan las entradas de los pasos aguas abajo, que es lo que hace automático el bucle del diagrama de arriba.

---

3. Ingesta de datos, almacenamiento y el Feature Store

3.1 De dónde vienen los datos

3.2 Feature Store: online frente a offline

3.3 Niveles del almacén online y semántica de escritura

AWS documenta dos niveles online:

• Standard: la configuración por defecto del almacén online;
• InMemory: respaldado por Amazon ElastiCache (Redis OSS) para las lecturas más rápidas. Es solo online (no hay replicación online↔offline) y no admite claves KMS gestionadas por el cliente.

En la vía de escritura, PutRecord.TargetStores acepta {OnlineStore, OfflineStore} con un máximo de 2 entradas, de modo que una sola llamada puede actualizar ambos almacenes, pero solo si un grupo tiene ambos habilitados.

Ejemplo 5, frescura de atributos con cifras reales. Un modelo de fraude llama a GetRecord y obtiene una respuesta en milisegundos de un dígito. El almacén offline del mismo grupo de atributos conserva cada versión histórica como Parquet en S3, que Athena puede consultar para un conjunto de entrenamiento correcto en point-in-time. Un PutRecord emitido a las 14:00 llega a S3 a más tardar a las 14:15 (bufferización de 15 minutos). El entrenamiento ve por tanto una instantánea ligeramente retrasada mientras la inferencia ve la fila más nueva, que es exactamente por lo que el examen pide ambos almacenes habilitados en un mismo grupo de atributos.

📚 ¿Sabías que…? La identidad del Feature Store no es solo una clave primaria: un registro se identifica de forma única por el identificador de atributos más el event time, y el almacén offline registra además write_time, api_invocation_time y un indicador is_deleted. Eso es lo que hace posibles los joins point-in-time: una consulta de entrenamiento a las 09:00 solo puede ver atributos cuyo event time sea anterior a las 09:00, aunque se hayan escrito después.

---

4. Procesamiento de datos, EDA e ingeniería de atributos

4.1 Qué servicio procesa qué carga de trabajo

4.2 El contrato del Processing job

Un Processing job de SageMaker tiene un contrato de cuatro pasos que al examen le gusta probar:

Esa propiedad de que «el cómputo se libera» es la razón por la que los Processing jobs vencen a una instancia de notebook permanentemente conectada para cualquier cosa programada.

4.3 Dónde viven ahora las herramientas sin código

Dos migraciones importan para el examen de 2026:

• Data Wrangler está integrado en SageMaker Canvas: ya no es una experiencia aparte en la barra lateral de Studio;
• la interfaz de Autopilot se trasladó a Canvas el 30 de noviembre de 2023: la API de AutoML sigue documentada y siendo invocable, pero la experiencia visual de AutoML es Canvas.

📚 ¿Sabías que…? Amazon Athena cobra por consulta y por gigabyte escaneado, así que la EDA más barata es una tabla Parquet particionada más un filtro WHERE dt = '…'. Un escaneo de tabla completa de un CSV de 1 TB cuesta aproximadamente 100× más que la misma consulta sobre Parquet particionado: el examen no pide el precio, pero sí pregunta si Athena es «SQL serverless sobre S3».

---

5. Entrenamiento, ajuste de hiperparámetros y orquestación

5.1 Training jobs y el techo de coste

5.2 Maneras de entrenar sin escribir el bucle tú mismo

5.3 Pipelines: la columna vertebral de la orquestación

Un SageMaker Pipeline es un DAG JSON cuyos pasos intercambian salidas como entradas. Los tipos de paso documentados son: Processing, Training, Tuning, AutoML, Register/Deploy model, Transform, Condition, Callback, Lambda, ClarifyCheck, QualityCheck, EMR, Notebook Job y Fail.

5.4 Model Registry

El Model Registry es la respuesta de calidad de producción a «¿qué modelo está en vivo?». Almacena Model Package Groups versionados, y cada Model Package lleva métricas, linaje, una etapa de staging, un estado de aprobación y ganchos para el despliegue CI/CD y el reparto entre cuentas. Todo lo que no esté en el Registry es, en términos de examen, un experimento sin seguimiento.

---

6. Evaluación, documentación y gobernanza

6.1 Amazon SageMaker Clarify: tres análisis distintos

Clarify escribe métricas de sesgo en JSON, atribuciones globales y un informe visual en S3, y puede ejecutarse contra un endpoint en vivo o contra un endpoint shadow temporal que Clarify crea y luego borra.

6.2 Model Cards y Model Dashboard

Si el examen dice «el propietario del modelo debe registrar los usos previos, la clasificación de riesgo, los detalles del entrenamiento y los resultados de evaluación», la respuesta es Model Cards: no el Dashboard (que agrega) ni Model Monitor (que solo rastrea deriva).

---

7. Despliegue: las cuatro opciones de inferencia

Este es el tema central de selección de servicios de toda la lección. SageMaker AI documenta exactamente cuatro opciones de inferencia, y cada una tiene un techo duro que debes poder recordar.

7.1 Lotes frente a tiempo real frente a asincrónica frente a serverless

7.2 Los techos numéricos en un solo lugar

Comprueba los techos antes de elegir una opción: manda la carga útil, no la preferencia de latencia:

7.3 Endpoints de tiempo real en detalle

• Endpoint HTTPS persistente invocado con InvokeEndpoint; el streaming de respuesta usa InvokeEndpointWithResponseStream.
• HTTP/2 bidireccional en el puerto 8443, con sesiones limitadas a 30 minutos.
• Varios modelos pueden compartir un endpoint mediante componentes de inferencia: la respuesta del examen cuando pide alojar varios modelos sin pagar por varios endpoints.

7.4 Serverless Inference en detalle

Tú eliges la memoria; AWS asigna las vCPUs proporcionalmente. El tiempo de arranque en frío lo determinan tamaño del modelo + descarga del modelo + arranque del contenedor, y por eso la memoria debe ser al menos del tamaño de tu modelo.

Serverless tiene exclusiones documentadas: sin GPUs, sin paquetes de AWS Marketplace, sin registros privados, sin endpoints multimodelo, sin configuración de VPC, sin data capture, sin Model Monitor y sin pipelines de inferencia. Y la conversión es de un solo sentido: convertir un endpoint de tiempo real existente a serverless falla con un ValidationError, mientras que la conversión inversa está permitida y es de un solo sentido.

7.5 Asynchronous Inference en detalle

InvokeEndpointAsync toma su entrada de S3, escribe la salida en S3 y envía una notificación de finalización. Las peticiones se encolan mientras la capacidad es cero, y el autoscaling puede reducir el número de instancias a 0: esa combinación (cola + escalado a cero) es lo que hace de la asincrónica la respuesta correcta para cargas útiles grandes y lentas.

7.6 Batch transform en detalle

• SplitType=Line divide el archivo de entrada en mini-lotes;
• BatchStrategy=MultiRecord|SingleRecord con MaxPayloadInMB;
• el CSV con saltos de línea incrustados no está soportado;
• MaxPayloadInMB=0 significa streaming troceado (no para algoritmos integrados);
• el nombre de salida por defecto es input1.csv.out;
• el MaxConcurrentTransforms ideal equivale al número de trabajadores paralelos que quieres.

7.7 Elegir entre las cuatro

Ejemplo 1: elección de opción por la carga útil. Una API de fraude recibe cargas de 3 KB y debe responder en menos de 200 ms → tiempo real (techos de 25 MB / 60 s). Más adelante se le pide al mismo modelo puntuar vídeos de 800 MB que tardan 10 minutos → eso supera el techo de 25 MB de tiempo real pero encaja en la asincrónica (≤ 1 GB, ≤ 60 min), así que cambias de opción y mantienes el escalado a cero.

Ejemplo 2: dimensionado serverless. Un modelo de 3,5 GB necesita MemorySizeInMB=4096 (la memoria debe ser ≥ tamaño del modelo; el rango permitido es 1024…6144). Fija MaxConcurrency=50 (permitido 1 to 200) con ProvisionedConcurrency=10 (debe ser ≤ MaxConcurrency) para precalentar parte del tráfico, y mantén la imagen del contenedor en ≤ 10 GB.

Ejemplo 3: aritmética de concurrencia batch. Con MaxPayloadInMB=25, el MaxConcurrentTransforms legal máximo es 4, porque 4 × 25 = 100 ≤ 100 MB. Fijar 5 rompería la regla documentada (5 × 25 = 125 > 100).

---

8. Monitorización, deriva y el bucle de reentrenamiento

8.1 Los cuatro tipos de monitor

Todos los monitores emiten métricas y violaciones a Amazon CloudWatch, que es la respuesta del examen cuando menciona «lanzar una alarma sobre umbrales». Ten en cuenta también que el contenedor de monitorización preconstruido solo admite datos tabulares: los modelos de NLP y de visión por computadora necesitan un contenedor bring-your-own.

8.2 De la alarma al modelo reentrenado

Ejemplo 6: el bucle deriva → reentrenamiento con cifras reales. Se calcula una línea base Deequ a partir de los datos de entrenamiento. Un job de monitorización programado compara el tráfico en vivo con ella. El monitor de atribución de atributos lanza una alarma automática cuando el NDCG cae por debajo de 0,90. Un ejemplo de sesgo usa un rango DPPL de (−0,1, 0,1) evaluado durante 2 días con intervalos de confianza bootstrap. La alarma va a CloudWatch, CloudWatch dispara una regla de EventBridge, y EventBridge inicia una ejecución de reentrenamiento de SageMaker Pipelines cuya nueva versión aterriza en el Model Registry como PendingManualApproval.

8.3 Qué recomienda ahora AWS en su lugar

Como Model Monitor y Clarify están cerrados a nuevos clientes, la propia documentación de cambios de disponibilidad de AWS apunta a un stack de reemplazo:

📚 ¿Sabías que…? Experiments Classic está disponible solo en Studio Classic, y AWS ahora recomienda MLflow 3.0 gestionado con Studio Apps: los artefactos del experimento se guardan en tu bucket S3, de modo que los datos de seguimiento sobreviven al notebook. MLflow es también la columna vertebral del reemplazo recomendado de Model Monitor.

---

9. Veredicto comparativo: SageMaker frente a las alternativas

9.1 SageMaker frente a servicios individuales

Los propios criterios de decisión de AWS son: gestión de infraestructura, compromisos de cómputo, preferencia de precios, soporte de la arquitectura del modelo y control sobre motor, configuración e infraestructura.

9.2 Amazon Bedrock frente a Amazon SageMaker: la línea oficial

9.3 Arquitectura de inferencia en streaming

El patrón que AWS documenta en sus blogs de arquitectura:

---

10. Disponibilidad, mantenimiento y trampas de retirada

El examen de 2026 prueba activamente la disponibilidad. Responder correctamente significa saber qué significa un aviso de mantenimiento y qué significa una retirada.

10.1 Instantánea de disponibilidad (SageMaker, 2026)

La redacción estándar de mantenimiento es: «Los clientes no pueden darse de alta… AWS seguirá operando y dando soporte a estos servicios… pero no los mejorará ni añadirá funcionalidad.» Los clientes existentes conservan el acceso; simplemente no hay nuevas funciones.

10.2 Mapa de funciones de SageMaker y su estado

📚 ¿Sabías que…? Studio Lab, el entorno gratuito de JupyterLab 4 que no requería ni cuenta AWS ni tarjeta de crédito, tenía como límites publicados solo 12 GB de RAM y 15 GB de almacenamiento, y ahora está cerrado a nuevos clientes con SageMaker Studio como reemplazo. Por eso «usa Studio Lab gratis» es un distractor en el material de 2026.

10.3 Actualizaciones de 2025 to 2026

Entre diciembre de 2024 y octubre de 2026 el ecosistema de SageMaker se renombró, se recortó y se redirigió varias veces. Cada fila de abajo proviene de un anuncio de AWS, de una página de cambio de disponibilidad de AWS o del historial de cambios de la certificación de AWS: nada aquí es de terceros, y las fechas que la propia AWS no publica se omiten deliberadamente (consulta la sección 13).

Dos datos de vocabulario completan el cuadro:

• Maintenance = sin nuevos clientes, sin nuevas funciones, aún con soporte · sunset = fin de operaciones planificado, normalmente anunciado con un año de antelación · full shutdown = retirado del portafolio de AWS. La referencia de Service Lifecycle de AWS define los tres estados, y cada fila de arriba está en los dos primeros.
• Las actualizaciones de la guía del examen llegan a la prueba aproximadamente un mes después de su publicación, así que todo lo que AWS publicó en v1.1 (30 abr 2026) ya es materia válida: incluidos SageMaker JumpStart, Bedrock AgentCore, Kiro y Strands Agents en la lista de servicios dentro del alcance.

📚 ¿Sabías que…? La página de disponibilidad de Kendra no dice «obsoleto»: redirige las nuevas aplicaciones de búsqueda a Amazon Bedrock Managed Knowledge Base, cuyo Smart Parsing y Agentic Retrieval API están documentados como el reemplazo de Kendra. «Kendra fue apagado» es por tanto un distractor: Kendra está en mantenimiento, que bajo el propio vocabulario de AWS significa que sigue funcionando para los clientes existentes.

---

11. Coste, free tier y los números que puedes memorizar con seguridad

11.1 Free tier de SageMaker (cada mes, durante los primeros 2 meses)

11.2 Patrón de coste resuelto

El ejemplo resuelto de la propia AWS suma $2,38: 2 horas de ml.m4.4xlarge a $0,96 cada una más 2 horas de ml.m5.xlarge a $0,23 cada una, con las reglas integradas de Debugger facturadas a $0. Aprende el patrón (horas-instancia × tarifa + recargos del job), nunca la tarifa: los precios de ml.* dependen de la región y de la fecha.

11.3 Cuotas

Los recuentos de endpoints, las cuotas de pipelines, los límites de jobs concurrentes y la concurrencia serverless viven en Service Quotas. Nunca adivines una cuota numérica en una respuesta de examen o en una revisión de diseño: búscala.

---

12. Ejemplos de AWS con cifras

Ejemplo 1: elección de opción por la carga útil (sección 7.7). API de fraude: cargas de 3 KB, < 200 ms → tiempo real (techos de 25 MB / 60 s). El mismo modelo puntúa vídeos de 800 MB que tardan 10 minutos → supera los 25 MB pero encaja en la asincrónica (≤ 1 GB, ≤ 60 min). Cambia de opción; mantén el escalado a cero.

Ejemplo 2: dimensionado serverless (sección 7.4). Modelo de 3,5 GB → MemorySizeInMB=4096; MaxConcurrency=50 (rango 1 to 200); ProvisionedConcurrency=10 (≤ 50) para precalentar; imagen del contenedor ≤ 10 GB.

Ejemplo 3: aritmética de concurrencia en lotes (sección 7.6). MaxPayloadInMB=25 → MaxConcurrentTransforms=4 máximo porque 4 × 25 = 100 ≤ 100 MB. Cinco trabajadores romperían la regla documentada.

Ejemplo 4: presupuesto de free tier. 250 horas de notebook ≈ 8,3 días-instancia; 50 horas de entrenamiento ≈ seis ejecuciones de 8 horas; 125 horas de tiempo real ≈ 4,2 días de hosting; 150.000 segundos serverless ≈ 41,7 horas facturables. Superar las 250 horas de notebook en el mes 1 inicia la facturación medida.

Ejemplo 5: frescura de atributos (sección 3.2). GetRecord online responde en milisegundos de un dígito; la tienda offline guarda cada versión como Parquet en S3 (consultable con Athena) para joins point-in-time; un PutRecord de las 14:00 llega a S3 a más tardar a las 14:15.

Ejemplo 6: el bucle deriva → reentrenamiento (sección 8.2). Línea base Deequ a partir de los datos de entrenamiento; monitorización programada del tráfico en vivo; la deriva de atribución lanza alarmas automáticas por debajo de NDCG 0,90; un ejemplo de sesgo usa DPPL ∈ (−0,1, 0,1) durante 2 días con intervalos de confianza bootstrap → CloudWatch → EventBridge → reentrenamiento con Pipelines.

Ejemplo 7: techo de coste de entrenamiento (sección 5.1). Un training job con el valor por defecto de MaxRuntimeInSeconds se detiene tras 1 día; el máximo duro es 28 días, y un job no puede superar los 30 días en total. Al detenerse, SageMaker envía SIGTERM y espera 120 segundos a que termine tu código de checkpoint.

---

13. Datos contradictorios, no verificables y no examinables

Los buenos candidatos al examen separan lo que AWS documenta de lo que AWS comercializa. Mantén esta lista fuera de tu set de memorización salvo donde se indique lo contrario.

Las fuentes primarias de esta lección son: la Exam Guide de AIF-C01; las páginas de la guía de desarrollador de SageMaker deploy-model-options, hosting-faqs, serverless-endpoints, batch-transform, processing-job, pipelines-overview, define-pipeline, model-registry, clarify-configure-processing-jobs, model-monitor, feature-store*, model-cards, model-dashboard, data-wrangler, autopilot-automate-model-development, mlflow; la referencia de API de SageMaker (API_StoppingCondition, API_feature_store_PutRecord); las guías de decisión bedrock-or-sagemaker.html y genai-guide.html; la página general de servicios en mantenimiento; y la página de precios de SageMaker.

---

Casos Reales

AWS publica estos casos en aws.amazon.com/solutions/case-studies/ y aws.amazon.com/blogs/machine-learning/. Pertenecen a esta lección porque cada uno mapea una etapa del ciclo de vida sobre una elección de servicio con una cifra asociada: que es exactamente cómo se plantean las preguntas de la Tarea 1.3.

Caso 1, HAYAT HOLDING: el bucle completo de entrenar → desplegar → monitorizar en el suelo de la planta

Los entornos de ML construidos por ellos mismos eran «costosos en tiempo y engorrosos» en este fabricante de paneles MDF. El pipeline publicado: 194 sensores sobre OPC-UA → SiteWise Edge Gateway en AWS IoT Greengrass → SageMaker Model Training + Automatic Model Tuning + Model Deployment, con SageMaker Edge Manager ejecutando el modelo en el dispositivo. Resultado: $300.000 al año ahorrados más mayor calidad de los paneles. Lección de ciclo de vida: las etapas 5 to 8 se ejecutan totalmente gestionadas, y Automatic Model Tuning reemplaza un barrido manual de hiperparámetros sobre 194 entradas. Fuente: aws.amazon.com/blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

Caso 2, Forethought: la inferencia hecha en casa es un impuesto oculto

Un equipo de 3 personas que soportaba 30 millones de interacciones al año ejecutaba los modelos y Kubernetes por su cuenta en Amazon EKS, incluidas excepciones de memoria y caídas. Migraron a endpoints multimodelo de SageMaker y Serverless Inference: −66% de coste en los endpoints multimodelo (con mejor latencia), ≈ −80% en serverless, y más del 80% de la inferencia con GPU ejecutándose ahora en SageMaker. Lección de ciclo de vida: etapa 7, los endpoints compartidos y el escalado a cero ganan a un clúster autoadministrado que tienes que atender a mano. Fuente: aws.amazon.com/solutions/case-studies/forethought-technologies-case-study.

Caso 3, RareJob: el cuello de botella era la orquestación, no la calidad del modelo

Entrenar en un PC local permitía un modelo por desarrollador; el intento posterior con EC2/ECS seguía costando demasiado. AWS Glue y Amazon Athena alimentan jobs paralelos de SageMaker Managed Spot Training. Resultado: −25% en tiempo de entrenamiento, > 10× de eficiencia de los desarrolladores, 100 horas al mes ahorradas, y las puntuaciones de las pruebas de habla devueltas en 2 to 3 minutos. Lección de ciclo de vida: las etapas 1 to 3 (recolectar → EDA → preprocesar) pertenecen a Glue y Athena; la cola, no el algoritmo, era la restricción. Fuente: aws.amazon.com/solutions/case-studies/rare-job-case-study (2020).

Caso 4, Chronomics: cuando la construcción interna falla, ve a AutoML

Cuatro meses de modelado interno personalizado de visión por computadora nunca alcanzaron el objetivo. Amazon Rekognition Custom Labels se entregó en 3 to 4 semanas con 96,5% de precisión / 97,9% de F1. Elevar el umbral de decisión a 0,99 produjo 99,6% de precisión pero descartó 5% de las predicciones; 0,999 dio 99,87% descartando 27%. Lección de ciclo de vida: etapa 6: la evaluación es lo que te dice cuándo dejar de construir, y la cola descartada necesita una ruta de revisión humana. Fuente: aws.amazon.com/blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (2022).

Caso 5, Sun Finance: separa el OCR del razonamiento

El primer intento enviaba fotos de documentos de identidad directamente a Claude Sonnet 4 y puntuaba 61,8% en total (43% en los números de documento): AWS lo rechazó. El pipeline reconstruido: OCR de Amazon Textract → Amazon Rekognition como fallback y enmascaramiento facial → estructuración con Claude Sonnet 4 → reglas de validación, con Amazon Titan Multimodal Embeddings en S3 Vectors para similitud de fraude, evaluado sobre 585 imágenes. Resultado: precisión 79,73% → 90,80%, coste por documento −91%, tiempo de procesamiento 20 horas → menos de 5 segundos, detección de fraude 81%. Lección de ciclo de vida: la evaluación (etapa 6) mató al prototipo elegante, y el servicio preconstruido: no el modelo: es dueño de la extracción. Fuente: aws.amazon.com/blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).

Caso 6, Anthem: primero lo preconstruido, los humanos en la cola

La extracción manual de formularios de reclamación tomaba 20 minutos por reclamación. Un pipeline de Amazon Textract (OCR más indexado/clasificación con ML detrás del portal de reclamaciones) automatizó el 80% del flujo de trabajo con un objetivo del 90%+, a través de miles de reclamaciones por día. Lección de ciclo de vida: etapas 1 to 2: llama a una API gestionada antes de entrenar cualquier cosa personalizada, y diseña la ruta de excepción humana para el 10 to 20% restante. Fuente: aws.amazon.com/solutions/case-studies/anthem (2021).

Los seis casos en una sola tabla

Cinco reglas que se repiten en los seis casos:

1. Elige la capa deliberadamente: servicio preconstruido (Anthem, Chronomics) → ML gestionado personalizado (HAYAT, RareJob, Forethought) → IA generativa (Sun Finance). El examen recompensa la capa más barata que funciona.
2. Línea base antes de construir: un porcentaje sin «antes» es marketing, no una métrica.
3. Separa las responsabilidades: el OCR no es razonamiento (Sun Finance), y la recuperación no es generación.
4. La evaluación es una fase, no una casilla: los primeros intentos de Sun Finance y de Chronomics fallaron en la etapa 6.
5. Mantén un humano en la cola: el 5% descartado y el 10 to 20% no automatizado siguen necesitando a alguien.

📚 ¿Sabías que…? La única tasa de producción que AWS publica para su propio Generative AI Innovation Center es el 65% de los proyectos que llegan a producción en 2025, algunos en tan solo 45 días, de más de 1.000 implementaciones, usando el marco de las Five V's de AWS: Value → Visualize → Validate → Verify → Venture. AWS nunca ha afirmado que todos los pilotos triunfen, así que cualquier opción que diga «100%» es errónea de entrada.

---

14. Preguntas de Práctica (Practice Questions)