El bucle de la lección anterior dejó a CineClick con un sistema que se vigila, se reentrena y se despliega con salvaguardas. Esta lección responde a las preguntas que ningún dashboard contesta: ¿por qué el sistema decidió lo que decidió sobre un cliente concreto? ¿Trata igual de bien a todos los segmentos? ¿Qué documentamos, cuánto tiempo guardamos qué, y qué espera de nosotros la regulación? La buena noticia — y la tesis de la lección — es que la gobernanza no es una capa de burocracia que se añade al final: el sistema que hemos construido durante seis módulos ya es auditable por diseño, y aquí solo vamos a hacerlo explícito, rellenar los huecos (model card, ADRs, análisis por subgrupos, política de privacidad de la tabla de predicciones) y situarlo en el mapa regulatorio con honestidad sobre sus límites.

1. Por qué la gobernanza no es burocracia
2. Trazabilidad extremo a extremo: el sistema ya es auditable
3. Model cards: la ficha del modelo
4. Datasheets for datasets, en breve
5. Documentar decisiones: ADRs ligeros
6. Equidad y sesgo: métricas por subgrupos
7. Privacidad en el sistema de CineClick
8. El marco regulatorio, en una pincelada honesta
9. Checklist de gobernanza

El modelo de churn decide sobre personas: a quién se le ofrece un descuento de retención y a quién no. Eso convierte en legítimas — y tarde o temprano en obligatorias — preguntas como: "¿por qué a este cliente se le ofreció la retención y a su vecino, con un perfil casi idéntico, no?". Puede preguntarlo el propio cliente, el equipo legal, un auditor o un regulador. Si la respuesta es "habría que ver qué modelo estaba desplegado entonces… creemos que el de marzo", el problema no es de papeleo: es que no controlas tu propio sistema.

La gobernanza es, simplemente, poder responder tres preguntas en minutos y con evidencia:

• ¿Qué pasó? — qué predicción se hizo, cuándo, con qué entrada.
• ¿Con qué? — qué modelo exacto, entrenado con qué datos y qué código.
• ¿Por qué está ahí? — quién aprobó ese modelo, con qué evidencia, siguiendo qué proceso.

Y la sorpresa agradable: casi todo eso ya existe en CineClick, porque las buenas prácticas de MLOps y los requisitos de auditoría son en gran medida la misma cosa vista desde dos oficinas distintas.

Hagamos el inventario explícito. Cada pregunta de auditoría tiene ya una respuesta con dirección concreta:

Léelo dos veces: no hemos añadido nada para auditoría. Versionar datos, trackear experimentos, exigir PRs de promoción y loguear cada predicción con su versión eran decisiones de ingeniería; la auditabilidad salió gratis. Esta es la lección profunda del apartado: la gobernanza barata se diseña, no se adjunta. El equipo que trabaja con notebooks sueltos y despliegues manuales no puede comprar esta tabla a posteriori a ningún precio.

Lo que sí falta son las piezas narrativas: los documentos que explican el sistema a quien no vive dentro de él. A eso vamos.

Una model card es la ficha técnica de un modelo: un documento corto y estandarizado que explica qué hace, con qué datos se construyó, cómo rinde (globalmente y por subgrupos), para qué NO sirve y qué consideraciones éticas plantea. La propuso Google en 2019 y se ha convertido en la pieza de documentación de modelos más extendida. Su público no es quien entrenó el modelo: es el compañero nuevo, el equipo legal, el auditor.

La model card completa del champion de CineClick, tal y como vive en docs/model-card-churn-v2.md:

Reglas de mantenimiento: la model card acompaña a la versión (v3 tendrá la suya, generada como parte del checklist de promoción de 05-02), se escribe en el repo (versionada con git, revisable en el PR), y la sección de limitaciones es la más valiosa — una model card sin limitaciones honestas es marketing, no documentación.

La idea hermana, propuesta por Gebru et al.: así como los componentes electrónicos vienen con su datasheet, cada dataset debería llevar la suya — motivación (por qué existe), composición (qué contiene, qué falta, qué sesgos de recogida tiene), proceso de recolección, usos recomendados y desaconsejados, y política de mantenimiento. Para CineClick, un docs/datasheet-clientes-churn.md de una página que documente el dataset de entrenamiento: origen de cada columna, el detalle de que las etiquetas de evaluación provienen del grupo de control, la ventana temporal cubierta y la advertencia de que la cohorte de la promo de primavera está infrarrepresentada antes de 2026-04. No lo desarrollamos completo: el patrón es el mismo que la model card, aplicado al dato.

