17. Sesgos Algorítmicos: Casos Reales y Framework de Detección

Introducción: El Costo Real de los Sesgos

2018, Amazon: Un sistema de reclutamiento con IA penalizaba CVs de mujeres.

2019, Healthcare: Un algoritmo usado por hospitales de EEUU asignaba menos recursos a pacientes negros, afectando a millones.

2020, Examen A-Level UK: Un algoritmo determinó calificaciones de estudiantes durante COVID. Resultado: 40% de notas rebajadas, afectando desproporcionadamente a estudiantes de escuelas públicas.

Costo total: Millones en compensaciones, demandas, y daño reputacional. Pero el costo humano es incalculable.

Los sesgos algorítmicos no son errores técnicos menores—son decisiones de diseño que perpetúan y amplifican desigualdades existentes a escala masiva.

Esta lección examina casos reales, tipos de sesgo, y un framework práctico para detectar y mitigar sesgos en tus sistemas de IA.

---

Caso 1: Amazon Recruiting AI - Gender Bias

El Contexto

2014-2018: Amazon desarrolló un sistema de ML para automatizar screening de CVs.

Objetivo: Procesar miles de CVs diariamente, identificar candidatos top, reducir tiempo de recruiting.

Datos de Entrenamiento: 10 años de CVs históricos y decisiones de contratación.

Inversión: Millones de dólares, equipo dedicado de ML engineers.

El Problema

En 2015, el equipo descubrió un problema crítico:

El sistema penalizaba sistemáticamente CVs de mujeres.

Evidencia:

• CVs con palabras como "women's" (ej: "women's chess club captain") recibían scores más bajos
• Graduadas de universidades femeninas (ej: "Smith College") penalizadas
• Mismas calificaciones, diferente género → scores diferentes

La Causa Raíz

DATOS HISTÓRICOS (2004-2014)
├─ Tech industry dominado por hombres
├─ 80% de CVs recibidos: hombres
├─ 85% de contrataciones: hombres
└─ Patrón aprendido: "masculinidad = predictor de éxito"

ALGORITMO APRENDIÓ
├─ CVs de hombres → "contrataciones exitosas"
├─ Lenguaje/experiencias masculinas → scores altos
├─ Lenguaje/experiencias femeninas → scores bajos
└─ Resultado: Discriminación automatizada a escala

FEEDBACK LOOP
├─ Sistema recomienda más hombres
├─ Se contratan más hombres
├─ Nuevos datos refuerzan sesgo
└─ Círculo vicioso

No fue malicia—fue matemáticas:

El algoritmo hizo exactamente lo que se le pidió: replicar decisiones históricas. El problema: decisiones históricas reflejaban sesgos.

La Respuesta

2017: Amazon intentó fixes técnicos:

• Remover features explícitas de género
• Neutralizar lenguaje de género
• Re-entrenar con datos balanceados

Resultado: Mejoras marginales, pero no confianza en imparcialidad.

2018: Amazon canceló el proyecto completamente.

Lecciones Clave

1. Pasado ≠ Ideal Futuro

   • Replicar decisiones históricas perpetúa sesgos históricos
   • "Así es como siempre lo hicimos" no es fair

2. Remover Features Evidentes No Es Suficiente

   • Gender proxies: universidad, actividades, lenguaje
   • Correlaciones sutiles que humanos no detectarían

3. Diversidad en Data = Diversidad en Outcomes

   • 80% datos de hombres → 80% recomendaciones de hombres
   • No puedes "fix" data sesgada solo con algoritmo

4. Cancelar > Desplegar Sistema Sesgado

   • Amazon tomó decisión correcta
   • Costo de proyecto < costo de discriminación a escala

---

Caso 2: Uber Pricing Algorithm - Socioeconomic Bias

El Contexto

2016-2019: Investigadores estudiaron algoritmo de pricing dinámico de Uber.

Surge Pricing: Precios suben con demanda alta (eventos, mal tiempo, horas pico).

Promesa: Algoritmo "neutral" basado solo en oferta/demanda.

El Problema

Hallazgo (Investigación 2019):

