Esta última lección no construye nada nuevo — y eso es exactamente lo que la hace importante. Después de seis módulos añadiendo piezas, toca dar un paso atrás y ver el sistema entero: el mapa completo de la plataforma de CineClick, un incidente real recorrido de punta a punta que ejercita cada componente, el inventario del repo como plantilla reutilizable, y el cierre del arco que abrimos en el módulo 1 — los diez problemas de aquel diagnóstico, revisitados uno a uno. Termina con tu proyecto: replicar la plataforma completa en otro dominio, porque la prueba de que sabes MLOps no es haber seguido a CineClick, sino poder construirlo sin ella.

1. El mapa completo de la plataforma
2. Un incidente de punta a punta: la promo de primavera
3. Inventario del repo: cineclick-churn como plantilla
4. Los diez problemas del módulo 1, revisitados
5. Tu proyecto: la plataforma de "LuzYa"
6. Guía de adaptación: cuando tu caso no es CineClick
7. Ejercicios de síntesis

Este es el sistema que has construido, con las personas dibujadas exactamente donde el sistema se detiene a esperarlas:

Tres lecturas del mapa antes de seguir:

• Es un bucle, no una tubería. La flecha de MON a DRIFT a RETRAIN y de vuelta al registry es lo que separa el nivel 2 de madurez del nivel 1: el sistema se realimenta.
• Cuatro humanos, cuatro juicios. Revisar código, aprobar el despliegue del servicio, aprobar la promoción del modelo, interpretar la deriva. Todo lo mecánico entre ellos es automático; ninguno de los cuatro es eliminable sin perder una salvaguarda.
• Dos cadencias conviven: la del servicio (despliegues cuando hay cambios de código) y la del modelo (promociones cuando hay challenger validado). Desacoplarlas fue la decisión central del módulo 5.

Nada demuestra un sistema como un incidente. Este escenario ejercita, en orden, casi todas las piezas del mapa. Cada paso usa comandos y pantallas que ya conoces — no hay nada nuevo que aprender, solo verlo todo funcionar junto.

Día 0 — el mundo cambia. Marketing lanza la promo de primavera: tres meses a mitad de precio. Nadie avisa al equipo de ML (nunca avisan). Empiezan a entrar miles de altas: clientes jóvenes, plan basico, antigüedad cero. El servicio ni se inmuta — el HPA escala de 3 a 5 réplicas, p95 estable en ~90 ms. Plano de servicio: verde. El dashboard de 06-01 empieza a mover los proxies: la mezcla por plan se desliza hacia basico y el histograma de probabilidades engorda por arriba.

Semana 2 — el sistema mira, y ve. Lunes 07:00, el flow deteccion-deriva-churn compara la última semana de la tabla de predicciones contra la referencia versionada del champion. Resultado: PSI 0.31 en antiguedad_meses (> 0.25), deriva también en plan y horas_semana, drift_share por encima del umbral. Alerta en #alertas-ml con las features derivadas y el enlace al informe HTML de Evidently. Nadie tuvo que acordarse de mirar: ese era el punto de todo el módulo 6.

Semana 2, mismo día — playbook, no reflejo. Laura abre el informe y aplica el playbook de 06-02. ¿Error de datos upstream? No: el esquema_clientes de pandera pasa, los valores son plausibles, y las distribuciones desplazadas cuentan una historia coherente (clientes nuevos de verdad). ¿Cohorte legítima? Sí — dos mensajes a marketing lo confirman: es la promo. ¿Impacto? La tasa de positivos ha subido al 23%, aún dentro de la banda 10–25%, pero el modelo está extrapolando sobre una población que apenas vio en entrenamiento. Decisión humana: disparo extraordinario del reentrenamiento, documentada en el hilo de la alerta.

