Human-in-the-loop es una máquina de estados, no un botón

El agente redactó un reembolso por $4,200. Apareció un modal: Aprobar o Rechazar. El operador estaba en una reunión. Veinte minutos después, el cliente ya había llamado a soporte dos veces. La solicitud de aprobación quedó en una cola sin timeout, sin escalamiento, sin auditoría de quién fue notificado y sin un default seguro cuando nadie respondió. Human-in-the-loop se implementó como un botón. Producción necesitaba una máquina de estados.

Human-in-the-loop (HITL) existe porque algunas acciones de agentes conllevan riesgo que supera los umbrales de ejecución autónoma — transacciones financieras, cambios de datos irreversibles, comunicaciones con clientes, operaciones privilegiadas. El patrón es sólido. La implementación suele no serlo: una interrupción de UI sin estados definidos, transiciones, timeouts ni modos de fallo. Eso no es gobernanza. Es una pausa que a veces nunca termina.

Un botón modela un momento; una máquina de estados modela un proceso

Enfoque	Qué cubre	Qué omite
Botón Aprobar/Rechazar	Punto de decisión único	Timeout, escalamiento, aprobación parcial, rollback
Notificación por email	Alertar a un humano	Respuesta estructurada, auditoría, idempotencia
Mensaje de Slack	Visibilidad rápida	Persistencia de estado, revisores concurrentes
Máquina de estados	Ciclo de vida completo	Requiere diseño previo

Una máquina de estados HITL trata cada acción con compuerta como una instancia de workflow con estados y transiciones explícitos:

pending_review
    ├─(approve)→ approved → executing → completed
    ├─(reject)→ rejected → cancelled
    ├─(timeout)→ escalated → pending_review (new assignee)
    ├─(timeout, no escalation target)→ auto_rejected | auto_approved (policy)
    └─(execute fails)→ failed → rollback_pending → rolled_back | manual_intervention

Cada transición registra: actor (humano o sistema), timestamp, razón, estado previo, hash del payload. La auditoría no es una feature aparte — es la tabla de transiciones.

Una cola de aprobación sin vencimiento es un ataque de denegación de servicio que el producto construyó contra sí mismo.

Estados que todo workflow HITL necesita

pending_review. Acción propuesta, ejecución bloqueada. Incluye: payload propuesto, score de riesgo, contexto del solicitante, pool de revisores asignado, expires_at, nivel de escalamiento.

approved / rejected. Decisiones humanas terminales. El rechazo debe capturar un código de razón — no solo texto libre — para mejora de modelo y política.

escalated. Timeout o sobrecarga provocaron reasignación. Registra quién fue omitido y por qué. Las rutas de escalamiento deben ser finitas — el escalamiento infinito es otra forma de quedarse atascado.

executing. Aprobación humana; efectos secundarios en curso. Evita doble ejecución si el revisor hace doble clic o reintentos de red disparan aprobaciones duplicadas.

completed / failed / rolled_back. Verdad post-ejecución. Una ejecución fallida con efectos secundarios parciales necesita estado de rollback — no "intentar de nuevo" sin reconciliación.

auto_resolved. Default impulsado por política cuando los humanos no responden. Debe ser explícito y raro: auto-rechazar acciones de alto riesgo, auto-aprobar bajo riesgo dentro de límites. Un auto-approve silencioso en acciones de alto riesgo es cómo los incidentes se vuelven titulares.

Timeouts y escalamiento no son pulido opcional

Sin expires_at, las revisiones pendientes se acumulan. Los workflows de agentes se bloquean. Los clientes esperan. Los operadores vuelven a un backlog de decisiones obsoletas con contexto desactualizado.

Diseñar timeouts por nivel de riesgo:

Nivel de riesgo	Acción de ejemplo	Timeout de revisión	Escalamiento	Default al agotarse
Bajo	Borrador de email, nota interna	4 horas	Canal del equipo	Auto-aprobar o auto-cancelar
Medio	Reembolso bajo umbral	30 minutos	Rotación on-call	Auto-rechazar
Alto	Borrado masivo, transferencia bancaria	15 minutos	Aprobador nombrado + backup	Auto-rechazar, alerta
Crítico	Cambio de config en producción	5 minutos	Pager	Auto-rechazar, bloquear acción

El escalamiento debe cambiar asignado y notificar — no solo reenviar la misma notificación a alguien que ya la está ignorando. Tras N niveles de escalamiento, alcanzar un estado terminal definido. "Sigue pendiente" no es un estado terminal.

