fast.ai · Practical Deep Learning for Coders · Bonus

Ética de datos: casos reales, no principios abstractos

Dictada por Rachel Thomas, fundadora del Center for Applied Data Ethics de la Universidad de San Francisco. A diferencia de la mayoría de las secciones "de ética" en cursos técnicos, esta va con nombres, cifras y consecuencias concretas — no con generalidades sobre "usar la IA responsablemente".

Antes de leerlección 1

🎯 Al terminar vas a poder

Explicar con tus palabras qué es recourse y por qué un sistema sin vía de apelación es un problema de diseño, no un accidente.
Reconocer un feedback loop en un sistema que controla sus propios datos futuros, y nombrar un caso donde se evitó a propósito.
Distinguir historical, measurement, aggregation y representation bias en un caso concreto, y decir por qué "más datos" no arregla todos.
Aplicar las preguntas de Rachel Thomas y una checklist de señales de alarma a un sistema que vos mismo construiste o vas a construir.
Ubicar qué riesgos de los LLMs generativos el capítulo no anticipó, y qué parte de su marco sigue sirviendo para pensarlos.

1. Recourse: cuando nadie responde por el error

Arkansas implementó un algoritmo para asignar horas de cuidado médico a domicilio. Tammy Dobbs, una mujer con parálisis cerebral que necesita ayuda para levantarse, ir al baño y comer, vio sus horas de asistencia recortadas de golpe en 20 horas semanales, sin explicación. Un juicio reveló errores de implementación del software que afectaban específicamente a personas con diabetes o parálisis cerebral. Nadie asumió responsabilidad: el creador del algoritmo culpó a los funcionarios que lo aplicaron, y estos a quienes lo implementaron en el terreno. La investigadora Danah Boyd lo resume así: la burocracia siempre se usó para difuminar responsabilidad; los sistemas algorítmicos extienden esa misma burocracia, a mayor escala.

Un dato de contexto que el capítulo usa para mostrar que esto no es hipotético: en 2012, la FTC de EE.UU. encontró que el 26% de los reportes crediticios tenían al menos un error, y el 5% errores potencialmente devastadores. A un periodista le tomó más de una docena de llamadas y seis semanas corregir uno solo. Los datos siempre tienen errores — la pregunta de ética no es cómo evitarlos por completo, sino qué mecanismo de auditoría y corrección existe cuando aparecen.

El capítulo insiste en que la responsabilidad no se diluye por estar en el medio de una cadena. Su ejemplo es el ingeniero de Volkswagen que fue a prisión por el software que falseaba las emisiones diésel: no diseñó la estrategia de fraude, "solo" escribió el código que la implementaba, y eso no lo eximió. La lección para quien escribe modelos es directa — "yo solo entrené el modelo, la decisión la toma otro" es exactamente el argumento que el sistema de Arkansas usó para que nadie respondiera.

2. Feedback loops: YouTube, Facebook, Meetup

YouTube (más de 1.900 millones de usuarios, 1.000 millones de horas vistas por día) tiene un algoritmo de recomendación responsable de ~70% del contenido consumido, optimizado para watch time. Esto generó un boom documentado de teorías conspirativas, y en un caso extremo, el sistema armaba playlists de videos inocentes de niños en traje de baño para pedófilos — sin que ningún ingeniero de Google lo hubiera diseñado así explícitamente. Facebook mostró el mismo patrón: unirse a un grupo antivacunas te enrutaba algorítmicamente hacia grupos anti-GMO, terraplanistas y teorías de "chemtrails".

Un feedback loop ocurre cuando un modelo controla la siguiente ronda de datos que va a recibir — quedando "contaminado" por su propio output, y amplificando sesgos pequeños de forma exponencial. El mecanismo, paso por paso: el modelo recomienda X un poco más de lo que corresponde; más gente ve X; los datos nuevos muestran "a la gente le gusta X"; el modelo reentrenado recomienda X todavía más. Ningún paso individual es un error — el problema es el ciclo. El mismo mecanismo aparece en un recomendador de películas entrenado sobre sus usuarios más activos (Lección 7) y en un modelo de riesgo policial que manda patrullas a los barrios donde ya se registraron más arrestos.

El mecanismo de §2 paso a paso. Un modelo que decide lo que la gente ve también decide lo que van a decir los datos con los que se reentrena, y ese ciclo amplifica cualquier desvío inicial. Cortarlo es una decisión de ingeniería, como la de Meetup, no un ajuste del modelo.

