El modelo de churn de MercaFresh ya funciona, se sirve y se monitoriza. Pero hay una pregunta que la latencia y el AUC no responden: ¿es justo? El modelo decide qué clientes reciben descuentos de retención y cuáles no, usando datos personales de compra. Cada decisión automatizada sobre personas reales trae consigo cuestiones de sesgo, equidad, transparencia, privacidad y seguridad — y, cada vez más, obligaciones legales. En esta lección aprenderás de dónde vienen los sesgos, cómo auditar un modelo por grupos con las métricas que ya dominas, qué exige la transparencia, qué principios rigen la privacidad de los datos y cómo condensarlo todo en un checklist práctico para el proyecto de churn.

Advertencia importante: esta lección presenta principios generales con fines formativos y no es asesoramiento legal. Las implicaciones regulatorias (RGPD, normativa de IA, legislación sectorial) de cualquier sistema real deben revisarse siempre con un profesional legal o de compliance antes de su puesta en producción. Todos los datos y situaciones de MercaFresh son ficticios.

1. Por qué la ética no es un apéndice del proyecto
2. Sesgos: de dónde vienen
3. Variables proxy: el caso del código postal
4. Auditar la equidad: métricas por grupos
5. Transparencia y explicabilidad
6. Privacidad: minimización, anonimización y sus límites
7. RGPD: principios que un equipo de ML debe conocer
8. Seguridad del modelo
9. Checklist ético para el proyecto de churn

Un reflejo habitual es tratar la ética como un trámite final: "el modelo funciona; ahora, el capítulo de ética". Es un error por tres razones prácticas:

• Los problemas éticos son problemas técnicos con consecuencias humanas. Un sesgo es, en el fondo, un error de generalización (módulo 6) que afecta sistemáticamente a un grupo de personas. Se analiza con las mismas herramientas: datos, métricas, validación.
• Se originan al principio, no al final. El sesgo entra con los datos (módulo 3) y con las decisiones de diseño; cuando el modelo está en producción, corregirlo cuesta diez veces más.
• Tienen coste de negocio y legal. Una campaña de retención sistemáticamente injusta daña la confianza y la marca; un tratamiento ilegal de datos acarrea sanciones serias.

En MercaFresh el modelo decide algo aparentemente inocuo — a quién ofrecer un descuento —. Pero "inocuo" merece examen: si el modelo ofrece sistemáticamente peores condiciones a un colectivo, el supermercado está discriminando a escala, con la eficiencia de una máquina.

Un modelo no es neutral por ser matemático: aprende lo que hay en los datos, y los datos son un registro del mundo — con sus desigualdades incluidas. Las fuentes principales:

La lección transversal: el sesgo raramente entra por mala intención; entra por defecto, con los datos de siempre y el proceso de siempre, salvo que alguien lo busque activamente.

La respuesta ingenua al sesgo es "no uses variables sensibles": quita género, edad, nacionalidad, y el modelo será neutro. No funciona, por las variables proxy: variables correlacionadas con el atributo sensible que permiten al modelo reconstruirlo de facto.

El ejemplo canónico es el código postal. En el modelo de churn de MercaFresh parece una variable logística inocente ("¿desde dónde pide?"). Pero el código postal correlaciona fuertemente con nivel socioeconómico, y a menudo con origen o edad de la población del barrio. Si el modelo aprende que ciertos códigos postales tienen alto churn y por ello el sistema deja de invertir en retener (o de ofrecer ventajas) a esos barrios, el resultado práctico es una política comercial que trata peor a los barrios de menor renta — sin que la palabra "renta" aparezca en ninguna columna. Recuerda la correlación del módulo 2: el modelo no necesita la variable sensible si tiene una correlacionada con ella.

Qué hacer, en la práctica:

1. Inventario de proxies: para cada variable del modelo, preguntarse con qué atributos sensibles puede correlacionar (código postal → renta/origen; tipo de dispositivo → renta; franja horaria de compra → tipo de jornada laboral…). La correlación se puede medir (02-03), no solo intuir.
2. Decidir con criterio, no por inercia: a veces la variable tiene valor legítimo (la logística real varía por zona) y se mantiene con vigilancia; a veces su aportación predictiva no compensa el riesgo y se elimina. Es una decisión de diseño documentable, no un descuido.
3. Auditar el resultado por grupos — porque quitar variables no garantiza nada; hay que medir el comportamiento final del modelo. De eso trata la siguiente sección.

