5.2
Bloque 5 · Proyecto Integrador · Semanas 51–52

Diseño de intervención

La mayoría de los esfuerzos por "arreglar" un sistema fallan no porque la idea sea mala, sino porque optimizan una parte sin entender cómo esa parte se acopla con el resto. Aprende a diseñar intervenciones híbridas humano-IA que respetan la complejidad del sistema.

Sesión A — Principios de diseño para sistemas híbridos

Diseñar una intervención en un sistema complejo es diseñar dentro de una red de acoplamientos. No puedes cambiar un elemento sin afectar a otros. La pregunta no es "¿cuál es la solución óptima?" sino "¿cuál es la intervención que minimiza consecuencias imprevistas?"

Cinco principios guían el diseño de sistemas híbridos:

1. Modularidad con acoplamiento conocido. Divide el sistema en módulos (decisión humana, predicción algorítmica, ejecución, feedback). Pero documenta explícitamente dónde se acoplan. En modularidad ingenua, crees que cambiar un módulo no afecta a otros. En modularidad informada, sabes exactamente qué puntos de contacto existen.

2. Sensibilidad a retroalimentación. Todo sistema intervienido cambia en respuesta. Un algoritmo recomendador que favorece cierto contenido hace que los usuarios se adapten a ese algoritmo, que luego se re-entrena en los datos adaptados, en una espiral. Diseña para detectar y medir estos ciclos de retroalimentación. Si no lo haces, tu intervención se come a sí misma.

3. Degradación elegante. Asume que algo va a fallar. ¿Qué pasa si el modelo falla? ¿Si los humanos ignoran la recomendación? ¿Si hay lag en el feedback? Diseña los límites de aceptabilidad antes de lanzar. Define modos de fallida seguros: cuando las cosas se ponen mal, el sistema debe poder "bajar de marcha" sin colapsar.

4. Override humano explícito y verificable. Si un humano puede tomar una decisión, debe poder sobreescribir lo que el algoritmo decide. Pero ese override debe ser registrado, auditable. No es suficiente que técnicamente sea posible; debe ser obvio, incentivizado, y fácil de rastrear.

5. Transparencia proporcional. Más automatización = mayor exigencia de explicabilidad. Si un sistema toma 90% de decisiones automáticamente, cada decisión debe ser justificable. Si toma 10%, puedes tolerar más opacidad en los casos restantes. Pero ajusta la barra según el riesgo y la frecuencia.

Sesión B — Práctica

Sesión B — Prototipando tu intervención

Construye un prototipo de intervención seleccionando componentes y conectándolos. No estamos construyendo código real; estamos dibujando la arquitectura de un sistema híbrido y viendo dónde se generan los acoplamientos peligrosos.

Instrucciones: Selecciona componentes del panel izquierdo (nodo de decisión humana, clasificador ML, mecanismo de votación, bucle de feedback, etc.) y colócalos en el canvas central. El sistema te mostrará automáticamente cómo se conectan y alertará sobre posibles modos de falla.

Componentes disponibles:

  • Humano (H): Una o más personas tomando decisiones. Lento, flexible, explicable.
  • Clasificador (ML): Algoritmo que predice/clasifica. Rápido, consistente, opaco.
  • Votación: Mecanismo que agrega decisiones humanas o híbridas. Diversidad vs. conformidad.
  • Feedback: Loop que mide resultado y alimenta de vuelta al sistema. Peligroso si no está bien medido.
  • Validador: Punto de control explícito que verifica outputs antes de ejecución.
  • Autores

Qué observar: Cuando coloques componentes, ve cómo el sistema calcula métricas de riesgo: ¿hay puntos de falla únicos? ¿Los ciclos de feedback son demasiado cerrados? ¿Hay transparencia suficiente para un override humano?

Sesión C — Evaluación

Sesión C — Evaluación de dominio

Dominaste este concepto si:

Quiz de evaluación

Responde correctamente 3 de 4 preguntas (75% mínimo).

Contexto histórico

Orígenes: Herbert Simon y "The Sciences of the Artificial" (1969)