Como contraejemplo positivo, el capítulo cita a Meetup.com: decidieron deliberadamente no usar género como variable para recomendar meetups de tecnología, porque detectaron que generaría un loop autorreforzante — menos mujeres verían esos eventos recomendados, y el algoritmo terminaría recomendándolos aún menos a mujeres con el tiempo. Lo importante del caso es que fue una decisión de ingeniería, tomada por el equipo que construía el sistema, antes de que el problema existiera.

📐 Modelado formal de un Feedback Loop como Sistema Dinámico No Lineal

Formalmente, un recomendador o predictor algorítmico no es un observador pasivo, sino una política activa $\pi_\theta(a \mid x)$ que actúa sobre el entorno. Sea $x_t$ el estado latente del usuario o del sistema en el instante $t$ , $a_t \sim \pi_\theta(\cdot \mid x_t)$ la acción recomendada (ej. video mostrado o patrullero enviado), e $y_t$ el feedback observado.

La distribución de datos observados para la siguiente ronda de reentrenamiento $\mathcal{D}_{t+1}$ depende directamente de la política del modelo:

P(x_{t+1}, y_{t+1}) = \int P(x_{t+1}, y_{t+1} \mid x_t, a_t) \pi_{\theta_t}(a_t \mid x_t) P(x_t) \, d a_t \, d x_t

Al reentrenar $\theta_{t+1} = \theta_t - \eta \nabla \mathcal{L}(\mathcal{D}_{t+1})$ , el soporte empírico se contrae progresivamente. En teoría de sistemas dinámicos, esto induce un atractor colapsado donde la divergencia de Kullback-Leibler entre la realidad subyacente y los datos recolectados diverge:

\lim_{t \to \infty} D_{\text{KL}}\left(P_{\text{real}}(x) \parallel P_{\theta_t}(x)\right) \to \infty

3. Sesgo racial: COMPAS, reconocimiento facial

El algoritmo COMPAS, usado en EE.UU. para decisiones de sentencia y fianza, fue auditado por ProPublica en 2016 ("Machine Bias"): entre las personas que no reincidieron, las negras habían sido marcadas como "alto riesgo" casi el doble de veces que las blancas; entre las que sí reincidieron, las blancas habían sido marcadas como "bajo riesgo" con mucha más frecuencia. La empresa respondió que el modelo estaba calibrado (un puntaje de 7 significa lo mismo para cualquier grupo) — y las dos cosas son ciertas a la vez: distintas definiciones de "justo" son matemáticamente incompatibles cuando las tasas de base difieren, y elegir cuál importa es una decisión política, no técnica. Google Photos etiquetó por error a un desarrollador negro y a una amiga suya como "gorilas". El software de reconocimiento facial de Amazon (Rekognition) confundió a 28 congresistas de EE.UU. con fichas policiales, de forma desproporcionada entre personas de color.

📐 Teorema de Imposibilidad de la Equidad Algorítmica (Kleinberg et al., 2016)

Sea $Y \in \{0, 1\}$ el evento real (ej. reincidencia), $R \in [0, 1]$ la puntuación de riesgo predicha por el modelo, y $A \in \{0, 1\}$ un atributo protegido (ej. grupo racial). Consideremos tres condiciones deseables de equidad:

Calibración por grupo: Para cualquier puntaje $r$ , la probabilidad real de reincidir es la misma en ambos grupos: $P(Y = 1 \mid R = r, A = 0) = P(Y = 1 \mid R = r, A = 1) = r$ .
Tasa de Falsos Positivos igualada (Balance de negativos): La probabilidad de clasificar erróneamente a un inocente no depende del grupo: $P(R > \tau \mid Y = 0, A = 0) = P(R > \tau \mid Y = 0, A = 1)$ .
Tasa de Falsos Negativos igualada (Balance de positivos): La probabilidad de ignorar a un reincidente no depende del grupo: $P(R \le \tau \mid Y = 1, A = 0) = P(R \le \tau \mid Y = 1, A = 1)$ .

Teorema: Si las tasas base poblacionales difieren entre los grupos ( $P(Y = 1 \mid A = 0) \neq P(Y = 1 \mid A = 1)$ ), es matemáticamente imposible satisfacer simultáneamente la Calibración y el Balance de Tasas de Error, salvo en el caso trivial de un predictor perfecto sin error alguno ( $R = Y$ ).