Viajes que inician/terminan en vecindarios de bajos ingresos tenían:

• 30% más probabilidad de surge pricing
• Surges más prolongados (duraban más tiempo)
• Menos drivers disponibles (círculo vicioso)

Pero demanda era similar a vecindarios de altos ingresos.

La Causa Raíz

DATOS HISTÓRICOS
├─ Menos drivers viven en zonas de bajos ingresos
├─ Menos drivers aceptan viajes a esas zonas (percepción seguridad)
├─ Resultado: menor oferta histórica
└─ Algoritmo aprende: "zona X = baja oferta"

CÍRCULO VICIOSO
├─ Surge pricing frecuente → riders cancelan
├─ Riders cancelan → confirmación de "baja demanda"
├─ Algoritmo asigna menos drivers a zona
├─ Aún menos oferta → más surge pricing
└─ Loop se perpetúa

IMPACTO SOCIOECONÓMICO
├─ Comunidades de bajos ingresos pagan más
├─ O no pueden acceder a transporte
├─ Afecta acceso a trabajo, salud, educación
└─ Movilidad económica limitada por algoritmo

La Respuesta

Uber (inicialmente): Defendió algoritmo como "neutral de datos".

Realidad: Neutralidad de datos ≠ Fairness de outcomes.

Cambios implementados (2020+):

• Incentivos para drivers en zonas desatendidas
• Programas de subsidio en comunidades específicas
• Mayor transparencia en surge pricing

Lecciones Clave

1. Optimización Económica ≠ Justicia Social

   • Algoritmo maximizó revenue, no equidad
   • KPIs necesitan incluir fairness

2. Neutral en Código ≠ Neutral en Impacto

   • Algoritmo no menciona raza o ingreso
   • Pero outcomes son desproporcionalmente dañinos

3. Feedback Loops Amplifican Desigualdad

   • Pequeño sesgo inicial → círculo vicioso
   • Sin intervención, brecha crece exponencialmente

4. Contexto Histórico Importa

   • "Baja oferta" en zona X tiene razones históricas/sociales
   • No solo "el mercado lo decidió"

---

Caso 3: Healthcare Algorithm - Racial Bias

El Contexto

2019, Study en Science Magazine:

Algoritmo usado por sistemas de salud en EEUU para identificar pacientes de "alto riesgo" que necesitan programas de cuidado especial.

Usado por: Hospitales y aseguradoras sirviendo a ~200 millones de personas.

Objetivo: Predecir qué pacientes necesitarán más recursos médicos.

El Problema

Hallazgo devastador:

Para el mismo nivel de riesgo de salud, pacientes negros recibían scores significativamente más bajos que pacientes blancos.

Resultado: Pacientes negros necesitaban estar MUCHO MÁS ENFERMOS para recibir el mismo nivel de atención.

Números:

• A igual salud, pacientes blancos: score 70
• Pacientes negros: score 55
• 46% menos de pacientes negros recibían cuidado extra vs lo que deberían

Impacto: Millones de pacientes negros con condiciones crónicas no recibieron atención necesaria.

La Causa Raíz

TARGET DEL MODELO
├─ Objetivo: Predecir "costo de healthcare futuro"
├─ Asunción: Alto costo = alta necesidad médica
└─ ERROR: Esta asunción ignora disparidades de acceso

REALIDAD HISTÓRICA
├─ Pacientes negros tienen menos acceso a healthcare
├─ Mismo nivel de enfermedad → menos visitas médicas
├─ Menos visitas → menos costo registrado
├─ Algoritmo aprende: "negros cuestan menos"
└─ Resultado: "Necesitan menos atención"

EL SESGO REAL
├─ Costo ≠ Necesidad (para poblaciones con acceso desigual)
├─ Algoritmo predijo costo correctamente
├─ Pero costo era proxy HORRIBLE de necesidad médica
└─ "Accurate but unfair"

El algoritmo era técnicamente "preciso" prediciendo costos. El problema: predijo la métrica equivocada.

La Respuesta

Post-publicación:

• Sistemas hospitalarios revisaron algoritmos
• Reguladores exigieron auditorías de fairness
• Industria comenzó a cuestionar proxies tradicionales