Semana 2-3 — el reentrenamiento propone. Laura lanza reentrenamiento-churn desde la UI de Prefect con motivo="extraordinario-PSI-antiguedad". El flow construye el dataset nuevo con corte point-in-time (la cohorte de la promo entra con las etiquetas que ya tiene; el grupo de control mantiene las etiquetas limpias), hace dvc repro, y evalúa: test congelado recall 0.69 / precision 0.55 (umbral superado), test fresco recall 0.66. Registra v3 como @challenger con sus tags de linaje (datos_dvc_md5, ventana temporal, flow run) y notifica a #alertas-ml. En ningún momento toca @champion.

Semanas 3-5 — la sombra escucha. El PR de promoción se abre, pero antes: dos semanas de sombra obligatorias (ADR-007). Se activa MODO_SOMBRA en el ConfigMap churn-api-config; cada petición se puntúa con v2 (que responde) y v3 (que solo se registra: probabilidad_sombra, version_modelo_sombra). Al cerrar la ventana, el análisis de la tabla de predicciones muestra un desacuerdo del 9%, concentrado casi por completo en la cohorte nueva — v3 asigna probabilidades más bajas a los recién llegados de la promo. Es exactamente lo que debía pasar: v3 aprendió que "antigüedad cero + plan basico + promo" no implica el riesgo que v2 les extrapolaba. La evaluación por subgrupos (06-04) confirma que ningún segmento empeora; la model card de v3 se redacta con la cohorte como novedad y sus etiquetas aún jóvenes como limitación.

Semanas 5-6 — canary y promoción. Revisión humana del PR de promoción: checklist de docs/promocion-modelo.md, evidencia de sombra adjunta, subgrupos, model card. Aprobado. Canary de modelo: 5% → 25% → 100%, 24-48 h por escalón, con las métricas de guardia vigilando (5xx, p95, tasa de positivos en banda). Sin sobresaltos. promocionar_champion.py mueve el alias: v3 = @champion. El endpoint /version lo confirma; la referencia del detector de deriva se actualiza sola al dataset de v3 (el mecanismo del ejercicio 3 de 06-02).

Semana 6 — cierre. ADR nuevo en docs/decisiones/: contexto (promo no comunicada), decisión (reentrenamiento extraordinario y política acordada con marketing: avisar de campañas con dos semanas de antelación), consecuencias. El dashboard vuelve a verde con una anotación en la línea temporal: "v3 promocionado". Del día 0 al cierre: el sistema detectó solo, el humano decidió cuatro veces, y ningún cliente notó nada.

El repo que has visto crecer es, a estas alturas, una plantilla reutilizable. El inventario completo, con la lección donde nació cada pieza:

Para tu próximo proyecto, esta tabla es la lista de la compra: cada fila es una pieza que sabrás construir, y el orden de las lecciones es un orden de construcción razonable.

En 01-04 diagnosticamos el punto de partida de CineClick: un modelo prometedor muriendo en el notebook de Laura. Aquellos diez problemas, cerrados uno a uno:

El arco completo del curso cabe en esta tabla. Fíjate en que ninguna fila se resolvió con "más modelo": el recall pasó de 0.43 (v1) a 0.68 (v2) en el módulo 3, y todo lo demás fue convertir ese modelo en un sistema.

Ahora te toca. El proyecto final consiste en replicar la plataforma completa con otro caso: LuzYa, una comercializadora eléctrica ficticia que quiere predecir el impago de facturas para anticipar avisos y planes de pago. Mismo esqueleto, dominio nuevo — que es exactamente la situación en la que estarás en tu trabajo. Todos los datos deben ser sintéticos, generados por ti (como lo fueron los de CineClick).

El dataset (facturas_luzya.csv, genera ~20.000 filas sintéticas con ~12% de impago):

Fases, mapeadas a los módulos del curso, con criterios de autoevaluación:

• Fase 1 (M2) — Reproducibilidad. Repo luzya-impago con paquete, entorno con lock, DVC y pipeline dvc repro de 4 etapas.
  • [ ] Un compañero (o tú en otra máquina) reproduce el entrenamiento con 3 comandos.
  • [ ] dvc repro sin cambios no re-ejecuta nada.
