Interacción humano-agente y supervisión

Duración: 2 horas de clase + 1 hora de laboratorio Prerrequisitos: Semanas 1-11 (fundamentos hasta seguridad y alineamiento)

01Objetivos de Aprendizaje

Al finalizar esta clase, los estudiantes serán capaces de:

1. Distinguir entre los paradigmas human-in-the-loop, human-on-the-loop y totalmente autónomo
2. Asignar la autonomía de un agente a un marco de niveles y justificar el nivel adecuado para un caso de uso dado
3. Diseñar flujos de aprobación que equilibren seguridad y eficiencia
4. Aplicar principios de transparencia y explicabilidad a sistemas de agentes
5. Razonar sobre la calibración de confianza entre humanos y agentes
6. Diseñar experiencias de usuario para interfaces agénticas
7. Implementar mecanismos de retroalimentación que mejoren el rendimiento del agente con el tiempo

021. Human-in-the-Loop vs. Human-on-the-Loop vs. Totalmente Autónomo

1.1 Por qué importa la supervisión humana: la tensión central

La semana pasada discutimos seguridad, alineamiento y guardrails, es decir, los mecanismos técnicos que restringen el comportamiento del agente. Esta semana nos centramos en un tema complementario e igualmente importante: el papel del ser humano en los sistemas agénticos.

Esta es la tensión central: construimos agentes para automatizar trabajo, pero el mecanismo de seguridad más potente es el juicio humano. Cada paso hacia una mayor autonomía es un paso que se aleja de la supervisión humana. ¿Cómo obtenemos los beneficios de la automatización sin perder los beneficios del juicio humano?

No se trata de una pregunta nueva. La aviación se enfrentó a ella hace décadas, cuando los sistemas de piloto automático se volvieron lo suficientemente capaces como para pilotar aviones sin intervención del piloto. La respuesta a la que llegó la aviación no fue "eliminar al piloto" ni "no usar nunca el piloto automático", sino un sistema cuidadosamente diseñado de responsabilidad compartida donde la automatización gestiona las tareas rutinarias y los humanos se ocupan de las excepciones, las emergencias y las decisiones que requieren criterio. Las décadas de experiencia de la industria aeronáutica con la interacción humano-automatización proporcionan lecciones de enorme valor para la IA agéntica.

Para comprender el espacio de diseño, debemos comenzar con tres paradigmas fundamentales de interacción humano-agente.

1.2 Los tres paradigmas

Human-in-the-loop (HITL). El humano participa activamente en cada ciclo de decisión. El agente propone acciones y el humano las aprueba o rechaza una a una antes de la ejecución. El agente no puede actuar sin confirmación humana.

Piénsalo como un empleado nuevo en su primera semana. Viene a ti con cada decisión: "Creo que deberíamos responder a este cliente ofreciendo un 10 % de descuento. ¿Envío este correo?" Revisas cada acción, proporcionas retroalimentación y gradualmente construyes confianza.

HITL ofrece máxima seguridad porque cada acción se revisa antes de ejecutarse. Pero también proporciona mínima eficiencia porque el agente está constantemente esperando la aprobación humana. El ser humano se convierte en el cuello de botella.

Human-on-the-loop (HOTL). El agente actúa de forma autónoma, pero un humano supervisa su comportamiento y puede intervenir cuando sea necesario. El humano establece políticas y límites, y el agente opera dentro de ellos. El humano revisa resúmenes y puede intervenir en cualquier momento.

Esto es como un empleado de confianza que gestiona su propio flujo de trabajo pero proporciona actualizaciones periódicas a su responsable. El responsable puede intervenir en cualquier momento pero normalménte no necesita hacerlo. El empleado toma decisiones rutinarias de forma independiente y escala las inusuales o de alto impacto.

HOTL equilibra seguridad y eficiencia. El agente puede actuar rápidamente en tareas rutinarias mientras el humano se centra en las excepciones y la supervisión de alto nivel. El desafío está en diseñar el sistema de supervisión para que el humano realmente detecte los problemas (más sobre esto más adelante).

Totalmente autónomo. El agente opera sin supervisión humana durante la ejecución. Los humanos definen el objetivo y las restricciones iniciales, y luego el agente se ejecuta hasta completar la tarea. La participación humana se limita á una revisión á posteriori de los resultados.

Esto es como un freelance al que contratas para un proyecto. Defines los requisitos, él entrega el resultado y tú lo revisas. No tienes visibilidad del proceso mientras se está ejecutando.

La autonomía total proporciona máxima eficiencia pero mínima seguridad durante la ejecución. Es adecuada únicamente cuando los riesgos de fallo son bajos, el agente ha sido bien probado para la tarea específica y existe una revisión a posteriori adecuada.

1.3 Compromisos

Estos compromisos son fundamentales y no pueden eliminarse por completo. Se puede optimizar dentro de cada paradigma (diseñando mejores flujos de aprobación, paneles de supervisión más inteligentes), pero no se puede tener máxima seguridad y máxima eficiencia simultáneamente. Se trata de un compromiso de ingeniería que debe tomarse deliberadamente para cada caso de uso.

1.4 Cuándo usar cada uno

HITL es adecuado cuando:

• Las acciones son irreversibles (enviar correos, realizar compras, desplegar código en producción)
• Los errores tienen consecuencias graves (decisiones médicas, legales, financieras)
• No se ha establecido confianza en el agente (nuevo despliegue, nuevo tipo de tarea)
• Los requisitos regulatorios exigen supervisión humana (sanidad, justicia penal)
• El agente está operando en un dominio donde ha mostrado baja fiabilidad

HOTL es adecuado cuando:

• Las acciones son mayoritariamente reversibles o de bajo impacto
• El agente ha sido validado en tareas similares con un buen historial
• Se necesita alto rendimiento pero no se puede ignorar la seguridad por completo
• El humano puede supervisar eficazmente el comportamiento agregado (paneles, resúmenes)
• El coste de errores ocasionales es asumible

Totalmente autónomo es adecuado cuando:

• Las tareas están bien definidas, son rutinarias y de bajo riesgo
• El agente tiene un amplio historial en este tipo exacto de tarea
• La velocidad es crítica y la supervisión humana sería un cuello de botella
• Existe una auditoría a posteriorí adecuada para detectar errores después
• Las consecuencias del fallo están acotadas y son recuperables

1.5 Enfoques híbridos: el patrón del mundo real

En la práctica, la mayoría de los sistemas en producción utilizan enfoques híbridos donde el nivel de supervisión varía según la acción específica que se está realizando:

Esta granularidad por acción proporciona el mejor equilibrio entre seguridad y eficiencia. Leer datos es seguro (sin efectos secundarios), por lo que puede ser autónomo. Escribir datos tiene consecuencias pero a menudo es reversible (control de versiones, copias de seguridad), así que la supervisión es suficiente. Eliminar datos y enviar comunicaciones externas son potencialmente irreversibles, por lo que requieren aprobación explícita.

Este es exactamente el patrón que vemos en herramientas de producción como Claude Code: leer archivos y buscar son operaciones autónomas, pero escribir archivos y ejecutar comandos requiérén aprobación del usuario (que puede configurarse según el nivel de confianza del usuario y la operación específica).

Idea clave: El paradigma adecuado no es una elección global. Es una elección por acción que depende de la reversibilidad, las consecuencias y el riesgo de cada acción específica. Diseña tu sistema para que el nivel de supervisión pueda configurarse a nivel de acción, no solo a nivel de sistema.

Inténtalo tú mismo: clasifica los niveles de supervisión

Para cada una de las siguientes acciones de un agente, decide si debería ser autónoma, human-on-the-loop o human-in-the-loop. Justifica tu elección:

1. Un agente que lee la información de la cuenta de un cliente para responder a su pregunta
2. Un agente que actualiza la dirección de correo electrónico de un cliente en la base de datos
3. Un agente que envía un correo de restablecimiento de contraseña a un cliente
4. Un agente que reembolsa un pago de 500 $
5. Un agente que elimina la cuenta de un cliente
6. Un agente que redacta un resumen interno de los tickets de soporte del día
7. Un agente que pública una respuesta en redes sociales en nombre de la empresa

032. Niveles de autonomía del agente

2.1 Inspiración en los niveles de conducción autónoma

