Módulo 1: Why Ethics Matters in AI Engineering

4. Case Study #3: Apple Card y Credit Scoring

Siguiente →

Descripción de la cápsula

Noviembre 2019. David Heinemeier Hansson (creador de Ruby on Rails) postea en Twitter que Apple Card le otorgó un crédito 20x más alto que a su esposa, a pesar de que ambos comparten finanzas, presentan impuestos conjuntos, y ella tiene mejor credit score que él.

El thread se viralizó. Steve Wozniak (co-fundador de Apple) respondió que él tuvo la misma experiencia: 10x más crédito que su esposa, mismas finanzas. Decenas de otras parejas reportaron lo mismo.

En menos de 60 días, el New York Department of Financial Services abrió una investigación formal. Goldman Sachs (emisor de Apple Card) tuvo que defender su algoritmo públicamente. Y aunque la investigación oficial concluyó (2021) que no encontró evidencia legal de discriminación intencional, el caso quedó como ejemplo canónico de proxy discrimination: cómo un modelo puede discriminar sin usar features explícitas de género.

Esta cápsula cubre el caso. El payoff técnico es entender proxy variables — features aparentemente neutras que actúan como proxy de atributos protegidos, produciendo disparate impact. Y aprender cómo detectarlas antes de deployar.

Lo que pasó

Timeline

  • Agosto 2019: Apple Card lanza, emitida por Goldman Sachs. Marketing: "the most transparent, customer-friendly credit card". Algoritmo de credit scoring: propietario, no documentado.
  • Noviembre 7, 2019: David Heinemeier Hansson postea:

    "The Apple Card is such a fucking sexist program. My wife and I filed joint tax returns, live in a community-property state, and have been married for a long time. Yet Apple's black box algorithm thinks I deserve 20x the credit limit she does."

  • Noviembre 10, 2019: Steve Wozniak responde:

    "The same thing happened to us. I got 10x the credit limit. We have no separate bank or credit card accounts or any separate assets. Hard to get to a human for a correction though. It's big tech in 2019."

  • Noviembre 11, 2019: NY Department of Financial Services anuncia investigación formal.
  • Noviembre-Diciembre 2019: cientos de reportes similares en Twitter. Algunas mujeres reportan ser rechazadas completamente cuando aplican como individuos pero aprobadas cuando aplican con sus maridos.
  • Marzo 2021: NYDFS publica reporte. Conclusión oficial: no encontraron violación de ley anti-discriminación. Pero el reporte recomienda: mejor transparencia, mejor proceso de appeal, mejor fairness testing.

Lo que dijo Goldman Sachs

Goldman defendió que:

  • No usaron género como feature en el modelo.
  • No tenían acceso al estado civil ni datos de la pareja.
  • Los límites se decidieron solo en base a credit history individual, ingresos individuales, y otros factores financieros del aplicante.

Esa defensa es probablemente factualmente correcta. Y aun así, los outputs del sistema mostraban patrón de género claro.

¿Cómo es posible? La respuesta: proxies.

Por qué pasó: el mecanismo de proxy discrimination

Qué es una proxy variable

Una proxy variable es una feature que parece neutra, pero está estadísticamente correlacionada con un atributo protegido. Cuando el modelo aprende a usarla, indirectamente aprende a usar el atributo protegido.

Ejemplos clásicos:

Feature aparenteProxy deCómo
Código postalRazaSegregación residencial histórica → ZIP correlaciona con raza
UniversidadRaza, género, claseUniversidades históricamente filtran demográficamente
NombreGénero, etniaNombres tienen distribución demográfica clara
Historial de empleo continuoGénero (mujeres)Pausas por maternidad fragmentan historial
Tipo de empleoGéneroDistribución de género desigual entre industrias
Compra de productos específicosGénero, claseCategorías de consumo difieren demográficamente
Hora de compra / patrón de gastoEdad, géneroPatrones de vida correlacionan con demografía