Fixes implementados:

• Cambiar target: de "costo" a "necesidad médica real"
• Usar indicadores clínicos directos (labs, diagnósticos)
• Auditorías regulares por disparidad racial

Resultado (post-fix):

• Disparidad cayó de 46% a 17%
• Aún no perfecto, pero mejora masiva

Lecciones Clave

1. El Target Importa Más Que El Algoritmo

   • Puedes tener modelo perfecto, target equivocado
   • "Predecir correctamente la métrica equivocada"

2. Proxies Pueden Ocultar Sesgo

   • "Costo" sonaba neutral
   • Pero costo reflejaba acceso histórico desigual

3. Accurate ≠ Fair

   • Accuracy técnica no garantiza justicia
   • Necesitas medir fairness explícitamente

4. Escala Amplifica Impacto

   • 200 millones de personas afectadas
   • Lo que funcionaba (mal) en papel → catástrofe humana a escala

---

Tipos de Sesgo en IA

Taxonomía de Sesgos

1. SESGO DE DATOS
   ├─ Histórico: Datos reflejan discriminación pasada
   ├─ Representación: Grupos subrepresentados
   ├─ Medición: Cómo se colectaron/etiquetaron datos
   └─ Agregación: Grupos diversos tratados como uno

2. SESGO DE DISEÑO
   ├─ Target/Proxy: Métrica equivocada o proxy sesgado
   ├─ Features: Variables que correlacionan con grupos protegidos
   ├─ Modelo: Arquitectura favorece ciertos grupos
   └─ Evaluación: Métricas no miden fairness

3. SESGO DE DEPLOYMENT
   ├─ Contexto: Usado en contexto diferente al entrenamiento
   ├─ Feedback: Decisiones del modelo retroalimentan datos
   ├─ Interacción: Usuarios interactúan diferente por grupo
   └─ Amplificación: Pequeños sesgos se magnifican

Sesgo de Datos: Ejemplos

1. Historical Bias (Amazon)

Datos: 10 años de contrataciones tech (80% hombres)
Resultado: Modelo aprende que "ser hombre" predice éxito
Realidad: Datos reflejan discriminación histórica, no capacidad real

2. Representation Bias

Ejemplo: Sistema de reconocimiento facial
Datos: 90% fotos de personas blancas
Resultado: 99% accuracy para blancos, 65% para negros
Consecuencia: False arrests de personas negras

3. Measurement Bias

Ejemplo: Scoring de riesgo crediticio
Dato: Historial de préstamos pagados
Sesgo: Grupos sin acceso a crédito → sin historial → rechazados
Círculo: Sin acceso → sin historial → sin acceso

4. Aggregation Bias

Ejemplo: Modelo de diagnóstico médico
Datos: Promedios de población general
Sesgo: Síntomas de mujeres/minorías difieren del promedio
Resultado: Diagnósticos erróneos para grupos minoritarios

Sesgo de Diseño: Ejemplos

1. Proxy Bias (Healthcare)

Target: Predecir "costo de healthcare"
Proxy de: "Necesidad médica"
Error: Costo depende de acceso, no solo de necesidad
Resultado: Subestima necesidad de grupos con poco acceso

2. Feature Bias

Ejemplo: Lending algorithm
Feature: Código postal
Proxy de: Raza/etnicidad (redlining histórico)
Resultado: Discriminación geográfica = discriminación racial

3. Label Bias

Ejemplo: Recidivism prediction (COMPAS)
Label: "Arrestado en 2 años"
Sesgo: Comunidades minoritarias sobre-policiadas
Resultado: Más arrestos ≠ más crimen, solo más vigilancia

Sesgo de Deployment: Ejemplos

1. Feedback Loop (Uber)

1. Algoritmo asigna menos drivers a zona X
2. Usuarios en zona X tienen mala experiencia
3. Usan app menos → "confirma" baja demanda
4. Algoritmo asigna aún menos drivers
5. Loop se amplifica

2. Context Shift