El estándar de SAE International define seis niveles de automatización de la conducción (SAE J3016). Este marco ha resultado notablemente útil como analogía para la IA agéntica porque captura el mismo espectro desde "el humano hace todo" hasta "la máquina hace todo", con etapas intermedias claramente definidas.

La analogía con la conducción es instructiva porque la industria del automóvil ha dedicado décadas a pensar en cómo aumentar la automatización de forma segura. Han aprendido lecciones dolorosas sobre lo que ocurre cuando la automatización no se ajusta bien a las capacidades humanas (en particular, el "problema del Nivel 3", donde se supone que el humano está listo para tomar el control pero en realidad no está prestando atención). Estas lecciones se aplican directamente a la IA agéntica.

Mapeemos los seis niveles a los sistemas de agentes:

Nivel 0 -- Sin automatización (software tradicional). El humano realiza todas las tareas. El software proporciona información pero no toma decisiones. Ejemplo: un motor de búsqueda que devuelve resultados para que el humano actúe. Una herramienta de consulta de base de datos que devuelve datos para que el humano los intérprete. Un corrector ortográfico que subraya errores pero no los corrige.

El humano es plenamente responsable de todas las decisiones y acciones. El software es puramente una herramienta, sin ningún grado de autonomía.

Nivel 1 -- Asistencia (autocompletado/sugerencias). El agente gestiona una única subtarea bajo el control del humano. El humano dirige toda la toma de decisiones. Ejemplo: autocompletado de código, sugerencias de respuesta automática en correos, corrección ortográfica con autocorrección. El humano acepta o rechaza cada sugerencia.

La característica clave del Nivel 1 es que la contribución del agente es atómica: una única sugerencia, completado o corrección. El humano evalúa cada una de forma independiente.

Nivel 2 -- Automatización parcial (Copilot). El agente puede gestionar múltiples subtareas simultáneamente, pero el humano debe permanecer involucrado y supervisar de forma continúa. El humano puede tomar el control en cualquier momento. Ejemplo: GitHub Copilot generando bloques de código de varias líneas, un asistente de escritura que redacta párrafos, un agente de investigación que recopila información de múltiples fuentes pero la presenta para revisión humana.

La característica clave del Nivel 2 es que el agente produce resultados multi-paso, pero el humano sigue supervisando activamente cada paso. Si el humano deja de prestar atención, el agente no debería continuar.

Nivel 3 -- Automatización condicional (agente supervisado). El agente gestiona tareas completas de forma autónoma pero dentro de un dominio definido. El humano debe estar disponible para tomar el control cuando el agente encuentra situaciones fuera de su dominio. Ejemplo: un agente de atención al cliente que gestiona consultas rutinarias pero escala las complejas; un agente de programación que implementa funcionalidades sencillas pero pide ayuda con decisiones de arquitectura.

El Nivel 3 es donde las cosas se ponen interesantes y peligrosas. El agente es lo suficientemente autónomo como para que el humano pueda dejar de prestar atención (porque el agente está gestionando las cosas bien), pero no lo suficientemente autónomo como para manejar todas las situaciones. Esto crea el problema del Nivel 3: el humano está nominalmente "en el bucle" pero en realidad está desconectado y no preparado para tomar el control cuando el agente alcanza sus límites.

La industria automovilística ha lidiado con este mismo problema. El "Full Self-Driving" de Tesla opera aproximadamente en el Nivel 2-3, y el desafío de mantener al conductor humano atento cuando el coche conduce solo es una de las principales preocupaciones de seguridad. El mismo desafío se aplica a la IA agéntica.

Nivel 4 -- Alta automatización (agente monitorizado). El agente puede gestionar tareas completas, incluidos la mayoría de los casos límite, sin participación humana. Opera dentro de su dominio sin necesitar respaldo humano, pero no opera fuera de ese dominio. Ejemplo: un agente de programación que puede implementar funcionalidades, escribir tésts, depurar errores y gestionar errores comunes, pidiendo ayuda humana solo para requisitos ambiguos o cuestiones de arquitectura novedosas.

La diferencia clave entre el Nivel 3 y el Nivel 4 es que un agente de Nivel 4 puede gestionar sus propios fallos. Cuando ocurre algo inesperado, puede recuperarse o fallar de forma controlada en lugar de requerir que el humano tome el control. El humano revisa los resultados en lugar de supervisar el proceso.

Nivel 5 -- Automatización total (agente autónomo). El agente puede gestionar cualquier tarea dentro de su amplio dominio sin participación humana, incluídas situaciones novedosas. No se requiere supervisión humana durante la operación. Este nivel sigue siendo en gran medida aspiracional para agentes de propósito general en 2026, aunque los agentes de dominio reducido (como los sistemas de trading automatizado con reglas bien definidas) pueden aproximarse.

2.2 Aplicación del marco

Al decidir el nivel de autonomía para un despliegue específico de un agente, hay que considerar cinco factores clave:

1. Criticidad de la tarea: ¿Cuán graves son las consecuencias de los errores? Un bug en un proyecto personal es apropiado para el Nivel 4. Un bug en software médico es como mucho Nivel 2.
2. Previsibilidad de la tarea: ¿Cuán bien definida y rutinaria es la tarea? Formatear código (altamente previsible) puede ser más autónomo que diseñar la arquitectura de un sistema (altamente imprevisible).
3. Madurez del agente: ¿Cuán exhaustivamente ha sido probado el agente en este tipo de tarea? Un nuevo despliegue de agente debería comenzar en niveles de autonomía más bajos independientemente de su capacidad teórica.
4. Coste de recuperación: ¿Cuán costoso es recuperarse de un error? Si cada acción está respaldada por control de versiones, la recuperación es barata y se acepta mayor autonomía. Si las acciones son irreversibles, se necesita menor autonomía.
5. Requisitos regulatorios: ¿Existen mandatos legales de supervisión humana? Algunos dominios (sanidad, servicios financieros, justicia penal) tienen requisitos explícitos.

2.3 Autonomía progresiva

Un patrón práctico es la autonomía progresiva: comenzar con alta supervisión y reducirla gradualmente a medida que se establece confianza a través del rendimiento demostrado.

Esto refleja cómo las organizaciones incorporan a los empleados humanos: los nuevos tienen más supervisión, y la autonomía se gana demostrando competencia. Nadie le da a un empleado nuevo acceso administrativo completo el primer día.

La autonomía progresiva también proporciona un mecanismo natural de recopilación de datos. Durante las fases de alta supervisión, se acumulan datos etiquetados sobre lo que el agente hace bien y mal, lo que informa la decisión de cuándo aumentar la autonomía.

Idea clave: El nivel de autonomía adecuado no es una elección permanente. Debe evolucionar con el tiempo según el rendimiento demostrado. Diseña tu sistema para que soporte aumentos (y reducciones) graduales de autonomía a medida que cambia el historial del agente.

043. Diseño de flujos de aprobación eficaces

3.1 El problema del cuello de botella de la aprobación

Los sistemas HITL ingenuos crean un cuello de botella doloroso:

• Los agentes esperan inactivos la aprobación humana, desperdiciando cómputo y tiempo
• Los humanos sufren "fatiga de aprobación" por las interrupciones constantes, lo que lleva a aprobar todo de forma mecánica
• La latencia anula el propósito de la automatización (si cada acción requiere 5 minutos de revisión humana, ¿para qué usar un agente?)

El cuello de botella de la aprobación es una de las principales razones por las que las organizaciones pasan demasiado rápido a la autonomía total: la experiencia HITL es tan dolorosa que la gente se salta HOTL y va directamente a "dejar que el agente haga lo que quiera". Esto es peligroso. La solución no es eliminar la supervisión sino diseñar una supervisión mejor.

3.2 Patrones de diseño para flujos de aprobación

3.2.1 Aprobaciones por lotes

En lugar de aprobar cada acción individualmente, agrupa las acciones relacionadas:

Agente: "Planeo realizar las siguientes 5 acciones para resolver este problema del cliente:
  1. Buscar la cuenta del cliente #12345
  2. Comprobar el historial de pedidos de los últimos 30 días
  3. Identificar el cargo en disputa
  4. Calcular el importe del reembolso
  5. Emitir el reembolso

