Módulo 1: Why Ethics Matters in AI Engineering

7. Ethics Impact Analysis: el framework

Descripción de la cápsula

Las primeras 6 cápsulas establecieron por qué importa la ética en AI. Esta cápsula te da el cómo: un framework concreto para hacer Ethics Impact Analysis sobre cualquier sistema AI.

Es el equivalente al threat model en seguridad: no garantiza que el sistema sea ético/seguro, pero asegura que las decisiones se tomaron con visibilidad de los riesgos.

El framework tiene 5 fases:

Caracterización del sistema — qué hace, en qué context, con qué datos.
Identificación de stakeholders — quiénes afectan o son afectados.
Mapeo de modos de fallo — cómo puede causar daño.
Evaluación de severidad y probabilidad — cuán grave, cuán probable.
Priorización y mitigación — qué atender primero, con qué técnicas.

Al terminar, vas a poder producir un documento de 3-5 páginas profesional, defendible, y reusable. La cápsula 08 te lleva a aplicarlo en un caso real.

Antes de empezar: por qué hacer Impact Analysis

Tres razones, en orden de fuerza creciente:

1. Visibilidad de riesgos

Sin proceso, los riesgos quedan implícitos. Cada miembro del equipo asume que "alguien más" los está pensando. Resultado: nadie los piensa explícitamente.

Impact Analysis fuerza la pregunta: ¿qué puede salir mal y a quién? No ignora cosas porque "son obvias" — las documenta.

2. Comunicación con stakeholders

Cuando hablás con PM, legal, exec, exceeds — necesitás un artifact compartido que todos leen y firman. Impact Analysis es ese artifact.

"Mira, identifiqué estos riesgos, evalué severidad, propongo estas mitigations. ¿Estamos alineados?"

Sin documento, todo queda en conversaciones que se olvidan. Con documento, hay paper trail.

3. Compliance evidence

Bajo regulación moderna (EU AI Act, NIST AI RMF), tenés que demostrar due diligence. Impact Analysis es la evidencia primaria.

Si llega regulador o demanda: "¿qué due diligence hicieron antes de deployar?" Respuesta: "este es el Ethics Impact Analysis fechado, firmado, con mitigations implementadas y verificadas".

Sin documento, la respuesta es "lo pensamos" — que legalmente equivale a no haberlo hecho.

Fase 1: Caracterización del sistema

Antes de identificar riesgos, tenés que describir qué es exactamente lo que estás analizando. Vago = inútil.

Preguntas de caracterización

Respondé con detalle suficiente. Si no podés, el sistema no está suficientemente definido para deployar.

Sobre el sistema:

¿Qué hace? Una frase, sin jerga.
- Bueno: "Recomienda candidatos a entrevista basándose en CV y descripción del puesto".
- Malo: "Sistema AI inteligente para optimización de recruiting".
¿Qué tipo de modelo?
- Clasificación, regresión, ranking, generación, retrieval, agent.
- Trained from scratch, fine-tuned, o uso de API externa.
¿Quién provee el modelo?
- In-house, OpenAI, Anthropic, Google, open source (Llama), etc.
¿Cuál es el output formal?
- Score 0-1, ranking, decisión binaria, texto generado, embedding, action.
¿Cómo se usa el output?
- Decisión automática (sin human-in-the-loop).
- Decisión asistida (human approva).
- Solo informativo.

Sobre los datos:

¿De dónde vienen los training data?
- Datasets públicos, scraped, generados internamente, comprados.
¿Qué tipos de datos personales tienen?
- PII directo, PII indirecto, datos sensibles (salud, biométrica, religión, orientación, etc.).
¿Hay consent claro?
- Documentado, explícito, granular, revocable.
¿Composición demográfica del dataset?
- Donde sea inferible: género, edad, etnia, geografía, idioma, etc.

Sobre el deployment:

¿En qué jurisdicciones se usará?
- Solo US, US + EU, global.
- Determina qué regulaciones aplican.
¿Quiénes son los usuarios?
- End users individuales, empresas, gobiernos, healthcare workers, etc.
¿Qué scale?
- Decenas de personas, miles, millones, billones.
¿Cuán reversible es el output?
- Reversible (recomendación de producto).
- Difícilmente reversible (rechazo de hiring).
- Irreversible (publicación de contenido, decisión médica).

Ejemplo de caracterización

Sistema: Resume Screener — recomienda Top 10 candidatos a entrevista entre los aplicantes a un puesto.