Este teorema resolvió la disputa COMPAS: Northpointe tenía razón matemática en que su modelo estaba calibrado, y ProPublica tenía razón matemática en que violaba la igualdad de falsos positivos. La matemática prohíbe satisfacer ambas a la vez; elegir cuál sacrificar es una decisión ética y jurídica, nunca técnica.

El estudio más contundente es Gender Shades, de Joy Buolamwini (MIT) y Timnit Gebru (2018): el sistema de IBM tenía 34,7% de error en mujeres de piel oscura, contra 0,3% en hombres de piel clara — más de 100 veces más errores. El hallazgo metodológico es tan importante como la cifra: los benchmarks con que esas empresas reportaban "99 % de accuracy" estaban compuestos mayoritariamente por rostros de hombres de piel clara, así que el error en los otros subgrupos era invisible hasta que alguien armó un dataset balanceado y midió por separado. Tras la publicidad negativa, las empresas mejoraron drásticamente en menos de un año, lo cual es la parte más importante del caso: demuestra que el problema era de datasets de entrenamiento y evaluación pobres, no una limitación técnica inevitable de la visión por computadora.

4. Myanmar: cuando la escala supera la responsabilidad

Una investigación de la ONU (2018) determinó que Facebook jugó un "rol determinante" en el genocidio de los rohingya. Activistas locales alertaron a Facebook desde 2013, y en 2015 les advirtieron explícitamente del paralelismo con las radios que incitaron el genocidio de Ruanda (1 millón de muertos). Pese a esto, a fines de 2015 Facebook solo tenía cuatro contratistas que hablaban birmano. Zuckerberg recién prometió contratar moderadores en 2018 — años después de iniciado el genocidio, que incluyó la quema de al menos 288 aldeas.

El contraste que marca el capítulo: Facebook contrató rápidamente 1.200 personas en Alemania para evitar multas de hasta 50 millones de euros bajo la ley alemana antidiscurso de odio. Reaccionó más rápido a una amenaza financiera regulatoria que a la destrucción de una minoría étnica — la escala de la plataforma superó por completo su capacidad (o voluntad) de moderación responsable. El punto general que el capítulo extrae: un sistema que opera en un idioma, país o dominio que su equipo no entiende no tiene forma de detectar sus propios daños, y las alertas externas solo funcionan si hay alguien con poder para actuar sobre ellas.

5. Una taxonomía de bias, no solo "los datos están sesgados"

El capítulo toma de Suresh & Guttag (MIT) cuatro categorías concretas, no una noción vaga de "sesgo":

Tipo	Qué es	Ejemplo del capítulo	Por qué "más datos" no lo arregla
Historical bias	El sesgo ya existe en la sociedad, antes de tocar los datos	Médicos recomiendan menos cateterismo cardíaco a pacientes negros; vendedores de autos ofrecen precios iniciales US$700 más altos a compradores negros	Más datos del mismo mundo reproducen el mismo sesgo con más precisión
Measurement bias	Se mide mal la variable objetivo, o se usa un proxy que mide otra cosa	Un modelo para predecir ACV usando historia clínica encontró que "sinusitis" era predictor top — en realidad mide quién fue al médico, no quién tuvo un ACV	El proxy sigue siendo el proxy; hay que cambiar qué se mide
Aggregation bias	Un solo modelo para grupos que necesitan modelos distintos; se ignoran interacciones	Tratamiento de diabetes basado en estadísticas univariadas que ignoran diferencias reales por etnia/género	Requiere cambiar el modelo (o hacer varios), no la cantidad de filas
Representation bias	El dataset no representa a la población, y el modelo amplifica el desbalance	14,6% de cirujanos en el dataset eran mujeres; el modelo solo predijo 11,6% como mujeres	Este sí mejora con datos — pero datos del subgrupo subrepresentado, no más de lo mismo

Tener nombres distintos para cada mecanismo importa porque la solución es distinta en cada caso: más datos no arregla un measurement bias si la variable que se mide está mal definida desde el origen. El paper original va más allá de estas cuatro: agrega evaluation bias (el benchmark con que se mide el modelo no representa el uso real — exactamente el caso de Gender Shades) y deployment bias (el sistema se usa para algo distinto de aquello para lo que se diseñó — COMPAS fue pensado como apoyo para programas de rehabilitación y terminó influyendo sentencias). Vale la pena leerlo completo porque ubica cada tipo en una etapa del ciclo de vida del modelo, desde la recolección de datos hasta la puesta en producción, lo que lo convierte en una checklist de por dónde puede entrar el daño.

