El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
HOME Els meus cursos Finalitzats
◄ Anterior
◄

Governança, documentació i compliment

Següent ►
►

El bucle de la lliçó anterior va deixar CineClick amb un sistema que es vigila, es reentrena i es desplega amb salvaguardes. Aquesta lliçó respon a les preguntes que cap dashboard no contesta: per què el sistema va decidir el que va decidir sobre un client concret? Tracta igual de bé tots els segments? Què documentem, quant de temps guardem què, i què espera de nosaltres la regulació? La bona notícia — i la tesi de la lliçó — és que la governança no és una capa de burocràcia que s'afegeix al final: el sistema que hem construït durant sis mòduls ja és auditable per disseny, i aquí només ho farem explícit, omplirem els buits (model card, ADRs, anàlisi per subgrups, política de privadesa de la taula de prediccions) i el situarem al mapa regulatori amb honestedat sobre els seus límits.

Contingut

  1. Per què la governança no és burocràcia
  2. Traçabilitat d'extrem a extrem: el sistema ja és auditable
  3. Model cards: la fitxa del model
  4. Datasheets for datasets, en breu
  5. Documentar decisions: ADRs lleugers
  6. Equitat i biaix: mètriques per subgrups
  7. Privadesa al sistema de CineClick
  8. El marc regulatori, en una pinzellada honesta
  9. Checklist de governança

Per què la governança no és burocràcia

El model de churn decideix sobre persones: a qui se li ofereix un descompte de retenció i a qui no. Això converteix en legítimes — i tard o d'hora en obligatòries — preguntes com: "per què a aquest client se li va oferir la retenció i al seu veí, amb un perfil gairebé idèntic, no?". Ho pot preguntar el mateix client, l'equip legal, un auditor o un regulador. Si la resposta és "caldria veure quin model estava desplegat llavors… creiem que el del març", el problema no és de paperassa: és que no controles el teu propi sistema.

La governança és, simplement, poder respondre tres preguntes en minuts i amb evidència:

  • Què va passar? — quina predicció es va fer, quan, amb quina entrada.
  • Amb què? — quin model exacte, entrenat amb quines dades i quin codi.
  • Per què és allà? — qui va aprovar aquest model, amb quina evidència, seguint quin procés.

I la sorpresa agradable: gairebé tot això ja existeix a CineClick, perquè les bones pràctiques de MLOps i els requisits d'auditoria són en gran manera la mateixa cosa vista des de dues oficines diferents.

Traçabilitat d'extrem a extrem: el sistema ja és auditable

Fem l'inventari explícit. Cada pregunta d'auditoria té ja una resposta amb adreça concreta:

Pregunta d'auditoria On és la resposta Construït a
Quina predicció va rebre el client X el dia D? Taula de prediccions: timestamp, features, probabilitat, versio_model, grup 06-01
Quin model servia aquell dia? versio_model a cada fila del log + historial d'alias del registry 04-02, 03-02
Amb quines dades exactes es va entrenar aquell model? Tag dades_dvc_md5 al registry → dvc pull d'aquella versió al remote magatzem 06-03, 02-03
Amb quin codi? El run de MLflow guarda el commit de git; la imatge ghcr.io/cineclick/churn-api està etiquetada per versió 03-01, 04-03
Quines mètriques tenia i com es van comparar amb l'anterior? Run de MLflow (experiment churn-cineclick) + avaluació doble del flow de reentrenament 03-01, 06-03
Qui va aprovar posar-lo en producció i amb quina evidència? PR de promoció (revisor, discussió, checklist de docs/promocio-model.md) + resultats d'ombra i canary 05-02, 05-04
Es va comportar bé després del desplegament? Dashboard 06-01, mètriques reals setmanals, historial d'alertes a #alertes-ml 06-01
Per què es va reentrenar en tal data? motiu i flow_run del flow reentrenament-churn + tags de llinatge 06-03

