Módulo 1: Why Ethics Matters in AI Engineering

1. Introducción al módulo: Why Ethics Matters in AI Engineering

Descripción de la cápsula

Llegaste hasta acá después de 21 guías construyendo sistemas AI. Sabes hacer APIs, sabes hacer RAG, sabes hacer agentes, sabes deployar, sabes hacer scaling. Tu sistema funciona. Y eso está bien.

Pero esta guía existe porque "funciona" no es suficiente. Un sistema AI que funciona puede:

Discriminar contra mujeres en hiring (Amazon, 2014-2018, decommissioned después de años de desarrollo).
Identificar erróneamente a personas negras como criminales con error rates 100x más altos que para personas blancas (varios sistemas de reconocimiento facial, 2016-2020, terminó en arrestos erróneos y prohibiciones).
Negar crédito a comunidades enteras basándose en proxies indirectos de raza (Apple Card, 2019, regulación activada en menos de 60 días).

Cada uno de esos sistemas funcionaba. Devolvían respuestas. Tenían métricas verdes. Pasaban tests.

Y cada uno costó: dinero, reputación, carreras, y daño real a personas reales.

Este módulo no es un sermón filosófico sobre "ser buena persona". Es la evidencia concreta de que ignorar ética en AI tiene consecuencias financieras, legales y reputacionales devastadoras — y que prevenirlas es parte del trabajo del AI engineer, no algo que delegás al equipo legal o al PM.

Al terminar, vas a tener:

Tres case studies con datos reales: qué falló, por qué, costo medible.
Un mapa de las 4 dimensiones del costo: legal, reputacional, técnica, humana.
Una herramienta práctica — el Ethics Impact Analysis — que vas a aplicar a un sistema AI real.

¿Dónde estamos?