Por qué Apple Card podía discriminar sin features explícitas

Aunque Goldman no usó "género" como feature, usó muchas features que correlacionan con género:

Historia de crédito individual: en parejas heterosexuales tradicionales (especialmente parejas mayores), el crédito se ha emitido históricamente más al nombre del marido. Tarjetas conjuntas eran "primary cardholder" = marido por default. Eso produce que la mujer tenga historial de crédito propio más corto o más bajo, incluso si compartían las mismas tarjetas y pagaban juntos.

Aplicado a Wozniaks: Steve probablemente fue "primary" en tarjetas/préstamos durante 40+ años. Su esposa, técnicamente, tenía menos historia de crédito propia, aunque las finanzas familiares fueran exactamente las mismas.

Ingreso individual: en parejas donde un cónyuge gana significativamente más que el otro, el ingreso individual es más bajo para el cónyuge con menor ingreso, incluso si los gastos son compartidos.

Patrones de uso de crédito: tipos de compras correlacionan con género en datasets agregados. El modelo aprende eso.

Industry de empleo: si el aplicante es ingeniero (mayoritariamente masculino) vs profesor de yoga (mayoritariamente femenino), el modelo asocia industria con risk score. Indirectamente discrimina por género.

El proceso completo

Inputs aparentemente neutros:
  - credit history individual
  - ingreso individual  
  - patrones de uso
  - industria
  - código postal
  
        ↓
        
Modelo aprende correlaciones estadísticas
  
        ↓
        
Algunas correlaciones son proxies de género/raza/edad
  
        ↓
        
Output: credit limit con disparate impact
        por género (sin que el género esté en el modelo)

El género no entra; sale igual.

Por qué el modelo funciona "bien" individualmente pero falla agregadamente

A nivel individual, el modelo puede defenderse: "esta persona tiene historial de crédito X, ingreso Y, patrones Z; por eso recibe credit limit W". Cada variable es justificable.

A nivel agregado, la composición de variables produce sesgo: las mujeres como grupo tienen ciertas distribuciones de X, Y, Z que el modelo penaliza. El sesgo no está en una sola feature — está en cómo el conjunto de features sistemáticamente desfavorece al grupo.

Es como un casino donde cada juego individual tiene "fair odds" según una métrica, pero la composición de juegos disponibles favorece a la casa. Pieza por pieza, "fair". En agregado, sesgado.

El costo medible

Costo legal y regulatorio para Goldman/Apple

  • Investigación NYDFS: ~$1M+ en costos legales y de cumplimiento durante la investigación.
  • Cambios al sistema: Goldman tuvo que implementar process de re-evaluation. Costo operativo y de desarrollo.
  • Process de appeal: Goldman creó un proceso explícito para que aplicantes pidieran review humana de decisiones algorítmicas.
  • Cooperación regulatoria continua: Goldman ahora opera bajo escrutinio aumentado. Costos compliance permanentes mayores.

Costo reputacional

  • Coverage durante semanas en NYT, WSJ, FT, BBC, Bloomberg, decenas de medios.
  • Apple Card, marketing como "transparente y customer-friendly", quedó manchada con "algorithmic discrimination".
  • Decenas de blog posts y casos de estudio académicos. Caso enseñado en MBA programs.

Costo personal a aplicantes

Las mujeres reportaron:

  • Recibir credit limits dramáticamente más bajos que sus parejas con finanzas idénticas.
  • Sentir que tenían que "explicar su valor" mientras sus maridos no.
  • Imposibilidad de obtener clear answer sobre por qué el algoritmo decidió X.
  • Frustration con customer service ("no podemos explicar la decisión, es un algoritmo").

Costo regulatorio para la industria fintech

  • Aceleró regulación de "explainable AI" en credit decisions.
  • Reforzó FCRA (Fair Credit Reporting Act) application a sistemas de ML.
  • Catalizó proposals como el Algorithmic Accountability Act (US).
  • EU: el caso es citado en la sección de credit scoring del EU AI Act.

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