6. Preguntas concretas antes de desplegar

Lista de Rachel Thomas para analizar cualquier proyecto antes de lanzarlo:

¿Deberíamos siquiera estar haciendo esto?
¿Qué sesgo hay en los datos?
¿Pueden auditarse el código y los datos?
¿Cuáles son las tasas de error para distintos subgrupos?
¿Cuál es la precisión de una alternativa simple basada en reglas?
¿Qué proceso existe para manejar apelaciones o errores?
¿Qué tan diverso es el equipo que construyó esto?

Cada pregunta apunta a un caso de las secciones anteriores: la de tasas de error por subgrupo es Gender Shades; la de apelaciones es Arkansas; la de la alternativa basada en reglas existe porque un sistema simple y auditable a veces es más honesto que uno preciso e inexplicable; la del equipo es Myanmar — cuatro personas que hablaban el idioma. Prácticas organizacionales sugeridas: barridos éticos periódicos (como pentesting), ampliar el círculo de gente consultada más allá del equipo técnico, y un ejercicio deliberado de pensar como "la gente terrible" — cómo actores maliciosos podrían abusar, robar o armar lo que estás construyendo. El capítulo también menciona el enfoque del Markkula Center de mirar una decisión desde varias "lentes" éticas a la vez (derechos, justicia, utilidad, bien común, virtud): no para elegir una, sino porque cada una hace visible un daño distinto.

7. El vacío de este capítulo: no hay LLMs generativos acá

🟢 Lo que este capítulo de 2020 no podía anticipar

El capítulo menciona "texto autogenerado como desinformación" como riesgo emergente, citando la propuesta de Oren Etzioni de firmar digitalmente contenido verificado — pero no podía anticipar la escala real que tomó con GPT-3/4. No hay ninguna mención de jailbreaking o prompt injection, RLHF o alineación como mitigación (el concepto ni existía en el discurso público en 2020), deepfakes generativos con modelos de difusión (Stable Diffusion es de 2022), litigios por derechos de autor sobre datos de entrenamiento (NYT vs. OpenAI, artistas vs. Stability AI, todos de 2023 en adelante), ni la industria de AI safety/alignment que se consolidó después. El marco conceptual del capítulo (recourse, feedback loops, la taxonomía de Suresh & Guttag) sigue siendo la base correcta — pero los ejemplos concretos de riesgo específicos de LLMs generativos simplemente no estaban en el radar de nadie todavía.

Dos lecturas que sí cubren ese terreno con el mismo espíritu de taxonomía concreta: Weidinger et al., "Ethical and social risks of harm from Language Models" (2021, arXiv:2112.04359), que clasifica los riesgos de los LLMs en seis áreas — discriminación y toxicidad, fuga de información privada, desinformación, usos maliciosos, daños por interacción humano-máquina (por ejemplo, confiar de más en un sistema que suena seguro) y daños ambientales y socioeconómicos — y Bender, Gebru, McMillan-Major y Mitchell, "On the Dangers of Stochastic Parrots" (FAccT 2021), que argumenta que un modelo entrenado para continuar texto reproduce los sesgos de su corpus sin ningún acceso a la verdad de lo que dice. Las dos se leen como la continuación natural de la tabla de §5.

Vale la pena leer este capítulo precisamente por ese contraste: el marco (quién responde, cómo se amplifican los sesgos, qué tipo de sesgo es cada caso) es tan aplicable a un LLM de 2026 como a un algoritmo de asignación de horas de cuidado médico de 2018 — lo que cambió es la escala y la velocidad a la que estos sistemas ahora se despliegan. Un generador de texto que inventa una cifra con tono seguro es un problema de measurement (el modelo mide "qué texto es plausible", no "qué es verdad") y de recourse (¿quién corrige, y cómo se entera el lector?) al mismo tiempo.

8. Señales de alarma en tu propio proyecto

Una tabla de "errores comunes" sería forzada acá: no hay bug que corregir. En cambio, esta es una lista de señales que, si aparecen en cualquier sistema que despliegue un modelo, indican que alguna de las preguntas de §6 no tiene respuesta todavía. No están ordenadas por gravedad.

