Módulo 1: Why Ethics Matters in AI Engineering

6. La responsabilidad ética del engineer

Descripción de la cápsula

La pregunta más común cuando se discute ética en AI:

"Esto es responsabilidad del PM, ¿no? O del legal team. Yo solo implemento."

Esta cápsula te muestra por qué esa respuesta es incorrecta, en tres argumentos convergentes:

Convergencia regulatoria: estándares emergentes (EU AI Act, NIST AI RMF, ISO/IEC 42001) asignan responsabilidad técnica explícita al engineer/developer.
Información asimétrica: el engineer tiene información técnica que PMs/legal no tienen y no pueden tener.
Causalidad técnica: las decisiones técnicas determinan el comportamiento del sistema. La ética se implementa en código.

Después, traducimos esa responsabilidad a comportamiento concreto: qué tenés que hacer diferente vs qué hacías ayer. Y cubrimos la pregunta difícil: ¿qué hacés cuando tu PM/empresa te pide algo no ético?

Esta es la cápsula que cierra el cambio de mentalidad antes del framework concreto (cápsulas 7-8).

Argumento 1: Convergencia regulatoria

Lo que decían las regulaciones tradicionales

Hasta ~2020, la regulación tecnológica trataba al producto como sujeto, no a sus creadores individuales. Una empresa podía ser multada; un engineer raramente era named.

Lo que dicen las regulaciones emergentes

EU AI Act (efectivo 2024-2026):

Artículo 16-29: obligaciones de proveedores de sistemas AI. Incluyen:
- Risk management system (incluye risk identification técnico).
- Data governance: documentación de datasets, balance demográfico, etc.
- Technical documentation: detalle técnico del modelo.
- Record-keeping y logging.
- Conformity assessment.
- Post-market monitoring.
Cada una de estas obligaciones requiere conocimiento técnico. Legal/PM no puede cumplirlas sin engineer.
Artículo 50: transparency obligations específicas para sistemas con humano-AI interaction. Implementación requiere code changes — domain del engineer.

NIST AI Risk Management Framework (2023):

Función "GOVERN": cultura y políticas. Compartido legal/eng.
Función "MAP": context, intended users, risks. Eng input crítico.
Función "MEASURE": métricas técnicas, testing, monitoring. 100% engineering.
Función "MANAGE": treatment of risks. Eng implementa.

ISO/IEC 42001 (2023) — AI Management System:

Estándar de management system para AI, similar a ISO 27001 para infosec.
Certifica organizaciones, pero la implementación es ingeniería.
Certificadoras evalúan: ¿aplican bias testing? ¿documentan decisiones técnicas? ¿tienen process de incident response técnico?

Lo que esto significa en práctica

Personal liability está apareciendo:

En US, el Algorithmic Accountability Act (proposed) incluye disclosure requirements donde "responsible engineer" debe certificar prácticas.
En UK, el AI Safety Institute evalúa sistemas y publica capacidades técnicas — engineers individualmente identificables.
En Europa, el EU AI Act crea conformity assessment procesos donde el engineer debe atestar cumplimiento técnico.

"Yo solo implementé los requisitos" deja de ser defensa válida cuando los requisitos no incluían bias testing y vos sabías que era necesario.

Argumento 2: Información asimétrica

Lo que el engineer sabe que nadie más sabe

Cuando construís un sistema AI, vos accedés a información que el PM, legal, exec, y QA no tienen:

Información	Por qué solo el eng la tiene
Composición demográfica del training data	Solo accesible inspeccionando datasets
Performance por subgrupo	Requiere disaggregated testing
Features que correlacionan con atributos protegidos	Requiere análisis estadístico
Casos donde el modelo falla sistemáticamente	Solo visible en testing detallado
Limitaciones del modelo	Solo entendibles con eval framework
Trade-offs de arquitectura (precisión vs fairness)	Requiere conocer los algoritmos

Si el engineer no levanta estos issues, nadie más puede. PM/legal/exec literalmente no tienen forma de saberlos.

El problema de delegación imposible

PM dice: "Construí un sistema fair".

¿Qué significa "fair" técnicamente? Hay decenas de definiciones matemáticamente distintas:

Demographic parity (equal positive rate por grupo).
Equal opportunity (equal true positive rate).
Equalized odds (equal TP y FP rate).
Calibration (equal predicted probabilities).
Counterfactual fairness.
Predictive parity.

Y son mutuamente incompatibles en general. No podés satisfacer todas simultáneamente. Tenés que elegir cuál priorizás según context.

