Módulo 1: Why Ethics Matters in AI Engineering

2. Case Study #1: Amazon Hiring Algorithm

Siguiente →

Descripción de la cápsula

Amazon empezó en 2014 a construir un sistema de ML que automatizara la review de currículums. La promesa era simple: tomar las decenas de miles de aplicaciones que recibían cada año, scorearlas con un modelo entrenado en patrones históricos de "qué buenos hires se ven como", y devolver un ranking. Los recruiters revisarían solo el top 10%.

En 2018, Reuters reveló que el sistema había sido decommissioned silenciosamente. La razón: discriminaba sistemáticamente contra mujeres, y a pesar de múltiples intentos de arreglarlo, el sesgo era estructural en los datos.

Esta cápsula desgrana el caso. No para asignar culpa moral, sino para extraer el mecanismo técnico de fallo y las prácticas que lo habrían prevenido. Porque no fue un accidente raro — fue el resultado predecible de aplicar ML a datos que reflejaban una historia sesgada, sin testing adecuado.

Lo que pasó

Timeline de los hechos

  • 2014: Amazon Edinburgh ML team comienza a construir el sistema. Objetivo: scoring automático de CVs en escala 1-5 estrellas.
  • 2014-2015: entrenamiento del modelo. Datos: 10 años de CVs recibidos por Amazon (2004-2014), con labels derivadas de quién fue hired y quién promovido.
  • 2015: el equipo descubre que el modelo penaliza CVs con la palabra "women's" (ej., "captain of women's chess club"). También baja scores a graduadas de dos colleges all-women.
  • 2015-2017: intentos de mitigación. Editan el modelo para tratar términos específicos como neutrales. Los issues persisten.
  • 2017: el equipo concluye que no pueden garantizar que el modelo sea fair. Lo desactivan para hiring de roles técnicos. Lo reusan para tareas auxiliares como data deduplication.
  • 2018: Reuters publica el reporte. Amazon confirma que el sistema fue abandonado.

Magnitud técnica

  • Volumen de entrenamiento: ~500,000 CVs.
  • Roles cubiertos: ingeniería, software development, ciencias de datos.
  • Periodo de uso interno: ~3 años antes de ser descontinuado.
  • Equipo involucrado: ~12 personas en Edinburgh ML team.

Por qué pasó: el mecanismo técnico de fallo

Esta es la sección crítica. No fue mala intención — fue un patrón de fallo estructural que cualquier modelo entrenado en datos históricos tiende a reproducir si no se hace bias testing explícito.

Paso 1: el dataset reflejaba una historia sesgada

Los datos de entrenamiento eran 10 años de CVs recibidos por Amazon entre 2004 y 2014, con labels positivas para los CVs que llevaron a hires y promociones.

En esos 10 años:

  • La industria tech tenía aproximadamente 70-80% de hombres en roles técnicos.
  • Amazon, como muchas empresas tech, recibía proporcionalmente menos CVs de mujeres.
  • Las mujeres que aplicaban tenían tasas de hire similares — pero el volumen absoluto era mucho menor.

El dataset, por lo tanto, tenía una fuerte correlación entre features asociadas a hombres y la label positiva. No porque las mujeres fueran peor candidatas, sino porque había muchos menos ejemplos positivos de mujeres.

Paso 2: el modelo aprendió la correlación, no la causalidad

Un modelo de ML, por diseño, aprende correlaciones estadísticas. No tiene noción de causalidad. No puede distinguir entre:

  • "Esta feature predice 'buen candidato' porque indica habilidad técnica."
  • "Esta feature predice 'buen candidato' porque está correlacionada con género masculino, y el dataset tiene sesgo histórico hacia hombres."

El modelo aprendió ambas cosas con igual fuerza. Detectó que palabras como "executed", "captured", "captured" eran predictivas del label positivo — porque eran más comunes en CVs de hombres en el dataset. Detectó que "women's" era predictiva del label negativo — porque CVs con esa palabra tenían menos labels positivos en el dataset.

Paso 3: las features explícitas no eran el único problema

Amazon, naturalmente, no incluyó "género" como feature explícita. Eso habría sido obviamente problemático.

El problema fue que el modelo encontró proxies:

  • Palabras directamente asociadas a género ("women's").
  • Nombres de colleges all-women.
  • Patrones de lenguaje correlacionados con género en el corpus de CVs.
  • Probablemente otros proxies más sutiles que nunca se identificaron completamente.