Ejemplo: Modelo entrenado en hospital urbano rico
Deployment: Hospital rural pobre
Resultado: Pacientes, equipamiento, protocolos diferentes
Outcome: Modelo inefectivo o dañino

---

Framework de Detección: 15 Puntos de Auditoría

FASE 1: Auditoría de Datos (Puntos 1-5)

1. Representación de Grupos

# Checklist
✓ ¿Todos los grupos demográficos relevantes están representados?
✓ ¿Proporción en datos ≈ proporción en población objetivo?
✓ ¿Hay grupos con <5% de representación?

# Acción
- Calcular distribución por grupo protegido
- Comparar con población real
- Identificar gaps de >20%

# Red Flag
Grupo X es 15% de usuarios pero <2% de datos entrenamiento

2. Calidad por Grupo

# Checklist
✓ ¿Calidad de datos es similar entre grupos?
✓ ¿Missing values distribuidos uniformemente?
✓ ¿Ruido/errores afectan grupos diferencialmente?

# Acción
- Calcular completeness, accuracy por grupo
- Identificar si errors están concentrados

# Red Flag
Datos de grupo X tienen 30% missing values vs 5% en grupo Y

3. Labels y Etiquetado

# Checklist
✓ ¿Cómo se definió la label?
✓ ¿Quién etiquetó? ¿Sesgo del etiquetador?
✓ ¿Label mide directamente el outcome deseado?

# Acción
- Documentar proceso de etiquetado
- Inter-rater reliability por grupo
- Validar que label = objetivo real

# Red Flag
Labels de grupo X hechas por etiquetadores sin conocimiento cultural

4. Bias Histórico

# Checklist
✓ ¿Datos reflejan discriminación histórica?
✓ ¿Hay eventos históricos que sesgaron colecta?
✓ ¿Cambios sociales desde entonces?

# Acción
- Timeline de colecta de datos
- Investigar contexto histórico
- Consultar expertos de dominio

# Red Flag
Datos de contratación pre-leyes de igualdad de oportunidad

5. Features como Proxies

# Checklist
✓ ¿Alguna feature correlaciona con grupo protegido?
✓ ¿Código postal, nombre, afiliaciones son proxies?
✓ ¿Features compuestas ocultan proxies?

# Acción
- Correlación entre features y grupos protegidos
- Identificar proxies sutiles (ej: "prestigio escuela")
- Considerar remover o des-correlacionar

# Red Flag
Código postal correlaciona 0.8 con raza

FASE 2: Auditoría de Modelo (Puntos 6-10)

6. Métricas de Fairness

# Checklist
✓ ¿Calculas accuracy por grupo?
✓ ¿Mides disparate impact?
✓ ¿Defines fairness constraint explícito?

# Métricas Clave
- Demographic Parity: P(Y=1|A=0) ≈ P(Y=1|A=1)
- Equal Opportunity: TPR similar entre grupos
- Equalized Odds: TPR y FPR similares entre grupos

# Red Flag
Accuracy: 95% para grupo X, 75% para grupo Y

7. Error Distribution

# Checklist
✓ ¿False positives afectan grupos diferencialmente?
✓ ¿False negatives distribuidos equitativamente?
✓ ¿Qué tipo de error es más dañino?

# Acción
- Confusion matrix por grupo
- Analizar cuál error tiene más costo
- Ajustar threshold por grupo si necesario

# Red Flag
False arrests (FP) 5x más comunes en grupo minoritario

8. Feature Importance por Grupo

# Checklist
✓ ¿Modelo usa features diferentes para grupos diferentes?
✓ ¿Hay features que solo importan para grupo específico?
✓ ¿SHAP values similares entre grupos?

# Acción
- SHAP/LIME por grupo
- Comparar top features entre grupos
- Validar que lógica sea coherente

# Red Flag
Para grupo X usa "código postal", para Y usa "educación"

9. Calibración

# Checklist
✓ ¿Probabilidades predichas reflejan probabilidad real?
✓ ¿Calibración similar entre grupos?
✓ ¿Modelo "confiado" para unos, "dudoso" para otros?

# Acción
- Reliability diagram por grupo
- Brier score por grupo
- Re-calibrar si necesario

