En la lección anterior vimos que los datos arrastran sesgos y que el modelo los hereda. Ahora toca la pregunta incómoda que Diego planteó al final de aquella reunión: "Si el modelo de riesgo de devolución sospecha más de un barrio que de otro, ¿quién responde cuando un cliente de ese barrio se queje?". Esta lección responde a esa clase de preguntas. La ética en IA no es un apéndice para el final del proyecto ni un asunto exclusivo de juristas: es una parte del diseño, igual que la medida de rendimiento de 02-01 o la calidad de los datos de 02-03. Veremos por qué no es opcional, qué principios la orientan, qué problemas concretos aparecen (sesgo y discriminación, privacidad y vigilancia, opacidad, responsabilidad, impacto laboral, desinformación, sostenibilidad), qué exige el marco regulatorio europeo a nivel introductorio (RGPD y Reglamento de IA) y, sobre todo, qué herramientas prácticas permiten actuar: una checklist de proyecto, la evaluación de impacto, la revisión humana y las métricas de equidad. Terminaremos con código que mide, con números, si el modelo de riesgo de NovaMarket trata igual a dos zonas y añade una regla de revisión humana. Con esto cerraremos el módulo 2.

1. Por qué la ética no es opcional
2. Principios éticos para la IA
3. Sesgo y discriminación: un ejemplo numérico
4. Privacidad y vigilancia
5. Transparencia y explicabilidad: caja negra frente a modelo interpretable
6. Responsabilidad y rendición de cuentas
7. Impacto laboral, desinformación y sostenibilidad
8. Marco regulatorio introductorio: RGPD y Reglamento europeo de IA
9. Herramientas prácticas: checklist, evaluación de impacto, human-in-the-loop y métricas de equidad
10. Ejemplo en Python: medir la disparidad entre zonas y añadir revisión humana

Hay tres razones, y conviene tenerlas todas presentes porque convencen a públicos distintos:

• Razón de principio: los sistemas de IA toman o influyen en decisiones que afectan a personas (qué se les recomienda, si se les revisa una devolución, si su reseña se publica, cuánto tarda su paquete). Cualquier sistema que decide sobre personas debe hacerlo de forma justa y respetuosa; automatizarlo no elimina esa obligación, la escala: una persona sesgada revisa cien pedidos al día; un modelo sesgado revisa tres mil sin cansarse.
• Razón legal: en la Unión Europea, el RGPD y el Reglamento de IA imponen obligaciones concretas con sanciones muy elevadas. Ignorarlas no es una opción de negocio.
• Razón de negocio (la que convenció a Diego): un sistema injusto u opaco genera quejas, reclamaciones, mala prensa y pérdida de confianza, que en un e-commerce con un 4 % de devoluciones y márgenes ajustados se traduce en dinero. Y un sistema que nadie entiende no se puede corregir cuando falla.

La consecuencia práctica es que la ética entra en el proyecto desde el principio (al fijar la medida de rendimiento, al elegir los datos), no como una revisión final. Recuerda la anécdota de 02-01: el incentivo por "conversaciones cerradas por hora" produjo conversaciones cerradas sin resolver. Un modelo que optimiza "devoluciones evitadas" sin ninguna restricción producirá exactamente el tipo de comportamiento del que trata esta lección.

La mayoría de los marcos éticos (los de la Comisión Europea, la OCDE, la UNESCO, muchas empresas) convergen en un pequeño conjunto de principios, heredados en buena parte de la bioética:

Los principios son útiles como brújula, pero abstractos: "sé justo" no dice cómo. El resto de la lección los concreta en problemas, obligaciones y herramientas.

Es el problema más estudiado y el que más directamente conecta con 02-03. Un modelo discrimina cuando trata sistemáticamente peor a un grupo de personas por una característica que no debería influir (sexo, origen, edad, discapacidad, religión...) o por un sustituto de ella (proxy): el código postal, el nombre, el idioma del navegador o el tipo de móvil suelen correlacionar con origen o nivel de renta.

Veámoslo con el modelo de riesgo de devolución de NovaMarket (caso 3). Supongamos que el modelo asigna a cada pedido una puntuación de riesgo entre 0 y 1 y que los pedidos con puntuación mayor o igual a 0,40 se marcan para revisión manual (la revisión retrasa el reembolso varios días y puede acabar en denegación). Comparamos dos zonas de reparto, A y B, con clientes que en todo lo relevante (importe, historial de pedidos, devoluciones previas) son iguales:

