1. Por qué hablar de niveles de madurez
2. Nivel 0: proceso manual
3. Nivel 1: pipeline de entrenamiento automatizado
4. Nivel 2: CI/CD completo para ML
5. Tabla comparativa y autodiagnóstico
6. Los roles del equipo de ML
7. Cómo colaboran en la práctica: handoffs y ownership compartido
8. CineClick: nivel 0 con billete hacia el nivel 2

Los niveles de madurez que veremos son una síntesis, explicada con nuestras palabras, de los modelos que publicaron Google (tres niveles: 0, 1 y 2) y Microsoft (una escala más granular de cinco niveles, que en esencia describe el mismo camino con más peldaños). No son un estándar oficial ni un examen que aprobar: son un lenguaje común para responder a preguntas muy prácticas:

• ¿Dónde estamos hoy y qué nos falta?
• ¿Qué inversión tiene sentido dar ahora? (Saltar de 0 a 2 de golpe suele fracasar.)
• ¿Qué nivel necesita realmente nuestro caso? No todos los equipos necesitan el nivel máximo.

La idea que ordena los niveles es simple: ¿qué está automatizado? En el nivel 0, nada. En el nivel 1, el entrenamiento. En el nivel 2, también la integración y el despliegue de los propios pipelines.

Es el punto de partida de casi todos los equipos, y no es vergonzoso: es lo natural cuando se empieza. Sus rasgos:

• Todo el flujo es manual e interactivo: los datos se extraen a mano, el entrenamiento ocurre en notebooks, el "mejor modelo" se elige mirando resultados a ojo.
• Desconexión entre quien entrena y quien opera: el data scientist entrega un fichero de modelo (un .pkl, por ejemplo) y otro equipo —o nadie— lo pone a servir. La entrega es el artefacto, no el proceso.
• Despliegues infrecuentes: el modelo se actualiza pocas veces al año, porque cada actualización es un proyecto manual.
• Sin monitorización del modelo: se vigila, como mucho, que el servicio no se caiga. Nadie mide si las predicciones siguen siendo buenas.
• Sin registro sistemático: los experimentos, datos y decisiones viven en carpetas personales y memoria de la gente.

El riesgo característico del nivel 0 es la degradación silenciosa: como reentrenar es caro y no hay monitorización, el modelo envejece en producción hasta que el negocio nota que algo va mal — semanas o meses después de que empezara a fallar.

¿Cuándo es aceptable quedarse aquí? Para prototipos, pruebas de concepto o modelos que se usan una sola vez. En cuanto un modelo se usa de forma recurrente y el negocio depende de él, el nivel 0 se convierte en una deuda.

El salto cualitativo del nivel 1 es este: lo que se despliega ya no es un modelo, sino un pipeline que produce modelos. En lugar de entregar un .pkl, el equipo entrega un proceso automatizado que va de los datos al modelo validado sin intervención manual.

Qué implica en la práctica:

• Pipeline de entrenamiento ejecutable de principio a fin: extracción y validación de datos, preprocesado, entrenamiento, evaluación y validación del modelo, todo encadenado y parametrizado (la construcción de estos pipelines es el tema del módulo 2, y su orquestación se completa en el módulo 5).
• Entrenamiento continuo (CT, continuous training): el pipeline puede ejecutarse con frecuencia —por calendario o disparado por datos nuevos— y producir modelos frescos de forma rutinaria.
• Simetría entre experimentación y producción: el código que se usa para experimentar es el mismo que corre en producción, lo que exige que la fase experimental ya trabaje con código modular y versionado, no con notebooks sueltos.
• Validación automática de datos y de modelo: el pipeline comprueba que los datos de entrada tienen la pinta esperada y que el modelo nuevo supera umbrales antes de publicarse.
• Registro de experimentos y de modelos: cada ejecución queda trazada (módulo 3).

Lo que el nivel 1 no resuelve: el pipeline en sí se despliega a mano. Si el equipo cambia el código del pipeline (una feature nueva, otro algoritmo), probar y desplegar esa nueva versión del pipeline sigue siendo un proceso manual. Con pocos pipelines y pocos cambios, es asumible; cuando hay muchos modelos o mucho cambio, aparece el cuello de botella que motiva el nivel 2.

En el nivel 2, también el ciclo de vida del propio pipeline está automatizado. Es el nivel de organizaciones que operan muchos modelos o que necesitan iterar sobre ellos con rapidez y garantías.

Sus componentes, contados sin entrar en el detalle que corresponde al módulo 5:

• Integración continua (CI): cada cambio en el código dispara automáticamente la construcción y las pruebas — y en ML las pruebas van más allá del código: se testean también los datos y el comportamiento de los modelos.
• Despliegue continuo (CD): las nuevas versiones del pipeline (y los modelos que produce) llegan a producción mediante un proceso automatizado, con validaciones y sin rituales manuales.
• Todo el ciclo instrumentado: monitorización del servicio y del modelo, con la posibilidad de que una alerta de degradación dispare automáticamente un reentrenamiento (módulo 6).
• Despliegues frecuentes y de bajo riesgo: actualizar un modelo pasa de ser "el proyecto del trimestre" a un evento rutinario, gracias a estrategias de release progresivas (que veremos en el módulo 5).

Matiz importante: el nivel 2 no significa "sin humanos". Las decisiones críticas —aprobar un modelo para producción, validar que un comportamiento es aceptable— siguen teniendo puntos de aprobación humana. Lo que se automatiza es todo lo mecánico alrededor de esas decisiones, para que sean informadas, rápidas y trazables.

Para autodiagnosticar a tu equipo, hazte estas preguntas en orden; la primera respuesta "no" te dice tu nivel:

1. ¿Podéis reentrenar y publicar un modelo ejecutando un proceso automatizado, sin pasos manuales? Si no → nivel 0.
2. ¿Un cambio en el código del pipeline llega a producción mediante CI/CD (tests automáticos + despliegue automatizado)? Si no → nivel 1.
3. Si ambas son sí → nivel 2 (en la práctica, un espectro dentro del nivel 2: cuánta monitorización, cuánto reentrenamiento automático...).

Dos consejos sobre el diagnóstico: sé honesto (el nivel se mide por lo que ocurre, no por lo que "podríamos hacer"), y recuerda que distintos modelos de la misma organización pueden estar en niveles distintos — el nivel es del sistema, no de la empresa.

La madurez no la construyen las herramientas sino las personas. Estos son los roles habituales en un equipo que opera ML en producción. Ojo: son roles, no necesariamente personas distintas — en equipos pequeños una persona cubre varios; en organizaciones grandes cada rol puede ser un equipo entero.

Algunas observaciones que la tabla no captura:

• El ML engineer es el rol bisagra y el más "nuevo" de la lista: nació precisamente de la brecha notebook→producción. Comparte lenguaje con el data scientist (entiende de modelos) y con plataforma (entiende de sistemas). Gran parte de este curso es, de hecho, el temario de un ML engineer.
• El data engineer trabaja "aguas arriba" del modelo, pero su trabajo condiciona todo lo demás: la mayoría de los incidentes de ML en producción son, en origen, incidentes de datos.
• Negocio no es un rol decorativo: sin alguien que defina qué significa "funcionar" en euros o en clientes retenidos, el equipo optimiza métricas de ML en el vacío. Y como vimos, las decisiones de aceptación de riesgo y aprobación final son humanas y suelen ser suyas.

Conocer los roles no basta: los problemas reales aparecen en las fronteras entre ellos. Hay dos formas de organizar esas fronteras:

Modelo de handoffs (relevos): cada rol trabaja su etapa y "lanza el resultado por encima del muro" al siguiente. El data scientist entrega un notebook al ML engineer, que lo reescribe y entrega un contenedor a plataforma, que lo despliega. Es el modelo por defecto en organizaciones que separan equipos por especialidad, y tiene problemas conocidos:

• Pérdida de información en cada relevo: el ML engineer reimplementa el preprocesado y algo cambia sutilmente; el modelo de producción no se comporta como el del notebook.
• Ciclos lentos: cada mejora del modelo tiene que recorrer toda la cadena de relevos.
• Nadie es dueño del resultado final: cuando el modelo falla en producción, cada equipo mira al de al lado.

Modelo de ownership compartido: un equipo multidisciplinar es dueño del sistema de ML de extremo a extremo — del dato a la predicción monitorizada. Los roles siguen existiendo, pero comparten repositorio, pipeline y responsabilidad de guardia. Las prácticas que lo hacen posible:

• Artefactos comunes en lugar de entregas: no se entrega "un notebook" sino que todos trabajan sobre el mismo repositorio versionado, el mismo pipeline y el mismo registro de modelos. La herramienta compartida es el contrato.
• Contratos explícitos donde hay frontera inevitable: por ejemplo, un esquema de datos acordado y validado automáticamente entre data engineering y el pipeline de entrenamiento — así los cambios de datos rompen un test, no el modelo en producción.
• Revisión cruzada: el ML engineer revisa el código de features del data scientist; el data scientist revisa que el servicio implemente el preprocesado correcto.
• Responsabilidad de operación compartida: quien construye el modelo participa en vigilarlo. Nada mejora tanto la calidad de un pipeline como que su autor reciba las alertas.