Herbert Simon fue economista, psicólogo y pionero de la IA. En 1969, publicó "The Sciences of the Artificial", donde argumentó que el diseño (design) es una ciencia distinta de la explicación. No es suficiente entender cómo funcionan las cosas; debes aprender a intervenir en ellas sin romper nada.

Simon observó que los ingenieros y diseñadores operaban bajo "bounded rationality": no podían calcular la solución óptima, así que hacían iteraciones increíbles, probaban, medían, ajustaban. Llamó a esto "satisficing" (satisfacer + suficiente): no busques lo perfecto, busca lo que funciona.

El problema de Rittel y Webber: "Wicked Problems" (1973)

Horst Rittel y Melvin Webber, ambos planificadores urbanos, se dieron cuenta de que ciertos problemas son fundamentalmente distintos a los "well-defined" de la matemática. Una "wicked problem" es aquella donde:

Rittel propuso que estos problemas requieren "planning colaborativo": múltiples stakeholders con valores distintos tienen que diseñar juntos, iterativamente, sabiendo que cada intervención revelará nuevas comprensiones del problema.

Ostrom y la gobernanza de sistemas complejos (1990–2020s)

Elinor Ostrom ganó el Premio Nobel en Economía (2009) por su trabajo sobre cómo las comunidades diseñan sistemas de gobernanza para recursos compartidos: acuíferos, bosques, pesquerías. Estudió casos donde comunidades indígenas en Nepal, España e Indonesia evitaron la "tragedia de los comunes" sin intervención estatal ni privatización.

Ostrom identificó ocho "principios de diseño institucional" que aparecían en sistemas exitosos:

  1. Límites claros: Quién participa, qué recurso se gestiona.
  2. Congruencia: Las reglas de extracción y provisión se ajustan a las condiciones locales.
  3. Decisión colectiva: Los afectados participan en la formulación de reglas.
  4. Monitoreo: Hay contabilidad regular de la extracción y el estado.
  5. Sanciones graduadas: Los infractores reciben penalidades pequeñas primero, no castigos drásticos inmediatos.
  6. Resolución de conflictos: Mecanismos accesibles para disputas.
  7. Reconocimiento estatal: El gobierno respeta el derecho de la comunidad a autogobernarse.
  8. Empresas anidadas: Múltiples niveles de gobernanza si el recurso es grande.

Lo revolucionario: estos principios no son universales, pero son "traducibles". Nepal y España tienen contextos completamente distintos, pero los principios de diseño que emergieron son análogos.

Design Thinking (IDEO, 1980s–2000s)

David Kelley y su equipo en IDEO popularizaron "design thinking": una metodología iterativa que comienza con empatía (¿qué necesita el usuario realmente?), luego prototipado rápido (builds something, breaks it, learns), luego testing con usuarios. No es perfeccionismo; es aprendizaje por iteración.

Aplicación a sistemas híbridos humano-IA (2020s)

En los últimos años, grupos como la Universidad de Harvard (Riedl, Gajos), MIT (Riedl, Bernstein), y organizaciones como Partnership on AI han aplicado estos principios al diseño de sistemas híbridos. La lección clave: un sistema donde humanos y IA trabajan juntos requiere los mismos principios de Ostrom (límites claros, decisión colectiva, monitoreo, sanciones graduadas) que una comunidad que gestiona un bosque.

La diferencia: la IA opera a velocidad de software, así que los bucles de feedback son más rápidos pero también más peligrosos. Si no diseñas la retroalimentación explícitamente, el sistema puede divergir en horas.

Teoría profunda

Ley de Ashby de la Variedad Requerida (Ashby, 1956)

Ross Ashby, cibernetista británico, formuló un principio fundamental: "La variedad de perturbaciones que un controlador puede mitigar no puede exceder la variedad de respuestas disponibles."

En símbolos: V(controlador) ≥ V(perturbaciones). Si el sistema tiene N variables de estado, el controlador necesita (al menos) N grados de libertad para mantenerlo estable.

Aplicación a diseño híbrido: Si tu sistema tiene muchas fuentes de incertidumbre (variabilidad en comportamiento humano, cambios ambientales, adversarios), necesitas igual variedad en tu intervención. Un modelo de IA solo (una estrategia única) probablemente no sea suficiente. Necesitas múltiples modelos, múltiples caminos de decisión, la capacidad de escalar entre automatización alta y control manual.