Los clientes de B se devuelven exactamente igual que los de A (30 %), pero el modelo marca al 90 % de ellos frente al 20 % de A. ¿Cómo ha ocurrido? Por lo que vimos en 02-03: en el histórico, el equipo revisaba más los pedidos de la zona B, así que allí se "encontraron" más devoluciones fraudulentas, y el modelo aprendió que la zona B (o su código postal) es un indicador de riesgo. El modelo es "exacto" respecto a un pasado sesgado y sistemáticamente injusto respecto a la realidad presente. Además, si sus decisiones alimentan el histórico futuro (se revisa más B, se encuentra más en B), el sesgo se refuerza solo.

Observa dos cosas:

• La injusticia no está en la intención de nadie. Marta no incluyó "origen" ni "renta" en el modelo; incluyó el código postal porque "servía para las rutas". El sesgo entró por un proxy y por el histórico.
• Se detecta midiendo: comparando tasas por grupo, como haremos en la sección 10. Sin esa comparación, el modelo parece funcionar bien "en media".

Los grupos que hay que comparar dependen del contexto: zonas, franjas de edad, sexo, canal (web/app), idioma. En España y la UE hay características legalmente protegidas frente a la discriminación, y aunque el modelo no las use directamente, es responsabilidad del equipo comprobar que no discrimina a través de proxies.

Los sistemas de IA se alimentan de datos personales y, además, crean información nueva sobre las personas: un recomendador infiere intereses (a veces sensibles: salud, embarazo, situación económica) a partir de compras; un modelo de rutas conoce a qué hora hay alguien en cada casa; un asistente guarda transcripciones íntimas. Tres riesgos concretos:

• Inferencia no deseada: el sistema deduce cosas que el cliente no ha revelado ni querría que se supieran. Recomendar productos de bebé a alguien que ha comprado un test de embarazo puede ser útil o una intromisión grave.
• Reutilización de datos para fines distintos de los recogidos (los principios de finalidad y minimización de 02-03).
• Vigilancia: aplicar IA a los propios empleados (productividad de los repartidores, análisis de emociones en el equipo de atención al cliente) o a los clientes de forma desproporcionada. Es un terreno especialmente sensible: el Reglamento de IA prohíbe algunas de estas prácticas (sección 8) y el resto exige garantías laborales.

Medidas: minimizar, seudonimizar o anonimizar (02-03), limitar quién accede a las inferencias, no usar categorías sensibles ni sus proxies para decisiones que afecten al cliente, y preguntarse siempre "¿cómo se sentiría el cliente si supiera exactamente qué hacemos con sus datos?". Diego, que empezó escéptico con la IA, fue el más tajante aquí: "los repartidores no son un dato".

Transparencia es que se sepa que hay un sistema de IA, qué hace y con qué datos. Explicabilidad es poder dar razones de una decisión concreta. Ambas chocan con una realidad técnica: los modelos más potentes (redes neuronales profundas, módulo 5) son cajas negras: millones de parámetros numéricos sin significado individual. Los modelos simples (reglas, árboles de decisión pequeños, regresiones con pocas variables) son interpretables: se puede leer por qué deciden.

La decisión no es "interpretable siempre" ni "el más potente siempre": depende de las consecuencias. Regla práctica: cuanto mayor sea el impacto de la decisión sobre una persona, más peso debe tener la explicabilidad. Para NovaMarket:

• Ordenar la caja "también compraron": puede ser una caja negra; el coste de una mala recomendación es bajo.
• Marcar una devolución para revisión o denegarla: exige explicación (al cliente y al auditor). Modelo interpretable o híbrido, y en todo caso capacidad de dar el motivo.
• Redactar respuestas del asistente: caja negra (LLM) aceptable si hay controles y el cliente sabe que es un asistente automático.

Existen técnicas para explicar cajas negras (mostrar qué variables pesaron más en una predicción, buscar el cambio mínimo que cambiaría la decisión: "si su importe fuera 20 € menor no se habría marcado"), que se mencionan en el módulo 4; aquí basta con saber que existen, que son aproximadas y que no sustituyen la decisión de diseño de usar un modelo interpretable cuando las consecuencias lo exigen.

