Cómo diseñar bien el Human-in-the-Loop (HITL): patrones de aprobación para agentes de IA

Human-in-the-Loop (HITL) designa la integración deliberada de aprobaciones humanas en la cadena de acciones de un agente de IA. Cuando una acción es irreversible, costosa o tiene relevancia jurídica, una persona la revisa y la aprueba antes de que el agente actúe. HITL es la aplicación operativa de la supervisión humana que exige el artículo 14 del Reglamento de IA de la UE y, al mismo tiempo, una contramedida central frente al riesgo agéntico ASI09 de OWASP (Human-Agent Trust Exploitation).

• Cuándo hace falta HITL: antes de acciones irreversibles, costosas o con relevancia jurídica, no antes de cada paso.
• Qué patrones existen: Pre-Action Approval, Checkpoint Approval y Escalation-on-Anomaly, normalmente combinados.
• Qué falla con más frecuencia: el control de aprobación degenera en un trámite que se aprueba sin mirar (sesgo de automatización). La UX y la auditoría tienen que impedirlo activamente.

Por qué la autonomía ingenua es un problema de seguridad

Los sistemas agénticos planifican, razonan, eligen herramientas y actúan con una confirmación humana mínima paso a paso. Precisamente esa autonomía amplía la superficie de ataque. La entrada ASI02 de OWASP (Tool Misuse & Exploitation) señala como vector de ataque propio los modos de autoaprobación o «YOLO», que desactivan los diálogos de confirmación. Nuestra recomendación: desactiva la autoaprobación en cualquier herramienta que toque bases de datos, pagos, comunicaciones o despliegues, y sustitúyela por controles Human-in-the-Loop.

Por eso HITL no es una comodidad de UX, sino un control de seguridad. Limita el daño cuando un secuestro de objetivos (ASI01), una memoria envenenada (ASI06) o una cadena de suministro comprometida (ASI04) llevan a un agente a actuar en contra de la intención de quienes lo operan.

¿Cuándo hace falta una aprobación humana?

La decisión de poner o no un control de aprobación no debería tomarse sobre la marcha, sino a partir de una clasificación de riesgos documentada. Tres criterios cubren la mayoría de los casos:

• Irreversibilidad. ¿La acción no se puede deshacer, o solo con mucho esfuerzo? Borrados, pagos, envíos a clientes, consignas de producción.
• Costes. ¿La acción genera costes considerables o difíciles de acotar? Llamadas masivas a API, pedidos, aprovisionamiento de infraestructura.
• Relevancia jurídica. ¿La acción produce efectos jurídicos o afecta a datos personales? Contratos, resoluciones de crédito o de prestaciones, comunicaciones de operaciones sospechosas, exportación de datos maestros.

Por el contrario, las operaciones de solo lectura o las acciones fácilmente reversibles en un sandbox no suelen necesitar un control de aprobación. De lo contrario aparece la «fatiga de aprobación» y los revisores aprueban sin mirar por puro cansancio.

Patrones HITL: Pre-Action, Checkpoint, Escalation

Tres patrones básicos cubren la mayoría de las arquitecturas y en la práctica se combinan.

Pre-Action Approval. El agente se detiene justo antes de una acción crítica concreta. La acción prevista, con sus argumentos, pasa a una cola de aprobación; solo se ejecuta tras el visto bueno humano. Adecuado para operaciones individuales de alto riesgo (iniciar un pago, enviar un contrato).

Checkpoint Approval. En planes de varias fases, una persona revisa en hitos definidos antes de que arranque el siguiente segmento. Adecuado para flujos de trabajo largos en los que cada paso por separado es inofensivo, pero la trayectoria acumulada se vuelve crítica. El patrón responde al esquema de la «rana hervida» descrito por OWASP, en el que cada paso parece plausible, pero la trayectoria global es dañina.

Escalation-on-Anomaly. El agente trabaja de forma autónoma y solo involucra a una persona cuando saltan umbrales o detectores de anomalías: frecuencias inusuales de llamadas a herramientas, operaciones destructivas poco después de incorporar contenido externo, superaciones del rate limit. Técnicamente se puede implementar mediante policy-as-code (p. ej., con Open Policy Agent (OPA) o Cedar) como control de aprobación del uso de herramientas.

Una arquitectura HITL eficaz escalona la confianza: las decisiones de mayor impacto requieren más revisores o pruebas más sólidas («graduated trust»). Según OWASP, lo decisivo es que el control de aprobación exija una verificación independiente de las pruebas, no solo la recomendación del agente.

La matriz acción-riesgo-HITL

La siguiente matriz muestra, a modo de ejemplo, cómo se pueden clasificar las acciones. Está pensada como plantilla; cada organización debe ajustar los umbrales concretos a su apetito de riesgo.

El error más frecuente: el control de aprobación se degrada

El mayor riesgo no es la falta de un control de aprobación, sino su vaciado progresivo. OWASP lo recoge como riesgo propio de su Top 10: ASI09 (Human-Agent Trust Exploitation). Los agentes generan respuestas pulidas y con tono de autoridad; las personas tienden a darlas por buenas. Así, la capa de supervisión pensada como control de seguridad se convierte ella misma en el punto débil.

Los mecanismos relevantes:

• Sesgo de automatización: la respuesta se acepta sin revisión crítica.
• Deferencia a la autoridad: el tono seguro desanima a hacer preguntas.
• Escalada gradual de la confianza: el agente gana credibilidad con respuestas correctas antes de que lleguen las manipuladas.
• Sobrecarga cognitiva: el volumen y la complejidad superan la capacidad humana de revisión.
• «Alucinación pulida»: una respuesta segura de sí misma, falsa y convincente.

