Human-in-the-loop, cuándo no automatizar todo

La pregunta detrás de la pregunta

Has construido un agente que resuelve tareas. En algún momento aparece la pregunta: ¿lo dejas correr, o tiene que preguntar en ciertos pasos? Respuesta: depende. ¿Pero de qué exactamente? Eso es esta lección.

Los tres modos

Hay tres modos operativos para cualquier agente:

1. Autonomía total. El agente decide, ejecuta, informa después. Sin paso de aprobación.
2. Draft-first. El agente crea un borrador, lo deja para tu aprobación, ejecuta solo tras "sí".
3. Pausa ante incertidumbre. El agente corre autónomo por defecto pero se detiene si nota que está inseguro o que la decisión es demasiado grande.

El error de principiante es construirlo todo en modo 1 porque parece más rápido. El error de paranoico es construirlo todo en modo 2 porque parece seguro. Lo correcto: decidir por acción. No por agente.

El criterio de reversibilidad

La única regla que funciona: cuanto más difícil deshacer una acción, antes tiene que mirarla un humano.

• Fácil de deshacer: borrador de email. Una nota. Investigación cruda. Renombrar archivo en una carpeta de trabajo. → Autonomía total OK.

• Medio reversible: entrada de calendario. Un borrador de post en cola. Una fila de BD en tu propio sistema con botón de undo. → Autonomía OK, pero construir undo o loguear eventos.

• Difícil de deshacer: enviar email a clientes. Lanzar un pago. Subir archivo a dominio público. Borrar entradas de BD sin backup. Llamada API externa que cuesta dinero. → Siempre draft-first. Siempre paso de aprobación.

• Imposible de deshacer: post público en LinkedIn. Transferencia. Firma de contrato con cliente. Migración de schema en BD. → Principio de cuatro ojos. Idealmente agente crea, humano revisa, segundo humano confirma. Si trabajas solo: draft-first con buffer de tiempo ("releer mañana").

Cómo se ve el paso de aprobación en la práctica

El agente no escribe su borrador directamente fuera, sino a una cola. Tú ves la cola en un sitio que visitas regularmente (inbox, página de Notion, UI web dedicada). Haces clic en "Enviar" o "Descartar". Solo tras tu clic se ejecuta.

Suena costoso pero no lo es. La pérdida de tiempo es pequeña. La ganancia de confianza es grande. Y de paso entrenas a tu agente, porque en cada rechazo puedes decir por qué y la siguiente corrida es mejor.

Cuándo el agente mismo debe pausar

Incluso en acciones de la categoría "fácil de deshacer", el agente debería detenerse cuando:

• Ve una decisión no claramente cubierta por sus instrucciones.
• Nota que trabaja con datos que no puede identificar de forma única (p. ej. "qué cliente se refiere, hay tres Pérez").
• Un paso antes funcional empieza a lanzar un error inesperado.
• Va a hacer un cambio externo que no puede deshacer él mismo.

No es un déficit. Es el indicador de un agente maduro.

El anti-patrón a evitar

Nada peor que un agente que pregunta por cada nimiedad. "¿Pongo el asunto del email como 'Update' o 'Informe semanal'?" Eso no es human-in-the-loop, son simplemente instrucciones poco específicas. El agente debería poder decidirlo solo, le has dado un rol, lo cumple.

Preguntar es legítimo en: riesgo, ambigüedad real (no forzada), influencia externa (ventana caducada, fuente no accesible). Preguntar es malo en: detalles que el agente puede derivar solo.

Regla: si asientes con cada pregunta de mala gana, tu agente necesita calibración. Sube la autonomía. Si en cambio te alegras de que te haya preguntado y la decisión era importante, exactamente bien.

Dos ejemplos prácticos

Agente de email para consultas de cliente. Lee mails entrantes, clasifica, escribe borrador de respuesta. Modo: draft-first. El agente no responde solo, deja la respuesta en "Borradores". Lees por la mañana, das clic a lo que sale. El agente nunca envía solo, porque nunca quieres mandar un email IA vergonzoso a un cliente sin revisar.

Agente de búsqueda para research. Recopila material sobre un tema. Modo: autonomía total. Puede abrir webs, leer PDFs, recoger citas y devolver informe. El daño si lee algo equivocado es cero, la ganancia de tiempo es grande. Revisas el output, no el proceso.

Misma arquitectura, ajustes completamente distintos. Porque las acciones son críticamente diferentes.

Por qué legal también lo quiere así

EU AI Act, artículo 14, exige supervisión humana en sistemas "high-risk". Qué cuenta como "high-risk" es otro capítulo. Pero la lógica del artículo es exactamente esto: en decisiones de gran alcance debe poder mirar un humano. No cuestión técnica, requisito legal.

Es decir: si construyes un agente que toma decisiones sobre personas en el ámbito PYME (candidaturas, despidos, credit scoring), human-in-the-loop no es opcional. Es obligatorio. Y debe estar documentado.

Cómo empezar hoy

Repasa tus agentes existentes, o los procesos donde quieras construir uno. Por proceso:

• Lista las acciones individuales que hará el agente.
• Valora cada una en la escala de reversibilidad (fácil / medio / difícil / nada).
• Para todo lo "difícil" o "nada": draft-first.
• Para "fácil": autonomía total OK.
• Para "medio": mecanismo de undo o log de eventos.

Son diez minutos por agente y te ahorran tres meses después una situación incómoda.

Sigue

La Lección 4 del Nivel 6 profundiza en el deployment de agentes y servers, incluida la mecánica técnica detrás de los loops de aprobación. Y en el blog de la Academy (cuando leas esto) hay también un artículo sobre cómo construimos human-in-the-loop en nuestro propio agent fleet en StudioMeyer.