Tipo: Classifier + ranking. LLM-based (GPT-4) con prompt engineering, sin fine-tuning.

Output: lista ranked de candidate IDs con score 0-1.

Uso: el recruiter ve el ranking; decide a quién entrevistar. Tecnología de "decisión asistida" — humano final.

Datos: CVs de aplicantes (formato libre). Job descriptions internas. No usamos historical hire data (decisión deliberada para evitar Amazon Hiring scenario).

Composición: aplicantes mayoritariamente US (85%), tech roles (engineering, product), edad 22-50.

Jurisdicciones: US (EEOC, NYC AEDT Law) + UK + EU (EU AI Act high-risk dado que es hiring).

Scale: ~50,000 aplicaciones/año en empresas medianas; potencial 10x escala.

Reversibilidad: medio. El recruiter humano puede overrule, pero hay automation bias documentado — mucha gente no overrules.

Fase 2: Identificación de stakeholders

¿Quiénes interactúan con el sistema o son afectados por sus decisiones?

Categorías de stakeholders

Directos (interactúan con el sistema):

Usuarios primarios: quiénes operan el sistema (ej., recruiters en Resume Screener).
Sujetos: sobre quiénes el sistema toma decisiones (ej., aplicantes).

Indirectos (afectados por outputs):

Familiares/dependientes de sujetos (afectados por decisiones que impactan a ellos).
Comunidades representadas o sub-representadas.
Empleadores futuros / colegas del sujeto.

Sistémicos:

Regulators: agencias que pueden investigar o multar.
Sociedad amplia: si el sistema escala, efectos macro (perpetuación de sesgos sociales).

Para cada stakeholder identificado, documentar

Quiénes son (descripción concreta).
Cómo interactúan con el sistema.
Qué decisiones del sistema los afectan.
Qué outcomes son posibles para ellos (positivos y negativos).
Vulnerabilidades específicas del grupo (si aplica).

Ejemplo de stakeholder map

Stakeholder	Cómo interactúan	Decisiones que los afectan	Outcomes posibles	Vulnerabilidades
Aplicantes	Submit CV	Ranking que decide entrevista	Entrevista vs no-entrevista	Mujeres, minorías, edad > 50, sin perfil estandarizado
Recruiters	Operan sistema	Confianza en ranking; tiempo invertido	Eficiencia (positivo); ceguera a outliers (negativo)	Automation bias
Hiring managers	Reciben candidatos pre-filtrados	Pool de candidatos restringido	Buenos hires vs missed talent	Indirect (no acceso a rejected)
Empresa	Construye/deploya	Productividad; exposure legal	Hire eficiente vs lawsuits	EEOC/AEDT/EU AI Act
Comunidades sub-representadas	Sub-representadas en hiring outcomes	Acceso reducido a oportunidades	Acceso (positivo si fair); exclusión (negativo si bias)	Históricamente afectadas por hiring bias
Sociedad amplia	Patrones de hiring agregados	Mobility económica, equality	Distribución de oportunidad	Concentración de poder, segregación profesional

Fase 3: Mapeo de modos de fallo

¿Cómo puede el sistema causar daño?

Categorías estándar de modos de fallo

Bias / Discrimination:

Disparate impact por género, raza, edad, etc.
Proxy discrimination indirecta.
Subgroup error rates desiguales.

Privacy:

Leakage de datos personales en outputs.
Re-identification de individuos en datasets "anónimos".
Inferencia de atributos sensibles desde outputs.

Accuracy:

Hallucinations (LLMs).
Confidence misrepresentation.
Edge case failures.

Misuse:

Uso para purposes no intended.
Manipulación de inputs (adversarial).
Use por bad actors.

Transparency:

Falta de explainability.
Falsa sensación de objetividad.
Trust calibration issues.

Accountability:

Difusión de responsabilidad.
Imposibilidad de appeal.
Lock-in de decisiones algorítmicas.

Safety:

Daño físico (en sistemas con efectos físicos).
Daño psicológico (manipulación, addiction).
Daño económico.

Para cada modo de fallo, documentar

Modo de fallo: descripción concreta.
Mecanismo: cómo ocurriría técnicamente.
Stakeholders afectados: cuáles del Fase 2.
Outcome del daño: qué le pasa al stakeholder.

Ejemplo (continuando Resume Screener)

