En el módulo anterior cerraste el loop técnico: monitoreas, detectas drift, reentrenas, validas y promueves con red. Un modelo vivo dando vueltas solo. Pero si trabajas donde importa de verdad —banca, salud, cualquier decisión que afecta a personas— falta la pregunta que un regulador, un comité de riesgo o un auditor te va a hacer tarde o temprano: “¿puedes demostrar por qué este modelo decidió esto, con qué datos se entrenó, y que no discrimina?”. Este módulo final trata de eso: lo que convierte tu pipeline técnico en una práctica de organización defendible. Y con él cerramos los doce módulos.

La tesis del módulo

Un modelo técnicamente impecable que no puedes auditar, explicar ni defender ante un regulador no está listo para producción en un banco. La gobernanza no es burocracia: es la diferencia entre “el modelo funciona” y “puedo demostrar por qué funciona, con qué se hizo, y que es justo”. La madurez de MLOps se mide en cuánto de eso está automatizado en vez de improvisado.

Model governance: lo que un auditor exige

Model governance (glosado: el conjunto de prácticas para que un modelo sea auditable, rastreable, reproducible, justo y conforme a la regulación — el “quién, qué, con qué y por qué” de cada modelo en producción). En un banco no es opcional: es requisito para que el modelo salga a producción. Se apoya en cinco pilares que ya construiste a lo largo del curso, ahora leídos desde la lente de “¿puedo defender esto?”:

Auditoría. Un registro de quién entrenó, aprobó y desplegó cada versión, y cuándo. Si un modelo tomó una decisión polémica, tienes la trazabilidad de cómo llegó a producción.
Linaje (lineage). De qué datos exactos salió este modelo. Se apoya en la reproducibilidad del módulo 2: versionar datos y código no era un capricho, era esto.
Reproducibilidad. Poder regenerar bit a bit el modelo que está en producción. Sin esto no puedes ni auditarlo ni arreglarlo.
Fairness / sesgo. Verificar que el modelo no discrimina sistemáticamente a un grupo. Es un problema real y estudiado; lo vimos en Problemas del mundo real. En crédito, un modelo que rechaza más a un grupo por su origen y no por su riesgo real es a la vez ilegal y dañino.
Compliance. Cumplir la regulación aplicable (protección de datos, derecho a explicación, normativa financiera). En banca, un modelo que no cumple no se despliega, por bueno que sea.

Model cards: la ficha del modelo

Un model card (glosado: una ficha estandarizada que documenta un modelo — para qué sirve, con qué datos se entrenó, qué tan bien funciona, en qué grupos, sus límites y sus riesgos conocidos). Es la etiqueta nutricional del modelo: lo que necesita saber cualquiera que vaya a usarlo o auditarlo, sin tener que leer el código. Una model card mínima honesta contiene:

Sección	Qué documenta
Propósito	Para qué decisión se creó y para cuál NO debe usarse
Datos	Con qué se entrenó, período, fuente, sesgos conocidos
Desempeño	Métricas globales y desagregadas por grupo
Límites	Dónde falla, casos fuera de alcance
Fairness	Chequeos de sesgo hechos y resultados
Versión y linaje	Versión, quién la aprobó, de qué datos salió

La fila que más pesa en banca es “desempeño desagregado por grupo”: un accuracy global del 90% puede esconder un 95% en un grupo y un 70% en otro. La model card obliga a mirar ese detalle en vez de esconderlo bajo el promedio.

Los niveles de madurez de MLOps

Niveles de madurez MLOps (glosado: un marco para ubicar cuán automatizada está la práctica de MLOps de una organización — a más nivel, menos trabajo manual y más partes del ciclo corren solas). El marco más citado es el de Google, con tres niveles:

 NIVEL 0           NIVEL 1           NIVEL 2
 manual            pipeline + CT     CI/CD del
                                     pipeline
 ┌───────────┐    ┌───────────┐    ┌───────────┐
 │ notebooks │    │ pipeline  │    │ cambias   │
 │ a mano    │    │ automát.  │    │ el código │
 │           ├──► │ se dispara├──► │ y CI/CD   │
 │ deploy    │    │ solo y    │    │ despliega │
 │ manual    │    │ reentrena │    │ el pipe-  │
 │           │    │ (CT)      │    │ line solo │
 └───────────┘    └───────────┘    └───────────┘
 se reentrena     el modelo se     hasta el
 cuando alguien   renueva solo;    pipeline se
 se acuerda       el pipeline no   actualiza solo