# Red Flag
Score 0.7 = 90% chance para grupo X, 50% para grupo Y

10. Interseccionalidad

# Checklist
✓ ¿Auditas combinaciones de grupos? (ej: mujeres negras)
✓ ¿Hay compounding bias?
✓ ¿Performance cae exponencialmente para intersecciones?

# Acción
- Crear matriz de performance (gender x race x age)
- Identificar intersecciones con performance pobre
- Priorizar grupos más afectados

# Red Flag
Mujeres negras >50: accuracy 60% vs 95% baseline

FASE 3: Auditoría de Deployment (Puntos 11-15)

11. Feedback Loops

# Checklist
✓ ¿Decisiones del modelo afectan datos futuros?
✓ ¿Hay círculo vicioso potencial?
✓ ¿Diseñaste circuit breakers?

# Acción
- Map flujo: decisión → outcome → nuevos datos
- Identificar loops que amplifican sesgo
- Implementar monitoreo de drift por grupo

# Red Flag
Modelo rechaza grupo X → menos datos de X → más rechazos de X

12. Context Appropriateness

# Checklist
✓ ¿Contexto de deployment = contexto de entrenamiento?
✓ ¿Población objetivo representada en datos?
✓ ¿Infraestructura/procesos compatibles?

# Acción
- Comparar características de data vs deployment
- Pilot en subgrupo representativo
- Validar performance en contexto real

# Red Flag
Entrenado en hospital urbano, usado en rural

13. Human-in-the-Loop

# Checklist
✓ ¿Decisiones de alto impacto tienen revisión humana?
✓ ¿Humanos pueden override?
✓ ¿Proceso de apelación para afectados?

# Acción
- Definir threshold de human review
- Training de reviewers en fairness
- Tracking de overrides por grupo

# Red Flag
100% decisiones automáticas, sin apelación

14. Monitoreo Continuo

# Checklist
✓ ¿Dashboard de fairness en producción?
✓ ¿Alertas automáticas de drift de fairness?
✓ ¿Frecuencia de re-entrenamiento considera fairness?

# Acción
- Metrics de fairness en real-time dashboard
- Alertas si disparate impact > threshold
- Auditoría trimestral programada

# Red Flag
Solo monitoreamos accuracy global, no por grupo

15. Transparencia y Explicabilidad

# Checklist
✓ ¿Puedes explicar decisión a afectado?
✓ ¿Documentación clara de limitaciones?
✓ ¿Stakeholders entienden cómo funciona?

# Acción
- Model cards con fairness limitations
- Explanations en lenguaje plain
- Training de usuarios en interpretar outputs

# Red Flag
"Es un black box, solo confía en el score"

---

Técnicas de Mitigación

Pre-Processing: Fixing Data

1. Re-sampling

# Problema: Grupo minoritario subrepresentado
# Solución: Over-sample minority, under-sample majority

Técnicas:
- SMOTE (Synthetic Minority Over-sampling)
- Random under-sampling de majority
- Balanced batch sampling

Trade-off:
+ Balances representación
- Puede over-fit a minority o sub-fit a majority

2. Re-weighting

# Problema: Grupos desbalanceados
# Solución: Dar más peso a ejemplos de minority

Técnicas:
- Inverse frequency weighting
- Focal loss (más peso a ejemplos difíciles)

Trade-off:
+ No altera datos
- Puede sobre-enfatizar outliers

3. Data Augmentation

# Problema: Pocos ejemplos de grupo X
# Solución: Generar ejemplos sintéticos

Técnicas:
- Fairness-aware data generation
- Counterfactual data augmentation

Trade-off:
+ Aumenta diversidad
- Datos sintéticos pueden no reflejar realidad

In-Processing: Fair Learning

1. Fairness Constraints

# Agregar constraint al objetivo del modelo

Objetivo tradicional:
minimize(loss)

Objetivo fair:
minimize(loss) subject to fairness_constraint

Constraints:
- Demographic parity: P(Y=1|A=0) ≈ P(Y=1|A=1)
- Equal opportunity: TPR_group0 ≈ TPR_group1
- Equalized odds: TPR y FPR similares

