011 — Ética desde el diseño y límites de automatización

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 00 — Fundamentos, historia y método científico
Nivel: fundamentos · Horas estimadas: 4
Laboratorio: safety · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender ética desde el diseño y límites de automatización dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

1. Explicar ética desde el diseño y límites de automatización usando los conceptos ética, impacto, límites, supervisión.
2. Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
3. Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
4. Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
5. Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

ética, impacto, límites, supervisión

🗺️ Ubicación en el mapa de la IA

La ética aparece en la primera parte del programa, y no al final, por una razón de ingeniería: las decisiones con carga ética (qué datos usar, qué métrica optimizar, qué se automatiza y qué no) se toman en el diseño, cuando cambiarlas cuesta poco — no en la auditoría posterior, cuando cuesta el proyecto entero. Esta clase conecta la medida de desempeño de los agentes (clase 004) y la honestidad experimental (clases 008-010) con sus consecuencias sobre personas, y anticipa los marcos regulatorios que gobiernan la parte de despliegue.

📖 Fundamentos

🏗️ Ética desde el diseño (ethics by design)

Principio: los valores se implementan en artefactos técnicos concretos, no en declaraciones. Traducciones directas:

Un sistema de scoring crediticio entrenado con decisiones históricas ya contiene una postura ética (perpetuar el patrón histórico); no adoptarla conscientemente no la elimina, solo la deja sin dueño.

⚖️ Conceptos operativos

• Sesgo (bias): error sistemático que afecta de forma desigual a subgrupos. Entra por los datos (muestreo, etiquetas históricas), por la métrica (agregada sobre subgrupos desiguales) o por el despliegue (uso fuera de la población de diseño). Se mide por subgrupo — accuracy global puede ocultar disparidades severas.
• Equidad (fairness): existen múltiples definiciones formales (paridad demográfica, igualdad de oportunidades, calibración por grupo) y son mutuamente incompatibles en general (resultado de imposibilidad de Kleinberg et al. / Chouldechova): elegir una es una decisión de política, no un detalle técnico.
• Transparencia y rendición de cuentas: documentación estandarizada del modelo (Model Cards, Mitchell et al. 2019) y de los datos (Datasheets for Datasets, Gebru et al. 2021): uso previsto, poblaciones evaluadas, límites conocidos.
• Supervisión humana significativa: que el humano en el circuito pueda realmente discrepar del sistema (tiempo, información, autoridad e incentivos para hacerlo); un humano que aprueba en cadena lo que el sistema propone es teatro de supervisión (automation bias documentado).

🚦 Límites de automatización: qué no se delega

Criterios para decidir el grado de autonomía admisible de un sistema:

1. Reversibilidad del daño:   ¿el error se puede deshacer? (recomendación de película
                              vs. denegación de crédito vs. diagnóstico)
2. Costo asimétrico:          ¿un falso negativo vale lo mismo que un falso positivo?
3. Población vulnerable:      ¿el error cae sobre quien menos puede defenderse?
4. Explicabilidad exigible:   ¿la decisión debe poder justificarse individualmente
                              (derecho, medicina, empleo)?
5. Deriva del entorno:        ¿la distribución cambia más rápido de lo que se re-evalúa?

Cuanto más alto puntúa un caso en estos ejes, más cerca debe estar del extremo "el sistema solo informa, el humano decide" y más lejos de "el sistema decide y ejecuta". Los marcos regulatorios modernos codifican esta gradación: el AI Act europeo (Reglamento 2024/1689) clasifica sistemas por nivel de riesgo (inaceptable/alto/limitado/mínimo) con obligaciones proporcionales, y el NIST AI RMF estructura el ciclo govern-map-measure-manage.

🧾 El artefacto de esta clase

El laboratorio safety ejercita la versión mínima: una decisión automatizada con umbral, la tabla de errores por subgrupo y la declaración explícita de limitations. El artefacto risk_and_limitations.md de cada clase del programa es un Model Card embrionario.

🧮 Ejemplo trabajado

Un clasificador decide qué solicitudes de crédito revisar manualmente. Métricas por subgrupo sobre 2 000 casos de test (1 000 por grupo), con el mismo umbral global 0.5:

El informe ejecutivo diría "accuracy 0.83". La tabla por subgrupo muestra que el grupo B sufre el doble de rechazos injustos (0.20 vs 0.10) y la mitad de protección frente a impagos reales (0.50 vs 0.80) con la misma tasa base: el modelo está peor calibrado para B (típicamente por menos datos históricos de ese grupo). Opciones de diseño, cada una con carga ética explícita: recolectar datos de B, umbrales por grupo (¿es legal en la jurisdicción?), o enviar B a revisión humana (¿con qué sesgos revisa el humano?). No hay opción neutra; la ética desde el diseño consiste en elegir con los números sobre la mesa y documentar la elección.