Eliminar el proxy explícito ("women's") no eliminó el sesgo. El modelo simplemente lo recapturó vía otros proxies más sutiles. Es un fenómeno conocido como proxy discrimination o redlining 2.0.

Paso 4: el sesgo no fue detectado en testing tradicional

Los tests estándar de ML — accuracy, precision, recall, F1, AUC — pasaron. El modelo era bueno prediciendo "quién recibió un offer" porque, como dijimos, eso es lo que aprendió.

Lo que no se midió en testing tradicional:

  • Disparate impact: ¿la tasa de "alto score" era similar entre grupos demográficos?
  • Equal opportunity: dada igual cualificación, ¿el score era similar entre grupos?
  • Calibration: para un score dado, ¿la probabilidad real de éxito era similar entre grupos?

Estos son fairness metrics, distintos de accuracy. Y son los que habrían detectado el problema en la primera semana.

El costo medible

Costo financiero directo

  • Desarrollo perdido: ~3 años × ~12 personas × salario senior ML eng ($180K) ≈ $6.5M en costo de personal.
  • Infraestructura: GPU compute para entrenamiento + servers de inference. Estimado ~$500K-$1M.
  • Costo de oportunidad: el equipo pudo haber construido sistemas con valor producible.

Total estimado: $7-10M en costo directo.

Costo reputacional

  • Coverage en Reuters, picked up por NYT, Washington Post, Wall Street Journal, BBC, decenas de medios técnicos. Coverage durante semanas.
  • Caso de estudio canónico en facultades de ingeniería, business schools y compliance training. Cada nuevo curso de ML ethics cita Amazon Hiring. Es daño reputacional permanente.
  • Impacto en hiring: candidatas senior reportan que el caso afectó su decisión de aplicar a Amazon. Difícil cuantificar, real.

Costo legal / regulatorio

  • No hubo demanda directa (el sistema no llegó a hacer hiring decisions binding antes de ser desactivado, según Amazon).
  • Aceleró regulación: el caso es citado en la propuesta del EU AI Act, en NYC AEDT Law (2023), y en propuestas state-level US.
  • Aumentó scrutinio sobre Amazon en otros sistemas: rekognition, advertising, etc.

Costo en personas afectadas

Si el sistema fue usado durante 3 años para filtrar CVs incluso parcialmente:

  • Aplicantes mujeres que recibieron rejection sin review humana real, basado en un score discriminatorio.
  • Mujeres que estaban underranked y nunca llegaron a entrevista.

Imposible saber el número exacto — Amazon no reveló datos. Pero dado el volumen (decenas de miles de CVs/año), el orden de magnitud es miles a decenas de miles de candidatas afectadas.

Cómo se podía prevenir: las técnicas que faltaron

Lo siguiente no es "Monday morning quarterbacking". Las técnicas existían en 2014. Algunos equipos las aplicaban. Amazon, como muchos otros, no.

Técnica 1: Bias testing explícito

Lo que se hizo: testear accuracy, precision, recall.

Lo que faltó: testear disparate impact y equal opportunity por grupo demográfico (género, edad, etnia donde fuera inferible).

Implementación concreta:

# Pseudo-código del test que faltó
def test_disparate_impact(model, test_set, protected_attribute):
    """
    Mide si el modelo tiene tasas de positive prediction
    significativamente distintas entre grupos.
    """
    group_a = test_set[test_set[protected_attribute] == 'A']
    group_b = test_set[test_set[protected_attribute] == 'B']
    
    rate_a = model.predict(group_a).mean()
    rate_b = model.predict(group_b).mean()
    
    ratio = min(rate_a, rate_b) / max(rate_a, rate_b)
    
    # Regla del 80%: ratio < 0.80 indica disparate impact
    return {
        "ratio": ratio,
        "passes_4_5_rule": ratio >= 0.80,
    }

Aplicado a Amazon Hiring, este test habría salido rojo desde la primera versión del modelo.

Técnica 2: Subgroup error analysis

Lo que se hizo: medir error agregado.

Lo que faltó: medir error por subgrupo. ¿El modelo tiene tasa de falsos negativos similar entre hombres y mujeres? ¿Entre graduadas de colleges all-women y all-male? ¿Por edad?

Si el error global es 5% pero el error en CVs femeninos es 15% y en masculinos 3%, el modelo no es 95% accurate para mujeres. Es 85%.

Técnica 3: Counterfactual testing

Lo que se hizo: test sets de datos reales.