Tool: Fairlearn (Microsoft), AIF360 (IBM)

2. Adversarial Debiasing

# Entrenar modelo que no puede predecir grupo protegido

Arquitectura:
Input → Predictor → Output (Y)
         ↓
      Adversary → Output (A - grupo protegido)

Objetivo:
- Predictor maximiza accuracy de Y
- Adversary intenta predecir A
- Predictor minimiza ability de adversary

Resultado: Predictor aprende features que no revelan A

3. Multi-Objective Optimization

# Optimizar accuracy Y fairness simultáneamente

Pareto optimization:
- Objective 1: Maximize accuracy
- Objective 2: Maximize fairness metric
- Resultado: Conjunto de modelos en Pareto frontier

Usuario elige trade-off aceptable

Post-Processing: Adjusting Outputs

1. Threshold Adjustment

# Diferentes thresholds por grupo para igualar metric

Ejemplo: Equal Opportunity
- Encuentra threshold_A y threshold_B tal que:
  TPR_groupA(threshold_A) = TPR_groupB(threshold_B)

Tool: Fairlearn's ThresholdOptimizer

Trade-off:
+ Fácil de implementar
+ No requiere re-entrenar
- Puede reducir accuracy global

2. Calibration

# Re-calibrar scores para que reflejen probabilidad real por grupo

Técnicas:
- Platt scaling por grupo
- Isotonic regression por grupo

Resultado:
Score 0.7 = 70% probabilidad real (para todos los grupos)

3. Reject Option Classification

# En zona de incertidumbre, favorece grupo desfavorecido

Ejemplo:
Scores 0.4-0.6 = "uncertain"
En zona uncertain:
- Favorece grupo minoritario
- O deriva a human review

Trade-off:
+ Mitiga bias sin sacrificar mucho accuracy
- Zona "uncertain" es arbitraria

---

Checklist de IA Responsable

Antes del Proyecto

□ Definir fairness constraints explícitos
  ¿Qué métrica de fairness priorizamos?
  ¿Qué disparidad es aceptable/inaceptable?

□ Identificar grupos protegidos relevantes
  Raza, género, edad, discapacidad, etc.
  Considerar intersecciones

□ Stakeholder engagement
  Incluir representantes de grupos afectados
  Consultar expertos en fairness/ethics

□ Risk assessment
  ¿Qué daño puede causar bias?
  ¿Es reversible? ¿A quién afecta más?

□ Regulatory compliance
  GDPR, CCPA, fair lending laws, etc.
  Documentación de decisiones de diseño

Durante Desarrollo

□ Data audits (Puntos 1-5 del Framework)
  Representación, calidad, labels, historia, proxies

□ Model audits (Puntos 6-10 del Framework)
  Fairness metrics, errors, calibración, interseccionalidad

□ Bias mitigation techniques
  Pre-processing, in-processing, o post-processing

□ Explainability
  ¿Puedes explicar decisiones?
  Model cards, documentation

□ Adversarial testing
  Red team intenta encontrar sesgos
  Test en edge cases y grupos minoritarios

Pre-Deployment

□ Deployment audits (Puntos 11-15 del Framework)
  Feedback loops, contexto, human-in-loop, monitoreo

□ Pilot con monitoreo intensivo
  Empezar en subconjunto
  Monitorear fairness en tiempo real

□ Human review process
  Define qué decisiones requieren revisión
  Entrena reviewers en sesgos

□ Appeal process
  Cómo pueden afectados apelar decisiones
  Tracking de apelaciones por grupo

□ Communication plan
  Cómo comunicarás limitaciones
  Transparencia con usuarios

Post-Deployment

□ Continuous monitoring
  Dashboard de fairness metrics
  Alertas automáticas de drift

□ Quarterly audits
  Re-run framework completo
  Actualizar métricas de fairness

□ Incident response plan
  Qué hacer si detectas bias
  Circuit breakers para detener sistema

□ Re-training strategy
  Cuándo y cómo re-entrenar
  Asegurar nuevos datos no introducen bias