Llegeix-ho dues vegades: no hem afegit res per a l'auditoria. Versionar dades, trackejar experiments, exigir PRs de promoció i loguejar cada predicció amb la seva versió eren decisions d'enginyeria; l'auditabilitat va sortir de franc. Aquesta és la lliçó profunda de l'apartat: la governança barata es dissenya, no s'adjunta. L'equip que treballa amb notebooks solts i desplegaments manuals no pot comprar aquesta taula a posteriori a cap preu.

El que sí que falta són les peces narratives: els documents que expliquen el sistema a qui no hi viu a dins. Cap allà anem.

Model cards: la fitxa del model

Una model card és la fitxa tècnica d'un model: un document curt i estandarditzat que explica què fa, amb quines dades es va construir, com rendeix (globalment i per subgrups), per a què NO serveix i quines consideracions ètiques planteja. La va proposar Google el 2019 i s'ha convertit en la peça de documentació de models més estesa. El seu públic no és qui va entrenar el model: és el company nou, l'equip legal, l'auditor.

La model card completa del champion de CineClick, tal com viu a docs/model-card-churn-v2.md:

# Model Card: churn-cineclick v2 (@champion)

## Detalls del model
- **Model**: RandomForestClassifier (n_estimators=300, max_depth=20,
  class_weight="balanced"). Registry: `churn-cineclick` v2, alias @champion.
- **Data d'entrenament / promoció**: 2026-05 / 2026-06 (PR #241).
- **Responsables**: equip ML CineClick (Laura, DS; ML engineering).
- **Llinatge**: run MLflow a l'experiment `churn-cineclick`; dades
  `dades_dvc_md5: a3f9…`; codi al commit `git: 7c21…`.

## Ús previst
- **Propòsit**: estimar la probabilitat de baixa d'un subscriptor en els
  propers 30 dies, per prioritzar la campanya setmanal de retenció.
- **Usuaris**: equip de màrqueting (batch setmanal) i sistemes interns (API).
- **Decisió final**: l'oferta de retenció la configura màrqueting sobre la
  llista prioritzada; el model NO executa accions sobre clients per si mateix.
- **Fora d'abast**: decisions de preu individualitzat, denegació de
  servei, scoring creditici o qualsevol ús amb efecte jurídic sobre el
  client. No validat per a mercats fora de l'actual.

## Dades d'entrenament
- Dataset derivat del mestre de clients i taules d'esdeveniments, amb tall
  point-in-time (features anteriors al tall; etiqueta = baixa en 30 dies).
- Features: antiguitat_mesos, hores_setmana, tiquets_suport, pla,
  metode_pagament, descompte_actiu, ratio_tickets. Sense dades personals
  directes (vegeu Privadesa).
- Prevalença de churn ~15%. Etiquetes d'avaluació preses del grup de
  control permanent (no intervingut per la campanya).

## Mètriques
- **Globals (test congelat)**: accuracy 0.842, precision 0.55,
  recall 0.68, F1 0.61. Llindar operatiu 0.5 (env LLINDAR_ABANDONAMENT).
- **Criteri d'acceptació (negoci)**: recall >= 0.60 i precision >= 0.50.
- **Per subgrups**: vegeu la taula a docs/ (recall per pla: basic 0.71,
  estandard 0.67, premium 0.58; vegeu Limitacions).
- **En producció**: recall/precision reals setmanals al dashboard de
  monitoratge; referència offline 0.68/0.55.

## Limitacions
- Rendiment inferior al segment premium (recall 0.58) i en clients
  amb antiguitat < 3 mesos (poca història per a les features agregades).
- No modela estacionalitat ni esdeveniments de catàleg (estrenes, pujades
  de preu): la deriva de concepte associada requereix reentrenament.
- Probabilitats no calibrades finament: útils per ordenar i llindar,
  no com a probabilitat exacta de baixa.