Modo de fallo	Mecanismo	Stakeholders	Outcome del daño
Bias de género	LLM aprendió de internet con sesgo histórico → favorece lenguaje masculino en CVs	Aplicantes femeninas	Sub-ranking, menos entrevistas
Bias de edad	LLM penaliza implícitamente CVs con > 20 años de experiencia	Aplicantes > 50	Sub-ranking, ageism
Bias por non-standard CV	Modelo entrenado en CVs occidentales, falla en formatos diferentes	Aplicantes internacionales	Sub-ranking
Hallucination	LLM inventa "match" entre skills no presentes en CV	Recruiters, aplicantes	Decisión basada en datos falsos
Privacy leak	Prompt incluye CV completo → puede leak en logs	Aplicantes	Exposure de datos personales
Automation bias	Recruiter confía 100% en ranking sin review	Aplicantes mid-rank	Talento bueno descartado
No appeal	Aplicantes no saben por qué fueron rechazados	Aplicantes	Imposibilidad de feedback/improvement

Fase 4: Evaluación de severidad y probabilidad

Cada modo de fallo se evalúa en dos ejes:

Severidad

¿Qué tan grave es el daño si ocurre?

Nivel	Descripción	Ejemplos
Bajo	Inconveniencia, daño económico menor	Mala recomendación de producto
Medio	Daño económico significativo, frustration	Rechazo en proceso laboral
Alto	Daño material, oportunidades perdidas, daño psicológico	Discriminación sistemática en hiring
Crítico	Daño físico, libertad, vida; irreversible	Arresto erróneo, decisión médica errónea

Probabilidad

¿Qué tan probable es que ocurra?

Nivel	Descripción	Frecuencia esperada
Baja	Caso edge raro	< 1% de casos
Media	Casos no comunes pero recurrentes	1-10% de casos
Alta	Caso común	10-50% de casos
Muy alta	Casi default	> 50% de casos

Matriz Severidad × Probabilidad

              BAJA  MEDIA  ALTA  MUY ALTA  ← Probabilidad
              
CRÍTICO        🟡    🔴    🔴    🔴
ALTO           🟢    🟡    🔴    🔴
MEDIO          🟢    🟢    🟡    🔴
BAJO           🟢    🟢    🟢    🟡

↑
Severidad

🟢 = riesgo aceptable / monitor 🟡 = mitigation requerida 🔴 = bloqueante de deploy

Ejemplo (continuando Resume Screener)

Modo de fallo	Severidad	Probabilidad	Riesgo	Justificación
Bias de género	ALTO	ALTA	🔴	LLMs muestran bias documentado; impacto en hiring es alto
Bias de edad	ALTO	ALTA	🔴	Similar a género
Bias non-standard CV	MEDIO	ALTA	🔴	Common but solucionable
Hallucination	ALTO	MEDIA	🔴	LLMs hallucinate documentadamente
Privacy leak	ALTO	BAJA	🟡	Bajo si manejo correcto de logs
Automation bias	ALTO	ALTA	🔴	Recruiters tienden a confiar en rankings
No appeal	MEDIO	MUY ALTA	🔴	100% por default

7 de 7 modos de fallo identificados están en zona 🔴 o 🟡. El sistema no puede deployarse sin mitigations.

Fase 5: Priorización y mitigación

Para cada riesgo 🔴 o 🟡, proponer mitigation concreta.

Estructura de mitigation

Cada mitigation debe incluir:

Técnica específica (no abstracta).
Métrica para verificar que funciona.
Criterio de aceptación (cuándo se considera mitigated).
Ownership (quién es responsable).
Tiempo de implementación estimado.

Ejemplo de mitigations

Riesgo	Mitigation	Métrica	Criterio aceptación	Owner	Tiempo
Bias de género	Counterfactual testing en CI: 100 CVs con marcadores de género swapped, medir delta de scores	Mean delta de scores	< 0.05	ML eng	2 weeks
Bias de edad	Disparate impact testing por bracket de edad	Approval ratio worst/best	> 0.80	ML eng	2 weeks
Bias non-standard CV	Diversificar prompt examples; testing con CVs internacionales	Subgroup accuracy	> 0.85 cada subgrupo	ML eng	1 week
Hallucination	Forcing constrained output: solo skills/companies presentes en CV	Hallucination rate	< 1%	ML eng	1 week
Privacy leak	No persistir CV en logs; redact en prompts	Audit logs	Cero PII en logs	DevOps	1 week
Automation bias	UI changes: requerir recruiter ver al menos top 30, no top 10. Mostrar limitations explícitamente	Recruiter usage analytics	80% review > top 10	Frontend	2 weeks
No appeal	Implementar feedback channel: aplicantes pueden pedir explanation	Feedback request rate	Funciona p99 < 24h	Eng + customer ops	4 weeks

