Human-in-the-loop: cuándo debe decidir una persona en un flujo de IA
Human-in-the-loop es un diseño donde una persona aprueba, corrige o interrumpe el trabajo de un sistema de IA en puntos definidos. Cuándo ponerla, dónde y cómo.
¿Por qué un agente necesita una persona?
Un agente puede ejecutar cadenas de acciones: leer archivos, llamar herramientas, escribir cambios, enviar mensajes. Cada paso puede parecer razonable y el conjunto, en cambio, puede salirse de lo que la persona quería. Un modelo puede equivocarse con seguridad, y no siempre sabe cuándo se equivocó.
La persona aporta lo que el sistema no tiene: el contexto de la relación con el cliente, la tolerancia al riesgo del equipo, la información que no está en los archivos y el criterio sobre lo que es aceptable. Human-in-the-loop es la forma de meter ese criterio en el flujo sin frenar todo.
Hay una distinción útil entre dos tipos de intervención. La aprobación ocurre antes de una acción, y la persona puede impedirla. La revisión ocurre después, y la persona puede corregir o deshacer. Cada una exige diseño distinto.
¿Dónde poner la intervención?
No todos los pasos merecen una pausa. Un criterio práctico es mirar tres cosas de cada acción:
- ¿Es reversible? Leer un archivo o generar un borrador en memoria se puede tirar a la basura. Enviar un correo o borrar datos, no.
- ¿Tiene efecto fuera del sistema? Una acción que llega a un cliente, a un pago o a un sistema ajeno merece control.
- ¿El sistema puede verificar su propio resultado? Si un test o una regla confirma el resultado, la revisión humana puede ser por muestreo. Si nada lo confirma, la persona debe revisar.
Con esos tres criterios sale un mapa simple: lo reversible y sin efectos corre solo; lo irreversible o externo se aprueba; lo que nadie puede verificar se revisa.
¿Cómo se implementa la pausa?
Un sistema con human-in-the-loop necesita tres piezas:
- Detención. La ejecución se pausa cuando llega a un punto de control, sin continuar por inercia.
- Estado guardado. La tarea queda con su contexto, sus herramientas y la acción pendiente, para retomarla después.
- Decisión registrada. La aprobación o el rechazo quedan asociados a la acción, con quién decidió y cuándo.
El SDK de agentes de OpenAI documenta este flujo: cuando una herramienta requiere aprobación y no hay decisión guardada, la ejecución se pausa y devuelve las interrupciones pendientes. La aplicación aprueba o rechaza cada una y reanuda desde ese estado. Marcar una herramienta como que requiere aprobación puede ser fijo o decidirse por llamada, y si no se pueden inspeccionar los argumentos con seguridad, el SDK pide aprobación manual. La documentación advierte que restaurar el estado serializado no autentica al revisor, así que la aprobación debe validarse en el servidor: autenticar a quien decide, comprobar que está autorizado para esa ejecución y evitar reanudaciones repetidas o simultáneas. También aclara que aprobar no garantiza que la acción se ejecute exactamente una vez: si hay una caída después de que la herramienta actuó y antes de guardar el estado, al reanudar la acción puede repetirse, por lo que conviene usar claves de idempotencia en las herramientas con consecuencias.
Claude Code aplica una idea parecida con sus modos de permiso. En el modo Manual (default), pide confirmación antes de la mayoría de las acciones que editan archivos, ejecutan comandos de shell o acceden a la red, y solo lee archivos sin preguntar. Otros modos mueven el control: acceptEdits deja pasar las ediciones, y en auto un clasificador revisa las acciones en lugar de la persona. Cada modo es una decisión sobre dónde poner la pausa.
¿Cuándo NO conviene una persona en el circuito?
- En tareas de bajo riesgo y totalmente reversibles, como formatear texto o clasificar notas. Una pausa ahí solo cuesta tiempo y paciencia.
- Cuando hay tantas pausas que la persona aprueba sin mirar. Ese es el peor escenario: control aparente sin control real. Si la persona aprueba el noventa por ciento sin leer, reduce los puntos y mejora lo que se muestra.
- Cuando la pausa llega tarde. Pedir aprobación después de que la acción ya ocurrió no es control, es notificación.
Human-in-the-loop es el marco; cada punto de control tiene su propia página. La parte de aprobar una acción concreta está en aprobación de acciones de un agente, y cómo se presentan los permisos en pantalla, en UX de permisos para agentes. Cuando la decisión debe pasar a alguien del equipo, el handoff de IA a humano describe ese traspaso. Y los límites técnicos que contienen al agente, aunque nadie apruebe nada, están en sandboxing y permisos.
Ejemplo
Ejemplo ilustrativo: un agente ayuda a un equipo de soporte a responder tickets. Puede leer el historial, redactar respuestas y etiquetar casos sin pausa, porque nada sale todavía. Antes de enviar una respuesta al cliente, o de cerrar un ticket con reembolso, el agente se detiene y muestra la acción pendiente con su justificación.
Una semana después, el equipo nota que el agente pide aprobación para cada etiqueta, y que los revisores aceptan casi todo. Quitan la pausa de las etiquetas, dejan la del envío y la del reembolso, y agregan una muestra semanal de respuestas automáticas para revisar. El control queda donde el riesgo está.
¿Cómo medir si el control funciona?
Cada mes, pregunta tres cosas: qué porcentaje de las aprobaciones se acepta sin cambios, cuántos errores se detectaron en revisión y cuántos llegaron al cliente o al sistema externo. Si casi todas las aprobaciones se aceptan y ningún error se detecta antes de salir, el control es decorativo. Si se rechazan muchas, el agente necesita mejores planes, no más preguntas.
Errores comunes
- Poner la pausa en todos los pasos y terminar con aprobaciones automáticas.
- Pedir aprobación después de que la acción ya tuvo efecto externo.
- Mostrar a la persona una acción sin el contexto para decidir.
- No registrar quién aprobó qué y cuándo.
- Confiar en la serialización del estado sin validar en el servidor quién puede aprobar.