• Fase 2 (M3) — Experimentos y registry. MLflow, al menos dos versiones registradas (base + mejora), alias @champion, features.py como fuente única. Define TU criterio de negocio (p. ej. recall ≥ 0.65 con precision ≥ 0.45 — justifícalo: ¿qué cuesta más, un aviso de más o un impago no detectado?).
  • [ ] Puedes responder "¿con qué datos y código se entrenó el champion?" solo con MLflow + DVC.
• Fase 3 (M4) — Serving. API FastAPI (/predecir, /salud, /version), Docker multi-stage, despliegue en Kubernetes local (kind/minikube) con 2+ réplicas; batch mensual de scoring de la facturación.
  • [ ] p95 medido y presupuesto de latencia definido y documentado.
• Fase 4 (M5) — Automatización. CI con tests de código/datos (pandera)/modelo y tu umbral bloqueante; CD desacoplado; flow de scoring programado; plan de release por escrito (¿sombra? ¿canary? ¿qué métricas de guardia?).
  • [ ] Un PR que degrada el recall por debajo del umbral se bloquea solo.
• Fase 5 (M6) — Operación. /metrics + proxies, tabla de predicciones, deriva con Evidently programada, flow de reentrenamiento con point-in-time (num_impagos_previos y plan_pago_activo son tus trampas de leakage e intervención: resuélvelas como CineClick resolvió las suyas — corte temporal y grupo de control), model card, dos ADRs y la checklist de gobernanza de 06-04 completada.
  • [ ] Simula una deriva (genera un mes de datos con otra distribución de tarifa) y verifica que tu detector la ve.
  • [ ] Responde el simulacro de auditoría del ejercicio 1 de 06-04, versión LuzYa.

Consejo de alcance: hazlo en serie, no en paralelo, y no pases de fase sin cumplir su checklist — el orden de los módulos era también un orden de dependencias. Un proyecto con las fases 1-3 impecables vale más que las cinco a medias.

El esqueleto es el mismo casi siempre; estos son los ajustes típicos, en pinceladas:

• Modelos de deep learning: el bucle no cambia (registry, challenger, sombra, deriva), pero el entrenamiento se encarece — entra el tracking de checkpoints, datasets que no caben en un CSV (DVC sigue valiendo; cambia el remote y el formato), y evaluación más cara. Los fundamentos de modelado los cubre el curso de deep_learning del portal.
• Con GPU: afecta a dos sitios — el entrenamiento (colas y nodos GPU en el orquestador; el flow de reentrenamiento pide recursos distintos) y a veces la inferencia (batching de peticiones, y el presupuesto de latencia/coste de 04-05 se recalcula por completo). En Kubernetes, node pools y resources.limits con GPU: curso de kubernetes.
• Equipo grande: lo que en CineClick era "Laura y tú" se convierte en plataforma compartida — registry y tracking centralizados multiproyecto, entornos por equipo, y las aprobaciones humanas se formalizan en CODEOWNERS y environments protegidos. La disciplina de ramas, revisiones y pipelines a escala: cursos de ci_cd y docker para reforzar la base de entrega.
• Regulación fuerte (banca, salud, seguros): el módulo 6-04 pasa de "buena práctica" a requisito duro; la checklist crece con validación independiente de modelos y comités — pero fíjate: la estructura es la misma, solo cambia la exigencia de cada casilla.