Volvamos a la pregunta de Diego: ¿quién responde? La respuesta corta es: siempre una persona u organización, nunca "el algoritmo". Un sistema de IA no tiene personalidad jurídica ni conciencia (02-02); la responsabilidad recae en quien lo diseña, lo despliega y lo opera. Para que eso sea real y no un eslogan, hacen falta:

• Propietario del sistema: una persona con nombre responsable de cada sistema de IA en producción (igual que el propietario de los datos de 02-03). En NovaMarket, Marta del recomendador y la previsión; Diego del planificador de rutas y las reglas de devoluciones.
• Trazabilidad: registrar qué versión del modelo tomó qué decisión, con qué datos, cuándo. Sin registro no hay auditoría ni posibilidad de reparar.
• Vías de reclamación: el cliente afectado debe poder recurrir a una persona que revise la decisión (enlaza con el human-in-the-loop de la sección 9 y con los derechos del RGPD).
• Reparto claro con proveedores: si el asistente lo suministra un tercero, el contrato debe fijar quién responde de qué. "Lo hace el proveedor" no exime a quien lo despliega ante el cliente.

Cuando el sistema falla (y fallará: los entornos son estocásticos, como vimos en 02-01), la rendición de cuentas consiste en poder responder a tres preguntas: qué pasó, por qué pasó y qué se ha hecho para que no vuelva a pasar.

Tres consideraciones que van más allá del sistema individual pero que un profesional debe conocer:

• Impacto laboral. La IA automatiza tareas, no oficios enteros, pero cambia el contenido de muchos puestos. En NovaMarket, el asistente no elimina el equipo de atención al cliente pero sí desplaza su trabajo hacia los casos difíciles; el planificador cambia la autonomía de los conductores; el diagnóstico de incidencias cambia el trabajo del operador. Buenas prácticas: implicar a los equipos afectados en el diseño (Diego insistió en que los repartidores probaran el planificador), formar en las nuevas tareas, medir el impacto y ser transparente. La automatización que se hace contra los empleados suele fracasar operativamente además de éticamente (recuerda cómo se recibió el chatbot de 2015).
• Desinformación y deepfakes. La IA generativa produce texto, imágenes, voz y vídeo indistinguibles de los reales, lo que facilita la suplantación (un audio falso del director pidiendo una transferencia), las reseñas falsas (que afectan directamente al caso 4 de NovaMarket: un clasificador de reseñas debe contemplar que parte de ellas sean generadas) y la manipulación a gran escala. Como organización: no generar contenido engañoso, etiquetar el contenido generado (el Reglamento de IA lo exige en varios supuestos), y proteger los canales frente a suplantaciones.
• Sostenibilidad energética. Entrenar y ejecutar modelos grandes consume energía y agua de refrigeración de forma significativa. Para la mayoría de los proyectos (incluidos los de NovaMarket) el consumo es modesto, pero la pregunta "¿necesito un modelo enorme en la nube para esto o basta con uno pequeño?" tiene una dimensión de coste (que le gusta a Diego) y otra ambiental. Elegir el modelo más pequeño que resuelve el problema es buena ingeniería y buena ética.

Aviso previo: lo que sigue es una introducción conceptual con fines formativos, no asesoramiento jurídico. La normativa es compleja, tiene plazos de aplicación escalonados y su interpretación evoluciona; cualquier proyecto real debe revisarse con un profesional legal o de compliance y, si procede, con el delegado de protección de datos.

Ya vimos en 02-03 sus principios sobre datos personales (finalidad, minimización, conservación, seguridad, derechos). Para la IA hay que subrayar el derecho a no ser objeto de decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o significativos sobre la persona (salvo excepciones con garantías), lo que incluye el derecho a obtener intervención humana, a expresar el propio punto de vista y a impugnar la decisión. Denegar automáticamente una devolución o una garantía es un ejemplo de decisión que puede tener efectos significativos: por eso el caso 8 y el caso 3 de NovaMarket necesitan revisión humana. También exige, cuando el tratamiento entrañe alto riesgo para las personas, una evaluación de impacto en protección de datos antes de empezar.

Es la primera norma horizontal sobre IA del mundo, adoptada en 2024 con aplicación escalonada en los años siguientes. Su idea central es un enfoque basado en el riesgo: cuanto mayor es el riesgo de un uso de IA para la seguridad, la salud o los derechos fundamentales, más obligaciones tiene:

Además, los modelos de IA de uso general (los grandes modelos de lenguaje) tienen obligaciones propias para sus proveedores (documentación, derechos de autor, y más para los de riesgo sistémico), que afectan indirectamente a quien los integra.

Clasificación aproximada y orientativa de los casos de NovaMarket (a confirmar por un profesional):

Lectura: ninguno de los casos de NovaMarket es de riesgo inaceptable, y solo uno cae en el nivel "limitado" del AI Act (el asistente, con obligaciones de transparencia). Pero fíjate en dos matices que a menudo se pasan por alto: (a) el RGPD sigue aplicándose por encima del AI Act a todo lo que decida sobre personas (casos 3 y 8), y (b) sistemas "mínimos" pueden convertirse en "alto riesgo" si se reutilizan para gestionar trabajadores (casos 5 y 6). El nivel de riesgo depende del uso, no de la técnica.

De los principios a los hechos. Cuatro herramientas que caben en cualquier proyecto:

Marta la incorporó al inicio de cada proyecto de IA en NovaMarket. Es corta a propósito: si no cabe en una página no se usa.

1. Propósito: ¿qué decisión o acción automatizamos y a quién afecta? ¿Cuál es la medida de rendimiento y qué comportamiento indeseado podría maximizarla?
2. Datos: ¿qué datos usamos, con qué base jurídica y minimización? ¿Qué sesgos de muestreo, históricos o de etiquetado tienen? ¿Contienen características protegidas o proxies?
3. Equidad: ¿qué grupos vamos a comparar y con qué métrica? ¿Qué diferencia consideraremos inaceptable?
4. Explicabilidad: ¿qué nivel de explicación necesita el cliente, el operador y el auditor? ¿El modelo elegido lo permite?
5. Supervisión humana: ¿qué decisiones pasan por una persona? ¿Cómo recurre el afectado?
6. Responsabilidad: ¿quién es el propietario? ¿Qué se registra? ¿Qué pasa con el proveedor?
7. Impacto: ¿en empleados? ¿en clientes vulnerables? ¿riesgo de mal uso? ¿coste energético proporcionado?
8. Regulación: ¿nivel de riesgo aproximado (AI Act)? ¿decisión automatizada (RGPD)? ¿revisado por legal?
9. Seguimiento: ¿cómo detectaremos que el sistema se degrada o discrimina una vez en producción? ¿Quién lo mira y con qué frecuencia?

Para los sistemas que deciden sobre personas, la checklist se amplía en una evaluación de impacto (algorítmico y, si hay datos personales de alto riesgo, de protección de datos): un documento que describe el sistema, los afectados, los riesgos identificados para cada grupo, las medidas de mitigación y el plan de seguimiento. Se hace antes de desplegar y se revisa periódicamente. Es el equivalente en IA a un análisis de riesgos laborales.

Colocar a una persona en el circuito de decisión, de forma proporcional al impacto:

La revisión humana no es gratis (Diego lo recuerda) ni infalible (la persona puede limitarse a confirmar lo que dice la máquina, el llamado sesgo de automatización). Hay que dimensionarla, formar a los revisores y medir si de verdad corrigen a la IA o solo la ratifican.

Para pasar de "creemos que es justo" a "hemos medido", se comparan resultados entre grupos. La idea más simple es la paridad de tasas: la proporción de personas que reciben cierto resultado (ser marcado, ser aprobado, recibir una oferta) debería ser parecida en todos los grupos, salvo que haya una razón legítima y demostrable para que difiera. Una regla práctica muy usada (la "regla de los cuatro quintos", de origen laboral estadounidense) considera sospechosa una diferencia cuando la tasa del grupo menos favorecido es inferior al 80 % de la del más favorecido.

Hay refinamientos: comparar no la tasa bruta sino la tasa de error por grupo (¿se equivoca más el modelo, marcando a quien no iba a devolver, en una zona que en otra?), o comparar solo entre personas con el mismo riesgo real. Estas variantes, y el hecho de que no todas pueden cumplirse a la vez, se tratan en el módulo 4 junto con las métricas de evaluación. Aquí nos basta la intuición: calcula la misma cifra para cada grupo y mira si es parecida. Es lo que hace el código siguiente.