Las decisiones importantes del sistema se tomaron a lo largo del curso: sombra obligatoria de dos semanas, banda de positivos 10–25%, reentrenamiento mensual, umbral PSI 0.25, ventana de 30 días. Dentro de un año, alguien preguntará "¿por qué dos semanas y no una?" — y la respuesta no puede vivir en la memoria del equipo.

Un ADR (Architecture Decision Record) ligero es un fichero markdown de media página: contexto, decisión, alternativas consideradas, consecuencias. El repo ya tiene el embrión del patrón (docs/promocion-modelo.md documenta el proceso de promoción); lo generalizamos con un directorio docs/decisiones/:

La convención: un ADR por decisión, numerados, inmutables (si la decisión cambia, se escribe otro ADR que "sustituye a ADR-007" — el historial de decisiones es tan valioso como la decisión vigente). El coste es de quince minutos por decisión; el retorno, cada vez que alguien nuevo pregunta "¿y esto por qué es así?".

Las métricas globales pueden esconder que el modelo funciona sistemáticamente peor para un segmento. En CineClick el efecto es tangible: un recall bajo en un subgrupo significa que sus clientes en riesgo no reciben la oferta de retención — el beneficio del sistema se reparte de forma desigual. El análisis es directo con sklearn sobre el test set versionado:

Salida ilustrativa para plan:

Cómo leerla sin engañarse:

• Compara recall entre grupos, pero mira siempre n y prevalencia: premium tiene menos clientes y menos churn — su recall es más ruidoso y su tarea es objetivamente más difícil (menos ejemplos positivos de los que aprender).
• tasa_positivos mide el reparto del "beneficio" (la oferta): si un grupo con prevalencia similar recibe sistemáticamente menos ofertas, hay un problema de equidad aunque el recall cuadre.

¿Y si un subgrupo sale sistemáticamente peor? El menú de respuestas, de menos a más intervención: (1) documentarlo en la model card (hecho: premium 0.58) y vigilarlo como panel del dashboard; (2) más datos o mejores features para ese segmento — a menudo el recall bajo de premium es falta de señal, no sesgo del algoritmo; (3) umbrales por segmento o reponderación en el entrenamiento — con un ADR, porque introduce trato diferenciado explícito que hay que poder justificar; (4) si el subgrupo se define por una característica protegida o su proxy, escalar a legal/compliance antes de tocar nada. Y una regla transversal: este análisis se ejecuta en cada evaluación de candidato (se añade al flow de 06-03), no una vez al año.

Repasemos el sistema con las gafas de protección de datos, porque varias decisiones que tomamos por ingeniería resultan ser también decisiones de privacidad:

• Minimización: el modelo no usa datos personales directos — ni nombre, ni email, ni dirección, ni datos de pago; solo id_cliente (un identificador interno) y features de comportamiento. La mejor manera de no filtrar un dato es no habérselo dado al sistema.
• El hash_entrada del log (04-02): la tabla de predicciones no guarda payloads crudos; el hash permite detectar duplicados y verificar integridad sin almacenar la entrada literal. Auditoría sin acumulación.
• Retención: la tabla de predicciones no puede crecer para siempre. CineClick define una política explícita — detalle completo (con features) durante 13 meses (cubre un ciclo anual de estacionalidad + margen de auditoría); después, agregados anónimos para series históricas del dashboard. La cifra exacta la fija legal; lo importante es que exista y esté automatizada (un job de purga, no una intención).
• Derecho de supresión y datos versionados — el punto delicado. Si un cliente ejerce su derecho de supresión, ¿qué pasa con los datasets inmutables de DVC donde aparece? Borrar una fila cambia el hash y rompe la reproducibilidad de todos los modelos entrenados con ese dataset. Las estrategias, en orden de preferencia:
  1. No versionar PII: si el dataset solo contiene id_cliente interno y comportamiento, la supresión se resuelve en la tabla maestra que mapea identidad↔id (que NO está en DVC). Es la estrategia de CineClick, y otra victoria de la minimización.
  2. Seudonimización antes de versionar: los datos entran a DVC ya seudonimizados; la clave del seudónimo vive fuera y borrarla desvincula a la persona de sus filas.
  3. Purga de raw + re-derivación: si hubiera que borrar de verdad, se elimina el dato del raw, se regenera el dataset (nuevo hash) y se documenta con un ADR que las versiones antiguas ya no son reproducibles y por qué. Reproducibilidad rota con causa justificada y rastro, en vez de silenciosamente.