No existe un camino para que un afectado diga "esto está mal" y alguien lo revise. Si la única forma de corregir una salida es que un desarrollador la vea por casualidad, el sistema no tiene recourse (§1).
La métrica que optimizás es un proxy y nadie mira la diferencia con lo que realmente importa. Watch time no es satisfacción; "texto plausible" no es "texto verdadero"; visitas al médico no son enfermedades (§2, §5).
Reportás una sola tasa de error global. Si no la desagregaste por subgrupo (idioma, región, género, tipo de entrada), no sabés si el 2 % de error es 0,3 % para unos y 35 % para otros (§3).
Las salidas del modelo alimentan, directa o indirectamente, sus próximos datos de entrenamiento o su próxima selección de datos. Ese es el feedback loop, y no hace falta que sea un recomendador: alcanza con que el sistema decida qué se muestra, qué se registra o qué se revisa (§2).
Nadie en el equipo entiende el idioma, el dominio o el contexto de una parte de los usuarios. No vas a detectar daños en un lugar que no podés leer (§4).
La respuesta a "¿qué pasa si alguien lo usa a propósito para hacer daño?" es "no está pensado para eso". Deployment bias: el uso real siempre excede el uso previsto (§5, §6).
El modelo se evalúa con un benchmark que no se parece al tráfico real. Evaluation bias: Gender Shades existe porque los benchmarks estaban compuestos por rostros de un solo tipo (§3, §5).
Un error del sistema no tiene un responsable con nombre. Si la explicación de un fallo termina en "el modelo decidió", nadie va a arreglarlo (§1).
No hay una alternativa simple contra la que compararse. Si nunca mediste qué haría una regla fija o un humano con una planilla, no podés afirmar que el modelo agrega valor neto (§6).
La salida se entrega al usuario con más confianza de la que el modelo tiene. Un número sin intervalo, un texto sin marca de "generado", una recomendación sin "por qué": todo eso empuja al lector a confiar de más (§7).

9. Resumen

La falta de recourse (vías de apelación) es, según el capítulo, el problema estructural más común en sistemas algorítmicos desplegados a escala — y escribir el código no exime de responsabilidad.
Los feedback loops amplifican sesgos pequeños hacia extremos, sin que nadie lo haya diseñado explícitamente así; Meetup muestra que se pueden cortar por decisión de ingeniería.
El sesgo algorítmico documentado (COMPAS, reconocimiento facial) no es una limitación técnica inevitable — mejora rápido cuando hay presión pública real, y se vuelve visible recién cuando se mide por subgrupo.
La taxonomía de Suresh & Guttag (historical, measurement, aggregation, representation, y además evaluation y deployment bias) importa porque cada tipo necesita una solución distinta; "más datos" solo arregla uno.
Las preguntas de Rachel Thomas y la checklist de señales de alarma son herramientas para aplicar a tus propios sistemas, no para leer sobre los ajenos.
El capítulo es de 2020 y no anticipa ningún riesgo específico de LLMs generativos — pero su marco conceptual sigue siendo la base correcta para pensarlos; Weidinger et al. y "Stochastic Parrots" son la continuación.

10. Ponete a prueba

Respondé antes de abrir cada respuesta. Si fallás una, volvé a la sección indicada.

1. ¿Qué tienen en común el caso de Tammy Dobbs y los reportes crediticios con errores?

En ambos, el problema central no es que el sistema se equivoque (todos los datos tienen errores) sino que no hay un mecanismo accesible para detectar y corregir el error, ni un responsable identificable — falta de recourse. (§1)

2. Describí el feedback loop de YouTube en cuatro pasos, sin usar la palabra "sesgo".

El algoritmo recomienda un tipo de video un poco más; más gente lo mira; los datos nuevos dicen "esto retiene"; el modelo reentrenado lo recomienda todavía más. Ningún paso es un error; el ciclo es el problema. (§2)

3. Un sistema de reconocimiento facial reporta 99 % de accuracy. ¿Qué le preguntás antes de creerle?

Sobre qué dataset se midió y cómo está compuesto, y cuál es el error por subgrupo (tono de piel × género). Gender Shades mostró 0,3 % vs. 34,7 % detrás de un promedio que parecía excelente. (§3)

4. Un modelo predice ACV y su mejor predictor es "consultó por sinusitis". ¿Qué tipo de bias es y qué lo arregla?

Measurement bias: la variable objetivo mide "quién fue al médico y quedó registrado", no "quién tuvo un ACV". No lo arregla juntar más registros del mismo tipo; hay que cambiar cómo se define y mide el target. (§5)

