Al cerrar el módulo 7, el equipo de TecnoMarket entregó un portfolio de cinco modelos funcionando: clasificador de imágenes, generador de descripciones, detector de fraude, GAN de imágenes promocionales y un modelo afinado con transfer learning. Todos funcionan. Pero "funciona" no es lo mismo que "es correcto usarlo así". Un detector de fraude con buen recall global puede estar penalizando sistemáticamente a un barrio entero; un generador de imágenes puede fabricar contenido engañoso; un clasificador puede discriminar sin que nadie lo haya programado para ello. Esta lección convierte esas preocupaciones difusas en herramientas concretas: cómo se origina el sesgo, cómo detectarlo con código, cómo mitigarlo, cómo explicar decisiones de una caja negra, cómo tratar los datos personales y qué hacer con el contenido sintético. Es, además, donde saldamos la deuda pendiente desde la lección 05-01: el riesgo de los deepfakes.

1. Sesgo algorítmico: de dónde viene realmente
2. El sesgo en TecnoMarket: dos casos concretos
3. Detección práctica: métricas por subgrupos
4. Mitigación del sesgo y sus dilemas
5. Transparencia y explicabilidad: abrir la caja negra
6. Privacidad: los datos personales detrás del modelo
7. Deepfakes y contenido sintético: la deuda de 05-01
8. Checklist ética de TecnoMarket antes de cada despliegue

Un mito frecuente: "el algoritmo es matemático, luego es neutral". Falso. Una red neuronal aprende exactamente lo que hay en sus datos, incluidos los patrones que preferiríamos que no aprendiera. El sesgo algorítmico no suele venir de un programador malintencionado, sino de tres fuentes mucho más mundanas:

• Datos históricos sesgados: si los datos reflejan decisiones humanas pasadas injustas, el modelo las perpetúa. Aprendió del pasado, y el pasado no era neutral.
• Representación desigual: si un grupo aparece poco en el dataset, el modelo funciona peor para ese grupo. No por "odio", sino por pura estadística: menos ejemplos, peor generalización. Es el mismo fenómeno que vimos con clases desbalanceadas en el detector de fraude (07-03), aplicado a personas.
• Variables proxy: el modelo no necesita ver la variable sensible (género, etnia, edad) para discriminar por ella. Basta con que otra variable correlacione: el código postal correlaciona con nivel de renta y origen; el historial de compras, con la edad; el nombre, con el género.

Algunos casos reales conocidos que conviene tener presentes:

Fíjate en el patrón: en ninguno de estos casos alguien programó la discriminación. Emergió de los datos. Esa es la lección central: el sesgo es el comportamiento por defecto de un modelo entrenado con datos del mundo real, no una anomalía exótica.

Bajemos a nuestro portfolio. Dos de los cinco modelos tienen riesgo directo de sesgo:

El detector de anomalías de 07-03 usa, entre otras variables, datos de la transacción y del cliente. Supongamos que el equipo incluyó el código postal (o algo que correlaciona con él, como la franja de precio media del barrio de entrega). Riesgo: si históricamente hubo más fraude detectado en ciertos barrios —quizá porque se investigaba más allí, no porque hubiera más fraude real—, el modelo aprenderá "código postal X ⇒ sospechoso". Resultado: clientes legítimos de esos barrios sufren más bloqueos, más fricción y más "clientes molestos" de los que cuantificamos a 5 € en la matriz de confusión en euros de 07-03. Pero ese coste de 5 € no se reparte uniformemente: se concentra en un grupo. Eso ya no es solo un coste de negocio; es un problema de equidad.

TecnoMarket permite a vendedores externos subir productos. Los grandes vendedores suben fotos de estudio (fondo blanco, buena luz); los pequeños, fotos caseras (fondo de cocina, luz amarilla, móvil antiguo). Si el clasificador de 07-01/07-05 se entrenó mayoritariamente con fotos de estudio, tendrá peor accuracy en fotos caseras. Consecuencia: los productos de vendedores pequeños se clasifican mal, caen más a menudo en la cola de revisión humana (03-04) o directamente se categorizan mal y no aparecen en las búsquedas. El modelo, sin saberlo, favorece a los vendedores grandes. Es representación desigual pura: el subgrupo "foto casera" está infrarrepresentado.

