Humano en el loop se volvió la respuesta por defecto a cualquier duda sobre agentes de IA. ¿El agente puede equivocarse? Pon a un humano aprobando. ¿Legal está incómodo? Humano aprobando. El problema es que esa respuesta suele diseñarse como un botón de "aprobar" en cada acción, y un botón que se aprieta 200 veces al día deja de ser control. Se vuelve ritual. La persona aprueba porque el agente casi siempre acierta, y el día en que se equivoca, también aprueba.
El mercado lo está descubriendo en la práctica. Una encuesta de VentureBeat Intelligence publicada en octubre de 2026, con 140 encuestados, mostró que la proporción de empresas con agentes en producción que esperan mantener revisión humana en el futuro previsible subió del 20% en julio al 42% en agosto. En la misma muestra, el 61% de quienes usan evaluación previa a producción reportó al menos una falla visible para el cliente después de que el agente pasara las pruebas internas. Las empresas quieren más humano en el loop. La cuestión es si ese humano va a decidir algo.
Por qué aprobar cada acción se vuelve un sello automático
Aprobar todo parece el diseño más seguro, y es el que más falla. Tres mecanismos lo explican.
Fatiga de aprobación. Cuando el 98% de las solicitudes son correctas, el revisor aprende que aprobar es el comportamiento correcto. Tras unas semanas, lee el título, no el contenido. La revisión sigue registrada en el log, pero la atención ya no está ahí. Es el mismo fenómeno de la alarma de hospital que suena demasiado: nadie corre.
Sesgo de automatización. Las personas tienden a aceptar lo que propone un sistema automatizado, sobre todo cuando suena seguro y bien formateado. Un agente que escribe su justificación con tono confiado vuelve el rechazo socialmente más caro para quien revisa. El artículo de TechTarget de junio de 2026 sobre el tema resume el diagnóstico de los analistas consultados: revisar grandes volúmenes de salida de IA no compromete cognitivamente a nadie.
Revisor sin contexto. Muchas pantallas de aprobación muestran la acción ("enviar correo al cliente X", "aplicar descuento del 12%") sin mostrar el porqué: qué datos usó el agente, qué política invocó, qué pasa si la acción está mal. Sin eso, el humano no tiene base para discrepar. Solo puede confiar o bloquearlo todo.
Una aprobación que nunca se rechaza no es control; es una demora con firma.
Dónde debe entrar el humano en el loop de un agente
La pregunta útil no es "¿el agente necesita un humano?", sino "¿qué acciones lo necesitan?". Dos ejes resuelven la mayoría de los casos: reversibilidad (¿se puede deshacer en minutos y sin costo?) e impacto (¿cuánto cuesta el error en dinero, clientes o cumplimiento?).
Al cruzarlos salen cuatro franjas de tratamiento:
- Reversible y bajo impacto: el agente actúa solo. Clasificar un ticket, redactar una respuesta interna, actualizar un campo de estado. El control aquí es observabilidad y muestreo posterior, no aprobación previa.
- Reversible y alto impacto: el agente actúa, un humano revisa después. Reprogramar una entrega, cambiar la prioridad de un caso. El agente ejecuta, la acción entra en una cola de revisión con plazo y el humano corrige si hace falta. Es lo que algunos llaman human on the loop.
- Irreversible y bajo impacto: el agente actúa dentro de un límite fijo. Enviar un mensaje estándar, emitir un cupón de bajo valor. El control es un tope codificado (valor, cantidad, frecuencia), no un humano.
- Irreversible y alto impacto: un humano aprueba antes. Reembolso por encima de un monto, cambio contractual, eliminación de datos, comunicación fuera de plantilla. Solo aquí la aprobación previa tiene sentido y, justamente por ser rara, tiende a leerse.
Es la misma lógica que usamos al analizar cuándo Agentforce Commerce puede vender sin humano en el loop: ticket bajo y SKU estándar toleran autonomía; excepción de precio y contrato piden aval. El criterio cambia de dominio, pero la matriz se repite.
Un punto que suele pasar desapercibido: el límite de la franja 3 solo existe de verdad si el agente no tiene permiso técnico para superarlo. Un tope escrito en el prompt es una sugerencia. Un tope aplicado en la credencial y en el alcance de la herramienta es control, como detallamos al hablar de identidad propia para el agente de IA en lugar de un login prestado.
Cómo diseñar una aprobación que alguien realmente lea
Una vez decidido dónde entra la aprobación, el diseño de la aprobación misma define si funciona. La secuencia que aplicamos en proyectos:
- Muestra la decisión, no solo la acción. La pantalla de aprobación trae lo que el agente quiere hacer, los datos que usó, la regla o política en que se basó y el efecto si está mal. Si el revisor tiene que abrir tres sistemas para entenderla, va a aprobar sin abrirlos.
- Haz que rechazar sea barato. Rechazar tiene que ser tan rápido como aprobar, con un motivo de un clic ("dato desactualizado", "fuera de política", "cliente sensible"). Un rechazo caro se vuelve aprobación por cansancio.
- Limita el volumen por revisor. Si un analista recibe más aprobaciones al día de las que puede leer con atención, el diseño falló. Una referencia práctica nuestra (estimación, no benchmark de mercado): por encima de 30 a 50 aprobaciones por persona al día, la calidad de la revisión cae de forma visible.
- Nombra quién aprueba qué. La aprobación de reembolsos es de finanzas; la comunicación al cliente, del dueño del proceso. Una cola genérica "para el equipo" no tiene dueño y se acumula.
- Define qué pasa ante el silencio. Si nadie aprueba en X horas, ¿la acción expira, escala o sigue? Para acciones de la franja 4, el silencio nunca debe significar "aprobado".
- Inserta casos de prueba. De vez en cuando, pon en la cola una acción deliberadamente errónea y mira si se rechaza. Es la forma más directa de saber si el revisor está leyendo.
Tasa de rechazo: la métrica que muestra si la revisión es real
Todo flujo con humano en el loop debería publicar un número: la tasa de rechazo o edición de las acciones enviadas. Dice más sobre la salud del control que cualquier política escrita.
Una tasa cercana a cero durante semanas tiene dos lecturas posibles. O el agente es tan bueno en esa acción que la aprobación previa se volvió desperdicio y debe bajar de franja, o el revisor dejó de mirar. Los casos de prueba del paso 6 separan una lectura de la otra. Una tasa alta y estable indica lo contrario: el agente no está listo para esa acción y el humano está haciendo el trabajo que debería hacer el agente.
El movimiento sano es que la acción baje de franja con el tiempo, con evidencia. Empieza en la franja 4, acumula semanas de historial con tasa de rechazo baja y casos de prueba detectados, y pasa a la franja 2 con revisión posterior por muestreo. Ese historial es el argumento para darle más autonomía al agente, y solo existe si la revisión se midió desde el principio. Es el mismo principio de reservar al humano para los casos de frontera cuando un LLM evalúa a otro: la atención humana es un recurso escaso y debe ir adonde la máquina duda o el error cuesta caro.
La autonomía de un agente se gana acción por acción, con historial de revisión medido, nunca por decreto.
Qué cambia en la gobernanza del agente
Tratar al humano en el loop como diseño, y no como botón, tiene consecuencias organizacionales. Alguien tiene que ser dueño de la matriz de franjas, revisarla cuando el agente gana herramientas nuevas y responder por la tasa de rechazo como por cualquier indicador operativo. Sin eso, la matriz se congela el día del go-live y el agente gana permisos sin que ninguna acción cambie de franja.
La ganancia es doble. El riesgo baja en las acciones que importan, porque la atención humana deja de diluirse en cientos de aprobaciones triviales. Y el agente entrega más valor, porque las acciones de bajo riesgo dejan de esperar en una cola que nadie lee con atención. Un humano en el loop bien diseñado decide menos veces y decide de verdad.
Preguntas que siempre vuelven
Dudas comunes de quienes están llevando agentes de IA a producción con aprobación humana.
¿Qué es humano en el loop en agentes de IA?
Humano en el loop (human-in-the-loop) es el punto del flujo en que el agente de IA se detiene y espera que una persona apruebe, corrija o rechace una acción antes de ejecutarla. Se diferencia del humano on the loop, en el que el agente actúa y la persona revisa después, con poder para corregir. Ambos son controles válidos, para franjas de riesgo distintas.
¿Toda acción de un agente necesita aprobación humana?
No, y exigir aprobación en todo suele reducir la seguridad en lugar de aumentarla. La aprobación previa tiene sentido para acciones irreversibles y de alto impacto; las acciones reversibles o de bajo impacto funcionan mejor con límites técnicos, revisión posterior por muestreo y observabilidad. Concentrar la aprobación en lo que importa es lo que mantiene atento al revisor.
¿Cómo saber si la aprobación humana se volvió un sello automático?
Sigue la tasa de rechazo o edición de las acciones enviadas e inserta periódicamente casos deliberadamente erróneos en la cola. Si la tasa queda cerca de cero y los casos de prueba se aprueban, la revisión se volvió un sello automático. Si los casos de prueba se rechazan y la tasa sigue baja, la acción puede bajar de franja y ganar autonomía.