5. ¿Por qué el paper de Suresh & Guttag distingue evaluation bias de representation bias, si ambos hablan de datasets?

Representation bias está en los datos de entrenamiento (el modelo aprende mal a un subgrupo); evaluation bias está en el benchmark (el modelo puede ser malo para un subgrupo y la métrica no lo muestra). Se pueden tener por separado, y se corrigen en etapas distintas del ciclo de vida. (§5)

6. ¿Qué parte del marco del capítulo aplica a un LLM que inventa una cifra con tono seguro, y qué parte del riesgo no está cubierta?

Aplica measurement bias (el modelo optimiza plausibilidad, no verdad) y recourse (¿quién corrige, cómo se entera el lector?). No cubre lo específico de la generación: prompt injection, jailbreaks, la escala de producción de desinformación — para eso, Weidinger et al. (§7)

11. Para practicar

✏️ Ejercicio 1 — Las siete preguntas sobre un sistema que conocés

Elegí un sistema que hayas construido o que conozcas por dentro. Si no tenés otro a mano, usá el generador de artículos financieros con gate de verificación descrito en la sección de proyectos — es un sistema donde un modelo genera texto y una etapa posterior decide si sale o no. Respondé por escrito, en una o dos líneas cada una, las siete preguntas de §6. Reglas: (a) si la respuesta honesta es "no sé", escribila así — es la respuesta más útil del ejercicio; (b) no inventes mecanismos que el sistema no tiene; (c) para "tasas de error por subgrupo", definí primero cuáles serían los subgrupos relevantes para ese sistema (tipo de artículo, fuente, idioma, período, tipo de cifra) antes de responder.

Pista / qué esperar

Lo típico: las preguntas 2 y 4 (sesgo en los datos, error por subgrupo) son las que suelen quedar en "no sé" porque nunca se midió por separado; la 5 (alternativa basada en reglas) revela si existe un baseline contra el que comparar el gate; la 6 (apelaciones) es la más incómoda para un sistema que publica texto — ¿cómo se entera el sistema de que un artículo publicado tenía un error que el gate no atrapó, y quién lo corrige? Si al terminar tenés tres "no sé", el ejercicio funcionó.

✏️ Ejercicio 2 — Clasificar tres fallos con la taxonomía

Sobre el mismo sistema, imaginá tres fallos concretos que podría tener (un dato inventado que pasa el gate, una fuente sistemáticamente mal interpretada, un tipo de artículo que siempre se rechaza). Para cada uno, decidí en qué categoría de Suresh & Guttag cae (historical, measurement, aggregation, representation, evaluation, deployment), en qué etapa del ciclo de vida entró, y cuál sería la corrección — y marcá explícitamente si "más datos" ayudaría o no.

Pista / qué esperar

Un dato inventado que pasa el gate suele ser measurement (el gate mide algo distinto de "verdad") o evaluation (el conjunto de prueba del gate no incluía ese tipo de invención). Un tipo de artículo siempre rechazado apunta a representation (poco visto en entrenamiento o calibración) o aggregation (un solo umbral para tipos que necesitarían umbrales distintos). Si un fallo cae en dos categorías, está bien: el ejercicio es ver que cada una sugiere una corrección distinta.

12. Fuentes y para seguir

fastbook — 03_ethics.ipynb — el capítulo completo, con todos los casos de esta página y las referencias primarias de cada uno.
ProPublica, "Machine Bias" (2016) — la investigación original sobre COMPAS; leé también la metodología publicada aparte para ver cómo se mide sesgo por subgrupo en un caso real.
Buolamwini & Gebru, "Gender Shades" (PMLR 81, 2018) — el paper de §3: cómo armar un benchmark balanceado y qué aparece cuando se mide por tono de piel y género.
Suresh & Guttag, "A Framework for Understanding Sources of Harm throughout the Machine Learning Life Cycle" — la taxonomía completa de §5, ubicada en el ciclo de vida del modelo; la versión más reciente en arXiv agrega categorías respecto de la que cita el libro.
ONU — Independent International Fact-Finding Mission on Myanmar (2018) — el informe de la misión citado en §4, con la sección sobre el rol de las redes sociales.
Weidinger et al., "Ethical and social risks of harm from Language Models" (2021) — la taxonomía de riesgos específica de LLMs que le falta al capítulo; leela después de §7.