Técnica 1: Disparate impact testing

Faltó: testear si los outputs del modelo tenían tasa de aprobación o credit limits significativamente desiguales por subgrupo demográfico.

Aunque género no era input, el modelo podía ser tested para ver si el output diferenciaba por género. Goldman pudo (debió) hacer un análisis interno donde:

  1. Tomar muestra de aplicantes históricos.
  2. Inferir o joinear con datos demográficos donde fuera legal.
  3. Calcular tasa de aprobación / credit limit promedio por género.
  4. Aplicar 4/5 rule.

Si el ratio resultaba < 80%, el modelo tenía disparate impact y debía ser revisado antes de ir a producción.

Implementación:

def disparate_impact_test(model_decisions, demographics):
    """
    model_decisions: DataFrame con scores/aprobaciones
    demographics: DataFrame con género, etnia, etc.
    """
    merged = model_decisions.merge(demographics, on='applicant_id')
    
    by_gender = merged.groupby('gender').agg({
        'approved': 'mean',
        'credit_limit': 'mean',
    })
    
    approval_ratio = (
        by_gender.loc['F', 'approved'] / 
        by_gender.loc['M', 'approved']
    )
    
    limit_ratio = (
        by_gender.loc['F', 'credit_limit'] / 
        by_gender.loc['M', 'credit_limit']
    )
    
    return {
        'approval_ratio_F_to_M': approval_ratio,
        'limit_ratio_F_to_M': limit_ratio,
        'passes_4_5_rule_approval': approval_ratio >= 0.80,
        'passes_4_5_rule_limit': limit_ratio >= 0.80,
    }

Técnica 2: Detección de proxy variables

Faltó: análisis explícito de qué features actúan como proxies de atributos protegidos.

Implementación: para cada feature en el modelo, calcular la correlación con género (donde sea inferible), raza (vía ZIP, nombre), edad. Features con correlación alta son proxies sospechosas.

def detect_proxies(features_df, protected_attribute):
    """
    Para cada feature, calcular cuánto predice protected_attribute.
    Si una feature predice bien protected_attribute, es proxy.
    """
    from sklearn.linear_model import LogisticRegression
    
    proxies = {}
    for feature in features_df.columns:
        if feature == protected_attribute:
            continue
        
        X = features_df[[feature]]
        y = features_df[protected_attribute]
        
        model = LogisticRegression()
        model.fit(X, y)
        accuracy = model.score(X, y)
        
        # Si una feature sola predice protected con >60% accuracy
        # (mejor que 50/50 random), es proxy fuerte
        proxies[feature] = {
            'predicts_protected_accuracy': accuracy,
            'is_strong_proxy': accuracy > 0.60,
        }
    
    return proxies

Si Goldman hubiera corrido este test sobre sus features, habría visto que features como "industry of employment", "credit history length", "average transaction patterns" predicen género con accuracy > 70-80%. Eso es señal clara de proxy.

Técnica 3: Mitigación post-detección

Detectar proxies no es suficiente. Hay que mitigar.

Opciones:

Opción A: Eliminar la feature (drástico, pierde signal predictivo).

Opción B: Re-balancear training data para que la correlación se diluya.

Opción C: Adversarial debiasing — entrenar el modelo con un loss adicional que penaliza si las predicciones correlacionan con atributos protegidos. Técnicamente complejo pero efectivo.

Opción D: Post-processing — ajustar outputs post-prediction para igualar tasas de aprobación entre grupos. Controvertido pero usado en algunas regulated industries.

Goldman podría haber aplicado cualquiera de estas. No lo hizo (al menos no antes del lanzamiento).

Técnica 4: Explainability para customers

Faltó: cuando un aplicante recibió credit limit bajo, no había explicación. "El algoritmo decidió" no es explicación.