Señales de detección con las que se puede medir la degradación: el tiempo de decisión de los revisores baja aunque la complejidad de las tareas se mantenga, y los patrones de aprobación se correlacionan de forma extrema con la recomendación del agente. Ambas cosas apuntan a que se aprueba sin mirar.

Diseño UX que obliga a revisar

Que el HITL funcione o no depende de la interfaz. Un simple botón de «Aprobar» invita a firmar sin leer. Lo que ayuda son los patrones de force engagement, que obligan a una revisión real:

• Hacer visible el razonamiento. Mostrar la justificación, la procedencia de las fuentes y los intervalos de confianza, no ocultarlos. Según OWASP, quien esconde la traza de razonamiento en la UI genera precisamente una señal de detección de ASI09.
• Resaltado de outputs adversariales. Avisos del tipo «esta respuesta podría estar influida por contenido externo» allí donde el contenido procede de fuentes no fiables.
• Retardo obligatorio. En aprobaciones de alto riesgo, imponer un retraso deliberado para impedir la confirmación refleja.
• Formación sobre el sesgo de automatización para los revisores e inyecciones de prueba periódicas («simulacros de incendio») que comprueban si el HITL sigue funcionando.

Escenario de ejemplo: la cascada de compras

Un escenario hace tangible el fallo del HITL. Supongamos que, a lo largo de tres semanas, se convence paso a paso a un agente de compras de que su límite de aprobación es de 500.000 USD. Después, el atacante coloca en diez transacciones pedidos falsos por un total de 5 millones de USD. El aprobador humano cree al agente, que afirma con cada vez más insistencia estar autorizado para importes mayores. Un caso de manual de ASI09, agravado por errores en cascada (ASI08).

En pseudocódigo, un control Pre-Action eficaz podría esbozarse así:

```text
on agent_action(action):
risk = classify(action) # reversibilidad, costes, derecho
if risk in {ALTO, CRÍTICO}:
evidence = gather_provenance(action) # fuentes, confianza, razonamiento
approver = route_by_amount(action) # >límite -> cuatro ojos / escalado
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # firmado
if not decision.approved: abort()
execute(action)
```

Importante: el límite (route_by_amount) está fuera de la memoria del agente y protegido contra manipulaciones. De lo contrario, el agente reaprende su propio límite, como en el ejemplo.

Auditoría: sin registro no hay supervisión

La supervisión humana solo es sólida si se puede demostrar. Como mínimo forense, por cada acción del agente deben quedar registrados: el prompt completo (usuario, sistema, contexto inyectado), la versión del modelo y el hash de configuración, la secuencia de llamadas a herramientas con sus argumentos, las consultas de recuperación y los ID de documento, la respuesta y la justificación de la decisión, los eventos de intervención humana, las operaciones de lectura y escritura en la memoria, así como los costes y la latencia.

Han dado buen resultado los registros WORM (write-once-read-many) y una firma criptográfica que hace detectables las manipulaciones. Para la conservación, el Reglamento de IA de la UE fija un mínimo en los sistemas de alto riesgo: proveedores y responsables del despliegue deben conservar los registros generados automáticamente, en la medida en que estén bajo su control, durante al menos seis meses (art. 19, art. 26, apartado 6), salvo que el derecho de la Unión o el nacional dispongan otra cosa. Si un agente desencadena operaciones comerciales, como pedidos o pagos, a los justificantes contables y las cartas comerciales se les aplican además los plazos de conservación del derecho mercantil, en Austria siete años según el § 212 UGB. Estos registros son a la vez tu prueba ante los auditores de que el HITL funciona en la práctica.

Relación con la regulación (no es asesoramiento jurídico)

El Reglamento de IA de la UE exige en su artículo 14 una supervisión humana eficaz para los sistemas de IA de alto riesgo. El apartado 4, letra b), menciona expresamente el sesgo de automatización, es decir, justo el mecanismo que hay detrás de OWASP ASI09. Esta obligación de diseño recae en el proveedor: debe construir el sistema, incluida la interfaz persona-máquina, de forma que las personas encargadas de la supervisión puedan detectar el sesgo de automatización e intervenir. El responsable del despliegue debe designar, conforme al artículo 26, apartado 2, a personas encargadas de la supervisión con la competencia, la formación y la autoridad necesarias. Quien construye y utiliza sus propios agentes asume ambos roles.

Además, el BSI y la ANSSI francesa publicaron en agosto de 2025 el documento Design Principles for LLM-based Systems with Zero Trust. Trata, entre otros temas, la autenticación y la autorización, el sandboxing y la monitorización, y exige en los casos críticos el consentimiento del usuario como Human-in-the-Loop.

Nota: este artículo es una valoración técnica y no sustituye el asesoramiento jurídico. Debes aclarar con asesoramiento jurídico cualificado si tu sistema concreto se considera IA de alto riesgo en el sentido del Reglamento de IA de la UE y qué obligaciones se derivan de ello.

Para agencias y responsables de decisión B2B

Quien desarrolla agentes para clientes o los utiliza en su propia empresa debería tratar el HITL no como una funcionalidad añadida a posteriori, sino como una decisión de arquitectura. En concreto: una matriz acción-riesgo como parte de cada diseño de agente, aprobaciones escalonadas en lugar de autoaprobación generalizada, interfaces de force engagement contra el sesgo de automatización y registros de auditoría a prueba de manipulaciones desde el principio. Blck Alpaca, desde Viena, ayuda a empresas de toda Europa a diseñar flujos de trabajo agénticos en los que la autonomía y la supervisión humana estén en el equilibrio adecuado: seguros, demostrables y compatibles con el Reglamento de IA de la UE y el OWASP Agentic Top 10.