## Consideracions ètiques
- Efecte de la decisió: rebre o no una oferta de descompte. Risc
  principal: distribució sistemàticament desigual d'ofertes entre
  segments (vegeu anàlisi per subgrups i revisió trimestral).
- Sense variables protegides com a entrada; no es descarta proxy indirecte
  (p. ex. pla com a correlat socioeconòmic) — vigilat per subgrups.
- Humà al bucle en la promoció de models i en el disseny de la campanya.

Regles de manteniment: la model card acompanya la versió (v3 tindrà la seva, generada com a part de la checklist de promoció de 05-02), s'escriu al repo (versionada amb git, revisable al PR), i la secció de limitacions és la més valuosa — una model card sense limitacions honestes és màrqueting, no documentació.

Datasheets for datasets, en breu

La idea germana, proposada per Gebru et al.: així com els components electrònics venen amb la seva datasheet, cada dataset hauria de portar la seva — motivació (per què existeix), composició (què conté, què hi falta, quins biaixos de recollida té), procés de recollida, usos recomanats i desaconsellats, i política de manteniment. Per a CineClick, un docs/datasheet-clients-churn.md d'una pàgina que documenti el dataset d'entrenament: origen de cada columna, el detall que les etiquetes d'avaluació provenen del grup de control, la finestra temporal coberta i l'advertència que la cohort de la promo de primavera està infrarepresentada abans del 2026-04. No el desenvolupem complet: el patró és el mateix que la model card, aplicat a la dada.

Documentar decisions: ADRs lleugers

Les decisions importants del sistema es van prendre al llarg del curs: ombra obligatòria de dues setmanes, banda de positius 10–25%, reentrenament mensual, llindar PSI 0.25, finestra de 30 dies. D'aquí a un any, algú preguntarà "per què dues setmanes i no una?" — i la resposta no pot viure a la memòria de l'equip.

Un ADR (Architecture Decision Record) lleuger és un fitxer markdown de mitja pàgina: context, decisió, alternatives considerades, conseqüències. El repo ja té l'embrió del patró (docs/promocio-model.md documenta el procés de promoció); el generalitzem amb un directori docs/decisions/:

# ADR-007: Finestra d'ombra de 2 setmanes per a tot challenger

- **Data**: 2026-06 · **Estat**: acceptada · **Decideix**: equip ML + producte

## Context
Després de l'incident del canary de v2 (05-04) es va acordar exigir una
fase d'ombra a tot challenger. Cal fixar-ne la durada.

## Decisió
2 setmanes naturals, sense excepció, incloent-hi models de reentrenament
rutinari.

## Alternatives considerades
- 1 setmana: no cobreix dos cicles complets del patró setmanal d'ús
  (cap de setmana + laborables x2) ni deixa acumular prou volum
  per segment petit (premium).
- Variable segons el canvi: introdueix judici cas a cas just on
  volem una regla no negociable.

## Conseqüències
Cada promoció triga >= 2 setmanes des del registre del challenger.
Assumit: el churn no exigeix reacció en dies. Revisar si mai
necessitem un hotfix de model (procediment d'excepció: no existeix
a propòsit; vegeu ADR-008 si es crea).

La convenció: un ADR per decisió, numerats, immutables (si la decisió canvia, s'escriu un altre ADR que "substitueix ADR-007" — l'historial de decisions és tan valuós com la decisió vigent). El cost és de quinze minuts per decisió; el retorn, cada vegada que algú nou pregunta "i això per què és així?".

Equitat i biaix: mètriques per subgrups

Les mètriques globals poden amagar que el model funciona sistemàticament pitjor per a un segment. A CineClick l'efecte és tangible: un recall baix en un subgrup significa que els seus clients en risc no reben l'oferta de retenció — el benefici del sistema es reparteix de manera desigual. L'anàlisi és directa amb sklearn sobre el test set versionat:

# scripts/avaluar_subgrups.py
import pandas as pd
import mlflow
from sklearn.metrics import recall_score, precision_score