Lo que faltó: tests con CVs idénticos excepto por marcadores de género. Si cambiás "Mary Smith, captain of women's chess club" por "John Smith, captain of chess club" y el score cambia, eso es discriminación causal, no correlación.

Implementación concreta:

# Pseudo-código de counterfactual test
def test_counterfactual_fairness(model, cv_template, gender_markers):
    cv_male = cv_template.replace_markers(gender_markers['male'])
    cv_female = cv_template.replace_markers(gender_markers['female'])
    
    score_male = model.score(cv_male)
    score_female = model.score(cv_female)
    
    delta = abs(score_male - score_female)
    
    # Si la única diferencia es género, los scores deberían ser ~iguales
    return {
        "delta": delta,
        "fair": delta < 0.05,  # tolerancia configurable
    }

Aplicado a Amazon Hiring, este test habría revelado el sesgo en el primer mes.

Técnica 4: Diversidad en el equipo de evaluación

Lo que se hizo: equipo predominantemente masculino evaluando outputs.

Lo que faltó: incluir personas de los grupos potencialmente afectados en el equipo de evaluación. Las mujeres del equipo notarían patrones que los hombres no — porque conocen el lenguaje y los contextos asociados.

Esto no es ética performativa. Es información. Equipos diversos detectan modos de fallo que equipos homogéneos no ven.

Técnica 5: Documentación de limitaciones (model cards)

Lo que se hizo: documentación interna técnica estándar.

Lo que faltó: un model card público (incluso para uso interno) que documente explícitamente:

  • Datos de entrenamiento: ratio M/F, ratio por edad, ratio por etnia.
  • Performance por subgrupo, no solo agregado.
  • Limitaciones conocidas.
  • Casos donde NO usar el modelo.

Si el model card hubiera dicho "este modelo tiene 85% accuracy para CVs femeninos vs 95% para masculinos", el deploy a hiring real habría sido bloqueado por compliance.

La lección estructural

Amazon no fue víctima de mala suerte ni de falta de talento. El equipo Edinburgh ML era de los mejores del mundo en su momento.

La lección estructural es:

Modelos entrenados en datos históricos reproducen los sesgos históricos. Sin proceso explícito de bias testing, esto es prácticamente garantizado.

Esto se aplica a:

  • Hiring algorithms (Amazon).
  • Credit scoring (cápsula 04).
  • Predictive policing.
  • Healthcare resource allocation.
  • Recommendation systems.
  • Cualquier sistema entrenado en data del pasado, predicciendo el futuro.

El sesgo no es una anomalía — es el default. El proceso ético es lo que lo previene.

Trampas y errores comunes en interpretar este caso

1. "Los engineers de Amazon eran malos"

No. Eran muy buenos. Eso es exactamente la lección — buenos engineers + datos sesgados + proceso inadecuado = sistema discriminatorio. La calidad del equipo no es protección.

2. "El problema era los datos, no el modelo"

Parcial. Los datos eran problemáticos, sí. Pero el problema completo es:

  • Datos sesgados +
  • Modelo que aprende correlaciones sin distinguir causalidad +
  • Testing que no incluía bias metrics +
  • Falta de proceso para detectar proxy variables +
  • Equipo homogéneo que no levantó banderas tempranas.

Solo "datos malos" no captura el fallo sistémico.

3. "Solo eliminar la feature de género resuelve el problema"

Falso, como demostró Amazon. El modelo encontró proxies. Eliminar features explícitas no elimina sesgo cuando hay proxies disponibles.

4. "Esto solo aplica a hiring; mi sistema es distinto"

Falso. El mecanismo (datos históricos sesgados → modelo aprende sesgo → proxies hacen invisible el problema → testing tradicional no detecta) aplica a cualquier sistema entrenado en datos del pasado. Si tu sistema toma decisiones que afectan a personas, el riesgo aplica.

Auto-verificación

1. ¿Por qué eliminar "género" como feature explícita no resolvió el problema?

Porque el modelo encontró proxies — features correlacionadas con género que el modelo usó para reconstruir la información. Ejemplos:

  • Palabras directamente asociadas: "women's" en clubs, deportes.
  • Colleges all-women que aparecen en CVs.
  • Patrones de lenguaje (verbos, sintaxis) que difieren estadísticamente entre géneros en el corpus.