Esa elección es inherentemente técnica + ética combinadas. PM no puede tomarla sin entender el trade-off matemático. Legal no puede tomarla sin entender impact concreto. Solo el engineer está en posición de proponer la elección informada.

Y si el engineer no propone, alguien menos informado decide o la decisión queda como default (= elegida implícitamente, generalmente mal).

Analogía con security engineering

Comparable: en security engineering, no decimos "el SOC2 auditor es responsable de la seguridad". El engineer es responsable. El auditor verifica que el engineer aplicó prácticas correctas.

Lo mismo en AI ethics: el engineer es responsable. Auditor/legal verifican.

Argumento 3: Causalidad técnica

La ética se implementa en código

Ejemplos concretos de decisiones técnicas que son decisiones éticas:

Decisión 1: ¿qué dataset usás?

Decisión técnica: aparente.
Implicación ética: define quién está bien/mal representado, qué patrones aprende el modelo.
Quién la toma: engineer.

Decisión 2: ¿qué features incluís?

Decisión técnica: aparente.
Implicación ética: define qué información sobre personas usás, qué proxies pueden surgir.
Quién la toma: engineer.

Decisión 3: ¿qué threshold de confianza usás para "match"?

Decisión técnica: aparente.
Implicación ética: define la tasa de falsos positivos vs falsos negativos. En contextos como healthcare o policing, define vidas afectadas.
Quién la toma: engineer.

Decisión 4: ¿hacés bias testing?

Decisión técnica: aparente.
Implicación ética: define si detectás disparate impact antes o después del deploy.
Quién la toma: engineer.

Decisión 5: ¿qué loggeás?

Decisión técnica: aparente.
Implicación ética: define qué datos personales persisten, exposure surface.
Quién la toma: engineer.

Decisión 6: ¿cómo manejás errores del modelo?

Decisión técnica: aparente.
Implicación ética: define cómo el sistema falla — silenciosamente, ruidosamente, con fallback humano, sin fallback.
Quién la toma: engineer.

Cada una de estas decisiones se toma en código. Cada una es simultáneamente técnica y ética. La ética no está en algún documento de "values" — está en engine.py:line_47.

Implicación: separación imposible

Es imposible separar "engineering" de "ética" en AI. Todo eng decision es eng decision Y ethics decision al mismo tiempo.

Pretender lo contrario es como un cirujano diciendo "yo solo opero, las consecuencias son del hospital". Las consecuencias son resultado directo de cómo operás.

Lo que esto significa en tu día a día

Translation a comportamiento concreto:

Antes (mentalidad pasiva)

Recibís ticket: "implementar feature X".
Implementás feature X.
Tests pasan, commit, PR.
"Mi responsabilidad termina cuando el código compila y los tests pasan."

Después (mentalidad responsable)

Recibís ticket: "implementar feature X".
Antes de empezar: pregunto si feature X afecta a personas, quiénes, cómo.
Si aplica: aplico Ethics Impact Analysis (cápsulas 7-8) inicialmente.
Durante implementación: incluyo bias testing en code, no después.
Antes de PR: corro disaggregated testing si aplica. Reporto resultados explícitamente.
En PR description: documento limitaciones conocidas del modelo.
Si detecto problema ético: lo levanto al PM/team, bloqueando merge si es severo.
Mi responsabilidad termina cuando: el sistema deployed funciona dentro de bounds éticos verificados, NO solo cuando el código compila.

Concretamente, qué cambia

Práctica	Antes	Después
Acceptance criteria	"Tests pasan, performance > X"	"Tests pasan, performance > X, bias testing < Y por subgrupo, model card documented"
Code review	Performance, correctness	Performance, correctness, fairness implications, privacy implications
Deploy gate	Manual QA	Manual QA + bias gate (CI test) + privacy review
Post-deploy	Monitor errors	Monitor errors + disparate impact metrics + drift in fairness
Documentation	Code comments, API docs	Code comments, API docs, model card, ethics impact analysis

La pregunta difícil: ¿qué hacés cuando te piden algo no ético?

Realismo. A veces, vas a recibir requests que vos sabés que no son éticos:

"Lanzemos sin bias testing, ya iremos arreglando."
"No documentemos las limitaciones, scare the customers."
"Usá este dataset aunque no tengamos consent claro."
"Aprobá el deploy aunque el disparate impact sea > 4/5 rule."

¿Qué hacés?

Paso 1: documentar técnicamente

No empezar con "esto está mal éticamente" (eso polariza). Empezar con información técnica:

"Quería compartir mi análisis técnico antes de que tomemos la decisión. He medido disparate impact y el ratio actual es 0.65, debajo del threshold legal de 0.80 (4/5 rule). Eso significa exposición a [GDPR Art X / NYC AEDT / etc.]. Mis estimaciones de exposición legal son [Y]. Los costos de fix antes de deploy son [Z]."

Esto convierte el debate de "valores" a "hechos verificables + risk assessment".

Paso 2: ofrecer alternativas

Identificar el problema sin alternativa es solo "bloquear". Identificar con alternativa es "engineering".

"Si el deadline es crítico, hay tres opciones: A) Lanzar con bias issue — riesgo $4M esperado. B) Lanzar con scope reducido (sin afectar grupo X) — tarda 2 semanas más. C) Postponer 4 semanas para implementar mitigation completo. Recomiendo C basado en risk math."

Paso 3: escalar si no resuelve

Si tu PM/team no responde:

Escalar al manager: "Quería traerle este issue porque tiene exposición legal".
Escalar a security/legal: dependiendo de severity.
Documentar por escrito: email con tus concerns + análisis técnico. Esto crea paper trail que te protege individualmente y a la empresa institucionalmente.

Paso 4: línea última — disagreement and commit, o disagree and resign

En muchas empresas existe la cultura "disagree and commit" — argumentás, pero si la decisión va contra vos, te alineás.

Eso funciona para decisiones de producto razonables. No funciona para decisiones que causan daño significativo y vos lo sabés.

La línea última: hay decisiones donde tu única opción ética es no participar. Renunciar a la feature. Renunciar al proyecto. En extremo, renunciar al puesto.

Esto NO es lo primero. Es la última opción, después de documentar, alternativas, escalar. Pero existe, y es válida.

Whistleblowing: si el problema es severo (daño a personas a escala), y la empresa no responde, denunciar externamente es a veces la opción correcta. Esto tiene costos personales reales (Christopher Wylie, Frances Haugen). Pero también protecciones legales (Sarbanes-Oxley, EU Whistleblower Directive).

La respuesta culturalmente correcta vs la éticamente correcta

A veces, la cultura de la empresa te empuja a una respuesta culturalmente correcta ("ship rápido, iteramos") que es éticamente incorrecta.

La cultura no te exime. EU AI Act no acepta "es la cultura de mi empresa" como defensa. Tampoco GDPR. Tampoco la corte.

Tu responsabilidad personal no termina con "lo dijo mi PM". Termina con "actué con due diligence técnica, documenté mis concerns, escalé apropiadamente, y solo entonces participé/no participé".

Trampas y errores comunes

1. "Soy junior, no tengo poder"

Sí tenés. Tenés información técnica que tu manager no tiene. Levantar issues técnicos con análisis es exactamente lo que se espera de junior eng.

Si tu manager te ignora repetidamente con análisis sólido, ese es un indicador de cultura tóxica — y deberías considerar salir.

2. "No me pagan para pensar en ética"

Te pagan para construir sistemas que funcionan. Sistemas que no funcionan correctamente (bias, daño) no son "opcional ético" — son defectuosos técnicamente. Tu trabajo incluye prevenir defectos.

3. "Mejor pedir perdón que permiso"

En security: terrible idea. En privacy: terrible idea. En AI ethics: terrible idea.

Las consecuencias de "ya lo arreglaremos" son los costos 500x de la cápsula 05.

4. "Yo solo escribo código, otros toman las decisiones"

Las decisiones técnicas SON las decisiones éticas. Quien escribe el código toma decisiones, querás o no.

Aceptar esa responsabilidad es lo que separa "developer" de "engineer". Developer ejecuta requisitos. Engineer evalúa requisitos contra realidad técnica + ética + legal y propone alternativas cuando es necesario.

Auto-verificación

1. ¿Por qué "yo solo cumplí los requisitos" no es defensa válida bajo EU AI Act?

Porque EU AI Act asigna obligaciones técnicas específicas al provider, que solo el engineer puede cumplir:

Data governance (Art 10): documentar composición demográfica de datasets.
Technical documentation (Art 11): detalle del modelo.
Risk management (Art 9): identificar y mitigar riesgos técnicos.
Conformity assessment (Art 43): atestar cumplimiento.

Si los requisitos del PM no incluyen bias testing, y vos sabés que es requisito legal, vos sos el que tenía la información para saber que faltaba. "El PM no me lo pidió" no exime, porque vos eras el responsable técnicamente.

