Módulo 5: GDPR for AI Systems

Art. 22: Automated Decision-Making en detalle

Siguiente →

Descripción

Art. 22 GDPR es el artículo más relevante para AI Engineers. Esta cápsula profundiza: cuándo aplica exactamente, qué excepciones existen, qué nivel de explicación se requiere, y cómo cumplirlo en sistemas AI reales.

Al terminar vas a poder:

  • Identificar con precisión cuándo aplica Art. 22 a tu sistema
  • Aplicar las 3 excepciones legales correctamente
  • Especificar qué información proveer al sujeto bajo Art. 22(3)
  • Implementar mecanismos de "right to challenge" en tu producto

Los 3 criterios para que aplique Art. 22

Art. 22 aplica solo si los 3 criterios se cumplen:

Criterio 1: "Decisión basada SOLELY en automated processing"

"Solely" significa sin intervención humana significativa. Una review humana rubber-stamping (sin análisis real) NO califica como intervención.

Escenario¿"Solely automated"?
AI scoring + humano revisa cada caso con datos antes de decidirNO — hay análisis humano
AI scoring + humano aprueba sin revisar el casoSÍ — rubber stamp
AI scoring + auto-approve si >threshold, humano si <thresholdDepende — la rama auto-approve es "solely"
AI scoring + AI decide + email automatizado al usuarioSÍ

Implicación: para evitar Art. 22, necesitás meaningful human review, no checkbox.

Criterio 2: "Producing legal effects o similarly significantly affects"

  • Legal effects: cambia derechos legales (denegación de crédito, fin de empleo, denegación de visa)
  • Similarly significant: impacto comparable aunque no estrictamente legal (precio personalizado discriminatorio, exclusión de servicios, denegación médica)

Casos discutidos (sin consenso claro):

  • Pricing dinámico individual: probable "significant"
  • Filtros automáticos en redes sociales: probable NO significant
  • Personalized recommendations: NO significant typically

Criterio 3: Aplica a "data subject" (persona natural)

  • Decisiones automáticas afectando empresas (B2B) → Art. 22 NO aplica
  • Decisiones afectando empleados (HR systems) → SÍ aplica
  • Decisiones afectando consumidores → SÍ aplica

Las 3 excepciones del Art. 22(2)

Aún cuando los 3 criterios se cumplen, hay 3 excepciones legítimas:

Excepción A: Necesario para contrato

"Necessary for entering into, or performance of, a contract"

Aplica si: sin la decisión automatizada, el contrato no se puede formar o cumplir.

Ejemplo válido: auto-scoring para préstamo (necesario para procesar volumen sin scoring imposible). Ejemplo NO válido: pricing personalizado (no es "necesario", podés usar pricing uniforme).

Excepción B: Autorizada por ley

"Authorised by Union or Member State law"

Ej: detección de fraude bancario (regulación financiera lo autoriza). Compliance con KYC/AML.

Excepción C: Consent explícito

"Based on the data subject's explicit consent"

"Explícito" es key: no "checkbox consent" general, sino consent específico para esta decisión automatizada.

Requisitos del consent explícito:

  • Informado: usuario sabe específicamente qué consenta
  • Específico: para decisión automatizada concreta
  • Inequívoco: acción afirmativa clara
  • Revocable: usuario puede retirar el consent

¿Qué información debe proveer el sistema? (Art. 22(3))

Aún con excepción aplicable, el sistema debe:

  1. Información significativa sobre la lógica involucrada
  2. Significancia de la decisión
  3. Consecuencias previstas

Plus derechos del data subject:

  • Right to human intervention
  • Right to express their point of view
  • Right to contest the decision

Qué significa "información significativa sobre la lógica"

Esto es ambiguo y controvertido. Mínimo aceptable:

  • Qué factores se consideraron
  • Cómo se ponderaron (no necesariamente weights exactos)
  • Qué outcomes son posibles

Ejemplo bueno:

"Tu solicitud fue evaluada automáticamente considerando: historial crediticio (40% del peso), ingresos estables (30%), antigüedad laboral (20%), y otros factores (10%). En tu caso, el historial crediticio mostró X resultado, lo que llevó a una decisión negativa. Podés solicitar revisión humana en este formulario."

Ejemplo malo:

"Tu solicitud fue rechazada por nuestro sistema."

Ejemplo trabajado: sistema de credit scoring

Sistema

AI model que aprueba/rechaza préstamos automáticamente.

Análisis Art. 22

Aplica Art. 22?

  • Solely automated: ✅ (no human review en el flow normal)
  • Legal/significant effect: ✅ (acceso a crédito)
  • Data subject (consumer): ✅