Esta es la última guía del path AI Engineering (#24 de 25 — el #25 es el capstone). Hasta aquí:

Path AI Engineering — 24 guías técnicas → ÉSTA → Capstone
─────────────────────────────────────────────
Construyes sistemas que funcionan ───► Construyes sistemas
                                       que funcionan Y no causan daño

El path empezó enseñándote a invocar LLMs (#2). Luego a hacer RAG (#7-8), agentes (#10-12), evaluación (#13), producción (#14, #17-22), security (#22), system design (#23). Cada guía añadió una capa de competencia técnica.

Esta guía no añade competencia técnica. Añade responsabilidad profesional. Es la guía que separa al engineer que "hace cosas" del engineer que "hace cosas conscientemente".

La tesis de la guía en una sola frase

Construir sistemas AI que funcionan es la mitad del trabajo. La otra mitad es construirlos de forma que no causen daño cuando funcionan.

Esa segunda mitad incluye:

Detectar y mitigar bias antes de deployar (M2).
Proteger privacy de los datos de entrenamiento y los usuarios (M3).
Cumplir regulación que ahora es obligatoria en Europa, EE.UU., y crecientemente en el resto del mundo (M4-M6).
Aplicar un framework profesional integrador (M7).
Producir un audit completo sobre tu propio sistema (M8).

Este módulo es el diagnóstico inicial. Antes de aprender técnicas (M2-M7), tenés que ver el dolor que esas técnicas previenen.

El cambio de mentalidad de este módulo

Antes de este módulo, probablemente pensás:

"La ética en AI es responsabilidad del PM / del equipo legal / del CEO. Yo soy engineer."

Después de este módulo, vas a entender:

"El engineer que elige los datos de entrenamiento, que no testea por sesgo, que no documenta las limitaciones, que no aplica un framework de impact analysis — tiene responsabilidad directa en el daño que ese sistema causa."

No es opinión. Es convergencia regulatoria: la EU AI Act, NIST AI RMF, ISO/IEC 42001, y los estándares emergentes asignan responsabilidad técnica explícita al developer/engineer. Si tu modelo discrimina, vos no podés decir "yo solo cumplí los requisitos" — tenés que probar que aplicaste due diligence técnica.

Este módulo te muestra cómo se ve esa due diligence en la práctica.

Lo que vas a construir

El entregable de este módulo es un Ethics Impact Analysis — un análisis de riesgos éticos aplicado a un sistema AI (puede ser tu capstone, un sistema de tu trabajo, o un caso de estudio que te proveemos).

El Impact Analysis identifica:

Stakeholders afectados: quiénes interactúan con el sistema o son afectados por sus decisiones.
Modos de fallo potenciales: cómo puede el sistema causar daño (bias, privacy leak, hallucination con consecuencia, etc.).
Severidad y probabilidad: cuán grave es cada modo de fallo y cuán probable es que ocurra.
Riesgos prioritarios: cuáles requieren atención inmediata.
Conexión con módulos siguientes: qué módulo de esta guía aborda cada riesgo.

Es un documento de 3-5 páginas. Profesional. Reusable. El primer artefacto del workflow ético que aplicarás de acá en adelante en cada sistema AI que construyas.

Las cápsulas del módulo

8 cápsulas, en orden:

Introducción (esta cápsula) — establece tesis, contexto, cambio de mentalidad.
Case study #1: Amazon Hiring — algoritmo discriminatorio. Mecanismo, costo, lesson.
Case study #2: Facial Recognition Bias — error rates desiguales por raza. Arrestos erróneos.
Case study #3: Credit Scoring Discrimination — Apple Card y proxies indirectos.
Las 4 dimensiones del costo — legal, reputacional, técnica, humana.
Responsabilidad del engineer — por qué no podés delegar a "legal" o "el PM".
Ethics Impact Analysis: el framework — cómo se hace, paso a paso.
Mini-proyecto — producís tu propio Impact Analysis.

Cada cápsula construye sobre la anterior. La cápsula 8 cierra con el entregable.

Por qué los case studies importan tanto

Más de la mitad del módulo (cápsulas 2-5) son case studies. Hay una razón:

No podés enseñar prevención sin mostrar qué pasa cuando no se previene.

Es como enseñar seguridad informática sin mostrar nunca un ataque real. Sin el dolor concreto, las contramedidas suenan abstractas. Las cápsulas de case studies no son relleno — son la motivación necesaria para que las técnicas (M2-M7) se sientan urgentes y obligatorias.

Cada case study sigue la misma estructura:

Qué pasó: hechos verificables.
Por qué pasó: mecanismo técnico de fallo (no "porque el algoritmo era malo" sino "porque los datos de entrenamiento tenían X sesgo").
Costo: dólares, tiempo, empleos, regulación activada.
Cómo se podía prevenir: prácticas técnicas que habrían evitado el resultado.

La sección 4 es la conexión con lo práctico. No es "ojalá hubieran sido más éticos" — es "habrían podido hacer X test específico y habría detectado el problema".

Compliance ≠ ética

Importante separar dos cosas que se confunden:

Concepto	Qué es	Quién lo establece
Compliance	Cumplimiento de regulación legal	Gobierno (GDPR, EU AI Act, HIPAA)
Ética profesional	Estándar de cuidado más alto que lo legal	Profesión, comunidad técnica, conciencia individual

Podés cumplir 100% de la regulación y aun así construir algo dañino. Ejemplo: un sistema de hiring que cumple legalmente porque no usa explicítamente raza/género, pero discrimina vía proxies (código postal, universidad, hobbies). Compliance ✅. Ético ❌.

Esta guía cubre ambas dimensiones:

M1, M7, M8 — ética profesional (lo que va más allá de lo legal).
M2, M3 — técnicas que aplican a ambas (bias y privacy son problemas legales y éticos).
M4, M5, M6 — compliance regulatoria (GDPR, EU AI Act, NIST AI RMF, normativa US).

No vas a salir de esta guía pensando "compliance = ética". Vas a entender que compliance es el piso mínimo y la ética profesional es el estándar.

Quiénes deben leer esta guía

Si tu trabajo incluye alguna de estas tareas, esta guía es para vos:

✅ Elegir datasets de entrenamiento.
✅ Decidir features que entran en un modelo.
✅ Configurar guardrails de un LLM.
✅ Deployar un sistema AI a producción.
✅ Diseñar APIs que sirven respuestas de modelos.
✅ Hacer review de PRs que incluyen lógica AI.
✅ Liderar un equipo que hace cualquiera de las anteriores.

Si tu rol es AI engineer, ML engineer, data scientist, full-stack developer trabajando con LLMs, o tech lead de un equipo AI — sos responsable. Punto.

Trampas y errores comunes en este módulo

1. Saltarse case studies pensando "ya sé que la ética importa"

El conocimiento abstracto ("la ética importa") no produce comportamiento diferente que el ignorante ("la ética no importa"). Lo que produce comportamiento diferente es ver, con datos concretos, qué pasa cuando se ignora. Las cápsulas 2-4 son el trabajo. Hacelas.

2. Tratar este módulo como filosofía y no como ingeniería

Cada cápsula tiene un payoff técnico:

M1/02 (Amazon) → técnica: testing for disparate impact.
M1/03 (facial recognition) → técnica: subgroup error analysis.
M1/04 (credit scoring) → técnica: detecting proxy variables.

Si leés solo el "qué pasó" y no el "cómo se podía prevenir", el módulo se vuelve filosofía. La intención es ingeniería.

3. Confundir "no tengo poder" con "no tengo responsabilidad"

"Mi PM dijo que el sistema tenía que estar listo para el viernes" no te exime. Vos sos quien implementa. Vos sos quien tiene la información técnica. Vos sos quien puede decir "esto va a fallar X, necesitamos Y antes de deployar". Ético ≠ omnipotente, pero sí incluye alzar la voz cuando la evidencia técnica lo requiere.

4. Pensar que ética = no construir cosas controvertidas

No. Ética = construir cosas con due diligence. Podés construir un sistema de hiring AI éticamente — solo que requiere bias testing, fairness metrics, documentación, y monitoreo. Lo no-ético no es la categoría — es la falta de proceso.

Auto-verificación

1. ¿Por qué la primera mitad del módulo son case studies en vez de definiciones?

Porque las definiciones de "ética en AI" son numerosas y abstractas. Lo que cambia comportamiento de engineers es ver el costo concreto de ignorar el problema. Tres case studies con datos verificables son más persuasivos que 100 párrafos sobre "principios éticos".

Además, los case studies son el material del que salen las técnicas: bias testing salió de Amazon, subgroup analysis de facial recognition, proxy detection de credit scoring. La teoría se construye desde casos, no al revés.

2. ¿Cuál es la diferencia entre compliance y ética profesional?

Compliance es el cumplimiento de regulación legal: GDPR, EU AI Act, HIPAA, etc. Es obligatorio y verificable externamente.

Ética profesional es el estándar de cuidado de la profesión, que va más allá de lo legalmente requerido. Es un compromiso interno con prácticas de due diligence aunque la ley no las exija explícitamente.

Podés cumplir 100% de compliance y construir algo dañino — ej., un sistema que no usa género explícito pero discrimina vía proxies (universidad, código postal). Compliance ✅, ético ❌.

Esta guía cubre las dos: M2-M3 técnicas, M4-M6 compliance, M1-M7-M8 ética.

3. ¿Por qué la responsabilidad ética es del engineer y no solo del PM/legal?

Tres razones:

Convergencia regulatoria: estándares emergentes (EU AI Act, NIST AI RMF, ISO 42001) asignan responsabilidad técnica explícita al engineer. "Yo solo cumplí los requisitos" ya no es defensa.
Información asimétrica: el engineer tiene la información que PMs/legal no tienen — qué datasets se usaron, qué tests no se hicieron, qué edge cases el modelo no maneja. Si vos no levantás esos issues, nadie más puede.
Causalidad técnica: las decisiones técnicas (qué features, qué datos, qué arquitectura) determinan el comportamiento del sistema. La ética se implementa en código, no solo en políticas.

Esto no significa que el engineer es el único responsable — significa que es uno de los responsables, y que esa responsabilidad es directa, no derivada.

4. ¿Qué es el Ethics Impact Analysis y cuándo se aplica?

Es un documento estructurado que identifica:

Stakeholders afectados por el sistema AI.
Modos de fallo potenciales — cómo puede causar daño.
Severidad y probabilidad de cada modo de fallo.
Riesgos priorizados — cuáles atender primero.
Conexión con técnicas que mitigan cada riesgo.

Se aplica antes de deployar un sistema AI nuevo, y se revisa cada vez que el sistema cambia significativamente (nuevo dataset, nuevo dominio, nueva audiencia).

Es el equivalente al "threat model" en seguridad: no garantiza que el sistema sea seguro, pero asegura que las decisiones se tomaron con visibilidad de los riesgos. El proceso, más que el resultado, es lo valioso.

Resumen y siguiente paso

Este módulo establece la tesis: construir sistemas AI que funcionan es la mitad del trabajo. La otra mitad es no causar daño.
El cambio de mentalidad: la responsabilidad ética del engineer es directa, no delegable a PM/legal.
El método: case studies con datos concretos → 4 dimensiones del costo → framework de Impact Analysis.
El entregable: un Ethics Impact Analysis aplicado a un sistema AI real.
Compliance ≠ ética: cumplir GDPR no garantiza un sistema ético. Esta guía cubre ambas dimensiones.

Checkpoint: antes de avanzar, deberías poder responder: ¿por qué un engineer no puede defenderse con "yo solo seguí los requisitos del PM"? Si la respuesta no te resulta clara, releé la sección "El cambio de mentalidad".

Puente a la siguiente cápsula: la cápsula 02 abre con el primer case study — Amazon Hiring. Vas a ver cómo un sistema construido por uno de los equipos de ML más sofisticados del mundo terminó discriminando contra mujeres durante años, qué mecanismo técnico produjo el sesgo, qué costó decommissionarlo, y qué test simple lo habría detectado en el primer mes. Es el caso que demuestra que "buenos ingenieros" no es protección suficiente — solo "buenos ingenieros aplicando proceso ético" lo es.

Recursos

EU AI Act — Official text — referencia regulatoria principal.
NIST AI Risk Management Framework — framework técnico US.
Algorithmic Accountability Act (US) — propuesta legislativa actual.
ACM Code of Ethics — Software — estándar profesional.

Siguiente: 02-case-study-amazon-hiring.md — Cómo Amazon construyó un sistema discriminatorio sin querer.

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

Siguiente →2. Case Study #1: Amazon Hiring Algorithm