El model de churn de MercaFresh ja funciona, se serveix i es monitora. Però hi ha una pregunta que la latència i l'AUC no responen: és just? El model decideix quins clients reben descomptes de retenció i quins no, fent servir dades personals de compra. Cada decisió automatitzada sobre persones reals porta amb si qüestions de biaix, equitat, transparència, privadesa i seguretat — i, cada vegada més, obligacions legals. En aquesta lliçó aprendràs d'on venen els biaixos, com auditar un model per grups amb les mètriques que ja domines, què exigeix la transparència, quins principis regeixen la privadesa de les dades i com condensar-ho tot en un checklist pràctic per al projecte de churn.

Advertència important: aquesta lliçó presenta principis generals amb finalitats formatives i no és assessorament legal. Les implicacions regulatòries (RGPD, normativa d'IA, legislació sectorial) de qualsevol sistema real s'han de revisar sempre amb un professional legal o de compliance abans de la seva posada en producció. Totes les dades i situacions de MercaFresh són fictícies.

1. Per què l'ètica no és un apèndix del projecte
2. Biaixos: d'on venen
3. Variables proxy: el cas del codi postal
4. Auditar l'equitat: mètriques per grups
5. Transparència i explicabilitat
6. Privadesa: minimització, anonimització i els seus límits
7. RGPD: principis que un equip de ML ha de conèixer
8. Seguretat del model
9. Checklist ètic per al projecte de churn

Un reflex habitual és tractar l'ètica com un tràmit final: "el model funciona; ara, el capítol d'ètica". És un error per tres raons pràctiques:

• Els problemes ètics són problemes tècnics amb conseqüències humanes. Un biaix és, al capdavall, un error de generalització (mòdul 6) que afecta sistemàticament un grup de persones. S'analitza amb les mateixes eines: dades, mètriques, validació.
• S'originen al principi, no al final. El biaix entra amb les dades (mòdul 3) i amb les decisions de disseny; quan el model és en producció, corregir-lo costa deu vegades més.
• Tenen cost de negoci i legal. Una campanya de retenció sistemàticament injusta danya la confiança i la marca; un tractament il·legal de dades comporta sancions serioses.

A MercaFresh el model decideix una cosa aparentment innòcua — a qui oferir un descompte —. Però "innòcua" mereix examen: si el model ofereix sistemàticament pitjors condicions a un col·lectiu, el supermercat està discriminant a escala, amb l'eficiència d'una màquina.

Un model no és neutral pel fet de ser matemàtic: aprèn el que hi ha a les dades, i les dades són un registre del món — amb les seves desigualtats incloses. Les fonts principals:

La lliçó transversal: el biaix rarament entra per mala intenció; entra per defecte, amb les dades de sempre i el procés de sempre, llevat que algú el busqui activament.

La resposta ingènua al biaix és "no facis servir variables sensibles": treu gènere, edat, nacionalitat, i el model serà neutre. No funciona, per les variables proxy: variables correlacionades amb l'atribut sensible que permeten al model reconstruir-lo de facto.

L'exemple canònic és el codi postal. Al model de churn de MercaFresh sembla una variable logística innocent ("des d'on fa la comanda?"). Però el codi postal correlaciona fortament amb el nivell socioeconòmic, i sovint amb l'origen o l'edat de la població del barri. Si el model aprèn que certs codis postals tenen un churn alt i per això el sistema deixa d'invertir a retenir (o d'oferir avantatges) aquests barris, el resultat pràctic és una política comercial que tracta pitjor els barris de menys renda — sense que la paraula "renda" aparegui en cap columna. Recorda la correlació del mòdul 2: el model no necessita la variable sensible si en té una de correlacionada amb ella.

Què fer, a la pràctica:

1. Inventari de proxies: per a cada variable del model, preguntar-se amb quins atributs sensibles pot correlacionar (codi postal → renda/origen; tipus de dispositiu → renda; franja horària de compra → tipus de jornada laboral…). La correlació es pot mesurar (02-03), no només intuir.
2. Decidir amb criteri, no per inèrcia: de vegades la variable té valor legítim (la logística real varia per zona) i es manté amb vigilància; de vegades la seva aportació predictiva no compensa el risc i s'elimina. És una decisió de disseny documentable, no un descuit.
3. Auditar el resultat per grups — perquè treure variables no garanteix res; cal mesurar el comportament final del model. D'això tracta la secció següent.

L'eina central d'una auditoria d'equitat és senzilla i ja la domines: les mètriques de la lliçó 06-02, desglossades per grup. Un model pot tenir un 85 % de precisió global i amagar un 92 % per a un grup i un 61 % per a un altre; la mitjana ho tapa tot.

Com llegir l'auditoria, amb les nocions de cost dels errors de 06-02:

• Recall per grup: dels clients d'aquest grup que realment anaven a abandonar, quina fracció detecta el model? Un recall baix en un grup significa que els seus membres en risc no reben l'oferta de retenció — el benefici del sistema no els arriba. Diferències grans de recall entre grups són el senyal d'alarma principal quan la predicció positiva dona accés a un benefici.
• Precision per grup i taxa de selecció completen el quadre: es contacten els grups en proporcions raonables respecte del seu risc real?
• n de cada grup: amb grups petits, les diferències poden ser soroll mostral — els intervals de confiança de 02-04 apliquen també aquí abans de cridar "biaix".

Dues advertències honestes: primera, hi ha diverses definicions matemàtiques d'equitat (igualar el recall entre grups, igualar la precisió, igualar les taxes de selecció…) i en general no es poden satisfer totes alhora; quina prioritzar és una decisió humana que depèn de quin error danya més a qui — l'anàlisi de costos de 06-04, amb dimensió moral. Segona, l'auditoria no "arregla" res per si sola: descobreix. Les correccions (reponderar dades, ajustar llindars per grup, redissenyar variables) parteixen sempre d'haver mesurat.

Quan un model decideix sobre persones, algú acabarà preguntant —amb tot el dret— "per què a mi?": el client que no va rebre l'oferta, el servei d'atenció que ha de respondre, el regulador que audita. La normativa europea de protecció de dades apunta en aquesta direcció per a decisions automatitzades amb efectes significatius: informació significativa sobre la lògica aplicada. D'aquí, dues exigències pràctiques:

• Transparència del sistema: poder explicar què fa el model — quines variables fa servir, com es va entrenar, quines mètriques té i per grup, qui el supervisa. És documentació, i tota la disciplina de versionatge de 08-02/08-03 (metadades, registre de models) n'és la base material.
• Explicabilitat de cada decisió: poder explicar un cas concret. Aquí connecta amb el que ja has vist: la importància de variables dels models d'arbres i valors tipus SHAP (esmentats a 07-03) permeten dir "aquest client puntua alt per la seva recència de 60 dies i les seves 3 incidències de lliurament" en lloc de "ho diu l'algorisme".

I una conseqüència de disseny que ja coneixes de 04-03: quan la decisió afecta significativament persones, un model interpretable pot valer més que un d'opac una mica més precís. Un arbre de decisió o una regressió logística amb pocs coeficients es poden explicar, auditar i defensar; si el boosting opac guanya només unes dècimes d'AUC, en una decisió amb impacte humà aquest marge pot no compensar la pèrdua d'explicabilitat. La tria de model és també una decisió ètica.

El model de churn s'alimenta de dades personals: historial de compra, adreces, hàbits. Principis de maneig responsable:

Minimització de dades: fer servir només les dades necessàries per a la finalitat declarada. Test pràctic per a cada variable candidata: aporta capacitat predictiva mesurable (els mètodes de selecció del mòdul 3)? La finalitat la justifica? En cas de dubte, fora — cada dada que no guardes és un risc que no tens. El model RFM de MercaFresh és un bon exemple de minimització: resumeix el comportament en tres agregats sense necessitar el detall de cada cistell.

Anonimització i pseudonimització — i els seus límits:

• Pseudonimitzar (substituir la identitat per un codi, com client_id) protegeix davant de mirades casuals, però l'organització conserva la taula de correspondència: continuen sent dades personals.
• Anonimitzar de debò és difícil. El risc és la reidentificació: creuar el dataset "anònim" amb altres fonts fins a recuperar identitats. Amb unes poques variables quasi-identificadores (codi postal + data de naixement + sexe) n'hi ha prou per assenyalar de manera única gran part d'una població, com han demostrat repetidament els estudis sobre reidentificació. Un històric de compres detallat és gairebé una empremta dactilar.
• Conseqüència pràctica: tracta les dades "anonimitzades" gairebé amb la mateixa cura que les personals, agrega sempre que puguis i no publiquis microdades sense una anàlisi seriosa del risc de reidentificació.

Sense entrar en assessoria legal (recorda l'advertència inicial), aquests principis del Reglament General de Protecció de Dades marquen el treball diari d'un equip de ML a Europa:

El missatge operatiu: aquests requisits condicionen l'arquitectura (pots esborrar un client de tots els teus snapshots?), així que han d'entrar al disseny des del principi — l'anomenat privacy by design — i validar-se amb els professionals legals de l'organització.

Breu però necessari: el mateix model pot ser una via de fuita d'informació o un objectiu d'atac.

• Fuita de dades d'entrenament: els models memoritzen més del que sembla. Atacs de membership inference intenten determinar si una persona concreta va ser al conjunt d'entrenament; els d'inversió de model intenten reconstruir atributs de les dades d'entrenament a partir de les sortides del model. Risc més gran com més sobreajustat està el model (una altra raó contra l'overfitting de 06-05) i com més exposada està l'API.
• Mitigacions de sentit comú: no exposar l'API públicament sense autenticació, limitar la taxa de peticions (dificulta els atacs per sondeig massiu), retornar només el necessari (cal la probabilitat exacta amb 6 decimals, o n'hi ha prou amb el tram de risc?), i registrar els accessos (08-03).
• Existeixen tècniques avançades (com la privadesa diferencial) que queden fora de l'abast del curs; n'hi ha prou de saber que aquest front existeix i que l'API d'un model és una superfície d'atac més.

El marc pràctic que condensa la lliçó, aplicable abans de cada desplegament del model de MercaFresh (complementa el checklist tècnic de 08-02):

Dades i biaix

• [ ] Base legal i finalitat del tractament documentades i validades amb legal/compliance.
• [ ] Minimització aplicada: cada variable justifica la seva presència.
• [ ] Inventari de proxies fet (codi postal i similars): decisió sobre cadascuna documentada.
• [ ] Representació dels grups rellevants a l'entrenament revisada.

Model i equitat

• [ ] Mètriques desglossades per grups rellevants (no només globals); diferències de recall/precision/taxa de selecció examinades i justificades o corregides.
• [ ] Llindar de decisió revisat també des de l'equitat, no només des del cost (06-04).
• [ ] Nivell d'interpretabilitat adequat a l'impacte de la decisió; explicació per cas disponible (importàncies/SHAP).

Operació

• [ ] Documentació del sistema al dia (versió, dades, mètriques, responsables) — el registre de 08-03.
• [ ] Via prevista perquè un client pregunti, reclami o demani intervenció humana.
• [ ] Dret de supressió executable en dades, snapshots i reentrenaments.
• [ ] API protegida: autenticació, límit de taxa, sortides mínimes, accessos registrats.
• [ ] L'auditoria per grups es repeteix a cada reentrenament (el drift també pot desequilibrar l'equitat).
• [ ] Revisió legal/compliance feta abans del desplegament i davant de cada canvi substancial.

• "He tret les variables sensibles, el model és neutre." Les proxies reconstrueixen el que s'ha eliminat. La neutralitat no es declara: es mesura, per grups, a les sortides del model.
• Auditar una vegada i arxivar l'informe. L'equitat es degrada com les mètriques (08-03): cada reentrenament i cada drift la poden alterar. L'auditoria per grups pertany al monitoratge continu.
• Concloure "biaix" de diferències en grups minúsculs. Amb una n petita, les mètriques per grup tenen molta variància; aplica el rigor estadístic de 02-04 abans de diagnosticar (i també abans de descartar).
• Tractar l'RGPD com un formulari de cookies. Els seus principis condicionen quines dades fas servir, com les guardes i si pots esborrar algú dels teus snapshots: és arquitectura, no paperassa final.
• Confondre pseudonimitzat amb anònim. Amb la taula de correspondència a casa —o amb prou quasi-identificadors— les dades continuen sent personals i el risc de reidentificació, real.
• Triar sempre el model amb millor AUC. Quan la decisió afecta persones, unes dècimes de mètrica poden no compensar perdre la capacitat d'explicar i defensar cada decisió.
• Consell: incorpora al checklist ètic la mateixa disciplina que als tests: es passa sencer abans de cada desplegament, i un punt en vermell atura el tren igual que un test trencat.

Exercici 1. Al model de churn de MercaFresh algú proposa afegir tres variables: (a) marca del telèfon des del qual es fa la comanda; (b) nombre d'incidències de lliurament; (c) franja horària habitual de compra. Per a cadascuna, identifica amb quin atribut sensible podria actuar com a proxy i què faries abans de decidir incloure-la.

Exercici 2. L'auditoria per grups del model dona, amb el llindar de negoci aplicat: zona urbana (n = 41.200): recall 0,78, precision 0,64; zona rural (n = 3.900): recall 0,55, precision 0,66. Interpreta què significa aquesta diferència per als clients rurals, proposa una causa probable connectada amb el que s'ha vist al curs, i suggereix dues accions.

Exercici 3. Un client de MercaFresh exerceix el seu dret de supressió. Enumera tots els llocs del sistema construït en aquest mòdul on viuen les seves dades i què caldria fer a cadascun (pensa en 08-02 i 08-03).

Solució 1. (a) Marca del telèfon: proxy conegut de nivell adquisitiu. Abans d'incloure-la: mesurar la seva correlació amb indicadors socioeconòmics disponibles, quantificar quant aporta realment al model i, si l'aportació és marginal, descartar-la; si s'inclou, vigilar-la a l'auditoria per grups. (b) Incidències de lliurament: en principi operativa i legítima (mesura qualitat de servei), però pot correlacionar amb la zona (la logística és pitjor en certes àrees), heretant l'efecte proxy del codi postal. Incloure-la probablement sí, però comprovar com es distribueix per zones i si introdueix diferències de tracte sistemàtiques. (c) Franja horària: pot reflectir el tipus de jornada laboral (torns nocturns, cures familiars). Risc moderat: mesurar aportació i correlacions, documentar la decisió i observar-la a l'auditoria. Patró comú: mesurar (02-03), justificar la necessitat (minimització), documentar i auditar el resultat — mai decidir per intuïció.

Solució 2. El recall de 0,55 rural davant del 0,78 urbà significa que gairebé la meitat dels clients rurals que abandonaran no són detectats i per tant no reben l'oferta de retenció, davant d'un cinquè dels urbans: el benefici del sistema arriba molt menys al grup rural. La precision similar indica que quan assenyala, encerta de manera semblant; el problema és a qui deixa fora. Causa probable: infrarepresentació (3.900 davant de 41.200) — el model ha après pitjor els patrons de churn rurals; també pot influir que el llindar únic de 06-04 estigui mal calibrat per a la distribució de probabilitats d'aquest grup. Abans de res, verificar que la diferència és estadísticament sòlida (la n rural no és trivial, però convindria l'interval de confiança). Accions possibles: reentrenar millorant la representació del grup (recollir més història, reponderar exemples) i avaluar un ajust del llindar que iguali aproximadament el recall entre grups, mesurant-ne el cost; en tots dos casos, repetir l'auditoria després del canvi.