Aprobar todo / Aprobar con modificaciones / Rechazar"

Esto da al humano una visión completa y reduce el número de decisiones de aprobación de 5 a 1. El humano puede evaluar todo el flujo de trabajo de una vez, lo cual es tanto más rápido como más eficaz que evaluar cada paso de forma aislada (porque el humano puede ver si los pasos tienen sentido en conjunto).

3.2.2 Aprobación a nivel de plan

El agente presenta su plan completo antes de ejecutar ninguna acción. El humano aprueba el plan y luego el agente ejecuta sin más interrupciones (a menos que ocurra algo inesperado).

Este patrón es utilizado por GitHub Copilot Workspace y herramientas similares. El humano aprueba la intención (lo que el agente planea hacer), y el agente se encarga de la ejecución (cómo hacerlo). Es eficiente porque el humano se centra en las decisiones de alto nivel donde su juicio aporta más valor, mientras que el agente se encarga de la ejecución mecánica donde su velocidad aporta más valor.

3.2.3 Aprobación basada en excepciones

Define lo que es "normal" y solicita aprobación sólo para las excepciones:

• Acciones normales: Se ejecutan automáticamente (registradas para auditoría)
• Acciones inusuales: Se marcan para revisión humana antes de ejecutarse
• Acciones prohibidas: Se bloquean inmediatamente y se notifica al humano

El desafío está en definir "normal", "inusual" y "prohibido". Esto puede hacerse mediante:

• Reglas explícitas (una lista de acciones normales permitidas)
• Líneas base estadísticas (cualquier acción que se desvíe significativamente de los patrones históricos)
• Puntuación de riesgo (cualquier acción por encima de cierta puntuación de riesgo requiere aprobación)

Este patrón funciona bien para sistemas de alto volumen donde la revisión humana de cada acción es impracticable. La atención del humano se concentra en las excepciones donde más se necesita.

3.2.4 Aprobación escalonada

Diferentes aprobadores para diferentes niveles de riesgo:

Esto refleja cómo las organizaciones gestionan las aprobaciones financieras: un responsable de equipo puede aprobar gastos hasta 1.000 $, un director hasta 10.000$, y el director financiero por encima de eso. El principio es el mismo: escalar la supervisión a medida que aumenta el riesgo.

3.3 Principios de diseño de UX para la aprobación

La experiencia de usuario del flujo de aprobación determina si los humanos se involucrarán de forma reflexiva o aprobarán todo de forma mecánica. Estos principios son esenciales:

1. Proporcionar contexto: Muestra el razonamiento del agente, no solo su acción propuesta. "Quiero emitir un reembolso de 50 " es menos útil que "Al cliente se le cobró dos veces por el pedido #1234. El cargo duplicado fue de 50 . Recomiendo emitir un reembolso por el cargo duplicado."

2. Qué la opción por defecto sea segura: Si el humano ignora la solicitud de aprobación (se aleja de su escritorio, se distrae), la opción segura debería ser la predeterminada. Normalmente, esto significa "no proceder". Una aprobación que expira no debería auto-aprobarse.

3. Minimizar la carga cognitiva: Presenta la información de forma jerárquica: resumen primero, detalles disponibles bajo demanda. El humano debería poder tomar una decisión rápida para los casos rutinarios y profundizar en los detalles para los inusuales.

4. Facilitar decisiones rápidas: Para aprobaciones rutinarias que coinciden con patrones establecidos, proporciona botones de aprobación con un clic. Pero equilibra esto con medidas contra la aprobación mecánica (ver más adelante).

5. Permitir deshacer: Incluso después de la aprobación, proporciona una ventana para que el humano revierta la decisión. "Deshacer esta acción en los próximos 30 segundos" da al humano una red de seguridad para aprobaciones apresuradas.

6. Rastrear patrones de aprobación: Identifica acciones que siempre se aprueban (candidatas a automatización, reduciendo la carga del humano) y las que siempre se rechazan (candidatas a actualizar las políticas, evitando que el agente las proponga). Estos datos impulsan la mejora continúa del flujo de aprobación.

3.4 Medidas contra la aprobación mecánica

La fatiga de aprobación es un problema serio. Cuando los humanos revisan cientos de propuestas del agente al día, empiezan a aprobar todo sin leer. Varias técnicas combaten esto:

Desafíos aleatorios: Inserta ocasionalmente propuestas obviamente erróneas para comprobar si el humano está prestando atención. Si aprueba una acción claramente incorrecta, alértale y exige un modo de revisión más lento.

Requisitos de detalle variables: De forma aleatoriá, solicita al humano que resuma por qué aprobó una acción específica. Esto fuerza una implicación que va más allá de hacer clic en un botón.

Monitorización de la tasa de aprobación: Rastrea la tasa de aprobación de cada revisor humano. Si se aproxima al 100 %, puede estar aprobando de forma mecánica. Señala esto a su responsable.

Períodos de pausa: Tras aprobar muchas acciones en rápida sucesión, inserta una pausa obligatoria: "Has aprobado 20 acciones en los últimos 5 minutos. Tómate un momento para revisar la siguiente con cuidado."

Idea clave: El objetivo de un flujo de aprobación no es simplemente obtener una firma humana en cada acción. Es asegurar que un humano realmente evalúe cada acción. Si tu flujo de aprobación resulta en aprobación mecánica, proporciona una falsa sensación de seguridad a la vez que añade retrasos. Diseña para un compromiso genuino, no solo para el cumplimiento del proceso.

054. Transparencia y explicabilidad en las acciones del agente

4.1 Por qué la transparencia importa para los agentes

La transparencia en la IA agéntica va mucho más allá de la explicabilidad tradicional de modelos (¿por qué el clasificador predijo "gato" en lugar de "perro"?). Para un agente, necesitamos explicar un conjunto mucho más rico de decisiones:

• ¿Por qué este plan? ¿Por qué el agente eligió esta secuencia de acciones sobre las alternativas?
• ¿Por qué esta herramienta? ¿Por qué el agente seleccionó esta herramienta particular para este paso?
• ¿Por qué estos parámetros? ¿Por qué el agente usó estos argumentos específicos?
• ¿Cuál fue el razonamiento? ¿Qué información consideró el agente en su decisión?
• ¿Qué se descartó? ¿Qué alternativas consideró y descartó el agente?
• ¿Cuánta confianza tiene el agente? ¿El agente cree que este es el enfoque correcto, o está inseguro?

Sin respuestas a estas preguntas, el humano no puede tomar decisiones de supervisión informadas. Aprobar una acción del agente que no se comprende no es una supervisión significativa; es aprobación mecánica con pasos adicionales.

4.2 Niveles de transparencia

Podemos pensar en la transparencia como algo que opera en cuatro niveles progresivamente más profundos:

Nivel 1 -- Transparencia de acción: El usuario puede ver qué hizo el agente.

Agent executed: search("python error handling best practices")
Agent executed: read_file("/src/main.py")
Agent executed: write_file("/src/main.py", <modified content>)

Esta es la transparencia mínima viable. El usuario sabe qué herramientas se invocaron y con qué parámetros. Es como un registro de transacciones: útil para auditoría pero no explica el porqué.

Nivel 2 -- Transparencia de razonamiento: El usuario puede ver por qué el agente lo hizo.

"Busqué las mejores prácticas de manejo de errores en Python porque el código
actual usa cláusulas except genéricas, lo cual es un antipatrón. Luego modifiqué
main.py para usar tipos de excepción específicos."

La transparencia de razonamiento responde a la pregunta del "por qué". Conecta las acciones con la justificación, permitiendo al usuario evaluar si el razonamiento es sólido.

Nivel 3 -- Transparencia de alternativas: El usuario puede ver qué más consideró el agente.

"Consideré tres enfoques:
  A) Añadir tipos de excepción específicos (elegido -- más Pythonic)
  B) Añadir un wrapper genérico de logging (rechazado -- enmascara los tipos de error)
  C) Refactorizar para evitar try/except donde sea posible (rechazado -- demasiado invasivo)"

La transparencia de alternativas revela el espacio de decisión. Al mostrar qué se rechazó y por qué, da al usuario confianza en que el agente consideró múltiples opciones y eligió con criterio. También facilita que el usuario diga "en realidad, prefiero la opción C."