Distinción: Robustez vs. Resilencia

Robustez: El sistema soporta perturbaciones sin cambiar. Un dique robusto resiste olas altas. Un sistema robusto de IA es uno que predice bien incluso con datos ruidosos.

Resilencia: El sistema cambia, pero mantiene su función. Cuando un río sube, un bosque resiliente se inunda pero recupera su ecosistema. Un sistema resiliente de IA es uno que se degrada gracefully: si el modelo falla, hay fallback humano; si el feedback es ruidoso, el sistema no sobre-reacciona.

Los sistemas complejos no pueden ser solo robustos. La robustez requiere aislamiento (el dique no interactúa con nada), pero un sistema híbrido está acoplado a humanos, datos, ambiente. Necesita resilencia: flexibilidad para cambiar sin colapsar.

Degradación elegante ("Graceful Degradation")

Define umbrales de riesgo para cada componente. Ejemplo:

Sin estos umbrales, un sistema híbrido puede oscilar entre extremos: funciona bien durante meses, luego de repente diverge porque pasó un threshold invisible.

Optimización local vs. Global

Un error clásico: optimizar cada componente independientemente. Ejemplo: maximizar precisión de un recomendador (componente A) puede llevar a que ignores diversidad de recomendaciones (propiedad del sistema global), lo que causa que usuarios se polaricen (comportamiento emergente negativo).

Matemáticamente: si el sistema tiene variables {x₁, x₂, ..., xₙ} con funciones objetivo {f₁, f₂, ..., fₙ}, no es verdad que max(f₁) + max(f₂) + ... = max(f₁ + f₂ + ...). Típicamente es menor, o el vector de soluciones es inviable (los óptimos de f₁ y f₂ se contradicen).

Solución: Establece una función objetivo global (ej: "mantener usuario satisfecho Y que el sistema sea interpretable Y que haya control humano"), luego define la arquitectura híbrida como un problema de optimización multi-objetivo con restricciones de acoplamiento.

Bucles de retroalimentación y estabilidad

Cada vez que tu sistema interactúa con humanos o con su ambiente, genera feedback que vuelve al sistema. Si el loop es largo (feedback tarda días), el sistema es estable porque hay tiempo para ajustarse. Si el loop es corto (feedback en milisegundos) y hay ganancia alta, el sistema puede oscilar o diverger rápidamente.

Diseña explícitamente:

Transparencia y explicabilidad proporcionales

No es práctico explicar cada decisión de un sistema grande. Pero puedes diseñar "puntos de explicabilidad" donde la decisión es más importante:

Esto requiere una "auditoría de impacto" del sistema: mapear cada decisión, su frecuencia, y su reversibilidad. Luego asignar barras de explicabilidad proporcionalmente.

Cómo estudiar este material

Textos clave a revisar:

1. Simon, H. A. (1969). "The Sciences of the Artificial". Es un libro corto (220 páginas). Lee especialmente el Capítulo 3 "The Architecture of Complexity" donde habla de sistemas jerárquicos y cómo el diseño necesita respetar la estructura del problema. Busca la sección sobre "satisficing" vs. "maximizing".

2. Rittel, H. & Webber, M. (1973). "Dilemmas in a General Theory of Planning". Paper seminal, 20 páginas. Define "wicked problems" y contrasta con "tame problems". Busca una copia en el repositorio de UC Berkeley. Enfócate en los 10 criterios que definen un wicked problem y por qué requieren co-diseño.

3. Ostrom, E. (2009). "A Polycentric Approach for Coping with Climate Change". O mejor aún, su libro "Governing the Commons" (1990). Es el trabajo sobre gobernanza descentralizada. Aunque habla de recursos naturales, los principios de diseño (límites, monitoreo, sanciones, decisión colectiva) son totalmente aplicables a sistemas híbridos IA-humano.

4. Ashby, W. R. (1956). "An Introduction to Cybernetics". Capítulo 12 sobre "La Ley de la Variedad Requerida". Es denso pero crucial. La idea central: tu controlador (intervención) necesita al menos tanta variedad de respuestas como la variedad de perturbaciones en el sistema. Si no lo cumples, el sistema diverge.

