Módulo 2: Bias and Fairness — Detection, Measurement, Mitigation

1. Introducción al módulo: Bias and Fairness

Descripción de la cápsula

En el Módulo 1 estableciste que los fallos éticos en AI tienen costo cuantificable: legal, reputacional, técnico, humano. Identificaste riesgos de bias en tu Ethics Impact Analysis. Sabés que Amazon Hiring discriminó por género, que facial recognition falla 30+ puntos peor para mujeres negras, que Apple Card produjo disparidad por proxies indirectos.

Lo que aún no sabés es: ¿cómo medir si tu sistema tiene esos problemas?

"Mi sistema podría ser sesgado" es una afirmación inservible. "Mi sistema tiene demographic parity de 0.72, lo cual indica disparidad significativa que requiere mitigación" es una afirmación accionable.

Este módulo es la transición de discurso ético a ingeniería ética. Bias deja de ser tema abstracto y se convierte en algo que:

Medís con métricas estándar de la industria (demographic parity, equalized odds, calibration, disparate impact).
Detectás con tests específicos integrados en CI (slicing, A/B demográfico, adversarial testing).
Mitigás con técnicas documentadas en tres categorías (pre-processing, in-processing, post-processing).

Es el módulo más técnico de la Phase 1. Va a tener fórmulas, código, y trade-offs incómodos. Es exactamente lo que tu workflow ético necesita para dejar de ser teoría.

¿Por qué bias primero?

Bias es el riesgo ético más frecuente, más medible, y más accionable en sistemas AI. Por eso es el primer módulo técnico de la guía.

Más frecuente

Cualquier sistema entrenado en datos del mundo real probablemente tiene bias. El default no es "sin bias" — el default es "con bias hasta probar lo contrario". Razón:

Los datos del mundo reflejan sesgos históricos.
Los modelos aprenden patrones, incluyendo los sesgados.
Sin testing explícito, el sesgo es invisible en métricas globales.

Más medible

A diferencia de "transparency" o "accountability" (conceptos que requieren juicio), bias se cuantifica con fórmulas matemáticas explícitas. Podés calcular un número, comparar con un threshold, y decidir.

Esa concreción es valiosa: convierte ética de "tema de discusión" en "decisión de QA gate".

Más accionable

Hay decenas de técnicas documentadas para mitigar bias detectado:

Pre-processing: rebalancear training data.
In-processing: agregar fairness constraints al loss function.
Post-processing: ajustar thresholds por grupo.

No estás inventando. Estás aplicando un cuerpo de conocimiento maduro, con software libraries (AI Fairness 360, Fairlearn, Fairness Indicators) listas para usar.

Lo que vas a aprender

8 cápsulas, en orden:

Introducción (esta cápsula) — qué es bias, por qué medible, mapa del módulo.
Demographic parity — la métrica más común. Definición, fórmula, código, cuándo aplicar.
Equalized odds y calibration — métricas más sofisticadas. Cuándo importan más.
Bias detection: slicing y A/B testing demográfico — cómo detectar en práctica.
Impossibility theorems — por qué no podés satisfacer todas las métricas. Trade-offs reales.
Mitigation: pre-processing — rebalancing, re-sampling, data augmentation.
Mitigation: in-processing y post-processing — adversarial debiasing, threshold tuning.
Mini-proyecto: Bias Audit Toolkit — implementación reutilizable.

Al terminar:

Calculás 4 fairness metrics desde cero, en código.
Diseñás bias tests específicos para tu sistema.
Aplicás mitigations apropiadas según el problema detectado.
Articulás trade-offs para hacer decisiones informadas (no recetas).
Producís un toolkit reusable que aplicás a sistemas futuros.

El cambio de mentalidad de este módulo

Antes:

"Bias es importante. Voy a tratar de tener cuidado con los datos."

Después:

"Bias es medible con fórmula X. Mi sistema actualmente tiene métrica X = 0.72. Threshold legal es 0.80. Voy a aplicar técnica Y de mitigation para subir a 0.85, y agregar test X.test_fairness() al CI para no regresionar."

Concreción. Métricas. Code. Decisiones informadas en lugar de buenas intenciones.

El trade-off honesto: fairness vs accuracy

Antes de entrar al módulo, una verdad incómoda:

Fairness y accuracy a veces tradeoff. No siempre, pero a veces.

Ejemplo simplificado: si tu modelo es muy accurate prediciendo "buen candidato" basado en patrones del pasado, y el pasado tenía sesgo, el modelo accurately predice patrones sesgados. Aplicar fairness constraints puede reducir accuracy en algunos puntos.

Esto no es excusa para no aplicar fairness. Es contexto para tomar decisiones informadas:

¿Cuánta accuracy estás dispuesto a perder por cuánta fairness ganada?
¿Cuál es tu threshold mínimo de cada uno?
¿Cómo justificás la decisión a stakeholders?

El módulo te enseña a tomar y documentar estas decisiones, no a esconderlas.

Los impossibility theorems

Más profundo aún: matemáticamente, no podés satisfacer todas las definiciones de fairness simultaneamente. Chouldechova (2017) y Kleinberg-Mullainathan-Raghavan (2017) demostraron formalmente:

Demographic parity (igual rate por grupo) +
Equalized odds (igual error por grupo) +
Calibration (igual confianza significa igual probabilidad por grupo)

Las tres son mutuamente incompatibles excepto en casos triviales (cuando los grupos tienen distribuciones idénticas, lo cual nunca ocurre en práctica).

Implicación: tenés que elegir cuál priorizar según context. La cápsula 05 cubre cómo.

Definición de "grupo protegido": no es trivial

Antes de medir bias, tenés que definir respecto a qué atributo:

Género (M/F/non-binary/no disclosed)?
Raza/etnia (cómo se categoriza?)?
Edad (en qué brackets?)?
Discapacidad?
Religión?
Orientación sexual?
Origen nacional?
Status migratorio?
Veteran status?
Combinaciones (intersectionality)?

Cada elección tiene complications:

Práctica: a menudo no tenés esos datos. Algunas jurisdicciones (Europa) prohíben recolectar ciertos atributos. ¿Cómo hacés bias testing sin los datos?

Solución parcial: inferencia (ZIP → raza), sampling demográfico (encuestas a sub-muestra), proxy testing (counterfactual con marcadores swapped).

Intersectionality: una mujer negra puede tener experiencia distinta a "mujeres" agregado o "personas negras" agregado. Bias por género solo NO captura discriminación interseccional. Capurralo requiere desagregar por género × raza, lo cual aumenta data requirement.

El módulo aborda estas dificultades. No vamos a pretender que es trivial — porque no lo es.

Lo que NO cubrimos en este módulo

Este módulo cubre bias como tema técnico. Hay temas relacionados que cubre la guía en otros módulos:

Privacy de datos demográficos → Módulo 3.
Compliance legal específica (GDPR, EU AI Act) → Módulos 4-6.
Framework integrador → Módulo 7.
Audit completo → Módulo 8.

Aquí nos enfocamos en: cómo medir, detectar, y mitigar bias. Las consecuencias legales y procesos organizacionales se cubren en otro lado.

Prerequisitos del módulo

Para sacar máximo provecho:

Completaste M1 y tenés tu Ethics Impact Analysis listo.
Sabés Python y entendés numpy, pandas, scikit-learn básico.
Familiaridad con conceptos de ML: classifier, training, predictions, confusion matrix.
Algo de estadística básica: distribuciones, ratios, proporciones.

Si te falta algo de scikit-learn o numpy, la guía #3 (Python + REST APIs) o las guías de ML del path tienen los fundamentals.

Mentalidad: bias audit como proceso continuo

Una idea importante para todo el módulo: bias no es algo que "arreglás una vez".

Razones:

Models drift: el comportamiento de tu modelo en producción cambia con el tiempo.
Data drift: la distribución de inputs cambia (cambios demográficos, nuevos contextos).
Concept drift: lo que significa "buen candidato" o "loan default" cambia con económica/social conditions.

Implicación: bias testing tiene que ser continuo, integrado en CI, monitoreado en producción.

El "Bias Audit Toolkit" del mini-proyecto (cápsula 8) está diseñado para correrse periódicamente, no como check único pre-deploy.

Trampas y errores comunes en este tema

1. "Mi sistema no tiene bias porque no usa género/raza"

Falso. Como demostró Apple Card y Amazon Hiring, proxies hacen el bias indirecto. Sin testing del output, no podés saberlo.

2. "Aplicar fairness constraints garantiza fairness"

Falso. Aplicar una definición de fairness puede violar otras. Por los impossibility theorems, no podés satisfacer todo. La elección requiere juicio informado.

3. "Las herramientas (AI Fairness 360, Fairlearn) lo resuelven"

Las herramientas implementan métricas y mitigations, sí. Pero vos tenés que elegir cuáles aplicar y cómo. Las herramientas no toman las decisiones por vos.

4. "Más datos resuelve bias"

Parcial. Más datos balanceados ayuda. Más datos desbalanceados solo amplifica. La calidad balanceada importa más que la cantidad.

5. "Fairness y accuracy son alineados"

A veces sí, a veces no. Honesty: a menudo hay trade-off. El módulo te enseña a navegarlo, no a negarlo.