Bajo EU AI Act, el provider es responsable, y el engineer es designado como responsible person dentro del provider para functions técnicas. Personal liability emergente.

2. ¿Por qué hay decisiones técnicas que solo el engineer puede tomar correctamente?

Porque requieren información técnica que solo el eng tiene + conocimiento de los trade-offs matemáticos.

Ejemplo: PM pide "sistema fair". Hay decenas de definiciones de "fair" que son matemáticamente incompatibles. Solo el engineer:

Sabe que existen las múltiples definiciones.
Sabe que son incompatibles.
Puede medir cuál tiene qué impacto en outputs.
Puede recomendar cuál priorizar según context.

Si el engineer no propone la decisión informada, alguien menos informado decide (típicamente, terminás con la peor opción técnica por accidente).

Esa es la responsabilidad: no "pensar más", sino levantar la información y proponer la decisión al stakeholder apropiado.

3. ¿Cómo escalás un problema ético sin sonar dramático ni sermonear?

Hablar de números, no de valores.

❌ "Esto no es ético, no debemos hacerlo." ✅ "Mi análisis muestra disparate impact ratio de 0.65 vs threshold legal 0.80. Estimo exposición regulatoria de $X. Costo de fix antes del deploy es $Y. Recomiendo opción [específica]."

La primera frase polariza. La segunda es engineering management.

Documentar por escrito. Email/ticket es paper trail que protege individualmente y crea record institucional.

Ofrecer alternativas concretas. No "no hagamos esto" sino "hagamos A, B, o C, recomiendo B".

Escalar progresivamente. Manager → security/legal → exec. Sin saltar niveles innecesariamente, pero sin estancarte.

4. ¿Cuándo es ético renunciar a una feature/proyecto/empresa?

Cuando:

Has documentado el issue con análisis técnico claro.
Has propuesto alternativas concretas y ejecutables.
Has escalado a manager + escalations apropiadas.
La decisión final es proceder con curso de acción que vas a saber que causa daño significativo.
Tu participación sería material para que ese daño ocurra.

Cuando los 5 cumplen, no participar es la respuesta correcta. Renunciar a la feature primero, al proyecto si necesario, al rol si es la única opción.

NO es la primera respuesta. Es la última, después de procedimientos. Pero existe, y es éticamente válida (incluso requerida en algunas profesiones — médicos, pilotos, ingenieros civiles).

Whistleblowing externo: respuesta más extrema, válida solo cuando daño es significativo (a escala, irreversible) y empresa no responde internamente. Tiene costos personales reales pero también protecciones legales en la mayoría de jurisdicciones.

Resumen y siguiente paso

Responsabilidad ética del engineer es directa, no derivada, basada en tres argumentos:
- Convergencia regulatoria: EU AI Act, NIST AI RMF, ISO 42001 asignan responsabilidad técnica explícita.
- Información asimétrica: solo el engineer tiene la información para detectar issues.
- Causalidad técnica: la ética se implementa en código.
Translation a comportamiento: bias testing en CI, model cards, disaggregated metrics, ethics impact analysis pre-deploy.
Cuando te piden algo no ético: documentar técnicamente, ofrecer alternativas, escalar, último recurso no participar.
La cultura no exime: "es como hacemos las cosas acá" no es defensa bajo regulación o conscience.

Checkpoint: deberías poder articular por qué "yo solo implementé los requisitos" deja de ser defensa válida bajo regulación moderna.

Puente a la siguiente cápsula: cápsulas 1-6 fueron motivación + contexto + responsabilidad. La cápsula 07 te da finalmente la herramienta concreta: el Ethics Impact Analysis framework, paso a paso. Vas a aprender cómo identificar stakeholders, mapear modos de fallo, calcular severidad, priorizar riesgos, y producir un documento profesional que es el equivalente al "threat model" en seguridad. Cápsula 08 es el mini-proyecto: aplicarlo a un sistema real.

Recursos

EU AI Act — Provider obligations (Art 16-29) — referencia legal.
NIST AI RMF — Responsibilities — framework US.
ISO/IEC 42001:2023 — AI Management Systems — estándar internacional.
ACM Code of Ethics — Professional responsibility — estándar profesional.
Christopher Wylie — Mindf*ck book — case study de whistleblowing tech.

Siguiente: 07-ethics-impact-analysis-framework.md — El framework concreto para hacer Ethics Impact Analysis.

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

← Anterior5. Las 4 dimensiones del costo de ignorar ética en AI Siguiente →7. Ethics Impact Analysis: el framework