Human-in-the-loop tiene mala prensa por una razón: cuando se implementa mal, convierte al humano en un cuello de botella burocrático. Cada paso pide aprobación, cada decisión trivial interrumpe al operador, y al final el proceso termina siendo más lento que antes de automatizar.
Cuándo un gate humano acelera
Un gate bien diseñado aparece solo donde el agente enfrenta ambigüedad real. Tres criterios claros para ubicar un gate:
- Irreversibilidad. Una acción que no se puede deshacer (pago, envío, borrado definitivo) merece validación humana. Una que sí se puede deshacer (actualizar un estado, enviar un draft), no.
- Montos o impacto. Acciones sobre operaciones de alto valor o alta exposición regulatoria deben pedir aprobación. Operaciones rutinarias bajo umbral, no.
- Ambigüedad detectada por el propio agente. Cuando el agente reporta baja confianza en su análisis, escala automáticamente. Esto solo funciona si el agente tiene una métrica de confianza confiable.
Cuándo un gate humano frena
Aparecen problemas cuando el gate se pone por defecto, por miedo, o porque "siempre se hizo así":
- Gates en pasos triviales (clasificar un email entrante) inflan latencia sin agregar valor.
- Gates que piden aprobación pero no muestran contexto obligan al humano a hacer el análisis desde cero. Es peor que la ejecución manual original.
- Gates sin SLA interno: el operador no sabe en cuánto tiempo tiene que responder, las tareas se acumulan, el cliente espera.
Cómo diseñar un gate que realmente funciona
Un gate útil hace tres cosas:
- Llega con toda la evidencia que usó el agente para proponer la decisión. El humano valida, no reconstruye.
- Permite responder en segundos: botones claros, decisión binaria o triádica (aprobar / editar / escalar).
- Aprende del feedback. Cuando el humano corrige la decisión del agente, ese caso se suma al dataset de evals.
Un buen diseño HITL no frena el flujo: lo auditorea, lo mejora y lo hace defendible. La alternativa es un sistema "autónomo" que nadie puede explicar cuando algo sale mal.