Solució 3. Les seves dades viuen a: (1) la base de dades operativa de clients i comandes — esborrament segons el procediment corporatiu; (2) els datasets d'entrenament i snapshots de referència de 08-03 — eliminar les seves files perquè no entri en reentrenaments ni en les comparacions de drift; (3) els scores del batch nocturn (els parquet de resultats de 08-02) — purgar els seus registres històrics; (4) els logs de l'API i del monitoratge — localitzar i esborrar les seves peticions/prediccions registrades; (5) els backups de tot l'anterior — assegurar-ne l'expiració o l'esborrament segons la política definida. El model entrenat en si no es reentrena de seguida per un cas individual (els paràmetres agregats no són en general dades personals recuperables), però el client ja no ha d'aparèixer en cap entrenament futur — una altra raó per la qual la supressió ha d'estar prevista a l'arquitectura des del disseny. I la coda obligada: el procediment complet, inclosos terminis i abast en backups, l'ha de validar un professional legal/compliance.

Aquí es tanca el mòdul 8, i amb ell, el camí complet del model de churn de MercaFresh: vas triar les eines i vas congelar l'entorn (08-01), vas serialitzar el pipeline, el vas servir en batch i per API, el vas empaquetar en Docker i el vas desplegar amb xarxa de seguretat (08-02), vas muntar el monitoratge que detecta drift i governa el reentrenament (08-03), i en aquesta lliçó li has posat l'última capa, la que converteix un sistema que funciona en un sistema defensable: biaixos rastrejats fins al seu origen, equitat mesurada per grups amb les mètriques de sempre, decisions explicables, dades minimitzades i tractades conforme a principis, l'API protegida i un checklist que es passa sencer abans de cada desplegament — sempre amb la revisió legal com a últim pany. Aquesta és la imatge completa del que significa fer aprenentatge automàtic professional: no un model amb bon AUC, sinó un sistema en producció, vigilat i responsable. Tot el que has après en vuit mòduls està ara a punt per exercitar-se de cap a cap: al mòdul 9 t'esperen cinc projectes complets —habitatges, imatges, sentiments, frau i segmentació— on recorreràs tu sol, amb dades noves, el camí que MercaFresh ens ha ensenyat.