📊 Propiedades y comparación

flowchart TD
    U["Caso de uso propuesto"] --> R{"Evaluar 5 ejes:<br/>reversibilidad, asimetría, vulnerabilidad,<br/>explicabilidad, deriva"}
    R -- "riesgo bajo" --> AUTO["Automatización completa<br/>+ monitoreo y rollback"]
    R -- "riesgo medio" --> HITL["Sistema propone,<br/>humano decide<br/>(supervisión con poder real)"]
    R -- "riesgo alto" --> INFO["Sistema solo informa/prioriza;<br/>decisión humana documentada"]
    R -- "inaceptable" --> NO["No automatizar<br/>(línea roja regulatoria o propia)"]
    AUTO --> MC["📄 Model card + datasheet +<br/>métricas POR SUBGRUPO"]
    HITL --> MC
    INFO --> MC
    MC --> MON["Monitoreo de deriva y daños<br/>→ re-evaluar los 5 ejes"]
    MON --> R

⚠️ Errores conceptuales frecuentes

1. "La ética es subjetiva, no se puede medir." Las consecuencias se miden: tasas de error por subgrupo, calibración por grupo, daños reportados. Lo valorativo es elegir el trade-off; lo técnico es exponerlo con números.
2. "Quitamos la variable protegida, ya no hay sesgo." Las variables correlacionadas (código postal, historial) la reconstruyen (proxy discrimination); la equidad se evalúa sobre resultados, no sobre columnas eliminadas.
3. "Un humano revisa, así que hay supervisión." Sin tiempo, información e incentivos para discrepar, el humano ratifica (automation bias); la supervisión se diseña y se mide (tasa de discrepancia) como cualquier componente.
4. "Optimizar todas las definiciones de fairness a la vez." Es matemáticamente imposible en general; hay que elegir la definición apropiada al dominio y justificarla.
5. "La regulación mata la innovación, mejor ignorarla hasta el final." Los requisitos del AI Act y NIST AI RMF (documentación, gestión de riesgo, datos de calidad) son práctica de ingeniería sólida; adoptarlos tarde cuesta rediseños completos.

🚀 Del aprendizaje a la operación

En producción, esta clase se convierte en artefactos con dueño: un registro de decisiones de diseño con su justificación ética (qué métrica, qué umbral, por qué); model cards y datasheets versionados junto al código; evaluación por subgrupo en el pipeline de CI, no solo en el informe inicial; un canal de reporte de daños con SLA de respuesta; y un mapa de qué decisiones el sistema tiene prohibido tomar solo — revisado cuando cambia la población, el modelo o la ley.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("safety"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

• tipo de laboratorio y semilla;
• entradas o decisiones observables;
• resultado estructurado;
• lista evidence con hechos que pueden inspeccionarse;
• lista limitations que impide presentar la demo como producción.

📓 Notebooks

• 📓 notebook.ipynb: recorrido guiado con la materia resumida.
• ✍️ notebook_student.ipynb: ejercicios para resolver.
• ✅ notebook_solution.ipynb: solución de referencia explicada.

📝 Evaluación

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

🔗 Referencias

• Mitchell et al. (2019). Model Cards for Model Reporting — uso: fuente primaria del mecanismo estudiado
• Gebru et al. (2021). Datasheets for Datasets — uso: fuente primaria del mecanismo estudiado
• NIST AI Risk Management Framework — uso: marco normativo de referencia
• Reglamento (UE) 2024/1689 — AI Act (texto oficial) — uso: marco normativo de referencia
• Kleinberg, Mullainathan & Raghavan (2016). Inherent Trade-Offs in the Fair Determination of Risk Scores — uso: fuente primaria del mecanismo estudiado
• ACM Code of Ethics and Professional Conduct — uso: referencia consultada en su fuente original

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

Normas y documentación oficial que aplica esta clase: AI Risk Management Framework · Reglamento (UE) 2024/1689

⬅️ Clase anterior

010 — Cómo leer papers, benchmarks y claims de IA

➡️ Siguiente clase

012 — Proyecto: mapa evolutivo verificable de la IA

📝 Evaluación completa

❓ Preguntas

1. Define ética desde el diseño y límites de automatización sin usar una marca o framework como definición.
2. Explica la relación entre ética, impacto, límites, supervisión.
3. Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
4. Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
5. Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

• el supuesto que estás probando;
• una medición o comprobación;
• la conclusión;
• una limitación.

✅ Criterio de aceptación

• [ ] lab.py termina con código 0.
• [ ] El resultado contiene kind, seed, evidence y limitations.
• [ ] La extensión no modifica el comportamiento de otras clases.
• [ ] La interpretación referencia datos impresos por el laboratorio.
• [ ] Se declara al menos un riesgo o condición de no uso.