test = pd.read_csv("data/processed/test.csv")
model = mlflow.sklearn.load_model("models:/churn-cineclick@champion")

X = test.drop(columns=["abandonament"])
test["prediccio"] = (model.predict_proba(X)[:, 1] >= 0.5).astype(int)

def metriques_per_subgrup(df: pd.DataFrame, columna: str) -> pd.DataFrame:
    files = []
    for valor, g in df.groupby(columna):
        files.append({
            columna: valor,
            "n": len(g),
            "prevalenca": g["abandonament"].mean(),      # churn real del grup
            "recall": recall_score(g["abandonament"], g["prediccio"], zero_division=0),
            "precision": precision_score(g["abandonament"], g["prediccio"], zero_division=0),
            "taxa_positius": g["prediccio"].mean(),      # % marcat en risc
        })
    return pd.DataFrame(files).round(3)

print(metriques_per_subgrup(test, "pla"))

# Segments d'antiguitat: els talls es defineixen ABANS de mirar resultats.
test["tram_antiguitat"] = pd.cut(test["antiguitat_mesos"], bins=[0, 6, 24, 999],
                                 labels=["0-6m", "6-24m", ">24m"])
print(metriques_per_subgrup(test, "tram_antiguitat"))

Sortida il·lustrativa per a pla:

pla n prevalenca recall precision taxa_positius
basic 1240 0.19 0.71 0.56 0.24
estandard 1410 0.14 0.67 0.55 0.17
premium 610 0.09 0.58 0.49 0.11

Com llegir-la sense enganyar-se:

  • Compara el recall entre grups, però mira sempre n i prevalenca: premium té menys clients i menys churn — el seu recall és més sorollós i la seva tasca és objectivament més difícil (menys exemples positius dels quals aprendre).
  • taxa_positius mesura el repartiment del "benefici" (l'oferta): si un grup amb prevalença similar rep sistemàticament menys ofertes, hi ha un problema d'equitat encara que el recall quadri.

I si un subgrup surt sistemàticament pitjor? El menú de respostes, de menys a més intervenció: (1) documentar-ho a la model card (fet: premium 0.58) i vigilar-ho com a panell del dashboard; (2) més dades o millors features per a aquest segment — sovint el recall baix de premium és falta de senyal, no biaix de l'algorisme; (3) llindars per segment o reponderació a l'entrenament — amb un ADR, perquè introdueix tracte diferenciat explícit que cal poder justificar; (4) si el subgrup es defineix per una característica protegida o el seu proxy, escalar a legal/compliance abans de tocar res. I una regla transversal: aquesta anàlisi s'executa a cada avaluació de candidat (s'afegeix al flow de 06-03), no una vegada l'any.

Privadesa al sistema de CineClick

Repassem el sistema amb les ulleres de protecció de dades, perquè diverses decisions que vam prendre per enginyeria resulten ser també decisions de privadesa:

  • Minimització: el model no fa servir dades personals directes — ni nom, ni email, ni adreça, ni dades de pagament; només id_client (un identificador intern) i features de comportament. La millor manera de no filtrar una dada és no haver-l'hi donat al sistema.
  • El hash_entrada del log (04-02): la taula de prediccions no guarda payloads crus; el hash permet detectar duplicats i verificar integritat sense emmagatzemar l'entrada literal. Auditoria sense acumulació.
  • Retenció: la taula de prediccions no pot créixer per sempre. CineClick defineix una política explícita — detall complet (amb features) durant 13 mesos (cobreix un cicle anual d'estacionalitat + marge d'auditoria); després, agregats anònims per a sèries històriques del dashboard. La xifra exacta la fixa legal; l'important és que existeixi i estigui automatitzada (un job de purga, no una intenció).
  • Dret de supressió i dades versionades — el punt delicat. Si un client exerceix el seu dret de supressió, què passa amb els datasets immutables de DVC on apareix? Esborrar una fila canvia el hash i trenca la reproduïbilitat de tots els models entrenats amb aquell dataset. Les estratègies, en ordre de preferència:
    1. No versionar PII: si el dataset només conté id_client intern i comportament, la supressió es resol a la taula mestra que mapeja identitat↔id (que NO és a DVC). És l'estratègia de CineClick, i una altra victòria de la minimització.
    2. Pseudonimització abans de versionar: les dades entren a DVC ja pseudonimitzades; la clau del pseudònim viu fora i esborrar-la desvincula la persona de les seves files.
    3. Purga del raw + re-derivació: si calgués esborrar de debò, s'elimina la dada del raw, es regenera el dataset (hash nou) i es documenta amb un ADR que les versions antigues ja no són reproduïbles i per què. Reproduïbilitat trencada amb causa justificada i rastre, en lloc de silenciosament.