Ambos casos comparten una propiedad incómoda: las métricas globales no los detectan. Un 91 % de accuracy global puede esconder un 96 % en fotos de estudio y un 74 % en fotos caseras. Por eso la detección exige desagregar.

La herramienta básica de auditoría de sesgo es sencilla y ya conoces todas las piezas: calcular las métricas del módulo 7, pero por separado para cada subgrupo relevante. Un ejemplo con el detector de fraude, evaluando recall y tasa de falsos positivos por segmento de código postal:

Un resultado como este debería encender todas las alarmas:

El recall es similar en todas las zonas (el modelo caza fraude parecido en todas), pero la tasa de falsos positivos es 5 veces mayor en la periferia: un cliente legítimo de periferia_norte tiene 5 veces más probabilidad de que le bloqueen la compra. Eso es sesgo medible. Claves del método:

• Elige los subgrupos antes de mirar resultados (zona, tipo de vendedor, franja de edad, idioma de la reseña...), para no buscar solo donde no duele.
• Compara la métrica que representa el daño para ese grupo. Para clientes legítimos, la tasa de falsos positivos; para vendedores, el accuracy de clasificación de sus fotos.
• Cuidado con subgrupos pequeños: con n = 50, las diferencias pueden ser ruido. Reporta también el tamaño de muestra.
• Automatízalo: este análisis debe correr en cada reentrenamiento, igual que la validación sobre el conjunto congelado de 06-05, no una vez y nunca más.

Detectado el sesgo, hay tres familias de intervención, ordenadas de más recomendable a más delicada:

El tercer punto merece pausa, porque revela algo profundo: existen varias definiciones matemáticas de "justicia" y son mutuamente incompatibles en el caso general. Igualar la tasa de falsos positivos entre grupos, igualar el recall, o usar el mismo umbral para todos son tres criterios razonables… y salvo casos degenerados no se pueden satisfacer los tres a la vez. No hay un teorema que decida por ti: es una decisión de valores que el equipo debe tomar explícitamente, documentar y poder defender. Lo inaceptable no es elegir un criterio u otro; es no haber elegido conscientemente ninguno.

Una red profunda con millones de parámetros no ofrece una explicación legible de por qué bloqueó una transacción. Esto importa por tres razones:

1. Confianza del usuario: "su compra ha sido bloqueada" sin motivo genera fuga de clientes.
2. Depuración del equipo: sin explicaciones, el sesgo del apartado anterior es más difícil de diagnosticar.
3. Derecho a explicación: en la UE, las personas tienen derecho a no ser objeto de decisiones totalmente automatizadas con efectos significativos, y a obtener intervención humana e información significativa sobre la lógica aplicada (idea recogida en el RGPD; ver la sección de privacidad y su advertencia legal).

Herramientas a nivel conceptual (no las implementaremos aquí):

• Mapas de saliencia / Grad-CAM (visión): resaltan qué píxeles influyeron más en la predicción. Si el clasificador de 07-05 "mira" el fondo de la cocina en vez del producto, lo verás literalmente: es la forma más directa de confirmar el sesgo de las fotos caseras.
• SHAP / importancia de atribución (tabular): asignan a cada variable de entrada una contribución a la predicción concreta. "Esta transacción se marcó por: importe 4× superior a la media del cliente (+0.31), envío a dirección nueva (+0.22)…". Si el código postal aparece sistemáticamente como principal contribuyente, tienes el proxy delante.
• Modelos sustitutos simples: entrenar un árbol de decisión que imite al modelo grande para obtener reglas aproximadas legibles.

Y la salvaguarda organizativa que ya construimos: la cola de revisión humana con umbral de confianza de 03-04. Cuando el modelo no está seguro —o cuando la decisión es de alto impacto, como bloquear a un cliente—, decide una persona, no el modelo. La decisión a tres bandas de 07-03 (aprobar / revisar / bloquear) es exactamente esto: la franja "revisar" es donde vive la garantía humana. La explicabilidad técnica y la revisión humana no compiten; se complementan: la primera ayuda al revisor humano a decidir mejor y más rápido.