Auto-verificación

1. ¿Por qué bias es el riesgo ético más medible?

Por tres razones:

Fórmulas matemáticas concretas: demographic parity = P(positive | group A) / P(positive | group B). Es un número, no una opinión.
Tests automatizables: corren en CI sin intervención humana. Pasa o falla.
Body of knowledge maduro: décadas de research en fairness en ML, statistics, legal frameworks. Tenés literatura y herramientas listas.

Comparado con "transparency" o "accountability" que requieren juicio cualitativo, bias se cuantifica. Es por eso que es el módulo técnico para empezar.

2. ¿Cuál es el problema con definir "grupo protegido"?

Múltiples:

Categorización compleja: ¿género binario o spectrum? ¿raza por self-identification, por census categories, por inference?
Datos no disponibles: a menudo no recolectás esos atributos.
Legalmente prohibido recolectar: Europa GDPR limita.
Intersectionality: agregados ocultan interseccionales.
Cambia con context: lo que es protected en US (raza) puede ser distinto en otros países.

Soluciones parciales:

Proxy testing (counterfactual con marcadores swapped sin necesitar self-identified data).
Sampling demográfico (encuesta a sub-muestra para análisis).
Inferencia cuidadosa (ZIP → raza con error rates documentados).

El módulo aborda estas dificultades, no las ignora.

3. ¿Por qué los impossibility theorems no son excusa para no aplicar fairness?

Los theorems demuestran que no podés satisfacer todas las métricas simultaneamente. NO demuestran que no podés satisfacer ninguna.

Implicación correcta: tenés que elegir cuál priorizar según context.

Para hiring: equalized odds (igual error rates) es probablemente más relevante.
Para healthcare: calibration (igual confidence-to-outcome ratio).
Para advertising: demographic parity (igual exposure por grupo).

Cada context tiene una métrica naturalmente más relevante. Elegirla, justificarla, documentarla, monitorearla es engineering judgment, no escape.

Lo que NO podés es decir "como no puedo satisfacer todo, no aplico nada". Eso sería como decir "como no puedo prevenir todos los bugs, no testeo".

4. ¿Por qué bias audit tiene que ser continuo, no one-time?

Tres tipos de drift afectan a sistemas AI:

Model drift: comportamiento del modelo cambia con scale, edge cases que aparecen en producción.
Data drift: la distribución de inputs cambia con el tiempo. Demografía cambia, nuevos use cases aparecen.
Concept drift: lo que significa "good outcome" cambia (regulación, normas sociales, condiciones económicas).

Cualquiera de los tres puede introducir bias que no estaba en pre-deploy testing.

Solución: bias metrics como monitoring continuo en producción, con alerts cuando exceden thresholds. Re-audit formal cada 6-12 meses o cuando hay cambio significativo.

El Bias Audit Toolkit del mini-proyecto está diseñado para esto: reusable, automatable, integrable en CI/monitoring.

Resumen y siguiente paso

Bias es el riesgo ético más frecuente, medible, y accionable en AI.
Métricas matemáticas concretas (demographic parity, equalized odds, calibration, disparate impact) reemplazan opiniones.
Trade-offs reales existen: fairness vs accuracy, impossibility theorems entre métricas. El módulo enseña a navegarlos, no a esconderlos.
Definir "grupo protegido" es no trivial: data availability, legal constraints, intersectionality.
Bias audit es continuo, no one-time. El toolkit del mini-proyecto está diseñado para integración en CI y monitoring.

Checkpoint: deberías poder articular por qué bias es donde "ética se vuelve ingeniería" en sistemas AI.

Puente a la siguiente cápsula: la cápsula 02 introduce la métrica más común: demographic parity (también llamada "independence" o "statistical parity"). Vas a ver la fórmula, implementarla en código, aplicarla a un dataset real, y entender cuándo es la métrica apropiada (y cuándo no). Es el primer paso en convertir tu intuición de "bias" en un número que podés medir y monitorear.

Recursos

Fairness in Machine Learning — Solon Barocas, Moritz Hardt, Arvind Narayanan (textbook) — referencia académica gratuita.
AI Fairness 360 — IBM open source — toolkit comprehensivo.
Fairlearn — Microsoft open source — alternativa Python.
Fairness Indicators — Google — para TF/Keras.
Survey of Bias in ML (Mehrabi et al., 2021) — paper survey.

Siguiente: 02-fairness-metrics-demographic-parity.md — La primera fairness metric: demographic parity.

Cápsula 01 de 08 — Módulo 2 — AI Ethics & Compliance Guide

← Anterior8. Mini-proyecto: Ethics Impact Analysis Siguiente →2. Fairness Metric: Demographic Parity