Reproducimos el ejemplo numérico de la sección 3 con datos ficticios. Cada fila es un pedido con su zona (A o B), la puntuación de riesgo que le dio el modelo, si el modelo lo marcó (puntuación ≥ 0,40) y si el pedido se devolvió realmente. Los clientes de ambas zonas son idénticos en importe e historial; la única diferencia es que el modelo suma sistemáticamente unas décimas a la zona B (el sesgo heredado del histórico).

Salida:

Explicación: tasa_por_grupo es una función genérica: cuenta, para cada valor de la columna de grupo (zona), cuántas filas hay y cuántas tienen el resultado positivo (si) en la columna indicada, y devuelve la proporción. La llamamos dos veces: una con la decisión del modelo (marcado_riesgo) y otra con la realidad (devuelto_real). El contraste es el corazón del problema: misma realidad (30 % y 30 %), decisiones muy distintas (20 % frente a 90 %). Si solo hubiéramos mirado la tasa global de marcado (11 de 20, 55 %) no habríamos visto nada.

Salida:

Explicación:

• El ratio de impacto aplica la regla de los cuatro quintos: 0,20 / 0,90 = 0,22, muy por debajo de 0,80. Alarma clara.
• La tasa de falsos positivos por grupo mide el daño concreto: de los clientes de la zona A que no iban a devolver nada, el modelo molestó (retrasó el reembolso, puso bajo sospecha) al 14 %; de los de la zona B, al 86 %. Es la misma información que la anterior, pero expresada como "a cuántos inocentes perjudicamos en cada grupo", que es como lo entiende un cliente, un juez o Diego.

Estas dos cifras son las que deberían aparecer en el panel de seguimiento del sistema (punto 9 de la checklist), calculadas cada semana sobre los datos reales.

Corregir el modelo de raíz exige volver a los datos (quitar el código postal y sus proxies, reequilibrar el histórico, reentrenar: módulo 4). Mientras tanto, y como salvaguarda permanente, añadimos revisión humana en la zona gris y registramos el motivo:

Salida:

y, para el pedido 11:

Explicación:

• decidir_con_revision sustituye la decisión binaria (marcar / no marcar) por tres salidas. La zona gris (puntuación entre 0,40 y 0,60) ya no se marca automáticamente: la revisa una persona, que ve los datos y decide. En nuestro ejemplo, 6 de los 9 pedidos de la zona B que el modelo marcaba pasan a revisión humana; una revisora que compruebe que un cliente con 5 pedidos previos y 0 devoluciones no tiene ningún motivo de sospecha aprobará el reembolso. La regla no elimina el sesgo del modelo, pero evita que se convierta automáticamente en daño, y además genera datos (las decisiones humanas de la zona gris) que sirven para diagnosticar y corregir el modelo.
• explicar construye la explicación mínima que exige la sección 5: qué puntuación, qué decisión y qué datos se usaron. Fíjate en que al leerla salta a la vista la anomalía: 0,46 de riesgo para un cliente fiel con 140 € es difícil de justificar, y esa incomodidad es exactamente lo que la explicabilidad debe producir. Nótese también que la explicación no menciona la zona: si el modelo la usa y no aparece en la explicación, la explicación es engañosa; si aparece, el problema es evidente. En ambos casos, la conclusión es que la zona no debería estar en el modelo.
• El coste de la revisión humana (8 revisiones de 20 pedidos en el ejemplo) es real y Diego lo cuantificará; pero es menor que el de las reclamaciones y el daño reputacional, y disminuirá cuando el modelo se corrija.

Este pequeño programa contiene, en miniatura, la práctica ética completa: medir por grupos, comparar con un umbral de disparidad, poner a una persona donde el modelo es dudoso y explicar cada decisión.