Esto se llama proxy discrimination. Cualquier dataset suficientemente rico va a tener proxies. La única forma de mitigar es:

  1. Detectarlos explícitamente (tests counterfactuales).
  2. Aplicar técnicas de fairness post-training (re-weighting, adversarial debiasing).
  3. Validar disparate impact incluso después de eliminar features explícitas.
2. ¿Qué test técnico habría detectado el problema en el primer mes?

Disparate impact testing + counterfactual fairness testing.

Disparate impact: medir si la tasa de "alto score" era similar entre CVs masculinos y femeninos en el test set. Regla del 80% (4/5ths rule) habría salido roja.

Counterfactual: tomar 100 CVs reales, generar versiones con marcadores de género opuesto (mismos contenidos, distintos pronombres y referencias específicas de género). Pasar ambas versiones por el modelo. Medir delta de scores. Si el delta es > tolerancia, hay sesgo causal.

Ambos tests son baratos (no requieren re-entrenamiento), automatizables (corren en CI), y estaban disponibles en 2014.

3. ¿Por qué la diversidad en el equipo de evaluación es información, no virtue signaling?

Porque personas de grupos afectados detectan modos de fallo que personas no afectadas no notan. Es información empírica.

Ejemplo: una ingeniera mujer en el equipo Amazon habría notado más rápido que el modelo bajaba scores por palabras como "women's chess club" — porque reconoce el patrón de cómo mujeres en CVs describen actividades extracurriculares de manera distinta a hombres.

Esto no es teoría. Es señal estadística que un cerebro entrenado en ese contexto detecta. Equipos homogéneos pierden esa señal sistemáticamente.

Es análogo a: si testing un sistema en español, querés testers que hablen español, no solo inglés. Diversidad demográfica es lo mismo aplicado a sistemas que afectan a poblaciones diversas.

4. ¿Cuál es la regla general que extraés de este caso?

Modelos entrenados en datos históricos reproducen los sesgos históricos. Sin proceso explícito de bias testing y mitigación, esto es prácticamente garantizado.

Esto significa que para cualquier sistema AI que vas a construir:

  1. Asumí que tu dataset tiene sesgos históricos.
  2. Asumí que el modelo los va a aprender, incluso si quitás features obvias.
  3. Asumí que testing tradicional (accuracy/F1) no los va a detectar.
  4. Implementá testing específico de fairness ANTES de deployar.
  5. Documentá performance por subgrupo en model cards.
  6. Re-evaluá después de deploy con datos reales de producción.

El sesgo es el default. La ausencia de sesgo es lo que requiere trabajo.

Resumen y siguiente paso

  • Amazon construyó un sistema de hiring AI que discriminaba contra mujeres durante ~3 años antes de ser decommissioned.
  • El mecanismo: datos históricos sesgados → modelo aprende correlaciones de género vía proxies → testing tradicional no detecta → deploy sin bias testing explícito.
  • El costo: ~$7-10M directo + reputacional permanente + miles de candidatas afectadas + aceleración de regulación.
  • Las técnicas que faltaron: disparate impact testing, counterfactual fairness, subgroup error analysis, equipo diverso, model cards.
  • La lección estructural: el sesgo es el default cuando se entrena en datos históricos. El proceso ético es lo que lo previene.

Checkpoint: deberías poder explicar por qué Amazon no logró arreglar el sistema simplemente quitando la palabra "women's" de las features.

Puente a la siguiente cápsula: la cápsula 03 cubre el segundo case study: facial recognition con error rates desiguales por raza, que terminó causando arrestos erróneos reales. Vas a ver cómo un problema técnico (training data desbalanceada) se tradujo en consecuencias en el mundo físico, no solo en hiring digital. Y cómo la respuesta regulatoria (prohibiciones municipales en San Francisco, Boston, etc.) cambió el panorama legal en menos de 24 meses.

Recursos

  1. Reuters report on Amazon hiring algorithm (2018) — la historia original.
  2. Disparate impact analysis — fairness 101 — concepto legal y técnico.
  3. Model Cards for Model Reporting (Mitchell et al.) — paper canónico sobre documentación de modelos.
  4. Fairness Indicators (Google) — herramientas open source.
  5. 4/5 Rule en EEOC guidelines — referencia legal US.

Siguiente: 03-case-study-facial-recognition.md — Reconocimiento facial con error rates 100x más altos para personas de color.

Cápsula 02 de 08 — Módulo 1 — AI Ethics & Compliance Guide

← Anterior1. Introducción al módulo: Why Ethics Matters in AI EngineeringSiguiente →3. Case Study #2: Facial Recognition Bias