Los cinco modelos de TecnoMarket se entrenaron con datos que, en un despliegue real, incluyen datos personales: historiales de compra, reseñas escritas por clientes, direcciones. Principios prácticos:

• Minimización: entrena solo con las variables que necesitas. Cada columna de datos personales que no usas es riesgo gratuito. ¿De verdad el generador de descripciones de 07-02 necesita el nombre del autor de cada reseña? No.
• Anonimización y sus límites: quitar el nombre y el DNI no basta. La combinación de código postal + fecha de nacimiento + sexo reidentifica a la mayoría de la población; los historiales de compra detallados son casi huellas dactilares. La seudonimización (sustituir identificadores por códigos) reduce el riesgo pero no lo elimina.
• Memorización de los generativos: los modelos generativos pueden memorizar y regurgitar fragmentos de entrenamiento. El generador de 07-02, entrenado con reseñas reales, podría reproducir literalmente una reseña que contenga datos personales ("llegó tarde a mi casa en la calle X..."). Esto refuerza la revisión humana de toda salida generada antes de publicarla, que ya establecimos en 07-02.
• Derechos de los interesados: acceso, rectificación, supresión. "Suprimir" es incómodo en deep learning: el dato puede estar diluido en los pesos. La práctica habitual es eliminarlo del dataset y aplicarlo en el siguiente reentrenamiento, documentando el proceso.

Sobre el marco normativo europeo, a nivel puramente orientativo: el RGPD regula el tratamiento de datos personales (base jurídica, minimización, derechos, decisiones automatizadas) y el Reglamento Europeo de IA (AI Act) clasifica los sistemas de IA por nivel de riesgo, imponiendo obligaciones crecientes —transparencia, supervisión humana, gestión de riesgos— a los de alto riesgo, y obligaciones de marcado a ciertos contenidos generados por IA.

Advertencia importante: nada de lo anterior es asesoramiento legal. Este curso resume ideas generales con fines formativos; los detalles, plazos, clasificaciones de riesgo y obligaciones concretas dependen del caso, el sector y la jurisdicción, y cambian con el tiempo. Antes de cualquier despliegue real que trate datos personales o tome decisiones sobre personas, el proyecto debe revisarlo un profesional de compliance/legal.

En 05-01 aprendimos cómo funcionan las GAN y aplazamos deliberadamente la conversación sobre su mal uso. En 07-04 entrenamos una DCGAN capaz de generar imágenes de ropa razonablemente convincentes. Es momento de saldar la deuda.

La misma tecnología escala a rostros y voces indistinguibles de los reales: los deepfakes. Los riesgos son concretos: suplantación de identidad (vídeos falsos de directivos autorizando transferencias), desinformación, imágenes íntimas no consentidas y erosión general de la confianza ("si todo puede ser falso, nada prueba nada").

TecnoMarket no hace deepfakes de personas, pero su generador de 07-04 (y cualquier evolución futura hacia imágenes promocionales realistas) plantea versiones comerciales del mismo problema:

• Generar una foto "del producto" que no corresponde al producto real ⇒ publicidad engañosa.
• Generar imágenes con personas sintéticas usándolas como si fueran clientes reales ("María, de Sevilla, opina...") ⇒ testimonios fabricados.
• Generar reseñas sintéticas con el modelo de 07-02 y publicarlas como si fueran de clientes ⇒ directamente fraude al consumidor.

Marco de uso responsable del contenido sintético, en cuatro reglas:

1. Nunca presentar lo sintético como real cuando eso influya en decisiones de compra o de confianza. Las imágenes promocionales generadas se usan como ilustración creativa, no como foto del producto.
2. Marcar el contenido sintético: etiqueta visible ("imagen generada por IA") y, cuando la herramienta lo permita, marcado técnico (metadatos de procedencia, estándares tipo C2PA, marcas de agua). El marcado además está alineándose con obligaciones regulatorias (ver advertencia legal anterior).
3. Revisión humana antes de publicar, la regla que ya rige el generador de texto de 07-02: nada generado sale al público sin ojos humanos.
4. Uso prohibido explícito: la política interna debe listar lo que no se hace nunca (reseñas falsas, personas sintéticas presentadas como reales, imitación de marcas o personas), para que no dependa del criterio individual de cada empleado un viernes por la tarde.