Total estimado: 4 semanas de trabajo + ongoing monitoring

Antes de las mitigations, el sistema NO debe deployarse a producción.

El documento final

El Ethics Impact Analysis se entrega como un documento de 3-5 páginas con esta estructura:

# Ethics Impact Analysis: [Sistema]

## 1. Resumen ejecutivo
- Sistema: [una frase]
- Stakeholders principales: [lista]
- Riesgos críticos: [N riesgos en zona 🔴]
- Recomendación: [proceder con mitigations / pause / no proceder]

## 2. Caracterización del sistema
[Fase 1]

## 3. Stakeholders identificados
[Fase 2 — tabla]

## 4. Modos de fallo
[Fase 3 — tabla]

## 5. Evaluación de riesgos
[Fase 4 — matriz + tabla]

## 6. Plan de mitigation
[Fase 5 — tabla con ownership y tiempos]

## 7. Plan de monitoring post-deploy
[Métricas que se verificarán periódicamente]

## 8. Decision log
- [Fecha] Análisis completado por [autor]
- [Fecha] Reviewed por [stakeholders]
- [Fecha] Approved por [decision maker]

## 9. Próxima revisión
[Fecha — típicamente 6 meses post-deploy o cuando hay cambio significativo]

Cuándo y cómo usar este framework

Cuándo aplicar

Antes de comenzar un nuevo sistema AI que afecta a personas.
Antes de deploy a nueva audiencia/jurisdicción.
Después de cambio significativo: nuevo dataset, nuevo modelo, nuevo dominio.
Periódicamente post-deploy (cada 6-12 meses).

Cuándo NO aplicar (es overkill)

Sistemas sin impact en personas (ej., recommendation interna de canciones para tu propia playlist).
Prototypes en dev solamente (pero aplicar antes de cualquier exposure externa).
Sistemas con human full review siempre (donde AI es 100% advisory sin automation).

Quién lo hace

Owner: el lead engineer del sistema. Es responsabilidad técnica.

Reviewers:

PM (entender riesgos product).
Legal (cumplimiento regulatorio).
Security (overlap con privacy).
Senior eng (review de calidad técnica).

Decision maker: el director/VP que aprueba deploy. Firma el documento.

Trampas y errores comunes

1. Hacer el análisis pero no implementar mitigations

El documento sin acción es inútil. Si identificás riesgo 🔴 y deploys sin mitigation, agravás (ahora hay paper trail de que sabías).

2. Análisis genérico

"Bias podría existir" no es análisis. "Bias de género detectable vía counterfactual testing con threshold X" es análisis.

3. Skip Fase 1 (caracterización)

Si la caracterización es vaga, todo el resto del análisis es vago. Forzá detalle hasta que el sistema esté inequívocamente descrito.

4. Olvidar stakeholders indirectos

Los más afectados a menudo no son los usuarios directos. En hiring, los aplicantes (sujetos) son más afectados que los recruiters (usuarios).

5. Severidad subjetiva

"Es bajo porque es solo recomendación, no decisión" — pero si el recruiter siempre confía, es decisión efectivamente. Severidad debe basarse en impact real, no en intent.

6. Probabilidad sin data

"Probabilidad baja" sin medición no es útil. Si vas a estimar probabilidad sin medir, es alta o muy alta por default conservador.

Auto-verificación

1. ¿Por qué Fase 1 (caracterización) es prerequisito de las otras 4?

Porque sin caracterización clara:

No sabés quiénes son stakeholders (Fase 2 imposible).
No sabés qué modos de fallo son relevantes (Fase 3 vaga).
No podés evaluar severidad (Fase 4 conjetural).
No podés proponer mitigations específicas (Fase 5 abstracta).

Si tu Fase 1 dice "el sistema es AI inteligente para optimización de hiring", todo el resto es ruido. Si dice "ranking de Top 10 candidatos a entrevista entre aplicantes a un puesto, usado por recruiter para decidir entrevistas, en US/UK/EU jurisdictions, scale 50K aplicaciones/año, decision asistida con humano final", el resto del análisis se vuelve concreto.