El patrón de runbooks para agentes IA en producción cubre la respuesta operacional cuando los agentes fallan — HITL es la capa de prevención para acciones que no deberían fallar de forma autónoma en primer lugar.

Idempotencia y concurrencia evitan la doble ejecución

Dos operadores abren la misma aprobación. Ambos hacen clic en Aprobar. Sin idempotencia, el reembolso se ejecuta dos veces.

Requisitos:

• Token de aprobación ligado a un único ID de instancia de workflow.
• La transición de pending_review a approved es atómica — gana el primero, el segundo recibe "ya resuelto."
• Paso de ejecución idempotente frente a sistemas externos — API de pago con clave de idempotencia, upsert en base de datos con clave de deduplicación.
• Bloqueo optimista en el campo de versión de estado.

Revisión concurrente sin bloqueo es una condición de carrera disfrazada de colaboración.

Rollback y calibración de confianza pertenecen al mismo diseño

La aprobación humana no garantiza ejecución correcta. Las acciones aprobadas pueden fallar a mitad de camino. Los fallos parciales necesitan transiciones de rollback y notificación humana — no bucles de reintento silenciosos.

Calibración de confianza en UI de IA aborda cuánta autonomía conceden los usuarios a los agentes en la interfaz. Las máquinas de estados HITL implementan esa calibración en el workflow de backend: qué acciones requieren estados humanos, cuáles proceden de forma autónoma y qué ocurre en los límites. Los ajustes de confianza en frontend y las máquinas de estados en backend deben coincidir — una UI que muestra "auto" mientras el backend encola cada acción genera confusión en ambas direcciones.

¿Cómo deberían los equipos implementar human-in-the-loop?

Estas decisiones de diseño separan gobernanza en producción de interrupciones de demo.

¿Es human-in-the-loop lo mismo que workflows de aprobación?

Los workflows de aprobación son una instancia de HITL. HITL también incluye: edición humana antes de enviar, selección humana entre propuestas del agente, override humano de la clasificación del agente. Cada variante necesita estados — no toda variante requiere binario Aprobar/Rechazar.

¿Qué debería ocurrir cuando nadie responde?

Nunca dejar acciones en pending_review indefinidamente. Política explícita: auto-rechazar por defecto para acciones irreversibles o de alto valor; auto-aprobar solo para acciones de bajo riesgo bajo umbrales definidos con auditoría completa. Documentar la política donde los operadores puedan verla antes de perder un timeout.

¿Cómo interactúa HITL con los presupuestos de contexto del agente?

Las revisiones pendientes retienen estado del agente — resultados de herramientas, acciones propuestas, contexto de conversación. Períodos pendientes largos inflan los presupuestos de ventana de contexto cuando el agente reanuda. Preferir resumir el estado pendiente al reanudar en lugar de reproducir el transcript completo pre-aprobación.

Un argumento común va en la dirección opuesta

La visión opuesta sostiene que HITL anula el propósito de los agentes — que los sistemas autónomos deberían confiarse o no desplegarse, y que las compuertas de aprobación crean cuellos de botella peores que el riesgo que previenen.

Los cuellos de botella vienen de botones sin máquinas de estados, no de HITL en sí. Un HITL bien diseñado auto-resuelve rutas de bajo riesgo al instante, enruta riesgo medio a revisión asíncrona y bloquea solo acciones genuinamente de alto riesgo. Eso es más rápido que recuperarse de errores autónomos en producción.

La autonomía plena sin HITL es válida para dominios de solo lectura o fácilmente reversibles. La máquina de estados sigue existiendo — solo que no tiene transiciones pending_review.

Key takeaways

• Human-in-the-loop es una máquina de estados: pending, approved, rejected, escalated, executing, completed, failed, rolled back.
• Botones Aprobar/Rechazar sin timeouts crean bloqueos indefinidos y decisiones obsoletas.
• Las rutas de escalamiento deben ser finitas con defaults terminales explícitos.
• Las transiciones idempotentes evitan doble ejecución por aprobadores concurrentes.
• Auditar cada transición de estado — actor, timestamp, razón, hash del payload.
• Alinear estados HITL de backend con ajustes de calibración de confianza en frontend.

Conclusion

El teatro de seguridad pone a un humano en la captura de pantalla. HITL en producción pone humanos en un workflow con finales definidos — qué ocurre cuando aprueban, rechazan, ignoran o se desconectan. La máquina de estados es la diferencia entre gobernanza y un modal que nunca se cierra.

La auditoría para productos de agentes existentes: listar cada acción que espera input humano. Para cada una, documentar estado actual, timeout, escalamiento y default cuando nadie responde. Las celdas vacías son el roadmap de implementación.