□ Stakeholder feedback
  Surveys de usuarios afectados
  Incorporar feedback en mejoras

---

Caso Práctico: Auditando un Sistema Real

Escenario

Tu empresa usa un modelo de credit scoring para aprobar préstamos.

Datos históricos: 50,000 préstamos (2015-2023)

Alerta: Tasa de rechazo de mujeres es 25% vs 15% de hombres.

Tu tarea: Auditar el sistema usando el Framework de 15 puntos.

Paso 1: Auditoría de Datos

# Punto 1: Representación
Mujeres: 35% de aplicantes, 30% de datos aprobados
→ RED FLAG: Subrepresentadas en datos positivos

# Punto 2: Calidad
Missing income data: 20% mujeres vs 5% hombres
→ RED FLAG: Calidad desigual

# Punto 3: Labels
Label = "pagó a tiempo en 2 años"
Mujeres tienen menos historial crediticio histórico
→ RED FLAG: Label sesgado por acceso histórico

# Punto 4: Bias Histórico
Datos incluyen época pre-Equal Credit Opportunity Act compliance
→ RED FLAG: Reflejan discriminación histórica

# Punto 5: Features como Proxies
Feature "Años en trabajo actual":
Mujeres más career breaks (maternidad)
→ RED FLAG: Proxy de género

Hallazgos Fase 1: 5/5 red flags. Datos problemáticos.

Paso 2: Auditoría de Modelo

# Punto 6: Métricas de Fairness
Approval rate: 85% hombres, 75% mujeres
Disparate impact: 0.88 (threshold legal: 0.80)
→ YELLOW FLAG: Cerca de límite

# Punto 7: Error Distribution
False Negatives (rechaza a quien debería aprobar):
15% mujeres vs 8% hombres
→ RED FLAG: Error más costoso afecta más a mujeres

# Punto 8: Feature Importance
Top features para mujeres: "Años trabajo", "Historial"
Top features para hombres: "Income", "Assets"
→ RED FLAG: Lógica diferente por grupo

# Punto 9: Calibración
Score 0.6 = 70% pay rate (hombres), 80% pay rate (mujeres)
→ RED FLAG: Modelo subestima creditworthiness de mujeres

# Punto 10: Interseccionalidad
Mujeres jóvenes (<30): approval rate 65%
Hombres jóvenes: 80%
→ RED FLAG: Compounding bias

Hallazgos Fase 2: 5/5 red flags. Modelo tiene bias significativo.

Paso 3: Plan de Mitigación

# INMEDIATO (esta semana)
1. Human review de rechazos de mujeres en "zona gris" (scores 0.45-0.55)
2. Alertas si disparate impact < 0.85
3. Pausar automated rejections hasta fix

# CORTO PLAZO (este mes)
4. Re-calibrar modelo por género
5. Threshold adjustment para equal opportunity
6. Remover/des-correlacionar features proxy

# MEDIANO PLAZO (este trimestre)
7. Re-entrenar con fairness constraints
8. Data augmentation para balancear representación
9. Implement adversarial debiasing

# LARGO PLAZO (continuamente)
10. Monitoreo continuo de fairness metrics
11. Auditorías trimestrales
12. Stakeholder feedback de mujeres rechazadas

Resultado Esperado

ANTES DEL FIX
├─ Approval: 85% hombres, 75% mujeres
├─ Disparate impact: 0.88
├─ False negatives: 15% mujeres
└─ Costo: Posibles demandas, pérdida clientes

DESPUÉS DEL FIX (post 3 meses)
├─ Approval: 82% hombres, 80% mujeres
├─ Disparate impact: 0.98
├─ False negatives: 9% mujeres, 8% hombres
└─ Beneficio: Compliance, más clientes, mejor reputación

Trade-off: 3% menos approvals de hombres
Pero: Más fair, legalmente defendible, éticamente correcto

---

Resumen: De Detección a Acción

Framework en Una Página

AUDITORÍA DE DATOS (5 puntos)
1. Representación: ¿Todos los grupos presentes?
2. Calidad: ¿Calidad uniforme entre grupos?
3. Labels: ¿Etiquetado sesgado?
4. Historia: ¿Datos reflejan discriminación?
5. Proxies: ¿Features correlacionan con grupos protegidos?