5. Riedl, C., Bernstein, M. S., et al. (2023). "Potential of AI for Collective Intelligence". Paper de MIT-Harvard sobre evaluación de sistemas híbridos. Enfócate en las secciones sobre "design principles for hybrid intelligence" y "measuring collective outcomes".

Cómo estudiar eficientemente:

Paso 1: Lee el abstract + conclusiones de Riedl et al. (2023) para un "roadmap" moderno. Toma 30 minutos.

Paso 2: Lee Rittel & Webber (1973) en 1 sesión de 1 hora. No busques entender todo; busca responder: ¿Qué hace que un problema sea "wicked"? ¿Cómo es distinto de problemas ingenieriles?

Paso 3: Lee Simon Cap. 3 en 1 sesión de 1.5 horas. Busca: ¿Por qué Simon dice que la complejidad del diseño es análoga a la complejidad de los sistemas naturales? ¿Qué implica eso para intervención?

Paso 4: Lee Ashby Cap. 12. Es matemático. No necesitas entender todos los símbolos. La idea central: variedad in = variedad out (requerida). Si tu sistema tiene 10 variables incontrolables, necesitas al menos 10 parámetros de control que sean independientes.

Paso 5: Vuelve a Ostrom y busca sus 8 principios. Para cada uno, pregúntate: ¿Cómo se refleja esto en un sistema híbrido IA-humano? Ej: "Decisión colectiva" = ¿hay un proceso donde humanos y IA participan en ajustar reglas?

Conexión con ISLR: ISLR Capítulo 2 habla sobre "Statistical Learning". Los principios de Ashby (variedad requerida) son el fundamento de por qué necesitas complejidad suficiente en tu modelo. Pero ISLR + Ashby es: complejidad suficiente para la tarea, pero luego necesitas diseño sistema-wise para que no diverja.

Práctica: Para cada paper/libro, toma notas sobre una pregunta: "Si yo estuviera diseñando un sistema híbrido para [tu dominio de interés], ¿qué principios de Simon/Rittel/Ostrom/Ashby aplicaría?" Eso es lo que importa.

Ejercicio expandido

Ejercicio A: Auditoría de acoplamiento

Toma un sistema híbrido existente (ej: ChatGPT + retroalimentación de usuarios, LinkedIn feed recomendador, sistema de selección de candidatos con filtro IA). Mapea:

  1. ¿Cuáles son los módulos? (humanos, modelo, base de datos, UI, feedback)
  2. ¿Dónde se acoplan? (qué datos pasan entre módulos)
  3. ¿Qué pasa si un módulo falla? (ej: si el feedback es corrupto, ¿cómo afecta?)
  4. ¿Hay ciclos de retroalimentación? (ej: recomendación → cambio de comportamiento usuario → nuevo feedback → re-entrena modelo)
  5. ¿Hay override humano claro?

Entrega: Un diagrama con módulos, flechas de acoplamiento, y 3-4 análisis de "qué si falla esto".

Ejercicio B: Diseño con degradación elegante

Diseña un sistema de recomendación de diagnóstico médico (híbrido doctor + IA). Define cuatro umbrales:

Entrega: Documento de 1-2 páginas describiendo cómo el sistema escala entre los 4 modos.

Ejercicio C: Multi-objetivo sin contradición

Tienes un sistema de moderación de contenido (IA + humanos). Tres objetivos:

  1. Detectar contenido nocivo rápidamente (minimizar falsos negativos).
  2. No censurar contenido legítimo (minimizar falsos positivos).
  3. Ser transparente sobre por qué se moderó algo (explicabilidad).

Estos tres objetivos pueden contradecirse. Ej: si bajas el threshold de "probablemente nocivo" para detectar más, subes falsos positivos. Si exiges explicación detallada, ralentizas el sistema. Diseña una arquitectura que negocie estas tensiones:

Entrega: Matriz de trade-offs (fila = objetivo, columna = componente del sistema, celda = cómo se relacion), y lista de métricas de monitoreo.

Evaluación: Los mejores ejercicios son aquellos donde identifica acoplamientos no-obvios, anticipa modos de falla antes de que ocurran, y diseña fallback sin comprometer el objetivo principal.