• Empezar el proyecto de LuzYa por la fase 4 o 5. La tentación de "ir a lo interesante" (CI/CD, deriva) sin una fase 1 sólida reproduce el error original de CineClick: automatizar sobre arena. Si dvc repro no funciona en una máquina limpia, nada de lo que montes encima es de fiar.
• Copiar los números de CineClick en lugar de derivar los tuyos. El umbral recall ≥ 0.60/precision ≥ 0.50, la banda 10-25% de positivos o el presupuesto de 300 ms salen del negocio de CineClick. En LuzYa el coste de un falso negativo (impago no detectado) y de un falso positivo (aviso injusto a un buen cliente) son otros — haz la cuenta antes de fijar el umbral, como en la fase 2.
• Tratar las trampas del dataset como detalles opcionales. num_impagos_previos sin corte temporal es leakage puro (contarás impagos que aún no habían ocurrido) y plan_pago_activo es una intervención que contamina la etiqueta, igual que el descuento de retención de CineClick. Si el modelo de la fase 2 te da métricas sospechosamente buenas, casi seguro que has caído en la primera.
• Confundir "tener las piezas" con "tener la plataforma". El escenario de la promo lo enseñó: el valor no está en Evidently ni en Prefect por separado, sino en que la alerta lleve a un playbook, el playbook a un reentrenamiento con linaje y este a un camino de release seguro. Al autoevaluarte, recorre un incidente inventado de punta a punta — es la checklist que de verdad importa.
• Saltarse a los humanos del mapa. Si en tu réplica el flow de reentrenamiento termina moviendo @champion directamente "porque total, soy yo solo", has vuelto al nivel 0 con más YAML. La disciplina de challenger + revisión se entrena en proyectos pequeños para que exista en los grandes.

Sobre el escenario de la promo de primavera (no requieren escribir código):

1. El contrafactual. Recorre el incidente imaginando que CineClick se hubiera quedado como al final del módulo 4 (sin módulo 5 ni 6): ¿en qué momento se habría detectado el problema, quién lo habría detectado, y qué habría pasado con la campaña de retención durante esas semanas? Señala las dos piezas cuya ausencia habría dolido más.

2. Los cuatro humanos. Durante el incidente hay cuatro intervenciones humanas (playbook, lanzamiento del reentrenamiento, revisión del PR de promoción, decisión sobre el canary). Para cada una, explica qué juicio aporta esa persona que el sistema no puede automatizar con lo construido en el curso — y cuál de las cuatro crees que sería la primera candidata a automatizarse en un hipotético nivel 3 de madurez, con qué salvaguarda a cambio.

3. La pieza que falló silenciosamente. En el escenario, marketing no avisó de la promo y el sistema la detectó por deriva dos semanas después. El ADR de cierre añade el aviso previo de campañas como política. ¿Qué te enseña esto sobre los límites de la solución técnica — es decir, qué clase de problemas de un sistema de ML en producción no se resuelven con más monitorización?

1. Sin módulo 6 no hay detección: ni proxies, ni Evidently, ni alerta. El problema se habría descubierto cuando alguien de marketing notara — semanas o meses después — que la campaña de retención "funcionaba raro": demasiados clientes nuevos marcados en riesgo (v2 extrapolando antigüedad cero como peligro), presupuesto de descuentos disparado sobre una cohorte que quizá no lo necesitaba, y clientes veteranos en riesgo compitiendo por hueco en la campaña con falsos positivos. Sin módulo 5, además, la respuesta habría sido artesanal: reentrenar a mano en el portátil de Laura, sin sombra ni canary, con el riesgo de sustituir un problema conocido por uno desconocido. Las dos ausencias más dolorosas: la tabla de predicciones (sin ella no hay ni diagnóstico retrospectivo: no sabrías ni cuántos clientes de la promo fueron marcados) y el camino seguro challenger → sombra → canary (sin él, la corrección es tan arriesgada como el problema).