Nivel 4 -- Transparencia de incertidumbre: El usuario puede ver cuánta confianza tiene el agente.

"Tengo un 90 % de confianza en que ValueError es el tipo de excepción correcto aquí,
pero existe la posibilidad de que TypeError sea más apropiado.
Recomendaría revisar la línea 42 con cuidado."

La transparencia de incertidumbre es el nivel más profundo. Indica al usuario dónde concentrar su esfuerzo de revisión: las áreas dónde el agente está inseguro merecen más escrutinio que las áreas dónde tiene confianza.

4.3 La cadena de pensamiento como transparencia

Una ventaja práctica de los agentes basados en LLM es que el razonamiento de cadena de pensamiento (chain-of-thought) proporciona una forma natural de transparencia. El razonamiento del agente se expresa en lenguaje natural que los humanos pueden leer y evaluar. Esta es una ventaja significativa sobre los modelos ML tradicionales, donde explicar una decisión requiere técnicas de interpretación especializadas.

Sin embargo, hay importantes advertencias, como destacaron Turpin et al. (2023):

La cadena de pensamiento puede no reflejar el razonamiento real. El modelo podría generar un razonamiento de apariencia plausible que no corresponde al cálculo real que produjo la respuesta. Esto se conoce como "razonamiento infiel" (unfaithful reasoning). La salida del modelo dice "Elegí A por X, Y y Z", pero el cálculo neuronal real que seleccionó A no involucró X, Y ni Z.

Racionalización a posteriori. El modelo podría decidir una acción primero y luego generar un razonamiento para justificarla, en lugar de razonar primero y luego decidir. Este es el equivalente computacional de un humano que toma una decisión instintiva y luego construye un argumento racional para apoyarla.

Reporte selectivo. El modelo podría omitir consideraciones relevantes de su razonamiento declarado. Podría mencionar los factores que apoyan su decisión mientras ignora los factores que argumentan en contra.

A pesar de estas limitaciones, la cadena de pensamiento sigue siendo el mecanismo de transparencia más práctico para los agentes actuales. La clave es tratarlo como una señal entre varias, no como la verdad absoluta sobre el proceso de decisión del agente. Combínalo con registro de acciones, validación de salida y revisión humana para una imagen más completa.

4.4 Patrón de diseño: el agente transparente

"""
Design pattern for a transparent agent that provides
multi-level explanations of its actions.
"""

from dataclasses import dataclass


@dataclass
class AgentAction:
    """A single action with full transparency metadata."""
    tool_name: str
    parameters: dict
    reasoning: str                    # Why this action?
    alternatives_considered: list[str] # What else was considered?
    confidence: float                  # 0.0 to 1.0
    risks: list[str]                   # What could go wrong?


@dataclass
class AgentPlan:
    """A complete plan with full transparency metadata."""
    goal: str
    steps: list[AgentAction]
    overall_reasoning: str
    estimated_duration: str
    rollback_plan: str                 # How to undo if things go wrong


def present_plan_to_user(plan: AgentPlan) -> str:
    """
    Format an agent plan for human review.

    Uses progressive disclosure: summary first, details on demand.
    This function generates the human-facing presentation of the
    plan, suitable for an approval workflow.
    """
    output = []
    output.append(f"## Goal: {plan.goal}")
    output.append(f"**Approach**: {plan.overall_reasoning}")
    output.append(f"**Estimated time**: {plan.estimated_duration}")
    output.append(f"**Rollback plan**: {plan.rollback_plan}")
    output.append("")
    output.append("### Steps:")

    for i, step in enumerate(plan.steps, 1):
        # Map numeric confidence to human-readable label
        confidence_indicator = (
            "high" if step.confidence > 0.8
            else "medium" if step.confidence > 0.5
            else "low"
        )
        output.append(
            f"\n**Step {i}**: `{step.tool_name}` "
            f"(confidence: {confidence_indicator})"
        )
        output.append(f"  - **Why**: {step.reasoning}")

        if step.alternatives_considered:
            output.append(
                f"  - **Alternatives considered**: "
                f"{', '.join(step.alternatives_considered)}"
            )

        if step.risks:
            output.append(f"  - **Risks**: {', '.join(step.risks)}")

    return "\n".join(output)

Las decisiones de diseño clave en este código:

• Cada acción lleva su propio razonamiento, alternativas, confianza y riesgos. Esto significa que los metadatos de transparencia viajan con la acción, no en un registro separado.
• La función present_plan_to_user implementa revelación progresiva: muestra el resumen de alto nivel (objetivo, enfoque, plan de reversión) antes de entrar en los detalles paso a paso.
• La confianza se traduce de un número a una etiqueta legible porque los usuarios responden mejor a "confianza media" que a "0,62."

065. Calibración de la confianza: cuándo confiar y cuándo verificar

5.1 El problema de la confianza

La calibración de la confianza es uno de los aspectos más importantes y menos comprendidos de la interacción humano-agente. Se refiere a la alineación entre la confianza de un usuario en un agente y la fiabilidad real del agente. Existen dos modos de fallo, y ambos son costosos:

Confianza excesiva (complacencia de automatización). El usuario confía en el agente más de lo que sus capacidades justifican. Esto lleva a una aceptación acrítica de las salidas del agente y a no detectar los errores. La confianza excesiva es especialmente peligrosa porque los errores que se escapan son precisamente los que requerían juicio humano: el agente acertó en los casos fáciles (construyendo la confianza del usuario) y falló en los difíciles (que el usuario sobreconfiado no revisó cuidadosamente).

La confianza excesiva se desarrolla naturalmente cuando un agente funciona bien la mayor parte del tiempo. Después de ver al agente tener éxito 50 veces seguidas, el humano deja de comprobar la salida número 51. Pero la salida 51 podría ser la errónea.

Confianza insuficiente (aversión a la automatización). El usuario confía en el agente menos de lo que sus capacidades justifican. Esto lleva a una verificación innecesaria de salidas correctas del agente, anulando los beneficios de eficiencia de la automatización. La confianza insuficiente suele desarrollarse tras un fallo dramático: el agente comete un error grave y el usuario ya nunca vuelve a confiar en él, aunque sea fiable el 99 % del tiempo.

La confianza insuficiente es costosa porque transforma el agente de una herramienta de productividad en una fuente de trabajo adicional. Si el humano rehace cada tarea que el agente completa, está haciendo el trabajo dos veces.

El objetivo es la confianza calibrada: la confianza del usuario sigue la fiabilidad real del agente. El usuario confía en el agente en tareas donde es fiable y verifica en tareas donde lo es menos.

5.2 Factores que afectan a la confianza

La investigación sobre la confianza humano-automatización, resumida en la influyente revisión de Lee y See (2004), identifica tres dimensiones:

Confianza basada en el rendimiento. Basada en el historial del agente. ¿Suele producir resultados correctos? La confianza basada en el rendimiento es la forma más racional: se basa en evidencia. Pero también es lenta de construir y rápida de destruir (un fallo dramático puede anular muchos éxitos).

Confianza basada en el proceso. Basada en comprender cómo funciona el agente. ¿Puede el usuario seguir el razonamiento del agente? La confianza basada en el proceso es la razón por la que la transparencia importa: un usuario que puede ver y evaluar el razonamiento del agente tiene una base para confiar en él más allá del simple historial. También es la razón por la que el razonamiento de cadena de pensamiento es tan valioso para construir confianza.

Confianza basada en el propósito. Basada en la intención percibida del agente. ¿El usuario cree que el agente está tratando de ayudarle? La confianza basada en el propósito es la razón por la que el encuadre importa: un agente que dice "Estoy tratando de ayudarte con X" establece su intención de forma clara.

Para los agentes basados en LLM, la confianza basada en el propósito es generalmente alta (los usuarios creen que el agente está tratando de ayudar), la confianza basada en el proceso es a menudo baja (los usuarios no entienden cómo funcionan los LLM y no pueden evaluar de forma fiable el razonamiento de cadena de pensamiento), y la confianza basada en el rendimiento varía según la experiencia.

5.3 Estrategias para una calibración adecuada de la confianza

5.3.1 Comunicar la incertidumbre

Los agentes deberían indicar explícitamente cuándo están inseguros. Este es quizás el patrón de diseño más importante para la calibración de la confianza:

Alta confianza:  "Voy a actualizar el archivo de configuración."
Confianza media: "Creo que el problema está en la conexión a la base de datos, pero no estoy seguro."
Baja confianza:  "No estoy seguro de cómo abordar esto. Aquí hay dos posibles estrategias..."

Cuando un agente comunica incertidumbre, el usuario sabe dónde concentrar su esfuerzo de revisión. Las acciones de alta confianza pueden revisarse rápidamente; las de baja confianza merecen un escrutinio cuidadoso. Sin comunicación de incertidumbre, el usuario debe tratar cada acción con el mismo nivel de escrutinio, lo cual es tanto agotador como ineficiente.

5.3.2 Mostrar el historial

Muestra la precisión histórica del agente para tareas similares:

"Este tipo de tarea (refactorización de código) tiene una tasa de éxito del 94 %
basada en las últimas 200 ejecuciones en tu organización."

La información del historial ayuda a los usuarios a calibrar sus expectativas. Si el agente tiene una tasa de éxito del 94 % en este tipo de tarea, el usuario sabe que puede esperar aproximadamente 1 fallo en 17 intentos y puede planificar su estrategia de revisión en consecuencia.

5.3.3 Revelación progresiva de la competencia

Deja que los usuarios descubran las capacidades del agente gradualmente en lugar de presentar una larga lista de funcionalidades. Comienza con tareas simples y amplía el alcance a medida que se construye confianza. Esto refleja cómo se desarrolla la confianza en las relaciones humanas: no compartes tus secretos más profundos con alguien que acabas de conocer.

5.3.4 Reporte honesto de fallos

Cuando un agente falla, debería informar claramente de:

• Qué estaba intentando hacer
• Qué salió mal
• Qué ya ha hecho (para propósitos de reversión)
• Qué recomienda como siguiente paso

Nunca ocultes los fallos. Un agente que falla silenciosamente o finge tener éxito destruye la confianza mucho más que uno que falla de forma transparente. Si el usuario descubre más tarde que el agente falló silenciosamente, nunca volverá a confiar en él (y con razón). El reporte honesto de fallos, aunque doloroso en el momento, construye confianza a largo plazo al demostrar que el agente es un informador fiable de su propio estado.

5.4 El compromiso del coste de verificación

Cada vez que un humano verifica el trabajo de un agente, hay un coste (el tiempo y la atención del humano). La calibración de la confianza ayuda a optimizar esto:

Coste esperado = P(error) * Coste(error_no_detectado) + P(verificar) * Coste(verificación)

La tasa óptima de verificación minimiza el coste esperado.

Para decisiones de alto impacto y baja frecuencia: verificar siempre (el coste de un error no detectado supera con creces el coste de la verificación). Para decisiones de bajo impacto y alta frecuencia: muestrear y verificar periódicamente (revisión puntual). Para impacto medio: verificar según la confianza expresada por el agente.

Este marco hace que la calibración de la confianza sea concreta y accionable. No se trata de "confiar" o "no confiar" en el agente en sentido absoluto; se trata de asignar el esfuerzo de verificación donde tiene el mayor valor esperado.

Idea clave: La confianza no es una propiedad binaria ("confío en este agente" o "no confío en este agente"). Es un problema de calibración: ajustar tu esfuerzo de verificación a la fiabilidad real del agente en cada tipo específico de tarea. La confianza excesiva desperdicia seguridad; la confianza insuficiente desperdicia tiempo. La confianza calibrada optimiza ambos.

076. Flujos de trabajo colaborativos: agente como asistente vs. agente como colega

6.1 Dos modelos de colaboración

A medida que los agentes se vuelven más capaces, la naturaleza de la colaboración humano-agente está evolucionando de una relación amo-sirviente a algo más paritario. Comprender estos dos modelos ayuda a diseñar los patrones de interacción adecuados.

Agente como asistente. El humano dirige. El agente ayuda con subtareas específicas cuando se le solicita. El humano mantiene el plan general y el contexto. Este es el modelo utilizado por la mayoría de las herramientas de IA actuales (ChatGPT, Copilot, Claude en modo chat estándar).

El modelo de asistente es cómodo y familiar porque refleja los patrones de uso de herramientas existentes. El humano siempre tiene el control y el agente es pasivo hasta que se le solicita. Pero también significa que el humano debe gestionar el contexto, recordar pedir ayuda y coordinar todas las piezas.

Agente cómo colega. El agente y el humano trabajan cómo pares en una tarea compartida. El agente puede perseguir subtareas de forma independiente, contribuir con ideas y cuestionar el enfoque del humano. El humano y el agente negocian la estrategia.

El modelo de colega está emergiendo en la práctica, particularmente en la ingeniería de software (Claude Code operando como un compañero de programación en pareja que sugiere mejoras de forma proactiva) y en la investigación (agentes que exploran la literatura de forma independiente y destacan hallazgos relevantes).

6.2 Características de cada modelo

6.3 Patrones prácticos del modelo de colega

El modelo de colega está emergiendo en la práctica, particularmente en la ingeniería de software:

Programación en pareja con IA. El humano y el agente se turnan para escribir código. El agente podría implementar una función, el humano la revisa y la refina, el agente escribe tests, el humano modifica los tests, y así sucesivamente. La diferencia clave con el modelo de asistente es que el agente toma la iniciativa: podría notar un bug potencial que el humano no preguntó y señalarlo de forma proactiva.

Revisión y crítica. El agente revisa el trabajo del humano y proporciona retroalimentación constructiva: no solo correcciones sino también sugerencias de enfoques alternativos, identificación de casos límite olvidados y preocupaciones de arquitectura. Esto requiere que el agente tenga "opiniones" (o al menos, que destaque consideraciones que el humano podría haber pasado por alto).

Contribución proactiva. El agente detecta problemas u oportunidades que el humano no ha preguntado: "He notado que la función que acabas de escribir tiene una posible condición de carrera. ¿Quieres que la corrija?" Esta es la marca distintiva del modelo de colega: el agente actúa según su propio juicio, no solo según instrucciones explícitas.

6.4 Protocolos de comunicación

Para una colaboración humano-agente eficaz, los protocolos de comunicación explícitos ayudan:

Actualizaciones de estado. El agente informa de forma proactiva qué está haciendo y qué planea hacer a continuación. Sin actualizaciones de estado, el humano no puede mantener un modelo mental del progreso del agente.

Puntos de control. En puntos de ruptura naturales, el agente resume el progreso y pregunta si debe continuar. Esto dá al humano oportunidades regulares de redirigir o corregir sin tener que interrumpir.

Traspasos. Cuando el agente encuentra algo fuera de su capacidad, traspasa claramente al humano con todo el contexto: qué estaba intentando hacer, dónde se quedó bloqueado y qué información necesita el humano para continuar.

Solicitudes de aclaración. En lugar de adivinar, el agente hace preguntas específicas cuando los requisitos son ambiguos. Las buenas solicitudes de aclaración son específicas ("¿El reembolso debe aplicarse al método de pago original o como crédito en la tienda?"), no vagas ("¿Qué debo hacer?").

087. Diseño de UX para interfaces agénticas

7.1 El desafío de UX

Las interfaces agénticas plantean desafíos de UX únicos que van más allá del diseño de software tradicional:

• Comportamiento no determinista: El agente podría hacer algo diferente cada vez, haciendo la interfaz menos predecible que el software tradicional
• Tareas de larga duración: Las tareas pueden llevar minutos u horas, con tiempos de finalización inciertos
• Trabajo invisible: Gran parte del trabajo del agente (razonamiento, búsqueda, planificación) es invisible para el usuario
• Necesidad de intervención: El usuario necesita entender el estado del agente lo suficientemente bien como para intervenir en los puntos apropiados

La UX de software tradicional asume que el usuario tiene el control y el software es determinista. La UX agéntica debe manejar una situación fundamentalmente diferente donde el agente tiene su propia "agencia" y el usuario debe supervisar en lugar de dirigir.

7.2 Patrones de UX fundamentales

7.2.1 El feed de actividad

Muestra un feed cronológico de acciones del agente, similar a un terminal de desarrollo o registro de actividad:

Este patrón proporciona: visibilidad en tiempo real de la actividad del agente, puntos de ruptura naturales para la intervención y un historial desplazable para revisión. Es familiar por las interfaces de terminal y CI/CD, reduciendo la curva de aprendizaje.

El feed de actividad es el patrón de UX más importante para interfaces agénticas porque aborda el problema del "trabajo invisible": el usuario puede ver lo que el agente está haciendo en cada momento.

7.2.2 La vista de plan

Muestra el plan general del agente con seguimiento de progreso:

La vista de plan proporciona orientación de alto nivel: ¿dónde está el agente en su tarea global? ¿Cuánto queda? El usuario puede modificar el plan (añadir pasos, eliminar pasos, reordenar) o cancelar por completo. Esto da al usuario el control sobre la estrategia mientras el agente se encarga de las tácticas.

7.2.3 La vista de diferencias

Para agentes que modifican archivos o datos, muéstra los cambios en un formato diff familiar:

La vista de diferencias es esencial para agentes que modifican código. Aprovecha una interfaz familiar (los diffs de código son universales en el desarrollo de software) y permite una revisión precisa de lo que el agente propone cambiar. El botón "Explicar por qué" conecta el diff con el razonamiento del agente, proporcionando transparencia de Nivel 2.

7.2.4 El indicador de confianza

Comunica visualmente la confianza del agente en sus acciones:

Los indicadores de confianza ayudan a los usuarios a calibrar su confianza por acción. Una recomendación de alta confianza puede aceptarse rápidamente; una de baja confianza merece una revisión cuidadosa. Fundamentalmente, el indicador muestra dónde el agente tiene menos confianza, concentrando la atención del usuario en las áreas que más probablemente necesiten juicio humano.

7.3 Principios de diseño para UX agéntica

Basándose en las heurísticas de usabilidad de Nielsen (1994) y en las directrices de Amershi et al. para la interacción humano-IA (2019), adaptadas para sistemas agénticos:

1. Visibilidad del estado del agente: Muestra siempre qué está haciendo el agente actualmente, qué planea hacer y qué ha hecho. Nunca dejes al usuario preguntándose "¿qué está haciendo el agente ahora mismo?". La incertidumbre sobre el estado del agente es la forma más rápida de erosionar la confianza.

2. Control y libertad del usuario: Proporciona mecanismos claros para pausar, reanudar, cancelar, deshacer y modificar el comportamiento del agente en cualquier punto. El usuario debería sentirse siempre en control, incluso cuando el agente está actuando de forma autónoma.

3. Consistencia y estándares: Usa patrones de UI familiares (diffs, feeds de actividad, barras de progreso) en lugar de inventar interfaces novedosas. La UX agéntica ya es lo suficientemente desafiante sin añadir curvas de aprendizaje de interfaz.

4. Prevención y recuperación de errores: Diseña la interfaz para que sea fácil detectar errores del agente antes de que surtan efecto. Muestra los cambios propuestos antes de aplicarlos. Proporciona la opción de deshacer para los cambios aplicados.

5. Reconocimiento antes qué recuerdo: Muestra las capacidades disponibles del agente en lugar de requerir qué el usuario recuerde comandos o prompts. Una interfaz descubrible reduce la barrera para un uso eficaz del agente.

6. Flexibilidad y eficiencia: Soporta tanto usuarios novatos (modo guiado, alta supervisión) como usuarios expertos (modo agilizado, menor supervisión). El mismo agente podría necesitar UX diferente para diferentes niveles de habilidad del usuario.

098. Mecanismos de retroalimentación: correcciones, preferencias, demostraciones

8.1 Por qué importa la retroalimentación

Un agente que nunca mejora con la experiencia es una herramienta estática. Los mecanismos de retroalimentación transforman los agentes de herramientas estáticas en sistemas de aprendizaje que mejoran con el tiempo. Los bucles de retroalimentación eficaces permiten:

• Corrección de errores específicos (el agente aprende a no repetir errores)
• Comunicación de preferencias y estilo (el agente aprende la forma de trabajar del usuario)
• Enseñanza de conocimiento específico del dominio (el agente aprende el dominio del usuario)
• Calibración del comportamiento con el tiempo (el agente aprende qué nivel de detalle, formalidad y cautela prefiere el usuario)

8.2 Tipos de retroalimentación

8.2.1 Correcciones explícitas

El usuario corrige directamente la salida del agente:

Agente: "He establecido el timeout en 30 segundos."
Usuario: "Cámbialo a 60 segundos. Nuestra API es lenta."
Agente: "Actualizado a 60 segundos. Usaré 60s como valor predeterminado para esta API en adelante."

El desafío clave es la generalización: el agente debería aprender de la corrección, no solo aplicarla a esta instancia. ¿Debería usar 60 segundos para todas las API? ¿Solo para esta? ¿Para todas las API lentas? El alcance de la generalización a menudo es ambiguo, y equivocarse puede causar nuevos problemas.

Una buena práctica es que el agente indique explícitamente qué ha generalizado: "Usaré 60s como valor predeterminado para la API de pagos en adelante. ¿Debo aplicar esto también a otras API?" Esto hace que la generalización sea visible y corregible.

8.2.2 Señales de preferencia

Votos positivos/negativos, valoraciones o elecciones entre alternativas:

El agente presenta dos implementaciones de código:
  Opción A: Usando recursión
  Opción B: Usando iteración

El usuario selecciona la Opción B.

El agente aprende: "Este usuario prefiere soluciones iterativas sobre las recursivas."

Las señales de preferencia requieren poco esfuerzo del usuario pero proporcionan menos información que las correcciones explícitas. Indican qué prefiere el usuario pero no por qué. El agente podría generalizar incorrectamente: quizás el usuario eligió la Opción B no porque prefiera la iteración en general, sino porque este problema específico es más adecuado para la iteración.

8.2.3 Demostraciones

El usuario muestra al agente cómo realizar una tarea:

Usuario: "Mira cómo gestiono este tipo de reclamación de cliente..."
[El usuario demuestra el flujo de trabajo paso a paso]
Agente: "Entendido. Para reclamaciones sobre retrasos en la entrega:
  1. Reconocer la frustración
  2. Consultar el estado del pedido
  3. Ofrecer una resolución específica (reembolso o reenvío urgente)
  4. Hacer seguimiento en 24 horas"

Las demostraciones requieren alto esfuerzo pero proporcionan información rica sobre el comportamiento deseado. Son más eficaces para enseñar flujos de trabajo complejos donde la secuencia de pasos y los criterios de decisión son difíciles de describir con palabras.

8.2.4 Retroalimentación implícita

Señales de comportamiento que indican satisfacción o insatisfacción sin que el usuario proporcione retroalimentación explícita:

• El usuario acepta la salida del agente sin modificaciones (positiva)
• El usuario modifica la salida significativamente (negativa)
• El usuario abandona la tarea (muy negativa)
• El usuario pide al agente que rehaga la tarea (negativa)
• El usuario usa la salida inmediatamente (positiva)

La retroalimentación implícita es abundante (cada interacción la genera) pero ruidosa (el usuario podría modificar la salida por razones no relacionadas con la calidad, como añadir contexto que el agente no tenía).

8.3 Implementación de bucles de retroalimentación

"""
Feedback collection and application system for agents.

This module shows how to collect user feedback, generalize it into
reusable rules, and inject those rules into the agent's context
to personalize its behavior over time.
"""

from dataclasses import dataclass
from enum import Enum
from datetime import datetime


class FeedbackType(Enum):
    CORRECTION = "correction"
    PREFERENCE = "preference"
    DEMONSTRATION = "demonstration"
    RATING = "rating"
    IMPLICIT = "implicit"


@dataclass
class FeedbackRecord:
    feedback_type: FeedbackType
    timestamp: datetime
    task_context: str
    agent_output: str
    user_feedback: str
    generalized_rule: str | None = None