• Dejar la ética para el final. Cuando el modelo ya está entrenado y desplegado, corregir el sesgo cuesta diez veces más. Usa la checklist en la primera reunión del proyecto.
• "No usamos datos sensibles, así que no discriminamos". Los proxies (código postal, nombre, dispositivo, idioma) discriminan igual. La única forma de saberlo es medir por grupos.
• Mirar solo la métrica global. Un modelo con un 90 % de acierto global puede tener un 60 % en un grupo minoritario. Desglosa siempre por grupos relevantes.
• Confundir explicación con justificación. Que el sistema pueda decir "porque el código postal es 28XXX" no hace la decisión aceptable; la explicabilidad sirve precisamente para detectar decisiones inaceptables.
• Revisión humana de adorno. Si el revisor tiene 20 segundos por caso y ve la recomendación de la máquina en grande, aprobará el 99 %. Diseña la revisión para que la persona pueda discrepar y mide cuántas veces lo hace.
• Culpar al proveedor o al algoritmo. La responsabilidad ante el cliente es de quien despliega. Exige al proveedor documentación, métricas por grupo y capacidad de explicación antes de firmar.
• Tratar la regulación como una lista de prohibiciones lejanas. El nivel de riesgo depende del uso: un planificador de rutas inocuo se convierte en un sistema de gestión laboral si se usa para sancionar. Revisa cada nuevo uso con legal.
• Consejo: ante cualquier sistema que decida sobre personas, hazte tres preguntas en este orden: ¿a quién perjudica un error?, ¿lo sabremos?, ¿podrá esa persona quejarse a alguien? Si alguna respuesta es "no lo sé", el proyecto no está listo.

NovaMarket quiere un sistema (caso 4) que clasifique automáticamente las reseñas en positivas/negativas y oculte las que detecte como falsas o abusivas. Recorre los nueve puntos de la checklist de la sección 9.1 y escribe, para cada uno, una o dos frases con los riesgos y medidas específicos de este caso.

Diego propone usar los datos del planificador de rutas (tiempos por parada, kilómetros, paradas por hora) para calcular una "puntuación de eficiencia" de cada repartidor y decidir con ella los turnos y las renovaciones de contrato. Analiza la propuesta desde: (a) el nivel de riesgo aproximado del AI Act; (b) las obligaciones que activaría; (c) los sesgos de datos probables (piensa en zonas urbanas frente a periféricas, tráfico, tipo de paquete); (d) una alternativa que conserve el beneficio operativo sin esos riesgos.

Con los datos de la sección 10: (a) calcula la tasa de falsos negativos por zona (entre los pedidos que sí se devolvieron, proporción que el modelo no marcó); (b) escribe una función paridad_ok(tasas, minimo=0.8) que devuelva True si el ratio de impacto de cualquier diccionario de tasas cumple la regla de los cuatro quintos; (c) prueba qué ocurre con el ratio de impacto del marcado si subimos el umbral a 0,50: ¿se corrige la disparidad? Explica por qué sí o por qué no.

Solución 1. Un ejemplo de respuesta (hay muchas válidas):

1. Propósito: clasificar y moderar reseñas; afecta a los clientes que las escriben (su voz puede ocultarse) y a los que las leen (información sesgada si se ocultan las negativas). Medida de rendimiento con trampa: "maximizar la valoración media visible" llevaría a ocultar críticas legítimas; usar acierto en detección de falsas/abusivas medido con etiquetas humanas.
2. Datos: reseñas con id_cliente (seudonimizar); sesgo de muestreo (escriben sobre todo los extremos); etiquetado de "falsa" y "abusiva" subjetivo, necesita guía y varios etiquetadores.
3. Equidad: comparar tasa de ocultación por idioma de la reseña, longitud, antigüedad del cliente y, si es posible, zona; el modelo podría ocultar más las reseñas escritas con faltas de ortografía o en otro idioma.
4. Explicabilidad: al cliente hay que poder decirle por qué no se publica su reseña; el modelo debe dar el motivo (abusiva, sospecha de falsedad) y no un simple "rechazada".
5. Supervisión humana: la ocultación por "falsa" pasa siempre por revisión humana (impacto sobre la reputación del cliente); la ordenación por sentimiento puede ser automática con auditoría.
6. Responsabilidad: propietario del sistema en marketing; registro de cada reseña ocultada, motivo y revisor.
7. Impacto: en clientes que critican legítimamente; riesgo de mal uso (ocultar críticas a productos con mucho margen); coste energético bajo.
8. Regulación: nivel mínimo del AI Act en principio, pero la moderación de contenido de usuarios tiene obligaciones de transparencia y recurso en la normativa de servicios digitales; consultar legal.
9. Seguimiento: cada mes, tasa de ocultación por grupo, tasa de recursos aceptados (cuántas ocultaciones revierte la revisión humana), muestra aleatoria auditada.

Solución 2.