Todo lo anterior se condensa en una checklist que el equipo añade al final de la checklist de despliegue de 06-05. Ningún modelo pasa a producción sin responderla por escrito:

Nótese que la checklist no exige perfección: exige haber mirado, haber decidido y haberlo documentado. La negligencia ética casi nunca es una mala decisión; es la ausencia de decisión.

• "Mi modelo no discrimina: no le doy la variable sensible." Error clásico. Los proxies (código postal, historial, nombre) transmiten la información igualmente. La única forma de saberlo es medir resultados por subgrupo, no inspeccionar la lista de columnas.
• Auditar una sola vez. El sesgo reaparece con cada reentrenamiento y con la deriva de datos (06-05). La auditoría por subgrupos debe ser parte del pipeline, no un evento.
• Confundir explicabilidad con excusa. "El modelo lo decidió" no es una explicación válida ante un cliente ni ante un regulador. Si no puedes explicar la decisión, la decisión de alto impacto no debe ser totalmente automática.
• Igualar métricas sin pensar cuál. Antes de aplicar umbrales por grupo, decide explícitamente qué noción de equidad persigues y documenta por qué; recuerda que no puedes satisfacerlas todas a la vez.
• Tratar la privacidad como un problema de la base de datos. Los pesos del modelo también "contienen" datos: los generativos pueden memorizar. Prueba activamente si tu generador regurgita textos de entrenamiento.
• Consejo: convierte la checklist en un documento vivo del repositorio, versionado junto al modelo. Cuando algo salga mal (saldrá), tener el razonamiento por escrito distingue un error honesto de una negligencia.
• Consejo: en subgrupos pequeños, acompaña siempre la métrica de su n. Una diferencia enorme con n = 30 merece recoger más datos antes que rediseñar el modelo.

El equipo desagrega el accuracy del clasificador de 07-05 por tipo de vendedor y obtiene: vendedores grandes (fotos de estudio, n = 18 000): 94 %; vendedores pequeños (fotos caseras, n = 2 400): 76 %. El director comercial dice: "el global es 92 %, superamos el objetivo del 90 %, desplegamos". Analiza: (a) ¿qué está mal en ese razonamiento?; (b) propón dos mitigaciones concretas de familias distintas, con su coste y su riesgo; (c) ¿qué papel puede jugar la cola de revisión humana de 03-04 mientras la mitigación llega?

En el detector de fraude, la tasa de falsos positivos es del 0,8 % en el centro y del 4,1 % en la periferia norte (recall similar). Un ingeniero propone subir el umbral de anomalía solo en la periferia hasta igualar los falsos positivos al 0,8 %. Simula la discusión del equipo: da un argumento sólido a favor, un argumento sólido en contra, identifica qué información adicional pedirías antes de decidir y qué opción alternativa existe que no toque los umbrales.

Marketing quiere usar la GAN (evolucionada) para generar: (a) fondos decorativos abstractos para banners; (b) imágenes fotorrealistas de los productos "mejoradas" para las fichas de producto; (c) rostros de "clientes satisfechos" junto a reseñas reales anonimizadas. Aplica el marco de uso responsable de contenido sintético a cada caso y dictamina: permitido sin más, permitido con condiciones (¿cuáles?), o prohibido (¿por qué?).