class FeedbackStore:
    """
    Stores and retrieves feedback for agent personalization.

    Feedback is stored as natural language rules that can be
    injected into the agent's context at inference time. This
    is a simple but effective approach: the agent's system prompt
    includes a section like "User Preferences" that contains
    learned rules from past feedback.
    """

    def __init__(self):
        self.records: list[FeedbackRecord] = []
        self.rules: list[str] = []

    def add_correction(self, context: str, agent_output: str, correction: str):
        """
        Record a user correction and attempt to generalize.

        In a production system, you would use an LLM to generalize
        the correction into a reusable rule. For example:
          Context: "Setting timeout for payments API"
          Agent output: "30 seconds"
          Correction: "60 seconds"
          Generalized rule: "For the payments API, use 60s timeout"
        """
        record = FeedbackRecord(
            feedback_type=FeedbackType.CORRECTION,
            timestamp=datetime.now(),
            task_context=context,
            agent_output=agent_output,
            user_feedback=correction,
        )
        self.records.append(record)

        # In practice, you might use an LLM to generalize the correction
        # into a reusable rule. Here we store it directly.
        rule = (
            f"When handling '{context}': "
            f"user prefers '{correction}' over '{agent_output}'"
        )
        record.generalized_rule = rule
        self.rules.append(rule)

    def add_preference(self, context: str, chosen: str, rejected: str):
        """Record a preference between two options."""
        record = FeedbackRecord(
            feedback_type=FeedbackType.PREFERENCE,
            timestamp=datetime.now(),
            task_context=context,
            agent_output=f"Chosen: {chosen}, Rejected: {rejected}",
            user_feedback=f"Preferred: {chosen}",
        )
        self.records.append(record)

    def get_relevant_rules(
        self, current_context: str, max_rules: int = 5
    ) -> list[str]:
        """
        Retrieve rules relevant to the current context.

        In a production system, this would use semantic similarity
        (e.g., embedding-based retrieval) to find the most relevant
        rules. Here we use a simplified recency-based approach.
        """
        return self.rules[-max_rules:]

    def build_personalization_prompt(self, current_context: str) -> str:
        """
        Build a prompt section containing relevant user preferences
        to inject into the agent's context.

        This is the bridge between feedback collection and behavior
        change: learned rules become part of the agent's instructions.
        """
        rules = self.get_relevant_rules(current_context)
        if not rules:
            return ""

        lines = ["## User Preferences (learned from feedback)"]
        for rule in rules:
            lines.append(f"- {rule}")

        return "\n".join(lines)

La arquitectura es sencilla pero potente: la retroalimentación se convierte en reglas, las reglas se convierten en parte del prompt, y el prompt moldea el comportamiento. Este enfoque de aprendizaje en contexto no requiere reentrenar el modelo; funciona aumentando el system prompt con preferencias aprendidas.

8.4 Desafíos del aprendizaje basado en retroalimentación

1. Escasez de retroalimentación: Los usuarios proporcionan retroalimentación raramente. La mayoría de las salidas del agente no reciben retroalimentación explícita. Esto significa que cada pieza de retroalimentación debe generalizarse con cuidado porque no se puede permitir desperdiciarla.

2. Retroalimentación contradictoria: Diferentes usuarios (o el mismo usuario en diferentes momentos) pueden proporcionar retroalimentación contradictoria. El agente podría aprender "usa lenguaje formal" de un usuario y "sé informal" de otro. Los sistemas multiusuario necesitan perfiles de preferencias por usuario.

3. Errores de generalización: Una corrección para un caso específico puede generalizarse incorrectamente. El usuario corrige un valor de timeout para una API, y el agente lo generaliza a todas las API. La sobregeneralización es tan perjudicial como la subgeneralización.

4. Latencia de la retroalimentación: El usuario puede no darse cuenta de que la salida era errónea hasta mucho después. Para entonces, el contexto se ha perdido, lo que dificulta asociar la retroalimentación con la acción específica que causó el problema.

5. Hackeo de la recompensa: El agente puede aprender a optimizar para retroalimentación positiva en lugar de calidad real. Por ejemplo, podría producir salidas que parecen buenas (bien formateadas, con tono seguro) pero son sutilmente incorrectas, porque tales salidas reciben retroalimentación implícita positiva (el usuario no nota el error y acepta la salida).

109. El papel de la supervisión humana en dominios de alto riesgo

9.1 Requisitos específicos por dominio

Diferentes dominios tienen diferentes requisitos de supervisión, moldeados por la regulación, la tradición y las consecuencias del error:

Sanidad. El diagnóstico médico y las recomendaciones de tratamiento requieren supervisión médica. La Ley de IA de la UE clasifica la IA en sanidad como de alto riesgo, exigiendo supervisión humana. Los agentes en sanidad deberían presentar hallazgos y recomendaciones, nunca tomar decisiones finales. El médico retiene la autoridad plena de decisión.

Derecho. Los agentes de investigación legal pueden encontrar casos y normativa relevantes, pero las conclusiones legales deben provenir de abogados licenciados. El privilegio abogado-cliente y las obligaciones de deber de cuidado requieren participación humana. Un agente que proporcione asesoramiento legal sin revisión de un abogado podría crear responsabilidad por mala praxis.

Finanzas. Los sistemas de trading algorítmico han operado durante mucho tiempo con diversos grados de autonomía, pero los marcos regulatorios (MiFID II en la UE, regulaciones de la SEC en EE. UU.) exigen mecanismos de supervisión humana, botones de emergencia y registros de auditoría. Las regulaciones posteriores al "flash crash" de 2008 abordan específicamente los riesgos de los sistemas de trading autónomos.

Educación. Los sistemas de tutoría con IA pueden adaptarse a las necesidades de los estudiantes, pero las decisiones educativas (calificación, promoción, intervención) deberían involucrar a educadores humanos que comprendan el contexto completo del estudiante. Un agente de tutoría que acelera a un estudiante a través de material que no ha dominado realmente puede ser contraproducente.

Justicia penal. Las herramientas de evaluación de riesgo utilizadas en decisiones de fíanza, sentencia y libertad condicional han sido ampliamente criticadas por sesgo y falta de transparencia. Dressel y Farid (2018) demostraron que modelos simples igualaban la precisión de herramientas comerciales como COMPÁS, cuestionando la necesidad de sistemas complejos y opacos. Los jueces humanos deben retener la autoridad plena de decisión, con la IA sirviendo solo como una entrada más entre muchas.

9.2 La paradoja de la automatización

Irónicamente, cuanto más fiable se vuelve un sistema automatizado, más difícil es para los humanos mantener una supervisión eficaz. Esto se denomina la "paradoja de la automatización" o "ironía de la automatización" (Bainbridge, 1983):

• Cuando el sistema funciona bien el 99 % del tiempo, la atención del humano decae
• Los fallos raros son precisamente los casos donde la intervención humana es más necesaria
• Pero el humano está menos preparado para intervenir porque no ha estado activamente involucrado
• Se produce degradación de habilidades: el humano pierde la capacidad de realizar la tarea manualmente

Esta paradoja está bien documentada en la aviación. Las cabinas altamente automatizadas han provocado incidentes en los que los pilotos, que no habían pilotado manualmente en meses, fueron incapaces de responder eficazmente cuando el piloto automático se desconectó inesperadamente.

Para la IA agéntica, esto significa:

• Los agentes de alta autonomía requieren estrategias deliberadas para mantener a los humanos implicados
• La ejecución manual periódica de tareas mantiene la competencia humana (práctica)
• Las pruebas sorpresa (inyectar errores conocidos para que el humano los detecte) mantienen la vigilancia
• Los activadores de escalación claros mantienen al humano en el bucle en los momentos críticos
• La interfaz debe impedir que el humano se desconecte completamente (no solo permitir la supervisión sino requerir participación periódica)

9.3 Diseño para una supervisión eficaz

La supervisión eficaz requiere más que simplemente poner a un humano en el bucle. El humano debe estar equipado para tomar buenas decisiones:

1. Densidad de información adecuada: Demasiada información abruma; muy poca es insuficiente. Muestra resúmenes con capacidad de profundización. La cantidad adecuada depende de la tarea y la experiencia del humano.

2. Puntos de intervención significativos: No solo alertes al humano; dale suficiente contexto y opciones para tomar una buena decisión rápidamente. "El agente quiere eliminar 5.000 registros. Aprobar/Rechazar" es peor que "El agente quiere eliminar 5.000 registros de clientes creados antes de 2020 como parte de la limpieza de retención de datos. Esto coincide con la política aprobada de limpieza para cuentas inactivas. Aquí hay 10 registros de muestra para revisión. Aprobar/Rechazar/Revisar más."