La progresión de madurez y la colaboración se refuerzan mutuamente: las herramientas de los niveles 1 y 2 (pipelines, registros, CI/CD) son precisamente lo que sustituye los relevos informales por artefactos compartidos y verificables.

Hagamos el diagnóstico de CineClick con las preguntas de autodiagnóstico:

• ¿Puede reentrenar y publicar con un proceso automatizado? No: el modelo vive en un notebook en el portátil de la data scientist, los datos se extraen a mano y no hay proceso de despliegue en absoluto. → Nivel 0 de manual.
• Roles: hay una data scientist (nuestra protagonista), un data engineer que mantiene las bases de datos de la plataforma, y un pequeño equipo de plataforma que opera la web de CineClick pero nunca ha desplegado un modelo. No hay ML engineer... todavía: ese es el rol que tú, como estudiante, vas a ejercer durante el curso.

El plan del curso es, literalmente, la escalera de madurez:

• Módulos 2 y 3 construyen los cimientos del nivel 1: código estructurado y reproducible, datos versionados, pipeline de entrenamiento, experimentos y modelos registrados.
• Módulo 4 añade lo que el nivel 1 presupone para servir: el modelo desplegado como servicio real.
• Módulo 5 da el salto al nivel 2: CI/CD para el código, los datos y los modelos, y orquestación de los pipelines.
• Módulo 6 completa el nivel 2 por el lado de la operación: monitorización, deriva y reentrenamiento automatizado.

No memorices este plan: lo verás desplegado con detalle (dataset, notebook inicial y stack de herramientas incluidos) en la próxima lección.

• Error: intentar saltar del nivel 0 al 2 de una vez. Montar toda la plataforma de golpe, sin haber consolidado antes un pipeline reproducible, suele producir una infraestructura compleja que nadie usa. Sube la escalera peldaño a peldaño; este curso está ordenado así a propósito.
• Error: tratar el nivel 2 como objetivo universal. Un equipo con un único modelo que se reentrena dos veces al año puede vivir perfectamente en un nivel 1 bien hecho. El nivel adecuado depende del número de modelos, la frecuencia de cambio y el coste de la degradación — no del prestigio.
• Error: confundir "tenemos las herramientas" con "tenemos la madurez". Instalar un orquestador y un registro de modelos no te sube de nivel si el proceso real sigue siendo manual. El nivel se mide por cómo llegó a producción el último modelo, no por el stack instalado.
• Error: contratar roles sin definir fronteras. Incorporar un ML engineer a un equipo que sigue trabajando por relevos de notebooks solo añade un relevo más. Define primero los artefactos compartidos (repositorio, pipeline, registro) y las responsabilidades sobre ellos.
• Consejo: en equipos pequeños, no te preocupes por cubrir cinco roles con cinco personas; preocúpate de que las cinco responsabilidades tengan dueño explícito. Una tabla de dos columnas (responsabilidad → persona) evita el clásico "pensaba que eso lo mirabas tú".

Diagnostica el nivel de madurez de estos tres equipos y justifica la respuesta:

1. Equipo A: cada lunes, un job programado reentrena el modelo con los datos de la semana, valida automáticamente que supera al modelo vigente y, si es así, lo publica en el registro de modelos. Sin embargo, cuando el equipo quiso añadir una feature nueva el mes pasado, tardó tres semanas: hubo que probar el pipeline modificado a mano en una máquina de staging y desplegarlo copiando ficheros.
2. Equipo B: el modelo se reentrena "cuando alguien tiene un rato": la data scientist descarga un extracto de la base de datos, ejecuta su notebook, y si las métricas le parecen bien envía el fichero del modelo por el chat interno al ingeniero que lo copia al servidor.
3. Equipo C: cada push al repositorio dispara tests de código, de datos y de modelo; si pasan, el pipeline actualizado se despliega solo, y las alertas de deriva pueden disparar un reentrenamiento automático que publica el modelo tras una aprobación humana registrada.

En CineClick, la data scientist ha creado en su notebook una feature muy predictiva: ratio_visualizacion (horas vistas / horas de contenido nuevo publicado en su plan). Entrega el notebook al futuro ML engineer para que la lleve a producción. Describe: (1) al menos dos problemas que puede causar este handoff tal como está planteado, y (2) cómo lo organizaría un equipo con ownership compartido y contratos explícitos.

Asigna cada tarea al rol que debería liderarla (data scientist, data engineer, ML engineer, plataforma/DevOps, negocio/product owner). Alguna tarea puede requerir colaboración de dos roles; indícalo:

1. Decidir si un recall del 70% en la clase "abandona" es suficiente para lanzar la campaña de retención.
2. Investigar por qué el modelo falla más con los clientes que pagan con PayPal.
3. Garantizar que la tabla de tickets de soporte llega cada noche completa y con el esquema acordado.
4. Reducir el tiempo de arranque de los contenedores del servicio de predicción en el cluster.
5. Convertir el preprocesado del notebook en un módulo Python testeado que usen tanto el entrenamiento como el servicio.

Solución 1:

1. Equipo A: nivel 1. El entrenamiento está completamente automatizado, con validación y publicación incluidas (eso descarta el nivel 0). Pero la evolución del pipeline es manual —pruebas a mano, despliegue copiando ficheros—, que es exactamente la limitación que define la frontera con el nivel 2. Las tres semanas para añadir una feature son el síntoma del cuello de botella característico del nivel 1.
2. Equipo B: nivel 0. Proceso manual de principio a fin, entrenamiento en notebook, entrega del artefacto por chat, despliegue copiando el fichero, sin validación sistemática ni trazabilidad. Es el nivel 0 de libro, incluida la desconexión entre quien entrena y quien opera.
3. Equipo C: nivel 2. CI con tests de código, datos y modelo; CD del pipeline; y monitorización conectada al reentrenamiento. Nótese que la aprobación humana antes de publicar no lo baja de nivel: el nivel 2 automatiza lo mecánico, no elimina las decisiones humanas.

Solución 2:

1. Problemas del handoff: (a) Reimplementación divergente: el ML engineer tendrá que reescribir el cálculo de ratio_visualizacion para producción y cualquier diferencia sutil (¿horas de qué ventana temporal? ¿qué cuenta como "contenido nuevo"?) hará que el modelo en producción vea features distintas de las de entrenamiento y rinda peor sin error visible. (b) Pérdida de contexto: las decisiones que la data scientist tomó explorando (por qué esa fórmula, qué casos límite descartó, cómo trató divisiones por cero) no viajan con el notebook. (c) Ciclo lento: cada ajuste futuro de la feature repetirá todo el relevo.
2. Con ownership compartido: la feature viviría desde el principio en el repositorio común como una función Python con sus tests (no en una celda de notebook); la data scientist y el ML engineer la revisarían mutuamente; y el mismo código se usaría en el pipeline de entrenamiento y en el servicio de predicción, eliminando la divergencia por construcción. Si el cálculo depende de datos que prepara el data engineer, habría un contrato de esquema validado automáticamente. (Cómo estructurar ese código compartido es justo el tema con el que abre el módulo 2.)

Solución 3:

1. Negocio/product owner, con el análisis del data scientist sobre qué significa ese 70% (a cuántos clientes llega, cuántos falsos positivos genera). La decisión de riesgo es de negocio; los números que la informan, del data scientist.
2. Data scientist: es análisis de errores del modelo por subgrupos. Puede necesitar al data engineer si la causa resulta ser un problema de calidad del dato de metodo_pago.
3. Data engineer: fiabilidad, completitud y esquema de una fuente de datos es su terreno natural.
4. Plataforma/DevOps, en colaboración con el ML engineer (que conoce el contenido del contenedor y puede reducir su tamaño o dependencias).
5. ML engineer: es la conversión de código exploratorio en código de producción compartido — su misión definitoria. Idealmente con revisión de la data scientist autora del preprocesado.

En esta lección hemos ganado dos mapas. El primero, vertical: los niveles de madurez MLOps — nivel 0 (todo manual, el modelo como fichero que alguien copia), nivel 1 (el pipeline de entrenamiento automatizado como entregable) y nivel 2 (CI/CD también para los propios pipelines, con la operación instrumentada) — junto con un método de autodiagnóstico honesto. El segundo, horizontal: los roles del equipo (data scientist, data engineer, ML engineer, plataforma y negocio) y la diferencia entre colaborar por relevos, donde la información se pierde en cada muro, y hacerlo con ownership compartido sobre artefactos comunes. Y hemos dejado a CineClick diagnosticado: nivel 0, sin ML engineer, con un modelo de churn atrapado en un notebook — y con este curso como plan para llevarlo al nivel 2.

Con los fundamentos completos, toca bajar del mapa al territorio. En la próxima lección conoceremos el proyecto del curso en detalle: el contexto de negocio del churn en CineClick, el dataset clientes_churn.csv columna a columna, el notebook inicial completo de la data scientist —con todos sus pecados—, y el stack de herramientas con el que lo transformaremos módulo a módulo.