AUDITORÍA DE MODELO (5 puntos)
6. Fairness: ¿Métricas de equidad medidas?
7. Errores: ¿Distribuidos equitativamente?
8. Features: ¿Importancia similar entre grupos?
9. Calibración: ¿Scores reflejan probabilidad real?
10. Interseccionalidad: ¿Auditas combinaciones?

AUDITORÍA DE DEPLOYMENT (5 puntos)
11. Feedback: ¿Círculos viciosos posibles?
12. Contexto: ¿Apropiado para uso real?
13. Human-in-loop: ¿Revisión de decisiones críticas?
14. Monitoreo: ¿Tracking continuo de fairness?
15. Transparencia: ¿Explicable y documentado?

Señales de Alerta

DETÉN EL PROYECTO SI:

• ❌ Disparate impact < 0.80 (umbral legal EEOC)
• ❌ No puedes explicar decisiones a reguladores
• ❌ Grupos protegidos tienen <5% representación en datos
• ❌ Error rates difieren >20% entre grupos
• ❌ No existe plan de monitoreo post-deployment

PROCEDE CON CAUTELA SI:

• ⚠️ Disparate impact 0.80-0.90
• ⚠️ Algún grupo tiene 5-10% representación
• ⚠️ Error rates difieren 10-20%
• ⚠️ Features son proxies sutiles
• ⚠️ Feedback loops posibles pero mitigables

OK PARA AVANZAR SI:

• ✅ Disparate impact > 0.90
• ✅ Todos los grupos >10% representación
• ✅ Error rates similares (<10% diferencia)
• ✅ Explicabilidad clara
• ✅ Monitoreo y human review implementados

Recursos para Profundizar

Herramientas Open Source:

1. Fairlearn (Microsoft)

   • Métricas de fairness
   • Algoritmos de mitigación
   • Dashboards de auditoría

2. AI Fairness 360 (IBM)

   • 70+ fairness metrics
   • 10+ bias mitigation algorithms
   • Tutorials y notebooks

3. What-If Tool (Google)

   • Visualización de bias
   • Counterfactual analysis
   • Threshold optimization

Papers Clave:

• "Fairness and Machine Learning" - Barocas, Hardt, Narayanan (libro gratuito online)
• "A Survey on Bias and Fairness in Machine Learning" - Mehrabi et al. 2021
• "Fairness Definitions Explained" - Verma & Rubin 2018

Frameworks Regulatorios:

• EU AI Act: Clasificación de riesgo, auditorías obligatorias
• GDPR: Right to explanation de decisiones automatizadas
• EEOC Guidelines: Disparate impact en employment
• Fair Lending Laws: Credit scoring y bias

---

Próximos Pasos

En la siguiente lección exploraremos IA Responsable: principios éticos, compliance básico con GDPR/CCPA, y un checklist completo de riesgos.

Reflexión Final:

"Los sesgos algorítmicos no son bugs—son features no deseados que resultan de diseño, datos y deployment descuidados. La diferencia entre un sistema que perpetúa desigualdad y uno que promueve equidad no es la tecnología, sino el compromiso con auditoría rigurosa, transparencia radical, y disposición a priorizar fairness sobre accuracy cuando sea necesario."

Tu Acción Esta Semana:

Elige un sistema de IA en tu organización. Aplica los primeros 5 puntos del Framework (Auditoría de Datos). Documenta hallazgos y comparte con tu equipo.

---

Caso de Estudio Adicional:

COMPAS (Correctional Offender Management Profiling for Alternative Sanctions)

• Sistema usado por cortes en EEUU para predecir recidivism
• ProPublica investigation (2016): Sesgo racial masivo
• False positive rate: 45% para negros vs 23% para blancos
• Resultado: Personas negras etiquetadas "high risk" sin justificación
• Impacto: Sentencias más largas basadas en predicción sesgada
• Lección: Alto stakes decisions requieren máximo escrutinio

Consecuencia: Movimiento nacional para auditar algoritmos en justicia criminal.