3. Retroalimentación sobre la calidad de la supervisión: Rastrea con qué frecuencia las anulaciones humanas mejoran los resultados. Si las anulaciones consistentemente empeoran las cosas, el humano puede necesitar formación. Si las anulaciones consistentemente mejoran las cosas, el comportamiento del agente puede necesitar mejoras.

4. Modelo mental compartido: El humano necesita comprender las capacidades, limitaciones y estado actual del agente lo suficientemente bien como para tomar decisiones de supervisión informadas. Construir este modelo mental compartido requiere comunicación continúa, no solo una sesión de formación inicial.

Idea clave: La paradoja de la automatización significa que cuanto mejor funcione tu agente, peor será tu supervisión humana, a menos que diseñes deliberadamente contra esta tendencia. La supervisión eficáz no es un subproducto natural de poner a un humano en el bucle; es un desafío de ingeniería que requiere atención de diseño específica.

1110. Preguntas de discusión

1. El dilema de la autonomía: Las organizaciones quieren que los agentes sean autónomos (por eficiencia) pero también seguros (requiriendo supervisión). ¿Cómo se diseña un sistema donde aumentar la autonomía y aumentar la seguridad no estén en tensión? ¿Es esto posible, o hay un compromiso fundamental?

   Pista: Considera cómo la autonomía progresiva y la aprobación basada en excepciones pueden aumentar tanto la autonomía (para casos rutinarios) cómo la seguridad (concentrando la atención humana en las excepciones). Considera también cómo una mejor monitorización podría permitir mayor autonomía manteniendo la seguridad.

2. Fatiga de aprobación: En un sistema HITL que procesa miles de acciones del agente al día, los humanos pueden empezar a aprobar todo de forma mecánica. ¿Cómo se puede diseñar el flujo de aprobación para mantener a los humanos implicádos y reflexivos? Considera perspectivas de la psicología y la economía conductual.

   Pista: Piensa en el refuerzo de ratio variable (desafíos impredecibles mantienen la implicación), la revelación progresiva (mostrar solo la información suficiente) y la responsabilidad social (saber que tu tasa de aprobación está siendo rastreada).

3. Transferencia de confianza: Si confías en un agente para un tipo de tarea (p. ej., formateo de código), ¿debería esa confianza transferirse a un tipo diferente de tarea (p. ej., revisión de seguridad)? ¿Cómo debería la interfaz comunicar los niveles de confianza específicos por tarea?

   Pista: La confianza generalmente NO debería transferirse entre tipos de tarea, porque la fiabilidad del agente varía según la tarea. Pero los usuarios naturalmente generalizan la confianza. ¿Cómo se diseña una interfaz que comunique "soy fiable en formateo pero menos fiable en revisión de seguridad"?

4. El modelo de colega en la práctica: Considera un equipo de desarrollo de software donde un "miembro" es un agente de IA. ¿Cómo cambia esto la dinámica del equipo? ¿Qué protocolos establecerías para la colaboración agente-humano? ¿Cómo gestionas los desacuerdos entre el agente y un miembro humano del equipo?

   Pista: Piensa en cómo los equipos gestionan actualmente los desacuerdos entre miembros humanos. ¿Cómo funcionaría la revisión de código si uno de los revisores es un agente? ¿Qué pasa cuando el agente y un humano no están de acuerdo en una decisión de arquitectura?

5. Supervisión en entornos adversariales: ¿Cómo se diseña la supervisión humana para agentes que operan en entornos adversariales (p. ej., ciberseguridad)? El atacante puede intentar manipular al agente para que genere acciones que parezcan razonables al supervisor humano pero que en realidad sean dañinas.

   Pista: Esta es una variante del problema de inyección indirecta de prompt de la semana pasada, pero aplicada a la interfaz de supervisión. ¿Y si el atacante diseña entradas pensadas no solo para engañar al agente, sino para engañar al humano que revisa las acciones del agente?

1211. Resumen y puntos clave

1. Tres paradigmas gobiernan la interacción humano-agente: human-in-the-loop (cada acción aprobada), human-on-the-loop (supervisión con intervención) y totalmente autónomo. La mayoría de los sistemas en producción usan enfoques híbridos con granularidad por acción, ajustando la supervisión según la reversibilidad y el riesgo de cada acción específica.

2. Los niveles de autonomía (análogos a los niveles de conducción autónoma 0-5) proporcionan un marco para decidir cuánta independencia dar a un agente. La elección depende de la criticidad de la tarea, la previsibilidad, la madurez del agente, el cóste de recuperación y los requisitos regulatorios. La autonomía progresiva (empezar con alta supervisión e ir reduciéndola) es un patrón práctico.

3. Los flujos de aprobación deben equilibrar seguridad y eficiencia. Los patrones clave incluyen aprobaciones por lotes, aprobación a nivel de plan, aprobación basada en excepciones y aprobación escalonada. Un buen diseño de UX y medidas contra la aprobación mecánica previenen la fatiga de aprobación manteniendo una supervisión genuina.

4. La transparencia opera en cuatro niveles: transparencia de acción (qué), transparencia de razonamiento (por qué), transparencia de alternativas (qué más se consideró) y transparencia de incertidumbre (cuánta confianza). El razonamiento de cadena de pensamiento proporciona transparencia pero puede no ser completamente fiel al proceso real de decisión del modelo.

5. La calibración de la confianza busca alinear la confianza del usuario con la fiabilidad del agente. Tanto la confianza excesiva (complacencia) como la insuficiente (aversión) son costosas. Comunicar la incertidumbre, mostrar historiales, la revelación progresiva de competencia y el reporte honesto de fallos apoyan una confianza calibrada.

6. Dos modelos de colaboración (asistente y colega) ofrecen diferentes compromisos. El modelo de colega (emergente en la ingeniería de software) permite una colaboración más rica pero plantea nuevos desafíos en torno a la iniciativa, el desacuerdo y la responsabilidad compartida.

7. El diseño de UX para agentes debe abordar el comportamiento no determinista, las tareas de larga duración, el trabajo invisible y la necesidad de intervención. Los patrones principales incluyen feeds de actividad (qué está pasando ahora), vistas de plan (cuál es la estrategia general), vistas de diferencias (qué cambios específicos se proponen) e indicadores de confianza (cuán seguro está el agente).

8. Los mecanismos de retroalimentación (correcciones, preferencias, demostraciones y señales implícitas) permiten que los agentes mejoren con el tiempo. Los principales desafíos son la escasez de retroalimentación, la retroalimentación contradictoria, los errores de generalización y el riesgo de hackeo de la recompensa. Un enfoque práctico almacena la retroalimentación como reglas en lenguaje natural inyectadas en el contexto del agente.

9. Los dominios de alto riesgo requieren un diseño cuidadoso de la supervisión que tenga en cuenta la paradoja de la automatización: a medida que los sistemas se vuelven más fiables, la supervisión humana se hace más difícil de mantener, precisamente cuando los fallos raros más necesitan intervención humana. Se requiere un diseño deliberado para mantener a los humanos implicados.

1312. Referencias

• Amershi, S., Weld, D., Vorvoreanu, M., Fourney, A., Nushi, B., Collisson, P., ... & Horvitz, E. (2019). Guidelines for human-AI interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, 1-13.

• Bainbridge, L. (1983). Ironies of automation. Automática, 19(6), 775-779.

• Dressel, J., & Farid, H. (2018). The accuracy, fairness, and limits of predicting recidivism. Science Advances, 4(1), eaao5580.

• Lee, J. D., & See, K. A. (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50-80.

• Nielsen, J. (1994). 10 usability heuristics for user interface design. Nielsen Norman Group.

• Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics -- Part A, 30(3), 286-297.

• SAE International. (2021). SAE J3016: Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles.

• Shneiderman, B. (2022). Human-Centered AI. Oxford University Press.

• Turpin, M., Michael, J., Pérez, E., & Bowman, S. R. (2023). Language models don't always say what they think: Unfaithful explanations in chain-of-thought prompting. Advances in Neural Information Processing Systems, 36.

Estos apuntes de clase forman parte del curso de IA Agéntica. Licenciados bajo CC BY 4.0.