Módulo 1: Why Ethics Matters in AI Engineering

8. Mini-proyecto: Ethics Impact Analysis

Cerrás el módulo aplicando el framework a un sistema AI real. El entregable es un Ethics Impact Analysis completo de 3-5 páginas — el primer artifact tangible de tu workflow ético.

Este documento es reusable: lo vas a refinar y extender a lo largo de la guía a medida que aprendas técnicas específicas (bias testing en M2, privacy en M3, compliance en M4-6).

Especificación del entregable

Mínimo viable

✅ Sistema definido: caracterización completa (Fase 1).
✅ Stakeholders identificados: tabla con al menos 4-5 stakeholders (Fase 2).
✅ Modos de fallo mapeados: al menos 6-8 modos de fallo concretos (Fase 3).
✅ Riesgos evaluados: matriz severidad × probabilidad para cada modo (Fase 4).
✅ Mitigations propuestas: técnica específica + métrica + ownership para cada riesgo 🔴/🟡 (Fase 5).
✅ Documento estructurado: 3-5 páginas siguiendo el template.
✅ Decision log: fechas y autores documentados.

Stretch goals

⭐ Implementar al menos 1 mitigation en código (ej., disparate impact testing como CI test).
⭐ Stakeholder review: compartir el documento con un PM/lead/legal y obtener feedback.
⭐ Comparar con sistema existente: aplicar el framework a un sistema que ya está en producción y identificar gaps.
⭐ Plan de monitoring post-deploy concreto con dashboards y alerts.

Elegir el sistema a analizar

Tres opciones:

Opción A: tu Capstone del path