Implementación: para cada decisión, generar explicación usando técnicas como SHAP o LIME que muestren qué features impactaron más la decisión. Eso permite:

  • Aplicante entiende por qué.
  • Aplicante puede pedir review si la explicación parece basada en feature problemática.
  • Auditores externos pueden ver el reasoning.

Goldman, post-controversia, implementó algo así. Antes, no.

Técnica 5: Joint application option

Faltó: aceptar joint applications donde finanzas son compartidas (parejas casadas, en community property states).

Apple Card no aceptaba joint applications inicialmente. Cada cónyuge aplicaba como individual, lo que activaba el sesgo.

Después de la controversia, Apple/Goldman agregaron opción de joint accounts. Pero el sistema inicial no la tenía — diseño sub-óptimo desde lanzamiento.

La lección estructural

Eliminar features explícitas de atributos protegidos NO elimina discriminación cuando hay proxies disponibles. Disparate impact testing del output es lo que detecta el problema, no inspección de features inputs.

Esto es el principio del proxy discrimination, central en compliance moderna:

  • US Fair Housing Act y Equal Credit Opportunity Act prohíben discriminación por proxy explícito.
  • Casos legales recientes (en US y EU) están aplicando esta lógica a ML.
  • EU AI Act incluye disparate impact como criterio de evaluación.

Para tu trabajo: siempre testear el output del modelo por subgrupo demográfico, no solo inspeccionar las inputs.

Trampas y errores comunes en interpretar este caso

1. "Si no incluyo género/raza, no puedo discriminar"

Falso, como demostró Apple Card. Proxies hacen el problema invisible al inspeccionar inputs. Output testing es la forma de detectar.

2. "Esto solo aplica a credit scoring"

Falso. Proxy discrimination aparece en:

  • Hiring (Amazon — palabra "women's" como proxy).
  • Insurance pricing.
  • Healthcare resource allocation.
  • Recommendation systems.
  • Content moderation.
  • Cualquier sistema con decisiones que afecten a personas.

3. "El modelo era técnicamente correcto"

Posiblemente, sí. Y eso no es defensa. El modelo capturaba patrones reales del mundo (incluyendo su sesgo histórico). El problema no es que el modelo sea técnicamente incorrecto — el problema es que reproducir patrones históricos sesgados en decisiones futuras perpetúa el sesgo. La función ética del sistema es no replicar el patrón, no copiarlo fielmente.

4. "NYDFS no encontró violación, entonces todo bien"

NYDFS no encontró violación legal. Eso significa que el sistema no violó las leyes específicas vigentes en NY. No significa que el sistema fuera ético, justo, o bien diseñado.

Compliance ≠ ética (volvemos a la cápsula 01). Pasar legal mínimo no es lo mismo que estar bien.

Auto-verificación

1. ¿Cómo puede un modelo discriminar por género si "género" no es una de sus features?

Vía proxies: features aparentemente neutras correlacionadas estadísticamente con género.

Ejemplos:

  • Credit history length: mujeres mayores típicamente tienen historiales propios más cortos por patrones históricos de "primary cardholder".
  • Industry of employment: industrias tienen distribución de género desigual.
  • Patrones de transacción: tipos de compras correlacionan con demografía.

El modelo aprende que estas features predicen "buen candidato a alto credit limit". Indirectamente, discrimina por género.

Solución: medir disparate impact del output, no solo inspeccionar inputs.

2. ¿Cuál es la diferencia entre disparate treatment y disparate impact?

Disparate treatment: tratamiento explícitamente diferente por atributo protegido. "Si es mujer, restar 10 puntos" — claramente ilegal.

Disparate impact: tratamiento aparentemente neutral que resulta en outcomes desiguales por grupo. Por ejemplo, requirement "10 años de historial laboral continuo" — neutral en superficie, pero excluye desproporcionadamente a mujeres por pausas de maternidad.