El marc regulatori, en una pinzellada honesta

Dues normes europees emmarquen un sistema com el de CineClick. Pinzellada, no tractat:

RGPD, article 22: les persones tenen dret a no ser objecte de decisions basades únicament en tractament automatitzat que produeixin efectes jurídics o els afectin significativament de manera similar. Oferir (o no) un descompte de retenció creua aquest llistó? És discutible i depèn del cas — però fixa't que el disseny de CineClick ja incorpora la salvaguarda natural: hi ha humans al bucle tant en la promoció de models com en el disseny de la campanya (màrqueting decideix l'oferta sobre la llista prioritzada; el model no executa accions sobre clients per si mateix, com declara la model card). L'arquitectura que vam triar per prudència operativa és també la que redueix el risc de l'article 22.

Reglament europeu d'IA (AI Act): classifica els sistemes per risc (inacceptable / alt / limitat / mínim) amb obligacions proporcionals. Un model de churn per a campanyes de retenció apunta a risc limitat o mínim — no és a les llistes d'alt risc (crèdit, ocupació, serveis essencials…). Però l'observació valuosa és una altra: els requisits que el reglament imposa als sistemes d'alt risc — gestió de riscos, governança de dades, documentació tècnica, registre d'esdeveniments (logging), supervisió humana, exactitud i robustesa monitorades — són exactament el contingut d'aquest mòdul. La taula de traçabilitat, la model card, la taula de prediccions, l'humà al bucle i el monitoratge continu són aquesta llista. Construir amb bones pràctiques de MLOps és, en gran manera, construir preparat per a la regulació.

Advertència important: tot això anterior és orientació tècnica d'enginyeria, no assessorament jurídic. La classificació regulatòria d'un sistema concret, l'aplicabilitat de l'article 22, els terminis de retenció i les obligacions exactes depenen del context de cada organització i han de ser determinats pels seus professionals de legal i compliance. La feina de l'ML engineer és construir un sistema capaç de complir — traçable, documentat, amb supervisió humana — i arribar a aquesta conversa amb les respostes tècniques preparades; la qualificació jurídica no és seva.

Checklist de governança

La lliçó, condensada en una taula que et pots emportar a qualsevol projecte:

# Ítem A CineClick Estat
1 Cada predicció registrada amb versió de model, features i timestamp Taula de prediccions (06-01) Fet
2 Cada versió de model traçable a dades (hash), codi (commit) i run Tags de llinatge al registry (06-03) Fet
3 Promocions amb aprovació humana documentada i evidència PR de promoció + ombra/canary (05-02, 05-04) Fet
4 Model card per versió de champion, amb limitacions honestes docs/model-card-churn-v2.md Fet
5 Datasheet del dataset d'entrenament docs/datasheet-clients-churn.md Fet
6 Decisions de disseny registrades com a ADRs docs/decisions/ Fet
7 Avaluació per subgrups a cada candidat, amb llindar d'escalat avaluar_subgrups.py al flow (06-03) Fet
8 Minimització: sense PII a features ni a logs (hash, ids interns) Disseny de 04-02 + datasets sense PII Fet
9 Política de retenció de prediccions, automatitzada Job de purga 13 mesos → agregats Fet
10 Procediment de supressió compatible amb dades versionades Estratègia "sense PII a DVC" + ADR d'excepcions Fet
11 Classificació regulatòria revisada amb legal/compliance Reunió anual + en canviar l'ús del model Pendent de calendari
12 Revisió periòdica d'aquesta checklist Trimestral, juntament amb l'anàlisi de subgrups Fet