La herramienta central de una auditoría de equidad es sencilla y ya la dominas: las métricas de la lección 06-02, desglosadas por grupo. Un modelo puede tener un 85 % de precisión global y esconder un 92 % para un grupo y un 61 % para otro; la media lo tapa todo.

Cómo leer la auditoría, con las nociones de coste de errores de 06-02:

• Recall por grupo: de los clientes de este grupo que realmente iban a abandonar, ¿a qué fracción detecta el modelo? Un recall bajo en un grupo significa que sus miembros en riesgo no reciben la oferta de retención — el beneficio del sistema no les llega. Diferencias grandes de recall entre grupos son la señal de alarma principal cuando la predicción positiva da acceso a un beneficio.
• Precision por grupo y tasa de selección completan el cuadro: ¿se contacta a los grupos en proporciones razonables respecto a su riesgo real?
• n de cada grupo: con grupos pequeños, las diferencias pueden ser ruido muestral — los intervalos de confianza de 02-04 aplican también aquí antes de gritar "sesgo".

Dos advertencias honestas: primero, hay varias definiciones matemáticas de equidad (igualar recall entre grupos, igualar precisión, igualar tasas de selección…) y en general no pueden satisfacerse todas a la vez; cuál priorizar es una decisión humana que depende de qué error daña más a quién — el análisis de costes de 06-04, con dimensión moral. Segundo, la auditoría no "arregla" nada por sí sola: descubre. Las correcciones (repesar datos, ajustar umbrales por grupo, rediseñar variables) parten siempre de haber medido.

Cuando un modelo decide sobre personas, alguien acabará preguntando —con derecho— "¿por qué a mí?": el cliente que no recibió la oferta, el servicio de atención que debe responder, el regulador que audita. La normativa europea de protección de datos apunta en esa dirección para decisiones automatizadas con efectos significativos: información significativa sobre la lógica aplicada. De ahí dos exigencias prácticas:

• Transparencia del sistema: poder explicar qué hace el modelo — qué variables usa, cómo se entrenó, qué métricas tiene y por grupo, quién lo supervisa. Es documentación, y toda la disciplina de versionado de 08-02/08-03 (metadatos, registro de modelos) es su base material.
• Explicabilidad de cada decisión: poder explicar un caso concreto. Aquí conecta con lo ya visto: la importancia de variables de los modelos de árboles y valores tipo SHAP (mencionados en 07-03) permiten decir "este cliente puntúa alto por su recencia de 60 días y sus 3 incidencias de entrega" en lugar de "lo dice el algoritmo".

Y una consecuencia de diseño que ya conoces de 04-03: cuando la decisión afecta significativamente a personas, un modelo interpretable puede valer más que uno opaco algo más preciso. Un árbol de decisión o una regresión logística con pocos coeficientes se pueden explicar, auditar y defender; si el boosting opaco gana solo unas décimas de AUC, en una decisión con impacto humano ese margen puede no compensar la pérdida de explicabilidad. La elección de modelo es también una decisión ética.

El modelo de churn se alimenta de datos personales: historial de compra, direcciones, hábitos. Principios de manejo responsable:

Minimización de datos: usar solo los datos necesarios para el fin declarado. Test práctico para cada variable candidata: ¿aporta capacidad predictiva medible (los métodos de selección del módulo 3)? ¿El fin la justifica? En caso de duda, fuera — cada dato que no guardas es un riesgo que no tienes. El modelo RFM de MercaFresh es un buen ejemplo de minimización: resume el comportamiento en tres agregados sin necesitar el detalle de cada cesta.

Anonimización y seudonimización — y sus límites:

• Seudonimizar (sustituir la identidad por un código, como cliente_id) protege frente a miradas casuales, pero la organización conserva la tabla de correspondencia: siguen siendo datos personales.
• Anonimizar de verdad es difícil. El riesgo es la reidentificación: cruzar el dataset "anónimo" con otras fuentes hasta recuperar identidades. Con unas pocas variables cuasi-identificadoras (código postal + fecha de nacimiento + sexo) basta para señalar de forma única a gran parte de una población, como han demostrado repetidamente los estudios sobre reidentificación. Un histórico de compras detallado es casi una huella dactilar.
• Consecuencia práctica: trata los datos "anonimizados" con casi el mismo cuidado que los personales, agrega siempre que puedas y no publiques microdatos sin un análisis serio del riesgo de reidentificación.

Sin entrar en asesoría legal (recuerda la advertencia inicial), estos principios del Reglamento General de Protección de Datos marcan el trabajo diario de un equipo de ML en Europa:

El mensaje operativo: estos requisitos condicionan la arquitectura (¿puedes borrar a un cliente de todos tus snapshots?), así que deben entrar en el diseño desde el principio — el llamado privacy by design — y validarse con los profesionales legales de la organización.

Breve pero necesario: el propio modelo puede ser una vía de fuga de información o un objetivo de ataque.

• Fuga de datos de entrenamiento: los modelos memorizan más de lo que parece. Ataques de membership inference intentan determinar si una persona concreta estuvo en el conjunto de entrenamiento; los de inversión de modelo intentan reconstruir atributos de los datos de entrenamiento a partir de las salidas del modelo. Riesgo mayor cuanto más sobreajustado está el modelo (otra razón contra el overfitting de 06-05) y cuanto más expuesta está la API.
• Mitigaciones de sentido común: no exponer la API públicamente sin autenticación, limitar la tasa de peticiones (dificulta los ataques por sondeo masivo), devolver solo lo necesario (¿hace falta la probabilidad exacta con 6 decimales, o basta el tramo de riesgo?), y registrar los accesos (08-03).
• Existen técnicas avanzadas (como la privacidad diferencial) que quedan fuera del alcance del curso; basta con saber que este frente existe y que la API de un modelo es una superficie de ataque más.

El marco práctico que condensa la lección, aplicable antes de cada despliegue del modelo de MercaFresh (complementa el checklist técnico de 08-02):

Datos y sesgo

• [ ] Base legal y finalidad del tratamiento documentadas y validadas con legal/compliance.
• [ ] Minimización aplicada: cada variable justifica su presencia.
• [ ] Inventario de proxies realizado (código postal y similares): decisión sobre cada una documentada.
• [ ] Representación de los grupos relevantes en el entrenamiento revisada.

Modelo y equidad

• [ ] Métricas desglosadas por grupos relevantes (no solo globales); diferencias de recall/precision/tasa de selección examinadas y justificadas o corregidas.
• [ ] Umbral de decisión revisado también desde la equidad, no solo desde el coste (06-04).
• [ ] Nivel de interpretabilidad adecuado al impacto de la decisión; explicación por caso disponible (importancias/SHAP).

Operación

• [ ] Documentación del sistema al día (versión, datos, métricas, responsables) — el registro de 08-03.
• [ ] Vía prevista para que un cliente pregunte, reclame o pida intervención humana.
• [ ] Derecho de supresión ejecutable en datos, snapshots y reentrenamientos.
• [ ] API protegida: autenticación, límite de tasa, salidas mínimas, accesos registrados.
• [ ] La auditoría por grupos se repite en cada reentrenamiento (el drift también puede desequilibrar la equidad).
• [ ] Revisión legal/compliance realizada antes del despliegue y ante cada cambio sustancial.

• "Quité las variables sensibles, el modelo es neutro." Las proxies reconstruyen lo eliminado. La neutralidad no se declara: se mide, por grupos, en las salidas del modelo.
• Auditar una vez y archivar el informe. La equidad se degrada como las métricas (08-03): cada reentrenamiento y cada drift la pueden alterar. La auditoría por grupos pertenece al monitoreo continuo.
• Concluir "sesgo" de diferencias en grupos minúsculos. Con n pequeño, las métricas por grupo tienen mucha varianza; aplica el rigor estadístico de 02-04 antes de diagnosticar (y también antes de descartar).
• Tratar el RGPD como un formulario de cookies. Sus principios condicionan qué datos usas, cómo los guardas y si puedes borrar a alguien de tus snapshots: es arquitectura, no papeleo final.
• Confundir seudonimizado con anónimo. Con la tabla de correspondencia en casa —o con suficientes cuasi-identificadores— los datos siguen siendo personales y el riesgo de reidentificación, real.
• Elegir siempre el modelo con mejor AUC. Cuando la decisión afecta a personas, unas décimas de métrica pueden no compensar perder la capacidad de explicar y defender cada decisión.
• Consejo: incorpora al checklist ético la misma disciplina que a los tests: se pasa entero antes de cada despliegue, y un punto en rojo detiene el tren igual que un test roto.

Ejercicio 1. En el modelo de churn de MercaFresh alguien propone añadir tres variables: (a) marca del teléfono desde el que se hace el pedido; (b) número de incidencias de entrega; (c) franja horaria habitual de compra. Para cada una, identifica con qué atributo sensible podría actuar como proxy y qué harías antes de decidir incluirla.