ML produce mucho más disparate impact que disparate treatment. La regulación moderna (US, EU) cubre ambas. Pero detectar disparate impact requiere análisis estadístico — no se ve inspeccionando código.

Implicación práctica: tu sistema puede tener cero discriminación intencional y aun así producir disparate impact ilegal. Testing del output es lo que detecta.

3. ¿Por qué "el modelo capturó patrones reales" no es defensa válida?

Porque los patrones reales del pasado incluyen sesgos sistémicos (segregación residencial histórica, discriminación de género histórica en empleo, etc.). Un modelo que captura fielmente esos patrones perpetúa el sesgo en decisiones futuras.

El propósito de un sistema AI nuevo no es reproducir el pasado — es tomar decisiones para el futuro. Si el pasado tenía sesgo, copiarlo fielmente es perpetuarlo.

Análogo: un sistema de pricing de seguros que aprende que "ZIP code X tiene más claims" técnicamente captura patrón real. Pero si ZIP code X correlaciona con minoría racial por segregación histórica, el sistema perpetúa redlining.

Decisión ética: a veces hay que romper el patrón histórico, no replicarlo.

4. ¿Cómo detectarías proxy variables en tu propio sistema?

Procedimiento:

  1. Identificar atributos protegidos: género, raza, edad, etnia, religión, origen nacional, discapacidad.
  2. Para cada feature en el modelo, calcular qué tan bien predice cada atributo protegido.
  3. Si una feature sola predice un atributo protegido con accuracy > 60% (significativamente mejor que random), es proxy fuerte.
  4. Decidir: eliminar la feature, mitigar via re-weighting, aplicar adversarial debiasing, o documentar y monitorear closely.

Adicionalmente: medir disparate impact del output del modelo completo, no solo features individuales. Combinaciones de features pueden ser proxy aunque ninguna individual lo sea.

Herramientas: SHAP, LIME, Fairlearn (Microsoft), AIF360 (IBM), WhatIfTool (Google).

Resumen y siguiente paso

  • Apple Card otorgó credit limits dramáticamente más bajos a mujeres vs sus parejas con finanzas idénticas (DHH 20x, Wozniak 10x).
  • Goldman Sachs no usaba género como feature — el sesgo entró vía proxies: historial de crédito individual, ingreso individual, industry of employment, etc.
  • NYDFS investigó pero no encontró violación legal. Compliance ≠ ética.
  • Costo: investigación regulatoria, cambios operativos, daño reputacional, aceleración de regulación.
  • Lección estructural: eliminar features explícitas no elimina discriminación. Disparate impact testing del output es lo que detecta proxy discrimination.

Checkpoint: deberías poder distinguir entre disparate treatment y disparate impact, y explicar por qué un modelo "técnicamente correcto" puede ser discriminatorio en outcomes.

Puente a la siguiente cápsula: las cápsulas 02-04 fueron los case studies. La cápsula 05 sintetiza: las 4 dimensiones del costo de ignorar ética en AI — legal, reputacional, técnica, y humana. Vas a tener un framework para argumentar (frente a un PM, un C-level, un cliente) por qué invertir en ethics process es ROI positivo, no overhead.

Recursos

  1. DHH Twitter thread (Nov 2019) — el inicio público.
  2. NYDFS Apple Card investigation report (2021) — conclusiones oficiales.
  3. Fairlearn (Microsoft) — fairness toolkit — open source.
  4. AI Fairness 360 (IBM) — toolkit comprehensive.
  5. Equal Credit Opportunity Act (ECOA) — referencia legal US.

Siguiente: 05-cuatro-dimensiones-costo.md — Las 4 dimensiones del costo: legal, reputacional, técnica, humana.

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

← Anterior3. Case Study #2: Facial Recognition BiasSiguiente →5. Las 4 dimensiones del costo de ignorar ética en AI