Si completaste el AI-Powered Knowledge Assistant (#25, capstone), aplicá Impact Analysis a ese sistema.

Ventajas: conocés el sistema en detalle, podés actuar sobre las findings (implementar mitigations).

Desventajas: si lo construiste sin pensar en ethics, vas a encontrar issues — eso es exactamente el punto.

Opción B: un sistema de tu trabajo

Si trabajás en una empresa que despliega AI, elegí un sistema real (con permission de management si aplica).

Ventajas: directamente útil profesionalmente.

Desventajas: confidentiality. No publicar findings sensibles.

Opción C: caso de estudio provisto

Si no tenés Capstone propio o sistema laboral, usá uno de los siguientes case studies:

C1: Healthcare Triage System

Sistema AI que recibe síntomas de pacientes via chat web y clasifica urgencia (immediate / 24h / week / non-urgent). Outputs: clasificación + recomendación de acción. LLM-based con prompt engineering. Datos de entrenamiento: 10,000 conversaciones históricas de triage anonimizadas. Deploy: clínica con 50K visits/año en US. Sustituye a triage telefónico tradicional.

C2: Content Moderation System

Sistema AI que clasifica posts de usuarios en una plataforma social (1M users) en categorías: safe / borderline / unsafe. Outputs: classification + confidence. LLM-based con few-shot prompting. Posts en multiple languages (English, Spanish, Portuguese, Hindi). Decision automática: posts "unsafe" se hide automáticamente, "borderline" van a review humana. Deploy: global.

C3: Loan Approval System

Sistema AI que predice probabilidad de default para applicants de loans personales ($1K-$50K). Output: score 0-1 + decision approve/deny/manual review. ML model (gradient boosting) entrenado en 5 años de data interna. Features: income, credit score, employment, location, age. Deploy: fintech US scale 10K applications/month.

C4: Educational Recommendation System

Sistema AI que recomienda cursos a estudiantes en plataforma online (500K users). Output: ranked list de cursos. Collaborative filtering + content-based hybrid. Datos: course completions, ratings, time spent. Decision: shown automatically en home page del student. Personalización via demographics inferidos (age, location, declared interests). Deploy: globalmente.

Cómo proceder

Paso 1: elegir sistema

Decidí cuál de las opciones (A, B, o C). Si C, elegí cuál case study (C1-C4).

Paso 2: aplicar las 5 fases

Trabajá las 5 fases en orden. No skipees Fase 1 — si la caracterización es vaga, todo lo demás se vuelve vago.

Fase 1: Caracterización

Respondé las 14 preguntas de caracterización (de la cápsula 07):

¿Qué hace? (1 frase)
¿Tipo de modelo?
¿Provee por quién?
¿Output formal?
¿Cómo se usa output?
¿De dónde vienen los training data?
¿Tipos de datos personales?
¿Hay consent?
¿Composición demográfica de datos?
¿Jurisdicciones?
¿Quiénes son los usuarios?
¿Scale?
¿Reversibilidad del output?

Fase 2: Stakeholders

Identificá al menos 4-5 stakeholders. Para cada uno: cómo interactúan, qué decisiones afectan, outcomes posibles, vulnerabilidades.

Fase 3: Modos de fallo

Identificá al menos 6-8 modos de fallo. Cubrí estas categorías como mínimo:

Bias / discrimination.
Privacy.
Accuracy / hallucination.
Misuse.
Transparency.
Accountability.

Fase 4: Severidad × probabilidad

Para cada modo de fallo, asigná severidad (BAJO/MEDIO/ALTO/CRÍTICO) y probabilidad (BAJA/MEDIA/ALTA/MUY ALTA). Justificá. Determiná zone (🟢/🟡/🔴).

Fase 5: Mitigations

Para cada riesgo en zona 🔴 o 🟡, proponé:

Técnica específica.
Métrica.
Criterio de aceptación.
Owner.
Tiempo estimado.

Paso 3: redactar el documento

Usá la estructura template (de la cápsula 07):

# Ethics Impact Analysis: [Sistema]

## 1. Resumen ejecutivo
## 2. Caracterización del sistema
## 3. Stakeholders identificados
## 4. Modos de fallo
## 5. Evaluación de riesgos
## 6. Plan de mitigation
## 7. Plan de monitoring post-deploy
## 8. Decision log
## 9. Próxima revisión

3-5 páginas. No menos (estás cortando análisis), no más (perdés precisión).

Paso 4: review

Compartí con al menos una persona (mentor, peer, PM) y obtené feedback. El feedback típico va en estas direcciones:

"Falta este stakeholder": revisá Fase 2.
"Severidad parece subestimada": revisá Fase 4 con conservatism mayor.
"Mitigation muy abstracta": revisá Fase 5 con más detalle técnico.
"Falta jurisdicción X": revisá Fase 1.

Iterá hasta que el feedback sea "doc completo, listo para stakeholder formal review".

Ejemplo desarrollado: caso C3 (Loan Approval System)

Mostramos las primeras 3 fases para que tengas modelo. Los detalles van en tu propio entregable.

Fase 1: Caracterización

Sistema: Loan Approval System — predice probabilidad de default para applicants de personal loans, output decision approve/deny/manual review.

Tipo: Binary classifier + threshold. Gradient boosting (XGBoost). Trained from scratch.

Provee: in-house ML team.

Output: probability score 0-1 + decision (approve si > 0.7, deny si < 0.3, manual review entre 0.3-0.7).

Uso: decision automática para approve/deny. Manual review solo para zona ambigua.

Training data: 5 años de loan history interna. ~500K applications, ~100K loans issued. Labels: defaulted vs paid.

PII en data: nombre, address, SSN (hashed), employment, income, credit history. Datos sensibles: sí (financial).

Consent: cláusula en application form, blanket consent para "credit decisions".

Composición demográfica: applicants históricos, US. Distribución racial: 65% white, 15% Hispanic, 12% Black, 8% Asian (per zip code inference). Distribución de género: 55% M, 45% F.

Jurisdicciones: US (FCRA, ECOA, CRA). State-specific: NY, IL, CA tienen extra requirements.

Usuarios: applicants individuales, loan officers (review manual zone).

Scale: 10K applications/month. ~$200M loan volume/year.

Reversibilidad: difícilmente reversible. Denied applicants rara vez re-aplicarán; approved tienen contractual commitment.

Fase 2: Stakeholders

Stakeholder	Cómo interactúan	Decisiones que afectan	Outcomes posibles	Vulnerabilidades
Applicants (todos)	Submit application	Approve/deny + interest rate	Acceso a crédito, oportunidad económica	Low-income, minorías, jóvenes/old
Loan officers	Review zone manual	Time invested, automation bias	Eficiencia (positivo); ceguera a edge cases (negativo)	Automation bias
Empresa	Construye/operates	Default rate, regulatory exposure	Profit; lawsuits	FCRA, ECOA enforcement
Comunidades históricamente sub-served	Sub-representadas en approvals	Acceso a crédito	Mobility económica vs exclusión	Redlining histórico
Regulators (CFPB, state)	Audit	Cumplimiento legal	Fines, cease-and-desist	—
Sociedad amplia	Patrones agregados de crédito	Distribución de crédito	Equity vs exclusión sistémica	—

Fase 3: Modos de fallo

Modo de fallo	Mecanismo	Stakeholders	Outcome del daño
Bias racial vía proxy ZIP	ZIP code correlaciona con raza por segregación; modelo aprende correlation	Minority applicants	Denegación injusta de crédito
Bias de género indirecto	Income, employment patterns correlacionan con género	Female applicants	Denegación o tasa más alta
Bias de edad	Length of credit history penaliza young + old	Young (< 25) y old (> 65)	Denegación
Disparate interest rates	Risk-based pricing escalates en proxies	Low-income, minorities	Tasas predatorias
Hallucination en feature engineering	(Less applicable to gradient boosting, pero data quality issues)	Applicants	Decisiones basadas en data corrupta
Privacy leak en logging	SSN, income en logs	Applicants	PII exposure
No appeal mechanism	Denied applicants no saben por qué	Applicants	Imposibilidad de feedback/improvement
Drift en datos post-deploy	Modelo se vuelve outdated	All stakeholders	Performance deterioration silent

(Continuá Fase 4 y 5 en tu propio entregable)

Ejercicio paso a paso

Paso 1: bloque de tiempo (4-8 horas)

Reservá 4-8 horas para hacer el análisis serio. Si hacés en 30 min, el doc va a ser superficial.

Paso 2: Fase 1 (1 hora)

Respondé las 14 preguntas. Si no podés responderlas, pará y obtené la información (talk to PM, read code, ask data science team) antes de avanzar.

Paso 3: Fase 2 (1 hora)

Brainstorm de stakeholders. Empezá con los obvios (users, sujetos), expandí a indirectos (familias, comunidades), terminá con sistémicos (regulators, society).

Paso 4: Fase 3 (2 horas)

El paso más laborioso. Por cada categoría (bias, privacy, accuracy, misuse, transparency, accountability), generá al menos 1-2 modos de fallo concretos. Usá los case studies (Amazon, facial recognition, Apple Card) como inspiración.

Paso 5: Fase 4 (1 hora)

Asigná severidad + probabilidad + zone. Sé conservador (eleva si dudas).

Paso 6: Fase 5 (1-2 horas)

Por cada riesgo 🔴/🟡, proponé mitigation técnica concreta. Si no sabés mitigation, googleá "mitigate [risk] in [system type]" — la literatura es extensa.

Paso 7: redactar (1 hora)

Compilá las 5 fases en template. Resumen ejecutivo al final (es lo que stakeholders leen primero, escribilo último cuando entendés todo).

Paso 8: review (variable)

Compartí. Iterá. Refiná.

Output esperado

Documento de 3-5 páginas

Con structure clara:

[ Resumen ejecutivo  — 1/3 página ]
[ Caracterización    — 1/2 página ]
[ Stakeholders       — 1/2 página ]
[ Modos de fallo     — 1 página   ]
[ Evaluación riesgos — 1 página   ]
[ Mitigations        — 1 página   ]
[ Monitoring + log   — 1/2 página ]

Total: ~4 páginas

Demonstración de competencia

Después de este mini-proyecto, deberías poder responder con confidence:

✅ "¿Quiénes son los stakeholders del sistema?" ✅ "¿Cuáles son los riesgos éticos prioritarios?" ✅ "¿Por qué [riesgo X] es severidad alta y probabilidad media?" ✅ "¿Qué mitigation propones para [riesgo X]?" ✅ "¿Cómo verificarás que la mitigation funciona post-implementation?"

Si podés, aprobaste el módulo.

Trampas comunes durante el ejercicio

1. Empezar por mitigations, no por análisis

Tentación: ya sabés que "bias testing es mitigation", saltás directo. Resultado: análisis superficial.

Mejor: Fase 1-4 primero, mitigations al final. Si no entendés el riesgo concretamente, mitigation va a ser genérica.

2. Usar "podría" como hedge

"Bias podría existir" no es análisis. Identificá mecanismo concreto: "Bias va a existir vía proxy ZIP code porque...".

Si no podés identificar mecanismo, el riesgo está sub-investigado, no es bajo.

3. Ignorar regulatory dimension

Si sistema tiene exposure a EU users, EU AI Act aplica. Documentalo. Si tiene applicants en hiring, EEOC + state laws aplican.

4. Self-defense por el sistema

Tentación: justificar decisiones de diseño actuales. "Es así porque ya está construido así".

Resistí. El framework es para identificar issues, no defender el status quo. Si el análisis revela que el sistema tiene problems, ese es el output deseado.

5. Pretender que tu propio sistema es excepción

"Otros sistemas tienen bias, pero el mío no". Falso por default. Asumí bias hasta probarlo lo contrario con testing.

Cierre del módulo

8 cápsulas

Introducción.
Case study #1: Amazon Hiring.
Case study #2: Facial Recognition Bias.
Case study #3: Apple Card Credit Scoring.
Las 4 dimensiones del costo.
Responsabilidad del engineer.
Ethics Impact Analysis: el framework.
Mini-proyecto: tu propio Impact Analysis (esta cápsula).

Lo que cambió en vos

Antes del módulo:

Pensabas "ética en AI = filosofía abstracta".
"Si pasamos compliance, estamos bien".
"Es responsabilidad del PM/legal".

Después del módulo:

Sabés que ética en AI = risk management cuantificable, con $$ específicos.
Sabés que compliance es el piso, no el techo.
Sabés que la responsabilidad técnica del engineer es directa, basada en regulación + información asimétrica + causalidad técnica.
Tenés una herramienta concreta (Impact Analysis) que aplicaste a un sistema real.

El documento que produjiste

No es un ejercicio académico. Es un artifact reusable que:

Se actualiza cuando el sistema cambia.
Se referencia en design reviews futuras.
Se incluye en compliance documentation.
Se comparte con regulators si llega auditoría.

Te llevás un documento profesional al pasar a M2.

Empezamos en el siguiente módulo

Módulo 2: Bias and Fairness. Tomamos uno de los riesgos identificados en tu Impact Analysis — bias — y profundizamos con técnicas concretas:

Cómo medir bias matemáticamente (fairness metrics).
Cómo testear bias en CI/CD.
Cómo mitigar bias detectado (re-weighting, adversarial debiasing, post-processing).
Cómo elegir definición de "fair" para tu context (decisión inevitable porque las definiciones son incompatibles).

La transición es natural: identificaste el riesgo en M1; M2 te da las herramientas para medirlo, testearlo y mitigarlo.

Recursos para el ejercicio

Microsoft Responsible AI Impact Assessment Template — template comercial.
Algorithmic Impact Assessment (Canada) — gov framework con questionnaire.
AI Now Institute — Algorithmic Accountability — research y reports.
Partnership on AI — Resources — frameworks y case studies.
NIST AI RMF Playbook — guidelines paso a paso.

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

Fin del módulo 1. Continúa con el módulo 2 (Bias and Fairness Deep Dive).

← Anterior7. Ethics Impact Analysis: el framework Siguiente →1. Introducción al módulo: Bias and Fairness