Dos normas europeas enmarcan un sistema como el de CineClick. Pincelada, no tratado:

RGPD, artículo 22: las personas tienen derecho a no ser objeto de decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o les afecten significativamente de modo similar. ¿Ofrecer (o no) un descuento de retención cruza ese listón? Es discutible y depende del caso — pero fíjate en que el diseño de CineClick ya incorpora la salvaguarda natural: hay humanos en el bucle tanto en la promoción de modelos como en el diseño de la campaña (marketing decide la oferta sobre la lista priorizada; el modelo no ejecuta acciones sobre clientes por sí mismo, como declara la model card). La arquitectura que elegimos por prudencia operativa es también la que reduce el riesgo del artículo 22.

Reglamento europeo de IA (AI Act): clasifica los sistemas por riesgo (inaceptable / alto / limitado / mínimo) con obligaciones proporcionales. Un modelo de churn para campañas de retención apunta a riesgo limitado o mínimo — no está en las listas de alto riesgo (crédito, empleo, servicios esenciales…). Pero la observación valiosa es otra: los requisitos que el reglamento impone a los sistemas de alto riesgo — gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos (logging), supervisión humana, exactitud y robustez monitorizadas — son exactamente el contenido de este módulo. La tabla de trazabilidad, la model card, la tabla de predicciones, el humano en el bucle y la monitorización continua son esa lista. Construir con buenas prácticas de MLOps es, en gran medida, construir preparado para la regulación.

Advertencia importante: lo anterior es orientación técnica de ingeniería, no asesoramiento jurídico. La clasificación regulatoria de un sistema concreto, la aplicabilidad del artículo 22, los plazos de retención y las obligaciones exactas dependen del contexto de cada organización y deben ser determinados por sus profesionales de legal y compliance. El trabajo del ML engineer es construir un sistema capaz de cumplir — trazable, documentado, con supervisión humana — y llegar a esa conversación con las respuestas técnicas preparadas; la calificación jurídica no es suya.

La lección, condensada en una tabla que puedes llevarte a cualquier proyecto:

• Tratar la gobernanza como un sprint final antes de la auditoría. La trazabilidad de la tabla del apartado 2 no se puede reconstruir a posteriori: o el sistema la genera al operar, o no existe. Diséñala desde el módulo 2, como hicimos (aunque entonces no lo llamáramos gobernanza).
• Model cards escritas una vez y nunca actualizadas. Una model card de v1 describiendo a v3 es peor que ninguna: documenta con autoridad algo falso. Átala al proceso de promoción: sin model card actualizada, el PR no se aprueba.
• Análisis de equidad solo con métricas globales del subgrupo favorito. Define los subgrupos y los cortes antes de mirar los resultados, y repítelo en cada candidato — un modelo puede ser equitativo en v2 y dejar de serlo en v3.
• Confundir "no uso variables protegidas" con "no hay sesgo". Los proxies existen (plan y método de pago correlacionan con nivel socioeconómico). Por eso se mide el resultado por subgrupos en lugar de confiar en la ausencia de la variable.
• Guardar todo para siempre "por si acaso". La retención indefinida es un pasivo de privacidad y de coste. Política explícita, plazo justificado, purga automatizada.
• Escribir los ADRs solo cuando la decisión es polémica. Las decisiones "obvias" de hoy son los misterios de dentro de dos años. Si costó una discusión de más de diez minutos, merece ADR.
• Jugar a ser el abogado. Prepara la evidencia técnica impecable y lleva las preguntas regulatorias a legal/compliance. Las respuestas de ingeniería a preguntas jurídicas envejecen mal.

1. Simulacro de auditoría. Un auditor pregunta: "El 14 de abril de 2026, el cliente 88213 fue incluido en la campaña de retención. Justifiquen esa decisión: qué modelo la tomó, con qué entrada, qué evidencia había de que ese modelo era adecuado, y quién lo aprobó". Escribe la respuesta paso a paso citando, para cada elemento, el componente exacto del sistema donde está la evidencia (usa la tabla del apartado 2).

2. El subgrupo que empeora. En la evaluación de v3 (el challenger del reentrenamiento), el recall del tramo 0-6m de antigüedad cae de 0.61 a 0.44, mientras el global sube de 0.68 a 0.71. Con lo aprendido en este módulo: (a) da una hipótesis plausible de la causa relacionada con el escenario de la promo; (b) di qué harías con la promoción de v3; (c) indica qué documentos habría que tocar sea cual sea la decisión.