Solución 1. (a) El 92 % global es una media ponderada que oculta que un subgrupo recibe un servicio muy inferior (76 %); como los vendedores pequeños son minoría (2 400 de 20 400), su mal resultado apenas mueve la media. El objetivo "90 % global" no protege a los subgrupos, y el daño es asimétrico: para un vendedor pequeño, la mala clasificación significa invisibilidad en las búsquedas — el modelo agrava la desventaja del más débil. (b) Mitigación de datos: recolectar/etiquetar varios miles de fotos caseras (incluso pidiéndolas a los propios vendedores o generando aumentos de datos con fondos y luces caseras); coste alto en etiquetado, riesgo bajo. Mitigación de reponderación: repetir el fine-tuning de 07-05 con peso mayor para las fotos caseras; coste bajo, riesgo de perder algo de accuracy en fotos de estudio, que habría que cuantificar (¿bajar de 94 % a 92,5 % a cambio de subir de 76 % a 86 % es buen trato? Casi seguro que sí). (c) Mientras tanto, bajar el umbral de confianza específicamente para fotos identificadas como "no de estudio", enviando más de ellas a la cola de revisión humana: los vendedores pequeños obtienen clasificación correcta (humana) a costa de latencia y coste de revisión, en lugar de obtener clasificación errónea automática.

Solución 2. A favor: la situación actual ya trata desigualmente a los grupos en resultados (un cliente legítimo de periferia sufre 5 veces más bloqueos); el umbral por zona no crea la desigualdad, la corrige, y el criterio "igual tasa de falsos positivos para clientes legítimos" es una noción de equidad defendible y documentable. En contra: introduce una regla explícita que decide distinto según la zona (proxy de origen/renta), lo que puede ser difícil de defender legalmente y ante la opinión pública ("TecnoMarket tiene umbrales distintos por barrio"); además, si el fraude real difiere entre zonas, subir el umbral en la periferia dejará pasar fraude real (coste de 400 €/caso según 07-03). Información adicional: ¿la diferencia de falsos positivos viene de fraude real distinto o de sesgo histórico en las etiquetas (se investigó más en la periferia)? ¿Qué variables empujan la puntuación en la periferia (mirar atribuciones tipo SHAP)? ¿Cuál es el n de cada zona? Alternativa sin tocar umbrales: atacar la causa — eliminar o revisar los proxies de zona en las variables de entrada, reetiquetar el histórico dudoso, reentrenar, y mientras tanto enrutar la franja dudosa de la periferia a la cola de revisión humana en vez de al bloqueo automático. Cualquiera que sea la decisión, debe quedar documentada y pasar por el punto 9 de la checklist (revisión legal).

Solución 3. (a) Fondos abstractos: permitido sin condiciones especiales; no representan nada real ni influyen en la percepción del producto; basta la política general de revisión antes de publicar. (b) Fichas de producto fotorrealistas "mejoradas": permitido solo con condiciones estrictas — la imagen no puede mostrar características que el producto real no tiene (eso es publicidad engañosa); debe marcarse como imagen generada/retocada; revisión humana obligatoria comparando con el producto real; en la duda, usar la generada solo como imagen ambiental y mantener fotos reales del producto. (c) Rostros de "clientes satisfechos": prohibido. Aunque las reseñas sean reales, asociarlas a personas sintéticas presentadas como clientes fabrica testimonios: engaña sobre la identidad de quien avala el producto, viola la regla 1 del marco (no presentar lo sintético como real cuando influye en la confianza) y se acerca al territorio deepfake que motivó este apartado. La alternativa legítima: mostrar las reseñas sin rostro, o con avatares claramente ilustrativos y etiquetados.

Hemos convertido la ética de una declaración de intenciones en un conjunto de prácticas medibles: el sesgo se detecta desagregando métricas por subgrupos (los dos casos de TecnoMarket lo demostraron: el global esconde al subgrupo), se mitiga actuando sobre datos, pesos o umbrales —sabiendo que las nociones de equidad compiten entre sí y hay que elegir una conscientemente—, la opacidad se combate con explicabilidad técnica y con la cola de revisión humana que arrastramos desde 03-04, la privacidad exige minimización y vigilar la memorización de los generativos, y el contenido sintético —la deuda de 05-01, por fin saldada— se gobierna con cuatro reglas: no hacerlo pasar por real, marcarlo, revisarlo y prohibir explícitamente los usos inaceptables. Todo ello cristaliza en la checklist que ahora acompaña cada despliegue de TecnoMarket. Pero estas decisiones de equipo ocurren dentro de un contexto mucho mayor: el deep learning está transformando el empleo, la economía y el acceso a la tecnología a escala de sociedades enteras. Ese es el zoom out de la próxima lección: el impacto social y económico del deep learning.