Caracterización vaga = análisis vago = falsa sensación de due diligence.

2. ¿Qué hacés si todos los modos de fallo identificados son 🔴 (bloqueantes)?

Tres opciones:

Implementar todas las mitigations antes de deploy. Esto retrasa launch pero produce sistema robusto.
Reducir scope: lanzar para subset de uso casos donde algunos riesgos no aplican. Ej., lanzar Resume Screener solo en US para empezar (reduce regulatorio EU AI Act); o solo para roles internos (reduce stakes).
No lanzar: si todos los riesgos son irreductibles a costo razonable, el proyecto puede no ser viable como diseñado. Repensar arquitectura o cancelar.

Lo que NO hacés: lanzar de todos modos. Bloqueante = bloqueante. Si lanzás, expone a la empresa y a vos personalmente.

Real-world: muchos sistemas AI necesitan este pause. El argumento es "el costo de retrasar es enorme" — y la respuesta es "el costo de un incidente es 50x mayor; math contra rush".

3. ¿Cómo asignás severidad cuando no tenés precedentes?

Heurísticas conservadoras:

Por default, asumir severidad alta si afecta a personas. Bajar solo con evidencia.
Considerar reversibilidad: irreversible (publicación, decisión médica) > difícilmente reversible (rechazo) > reversible (recomendación de producto).
Considerar scale: 1 persona afectada vs millones. Mismo per-capita pero costo agregado distinto.
Considerar vulnerabilidades del grupo afectado: minorías históricamente afectadas tienen severidad mayor por compounding daño.
Considerar precedentes en sistemas similares: si Amazon Hiring fue ALTO severidad, tu hiring system también probablemente.

Cuando dudes, eleva: es más fácil bajar severidad después con evidencia que subirla post-incidente.

4. ¿Cómo balanceás Impact Analysis vs velocity de desarrollo?

Balance correcto:

Sistemas bajo riesgo (no afectan personas, low scale): skip o do light version. 1 página máximo.
Sistemas riesgo medio (afectan personas pero low scale, reversible): full analysis pero light. 2-3 páginas. 1-2 días de trabajo.
Sistemas riesgo alto (afectan personas a scale, irreversible): full análisis. 5+ páginas. 1-2 semanas de trabajo, including stakeholder reviews.

El cálculo de costo: 1-2 semanas de Impact Analysis vs $4M esperado en costo de incidente (cápsula 05). ROI positivo abrumadoramente.

Para velocity: integrá Impact Analysis al diseño, no como overhead post-diseño. Hacelo en sprint planning de feature, no después.

Resumen y siguiente paso

Ethics Impact Analysis es el equivalente al threat model en seguridad: visibilidad de riesgos + paper trail.
5 fases: caracterización → stakeholders → modos de fallo → severidad/probabilidad → priorización/mitigation.
El documento final es de 3-5 páginas, profesional, defendible, reusable.
Quién lo hace: lead engineer, con review de PM/legal/security/senior eng.
Cuándo lo hace: antes de comenzar nuevo sistema, antes de cambios significativos, periódicamente post-deploy.
El cálculo de costo favorece masivamente el análisis: 1-2 semanas vs $4M+ en costo esperado de incidente.

Checkpoint: deberías poder describir las 5 fases, qué se hace en cada una, y qué deliverable produce.

Puente a la siguiente cápsula: la cápsula 08 es el mini-proyecto. Vas a aplicar el framework a un sistema AI real (puede ser tu capstone de path, un sistema de tu trabajo, o un caso provisto). El entregable es un Ethics Impact Analysis completo de 3-5 páginas que demuestra dominio del proceso. Ese documento es el primer artifact tangible de tu workflow ético, y lo vas a refinar en módulos siguientes a medida que aprendas técnicas específicas (bias testing en M2, privacy en M3, compliance en M4-6).

Recursos

Microsoft Responsible AI Impact Assessment Template — template comercial.
Google Model Cards Toolkit — open source.
NIST AI RMF Playbook — guidelines paso a paso.
EU AI Act — Risk Assessment guidance — referencia regulatoria.
Algorithmic Impact Assessment (Canada Treasury Board) — gov framework.

Siguiente: 08-mini-proyecto-ethics-impact-analysis.md — Producir tu propio Ethics Impact Analysis.

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

← Anterior6. La responsabilidad ética del engineer Siguiente →8. Mini-proyecto: Ethics Impact Analysis