3. Supresión con DVC. CineClick decide, en un proyecto nuevo, versionar con DVC un dataset que incluye el email de los clientes "porque simplifica los joins". Escribe el párrafo de objeción que enviarías al PR, mencionando: el conflicto con el derecho de supresión, las dos estrategias preferibles y el coste de arreglarlo después.

1. (i) Qué predicción: fila del cliente 88213 en la tabla de predicciones con timestamp 2026-04-13/14, sus features de entrada, probabilidad ≥ 0.5 y grupo distinto de control — origen: el batch semanal scoring-semanal-churn del lunes 13. (ii) Qué modelo: el campo version_modelo de esa fila (v2); se contrasta con el historial de alias del registry, que confirma v2 = @champion en esa fecha. (iii) Adecuación del modelo: run de MLflow de v2 (recall 0.68 / precision 0.55 en el test congelado, sobre el criterio de negocio 0.60/0.50), tags de linaje hacia el dataset DVC exacto, model card v2 con métricas por subgrupos, y resultados de sus dos semanas de sombra y canary previos a la promoción. (iv) Quién aprobó: el PR de promoción de v2 (revisor identificado, checklist de docs/promocion-modelo.md completada) y la ejecución de promocionar_champion.py asociada. (v) La decisión final de incluirlo en la campaña: la lista priorizada fue entregada a marketing, que configuró la oferta — humano en el bucle documentado en la model card. Tiempo estimado de respuesta con el sistema actual: minutos.

2. (a) Hipótesis: v3 se entrenó con la ventana que incluye la cohorte de la promo — muchos clientes nuevos (0-6m) con etiquetas aún inmaduras o comportamiento atípico (aún no ha pasado su horizonte de 30 días, o su patrón de uso inicial no representa su comportamiento estable), de modo que el modelo aprendió señal ruidosa o directamente errónea para ese tramo; el global sube porque los tramos grandes mejoran. (b) No promocionar todavía: el criterio global se cumple, pero una caída de 17 puntos de recall en un segmento significa retirar de facto la retención a los clientes nuevos — decisión de negocio que no puede tomarse por omisión. Opciones: retrasar v3 hasta que las etiquetas de la cohorte maduren, reponderar/ajustar el corte de inclusión de la cohorte en el dataset, o promocionar con umbral por segmento — cualquiera de ellas con ADR y de acuerdo con producto. (c) Documentos: la evaluación por subgrupos adjunta al PR de promoción (que en este caso lo bloquea), un ADR con la decisión tomada y sus alternativas, y — si finalmente se promociona alguna variante — la model card de v3 con la limitación del tramo 0-6m descrita honestamente.

3. Párrafo tipo: "Objeción al versionado del email en DVC: los datasets DVC son inmutables por diseño (el hash es la identidad del dato), así que una futura solicitud de supresión nos obligaría a elegir entre incumplir el plazo o purgar el raw y re-derivar, rompiendo la reproducibilidad de todos los modelos entrenados con ese dataset y obligando a un ADR de excepción. Propongo: (1) hacer los joins con id_cliente interno y mantener el mapeo identidad↔id fuera de DVC, donde la supresión es un DELETE sin efectos sobre el versionado; o (2) si el email aporta señal (dominio, antigüedad), derivar esas features y versionar solo el derivado seudonimizado. Arreglarlo después costará purgar y re-derivar N versiones históricas, invalidar la comparabilidad de los modelos entrenados sobre ellas y documentar la excepción — todo evitable hoy con un cambio de una línea en el join."

La gobernanza ha resultado ser, sobre todo, un cambio de mirada: el sistema construido en seis módulos ya respondía a las preguntas de auditoría — tabla de predicciones, linaje en el registry, PRs de promoción — y esta lección lo ha hecho explícito y le ha añadido la capa narrativa y de responsabilidad: la model card de v2 con sus limitaciones honestas, la datasheet del dataset, los ADRs en docs/decisiones/, la evaluación por subgrupos dentro del flow de candidatos, la política de privacidad de la tabla de predicciones (minimización, hash, retención, supresión compatible con DVC) y el mapa regulatorio con su advertencia: la ingeniería prepara la evidencia; la calificación jurídica es de legal y compliance. La checklist de doce puntos condensa el módulo en algo transportable. Y con ella se cierra la construcción: no queda ninguna pieza más que añadir a la plataforma de CineClick. La última lección del curso no construye — integra: el mapa completo del sistema, un incidente de punta a punta que lo ejercita todo, y el proyecto con el que harás tuyo, en otro dominio, todo lo aprendido.