2. Playbook: distingue causas que requieren contexto externo al sistema (¿es una promo? ¿un bug del equipo de datos?) — el sistema ve que la distribución cambió, no por qué; ese porqué vive en conversaciones con otros equipos. Lanzamiento del reentrenamiento: decide si el cambio merece la respuesta cara (cómputo, riesgo, revisión) — un juicio de coste/beneficio con información de negocio. Revisión del PR: responsabilidad — alguien con nombre asume que la evidencia (sombra, subgrupos, model card) justifica el cambio; es tanto control como rendición de cuentas. Canary: interpretar métricas de guardia en contexto (¿ese pico de p95 es el modelo o es el partido de fútbol?). La candidata natural a automatizar en un nivel 3 es la progresión del canary (los umbrales ya son objetivos y el rollback automático ya existe): se automatizaría el avance 5→25→100 cuando las métricas de guardia llevan N horas limpias, con la salvaguarda de que cualquier alerta congela la progresión y notifica — el humano pasa de aprobar cada escalón a supervisar por excepción. Las otras tres involucran contexto externo o responsabilidad, y automatizarlas eliminaría el juicio, no el trámite.

3. Que la monitorización es un detector de síntomas, no un sustituto de la comunicación entre equipos: el sistema técnico perfecto detectó la promo con dos semanas de retraso porque el problema no era técnico — era organizativo (una decisión de negocio que afecta a los datos no llegó a quienes operan el modelo). Ninguna cantidad de PSI convierte una sorpresa en un aviso. Por eso el cierre del incidente es un ADR con una política de comunicación y no una herramienta nueva: hay una clase entera de problemas (cambios de negocio, decisiones de producto, eventos externos previsibles) cuya solución barata es avisar antes y cuya solución técnica es solo el airbag. MLOps, como su pariente DevOps, es en última instancia una disciplina sociotécnica: la mitad de la plataforma son pipelines; la otra mitad, acuerdos entre personas — los cuatro humanos del mapa, los ADRs, el playbook y una promo comunicada a tiempo.

Aquí termina el viaje. Empezó en el módulo 1 con un notebook en el portátil de Laura: un random forest prometedor con recall 0.43 y diez problemas que le impedían tocar la realidad. Termina con la plataforma del mapa de esta lección: un paquete reproducible con datos versionados (M2); experimentos trazados y un registry donde v2 — y ahora v3 — llevan su linaje completo (M3); un servicio en Kubernetes con p95 de 92 ms y un batch semanal que alimenta la campaña de retención (M4); CI que convierte el criterio de negocio en umbral bloqueante, CD desacoplado con humanos en los puntos de responsabilidad, y releases con sombra, canary y rollback ensayado (M5); y un sistema que mira solo — dos planos de monitorización, deriva detectada cada lunes, reentrenamiento con disparo y point-in-time correctness, gobernanza auditable por diseño (M6). CineClick cruzó al nivel 2 de madurez, y tú cruzaste con ella.

Lo que sabes hacer ahora, en concreto: estructurar un proyecto de ML como paquete reproducible con entorno fijado; versionar datos y pipelines con DVC; trazar experimentos y gestionar el ciclo champion/challenger en MLflow; servir modelos online con FastAPI, empaquetarlos con Docker y operarlos en Kubernetes con presupuesto de latencia; montar CI con tests de código, datos y modelo, y CD desacoplado para servicio y modelo; orquestar con Prefect; diseñar releases con sombra, canary y A/B; monitorizar en dos planos y construir una tabla de predicciones auditable; detectar deriva con PSI y Evidently y reaccionar con un playbook; automatizar el reentrenamiento sin ceder la decisión de promoción; y documentar y gobernar el sistema — model cards, ADRs, subgrupos, privacidad — hasta poder superar un simulacro de auditoría en minutos.

Para seguir profundizando, tres caminos naturales: hacia el modelado (el curso de deep_learning del portal, si tus modelos crecen más que tus pipelines), hacia la infraestructura (los cursos de kubernetes, docker y ci_cd, si quieres operar la plataforma que otros usan), y hacia la práctica — que es el camino que de verdad consolida: el proyecto de LuzYa está esperando, y después de él, el primer modelo real de tu equipo que hoy esté muriendo en un notebook. Ya sabes exactamente qué hacer con él.