Ejercicio 2. La auditoría por grupos del modelo arroja, con el umbral de negocio aplicado: 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 esta diferencia para los clientes rurales, propone una causa probable conectada con lo visto en el curso, y sugiere dos acciones.

Ejercicio 3. Un cliente de MercaFresh ejerce su derecho de supresión. Enumera todos los lugares del sistema construido en este módulo donde viven sus datos y qué habría que hacer en cada uno (piensa en 08-02 y 08-03).

Solución 1. (a) Marca del teléfono: proxy conocido de nivel adquisitivo. Antes de incluirla: medir su correlación con indicadores socioeconómicos disponibles, cuantificar cuánto aporta realmente al modelo y, si la aportación es marginal, descartarla; si se incluye, vigilarla en la auditoría por grupos. (b) Incidencias de entrega: en principio operativa y legítima (mide calidad de servicio), pero puede correlacionar con la zona (la logística es peor en ciertas áreas), heredando el efecto proxy del código postal. Incluirla probablemente sí, pero comprobar cómo se distribuye por zonas y si introduce diferencias de trato sistemáticas. (c) Franja horaria: puede reflejar tipo de jornada laboral (turnos nocturnos, cuidados familiares). Riesgo moderado: medir aportación y correlaciones, documentar la decisión y observarla en la auditoría. Patrón común: medir (02-03), justificar la necesidad (minimización), documentar y auditar el resultado — nunca decidir por intuición.

Solución 2. El recall de 0,55 rural frente a 0,78 urbano significa que casi la mitad de los clientes rurales que van a abandonar no son detectados y por tanto no reciben la oferta de retención, frente a un quinto de los urbanos: el beneficio del sistema llega mucho menos al grupo rural. La precision similar indica que cuando señala, acierta parecido; el problema es a quién deja fuera. Causa probable: infrarrepresentación (3.900 frente a 41.200) — el modelo ha aprendido peor los patrones de churn rurales; también puede influir que el umbral único de 06-04 esté mal calibrado para la distribución de probabilidades de ese grupo. Antes de nada, verificar que la diferencia es estadísticamente sólida (n rural no es trivial, pero convendría el intervalo de confianza). Acciones posibles: reentrenar mejorando la representación del grupo (recoger más historia, repesar ejemplos) y evaluar un ajuste del umbral que iguale aproximadamente el recall entre grupos, midiendo su coste; en ambos casos, repetir la auditoría tras el cambio.

Solución 3. Sus datos viven en: (1) la base de datos operativa de clientes y pedidos — borrado según el procedimiento corporativo; (2) los datasets de entrenamiento y snapshots de referencia de 08-03 — eliminar sus filas para que no entre en reentrenamientos ni en las comparaciones de drift; (3) los scores del batch nocturno (los parquet de resultados de 08-02) — purgar sus registros históricos; (4) los logs de la API y del monitoreo — localizar y borrar sus peticiones/predicciones registradas; (5) los backups de todo lo anterior — asegurar expiración o borrado según la política definida. El modelo entrenado en sí no se reentrena de inmediato por un caso individual (los parámetros agregados no son en general datos personales recuperables), pero el cliente ya no debe aparecer en ningún entrenamiento futuro — otra razón por la que la supresión debe estar prevista en la arquitectura desde el diseño. Y la coda obligada: el procedimiento completo, incluidos plazos y alcance en backups, debe validarlo un profesional legal/compliance.

Cierra aquí el módulo 8, y con él, el camino completo del modelo de churn de MercaFresh: elegiste las herramientas y congelaste el entorno (08-01), serializaste el pipeline, lo serviste en batch y por API, lo empaquetaste en Docker y lo desplegaste con red de seguridad (08-02), montaste el monitoreo que detecta drift y gobierna el reentrenamiento (08-03), y en esta lección le pusiste la última capa, la que convierte un sistema que funciona en un sistema defendible: sesgos rastreados hasta su origen, equidad medida por grupos con las métricas de siempre, decisiones explicables, datos minimizados y tratados conforme a principios, la API protegida y un checklist que se pasa entero antes de cada despliegue — siempre con la revisión legal como último cerrojo. Esta es la imagen completa de lo que significa hacer machine learning profesional: no un modelo con buen AUC, sino un sistema en producción, vigilado y responsable. Todo lo que has aprendido en ocho módulos está ahora listo para ejercitarse de principio a fin: en el módulo 9 te esperan cinco proyectos completos —viviendas, imágenes, sentimientos, fraude y segmentación— donde recorrerás tú solo, con datos nuevos, el camino que MercaFresh nos ha enseñado.