Errors Comuns i Consells

  • Tractar la governança com un esprint final abans de l'auditoria. La traçabilitat de la taula de l'apartat 2 no es pot reconstruir a posteriori: o el sistema la genera en operar, o no existeix. Dissenya-la des del mòdul 2, com vam fer (encara que llavors no en diguéssim governança).
  • Model cards escrites una vegada i mai actualitzades. Una model card de v1 descrivint v3 és pitjor que cap: documenta amb autoritat una cosa falsa. Lliga-la al procés de promoció: sense model card actualitzada, el PR no s'aprova.
  • Anàlisi d'equitat només amb mètriques globals del subgrup favorit. Defineix els subgrups i els talls abans de mirar els resultats, i repeteix-ho a cada candidat — un model pot ser equitatiu a v2 i deixar de ser-ho a v3.
  • Confondre "no faig servir variables protegides" amb "no hi ha biaix". Els proxies existeixen (pla i mètode de pagament correlacionen amb nivell socioeconòmic). Per això es mesura el resultat per subgrups en lloc de confiar en l'absència de la variable.
  • Guardar-ho tot per sempre "per si de cas". La retenció indefinida és un passiu de privadesa i de cost. Política explícita, termini justificat, purga automatitzada.
  • Escriure els ADRs només quan la decisió és polèmica. Les decisions "òbvies" d'avui són els misteris de d'aquí a dos anys. Si va costar una discussió de més de deu minuts, mereix ADR.
  • Jugar a fer d'advocat. Prepara l'evidència tècnica impecable i porta les preguntes regulatòries a legal/compliance. Les respostes d'enginyeria a preguntes jurídiques envelleixen malament.

Exercicis

  1. Simulacre d'auditoria. Un auditor pregunta: "El 14 d'abril de 2026, el client 88213 va ser inclòs a la campanya de retenció. Justifiquin aquesta decisió: quin model la va prendre, amb quina entrada, quina evidència hi havia que aquell model era adequat, i qui el va aprovar". Escriu la resposta pas a pas citant, per a cada element, el component exacte del sistema on hi ha l'evidència (fes servir la taula de l'apartat 2).

  2. El subgrup que empitjora. A l'avaluació de v3 (el challenger del reentrenament), el recall del tram 0-6m d'antiguitat cau de 0.61 a 0.44, mentre el global puja de 0.68 a 0.71. Amb el que has après en aquest mòdul: (a) dona una hipòtesi plausible de la causa relacionada amb l'escenari de la promo; (b) digues què faries amb la promoció de v3; (c) indica quins documents caldria tocar sigui quina sigui la decisió.

  3. Supressió amb DVC. CineClick decideix, en un projecte nou, versionar amb DVC un dataset que inclou l'email dels clients "perquè simplifica els joins". Escriu el paràgraf d'objecció que enviaries al PR, mencionant: el conflicte amb el dret de supressió, les dues estratègies preferibles i el cost d'arreglar-ho després.