Nivel 0 — manual. Todo a mano: se entrena en un notebook, se despliega a mano, se reentrena cuando alguien se acuerda. Frágil y lento, pero es donde parte casi todo el mundo.
Nivel 1 — pipeline de ML automatizado. El entrenamiento es un pipeline reproducible (módulos 5 y 6) que se dispara solo —por calendario, por datos nuevos o por drift— y entrega un modelo nuevo validado: aquí entra el CT (Continuous Training), con validación de datos y de modelo automáticas. Lo que sigue siendo manual es desplegar una versión nueva del pipeline cuando cambia su código.
Nivel 2 — CI/CD del pipeline. Se suma CI/CD sobre el pipeline mismo: cuando el equipo cambia el código (una feature nueva, otro algoritmo), ese pipeline se testea, se empaqueta y se despliega solo, y recién ahí corre el CT. Es lo que permite probar ideas nuevas en producción muchas veces por semana sin romper nada: el loop del módulo 11 corriendo sin manos, incluidos sus propios cambios.

Para saber en qué nivel está una organización, la pregunta honesta es simple: ¿cuánto del ciclo pasa sin que un humano tenga que acordarse de hacerlo? Si el reentrenamiento depende de que alguien recuerde correr un notebook, estás en nivel 0 por más herramientas que tengas alrededor. No hay que avergonzarse del nivel 0 — hay que saber que se está ahí y tener un plan para subir.

Subir de nivel no es un fin en sí mismo. Un side project con dos usuarios no necesita CI/CD/CT completo; automatizar de más es tan caro como automatizar de menos. El nivel correcto es el que el riesgo y el volumen del modelo justifican. En banca, con decisiones que afectan a personas, el nivel 2 se paga solo; en un experimento personal, sería sobreingeniería.

El checklist de MLOps del curso

Condensado de los doce módulos, para tener a mano antes de decir “este modelo está listo”:

Fin del curso

Doce módulos: del “¿por qué un modelo se pudre solo?” a operar el ciclo de vida completo de un modelo en producción, con gobernanza defendible ante un auditor. El mapa de los tres bloques que recorrimos:

 BLOQUE BÁSICO       BLOQUE INTERM.      BLOQUE AVANZADO
 el ciclo y la       ponerlo a           mantenerlo
 trazabilidad        producir            vivo
 ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
 │ qué es MLOps │   │ pipelines    │   │ serving      │
 │ reproducir   ├─► │ feature      ├─► │ monitoreo    │
 │ tracking     │   │  stores      │   │ drift        │
 │ registry     │   │ CI/CD/CT     │   │ reentrenar   │
 └──────────────┘   └──────────────┘   └──────────────┘
   sabes qué          lo haces            no lo dejas
   tienes y por qué   correr solo         morir en silencio

La progresión completa: aprendes a rastrear y reproducir un modelo, lo llevas a producir como pipeline automatizado, y lo mantienes vivo vigilándolo y reentrenándolo cuando el mundo cambia. Ese era el contrato del módulo 1 —tomar el modelo del notebook y mantenerlo vivo— y está cumplido.

Si completaste los doce módulos con tu cuenta de la academia, el certificado es tuyo. El glosario de MLOps queda como referencia permanente para cuando necesites repasar un término.

Errores comunes

Tratar la gobernanza como papeleo del final. Auditoría, linaje y fairness se construyen desde el módulo 2 (versionar datos), no se improvisan cuando el auditor toca la puerta.
Reportar solo el accuracy global. Un promedio bonito esconde grupos donde el modelo falla feo. La model card obliga a desagregar por grupo.
Confundir “nivel de madurez alto” con “mejor”. El nivel correcto lo fija el riesgo y el volumen. Automatizar de más es tan caro como automatizar de menos.
Desplegar en banca sin chequeo de fairness ni compliance. Un modelo que discrimina o que incumple la regulación no se despliega, por bueno que sea su F1.
No tener model card. Si nadie puede saber para qué sirve el modelo, con qué se entrenó y dónde falla sin leer el código, el modelo es una caja negra indefendible.

La frase para llevarse

“Un modelo listo para producción no es el que tiene mejor accuracy, sino el que puedes reproducir, explicar, auditar y defender como justo. La madurez de MLOps se mide en cuánto de eso corre solo — y cuánto todavía depende de que alguien se acuerde.”

Qué viene: fin del curso

Aquí termina el Curso de MLOps. Los puentes con el resto de la Academia, porque MLOps no vive aislado: los modelos que operas aquí nacen en Del notebook a producción; la infraestructura, el CI/CD y el rollout que reusaste vienen de Rollout y confiabilidad; y cuando lo que operas es un agente sobre un LLM ajeno en vez de un modelo propio, evaluarlo es el terreno de Evaluación de agentes. MLOps complementa a Deploy de Agentes; no lo repite. Juntos cubren las dos formas de llevar IA a producción: el modelo que entrenas tú y la app que consume el modelo de otro.

MLOps — Módulo 12: gobernanza y madurez — el MLOps de una organización