• (a) Al usarse para decidir turnos y renovaciones de contrato, entra en el ámbito de "empleo y gestión de trabajadores": alto riesgo aproximado, muy distinto del nivel mínimo del planificador original. Es un caso de libro de cómo el uso cambia el nivel.
• (b) Obligaciones probables: gestión de riesgos documentada, calidad y representatividad de datos, documentación técnica, supervisión humana efectiva, transparencia hacia los trabajadores, registro; y, por el RGPD, evaluación de impacto, información y derechos de los empleados, además de la normativa laboral y la participación de la representación de los trabajadores.
• (c) Sesgos: los repartidores de zonas periféricas o con tráfico denso hacen menos paradas por hora por causas ajenas a ellos (sesgo de medición y de asignación); los que llevan paquetes voluminosos o entregas con firma tardan más; los datos históricos reflejan las rutas que se les asignaron, no su esfuerzo. La "eficiencia" mediría en gran parte la ruta, no la persona.
• (d) Alternativa: usar los datos del planificador para mejorar las rutas y la asignación (que es su fin), detectar problemas estructurales (zonas donde nadie llega a tiempo) y ofrecer a cada conductor su información para uso propio; mantener las decisiones sobre personas en un proceso de recursos humanos con criterios acordados, donde los datos de ruta sean, como mucho, un elemento contextualizado y revisado por personas.

Solución 3.

• (a) Los falsos negativos también son dispares, pero al revés: en la zona A el modelo deja pasar el 67 % de las devoluciones reales y en la B ninguna. Es la otra cara de la moneda: al sospechar de casi todos en B, "acierta" todas sus devoluciones a costa de perjudicar a los que no devuelven. Un modelo justo debería tener tasas de error parecidas en ambos grupos.
• (b) paridad_ok devuelve False para el marcado actual.
• (c) Subir el umbral a 0,50 reduce el marcado en las dos zonas (10 % y 60 %) pero no corrige la disparidad (ratio 0,17, incluso peor). Es lógico: el sesgo está en las puntuaciones (la zona B tiene sistemáticamente unas décimas más), y mover el umbral desplaza el corte para todos por igual sin tocar la diferencia entre grupos. La solución no está en el umbral sino en el modelo y sus datos: eliminar la zona y sus proxies, reequilibrar el histórico y reentrenar (módulo 4), manteniendo mientras tanto la revisión humana y la medición periódica.

En esta lección hemos visto que la ética en IA es una parte del diseño, obligatoria por principio, por ley y por negocio, y la hemos concretado. Hemos partido de los principios (beneficencia, no maleficencia, autonomía, justicia, explicabilidad) y los hemos aterrizado en problemas reconocibles: la discriminación a través de proxies (con el ejemplo numérico del modelo de riesgo que marca al 90 % de una zona y al 20 % de otra con la misma tasa real de devolución), la privacidad y las inferencias no deseadas, la tensión entre cajas negras y modelos interpretables, la responsabilidad que siempre recae en personas y organizaciones, el impacto laboral, la desinformación y la sostenibilidad. Hemos presentado el marco regulatorio europeo a nivel introductorio (RGPD, con el derecho frente a decisiones automatizadas, y el Reglamento de IA con sus cuatro niveles de riesgo) y clasificado de forma aproximada los casos de NovaMarket, comprobando que el nivel depende del uso y no de la técnica. Y hemos reunido herramientas que caben en cualquier proyecto: la checklist de nueve puntos, la evaluación de impacto, la revisión humana proporcional al impacto y la paridad de tasas entre grupos, que hemos programado en Python para medir la disparidad, aplicar la regla de los cuatro quintos y añadir una zona gris de revisión humana con explicación registrada.

Con esto cerramos el módulo 2. Ya tienes los cimientos conceptuales: sabes describir cualquier sistema como un agente racional en su entorno (02-01), situarlo en el mapa de tipos de IA (02-02), entender que sus decisiones nacen de los datos y de su calidad (02-03) y evaluar sus consecuencias éticas y regulatorias antes de ponerlo en producción (02-04). En el módulo 3, Algoritmos en IA, empezaremos a construir: retomaremos la formulación de problemas de 02-01 (estados, acciones, objetivo, coste) y veremos cómo un agente encuentra por sí mismo el camino hacia su meta con algoritmos de búsqueda, cómo decide frente a un adversario y cómo optimiza cuando el espacio de soluciones es demasiado grande para recorrerlo entero. El planificador de rutas de NovaMarket y la asignación de pedidos a almacenes serán nuestros primeros problemas de verdad.