→ Sí, aplica Art. 22.

¿Qué excepción puede aplicar?

  • (a) Contract necessity: ✅ posible argumentar (préstamo es contrato, scoring necesario)
  • (b) Authorised by law: parcialmente (regulación bancaria)
  • (c) Explicit consent: posible pero requiere consent específico al solicitar préstamo

Diseño de compliance:

1. Información al solicitar préstamo:
   "Tu solicitud será evaluada automáticamente por nuestro sistema de scoring.
   Considera: historial crediticio, ingresos, antigüedad. Tenés derecho a
   solicitar revisión humana después de la decisión."

2. Consent checkbox (separado del contrato general):
   [ ] Consiento a la evaluación automatizada para mi solicitud de préstamo

3. Notificación de decisión:
   "Tu solicitud fue [aprobada/rechazada]. La decisión se basó en X factores.
   Razón principal: [factor más significativo]. Podés:
   - Solicitar revisión humana → [link]
   - Apelar la decisión → [link]
   - Conocer más detalle de la lógica → [link]"

4. Procesos internos:
   - Logging completo de inputs, model output, decisión, timestamps
   - Workflow human review queue
   - Templates para responder explicaciones

Trampas comunes

Trampa 1 — "Tengo human review" pero es rubber stamp. Humano aprueba el 99% sin revisar. No cuenta como meaningful intervention.

Trampa 2 — Consent enterrado en T&C generales. Para Art. 22, consent debe ser específico y separado.

Trampa 3 — Explicación post-hoc inventada. "El sistema rechazó porque X". Pero el sistema no expone X — vos lo inventaste. Es engaño y violación de honesty.

Trampa 4 — "Right to challenge" sin proceso real. Botón "appeal" que va a /dev/null. Necesitás workflow real, SLA, response process.

Trampa 5 — Aplicación geográfica errónea. "Mi sistema corre en USA". Si decisiones afectan residentes EU, GDPR aplica.

Ejercicio

Tu producto: AI-powered ATS (Applicant Tracking System) que filtra CVs y muestra solo los top 20% al recruiter humano. El 80% restante recibe email automatizado "no avanza".

  1. ¿Aplica Art. 22?
  2. ¿Qué excepción podrías usar?
  3. Diseñá el flow de compliance (información, consent, decision communication, right to challenge)
Ver solución

  1. Sí, aplica:

    • Solely automated: el 80% rechazado NO ve human review
    • Significant effect: acceso a oportunidad laboral
    • Data subject: candidato (persona natural)

  2. Excepciones:

    • (a) Contract necessity: NO claramente aplica (proceso de hiring no es contrato aún)
    • (c) Consent: posible si el candidato consenta al aplicar

  3. Compliance flow:

    1. Job posting page:
   "Tu CV será evaluado por nuestro sistema AI. El sistema busca matches
    basado en experience, skills y educación según el job description.
    [ ] Consiento al procesamiento automatizado"

2. Submission acknowledgment:
   "Tu aplicación está siendo evaluada. Recibirás respuesta en 5 días."

3. Si el AI rechaza:
   "Lamentamos informarte que tu aplicación no avanza. La evaluación se
    basó en match de skills, experience y educación con el job description.
    En tu caso, faltó coincidencia significativa en [área].

    Si crees que la evaluación no fue justa, podés:
    - Solicitar revisión humana → [link, response SLA 5 días]
    - Conocer más detalle de los criterios → [link]"

4. Internal:
   - Log de inputs (CV parsed fields), AI score, decision
   - Human review queue con SLA
   - Audit anual de bias en decisiones

Resumen

Aprendiste:

  • ✅ 3 criterios para que Art. 22 aplique (solely automated, significant effect, data subject)
  • ✅ 3 excepciones legales (contract necessity, law, explicit consent)
  • ✅ Información obligatoria al sujeto (lógica, consecuencias, derechos)
  • ✅ Caso trabajado: credit scoring
  • ✅ Trampas: rubber stamp, consent enterrado, explicaciones inventadas

Checkpoint: si podés analizar un sistema AI y determinar Art. 22 aplicabilidad + diseñar compliance, estás listo.

Siguiente cápsula

03 — Right to Explanation para LLMs. La tensión más difícil: ¿cómo cumplir "right to explanation" con un LLM fundamentalmente opaco?

Recursos

  1. GDPR Article 22.
  2. WP29 Guidelines on Automated Decision-Making — interpretación oficial.
  3. Bygrave, "Article 22 GDPR" — análisis legal.
  4. Case studies of Art. 22 enforcement — multas reales.
← AnteriorIntroducción a GDPR for AI SystemsSiguiente →Right to Explanation para LLMs