Solucions

  1. (i) Quina predicció: fila del client 88213 a la taula de prediccions amb timestamp 2026-04-13/14, les seves features d'entrada, probabilitat ≥ 0.5 i grup diferent de control — origen: el batch setmanal scoring-setmanal-churn del dilluns 13. (ii) Quin model: el camp versio_model d'aquella fila (v2); es contrasta amb l'historial d'alias del registry, que confirma v2 = @champion en aquella data. (iii) Adequació del model: run de MLflow de v2 (recall 0.68 / precision 0.55 al test congelat, sobre el criteri de negoci 0.60/0.50), tags de llinatge cap al dataset DVC exacte, model card v2 amb mètriques per subgrups, i resultats de les seves dues setmanes d'ombra i canary previs a la promoció. (iv) Qui va aprovar: el PR de promoció de v2 (revisor identificat, checklist de docs/promocio-model.md completada) i l'execució de promocionar_champion.py associada. (v) La decisió final d'incloure'l a la campanya: la llista prioritzada va ser lliurada a màrqueting, que va configurar l'oferta — humà al bucle documentat a la model card. Temps estimat de resposta amb el sistema actual: minuts.

  2. (a) Hipòtesi: v3 es va entrenar amb la finestra que inclou la cohort de la promo — molts clients nous (0-6m) amb etiquetes encara immadures o comportament atípic (encara no ha passat el seu horitzó de 30 dies, o el seu patró d'ús inicial no representa el seu comportament estable), de manera que el model va aprendre senyal sorollós o directament erroni per a aquest tram; el global puja perquè els trams grans milloren. (b) No promocionar encara: el criteri global es compleix, però una caiguda de 17 punts de recall en un segment significa retirar de facto la retenció als clients nous — decisió de negoci que no es pot prendre per omissió. Opcions: endarrerir v3 fins que les etiquetes de la cohort madurin, reponderar/ajustar el tall d'inclusió de la cohort al dataset, o promocionar amb llindar per segment — qualsevol d'elles amb ADR i d'acord amb producte. (c) Documents: l'avaluació per subgrups adjunta al PR de promoció (que en aquest cas el bloqueja), un ADR amb la decisió presa i les seves alternatives, i — si finalment es promociona alguna variant — la model card de v3 amb la limitació del tram 0-6m descrita honestament.

  3. Paràgraf tipus: "Objecció al versionat de l'email a DVC: els datasets DVC són immutables per disseny (el hash és la identitat de la dada), així que una futura sol·licitud de supressió ens obligaria a triar entre incomplir el termini o purgar el raw i re-derivar, trencant la reproduïbilitat de tots els models entrenats amb aquell dataset i obligant a un ADR d'excepció. Proposo: (1) fer els joins amb l'id_client intern i mantenir el mapatge identitat↔id fora de DVC, on la supressió és un DELETE sense efectes sobre el versionat; o (2) si l'email aporta senyal (domini, antiguitat), derivar aquestes features i versionar només el derivat pseudonimitzat. Arreglar-ho després costarà purgar i re-derivar N versions històriques, invalidar la comparabilitat dels models entrenats sobre elles i documentar l'excepció — tot evitable avui amb un canvi d'una línia al join."

Conclusió

La governança ha resultat ser, sobretot, un canvi de mirada: el sistema construït en sis mòduls ja responia a les preguntes d'auditoria — taula de prediccions, llinatge al registry, PRs de promoció — i aquesta lliçó ho ha fet explícit i hi ha afegit la capa narrativa i de responsabilitat: la model card de v2 amb les seves limitacions honestes, la datasheet del dataset, els ADRs a docs/decisions/, l'avaluació per subgrups dins del flow de candidats, la política de privadesa de la taula de prediccions (minimització, hash, retenció, supressió compatible amb DVC) i el mapa regulatori amb la seva advertència: l'enginyeria prepara l'evidència; la qualificació jurídica és de legal i compliance. La checklist de dotze punts condensa el mòdul en una cosa transportable. I amb ella es tanca la construcció: no queda cap peça més per afegir a la plataforma de CineClick. L'última lliçó del curs no construeix — integra: el mapa complet del sistema, un incident de punta a punta que ho exercita tot, i el projecte amb què faràs teu, en un altre domini, tot el que has après.

◄ Anterior
◄
Següent ►
►
El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
© Copyright 2026. Tots els drets reservats