El control humano debe detener físicamente la acción
Lo que haría si la IA redactara una propuesta comercial, pusiera un descuento y la enviara al cliente. Separaría la preparación de la ejecución: el modelo propone, una persona confirma un payload concreto.
El error que eliminaría primero: Si la aprobación vive dentro de un workflow de larga duración, un timeout o un reinicio puede perder el estado. Es más fiable separar el guardado de la propuesta de la continuación tras la decisión.
Qué preparar y qué resultado esperar
- Resultado: El personal revisa solo los casos de alto riesgo y, tras una pausa, el workflow continúa desde el mismo punto.
- Define las acciones que requieren aprobación: enviar, reembolsar, borrar, publicar, cambiar permisos y operaciones financieras.
- Guarda los datos de origen y los derechos de acceso aparte del resultado para poder verificar qué hizo el workflow human-in-the-loop.
- Detén el escenario en la aprobación, rechaza la acción, apruébala unos minutos después y revisa el log.
Monta un flujo de aprobación que puedas verificar
- Separa la propuesta de la acción
La IA crea un draft_action, el workflow se lo muestra a una persona y un paso Execute separado solo se ejecuta tras el approve.
Проверьте: El botón de approve no solo cambia el estado: es la condición de ejecución.
Если не сработало: Quita la herramienta de escritura a la IA y déjala solo en la rama final.
- Persiste el estado
Registra run_id, action, payload, requester, approver, status y expires_at. Para una aprobación compleja, usa un nodo Wait o un webhook resume.
Проверьте: Tras una pausa puedes continuar el mismo run_id.
Если не сработало: Divide el workflow en start y resume en lugar de mantener un proceso largo en memoria.
- Muestra el contexto a una persona
La tarjeta de aprobación debe incluir la solicitud original, los datos encontrados, la propuesta de la IA, el riesgo y botones approve/reject/ask_more.
Проверьте: Se puede decidir sin buscar en cinco sistemas.
Если не сработало: Recorta la pantalla a los datos que cambian la decisión.
- Gestiona el rechazo y el timeout
Reject envía la tarea al owner o devuelve el borrador para editar. Un expires_at caducado no debe autoejecutar la acción.
Проверьте: Una solicitud rechazada nunca llega al cliente y es visible en el log.
Если не сработало: Añade una lista diaria de aprobaciones atascadas.
Estados que configuraría
Máquina de estados mínima: received → drafted → waiting_approval → approved/rejected → executed → failed. Guarda en el registro input_snapshot, proposed_action, reviewer_id, reviewed_at, rejection_reason y execution_id. Tras approved, el workflow vuelve a comprobar que la entrada no está obsoleta.
Para un email o un cambio en el CRM, divídelo en dos operaciones: la primera guarda el borrador y envía un botón de confirmación; la segunda ejecuta por approval_id. Así el proceso sobrevive a un reinicio y no reenvía.
- Reject debe explicar el motivo, no solo limpiar el estado.
- Si la confianza es baja, marca review_required en lugar de un bucle infinito de aclaraciones.
Qué debe haber en la pantalla de aprobación
Muestra el texto de origen, el resultado propuesto, los campos que cambiarán, un enlace a la fuente, el riesgo y botones approve/reject. Si una persona no entiende la decisión en un minuto, la pantalla está sobrecargada o la IA aportó demasiado poco contexto.
Dos cadenas en lugar de un workflow colgado
Workflow A: `Trigger → Get context → AI draft → Validate → proposal_id → action_hash → Save approval → Slack/Gmail`. Workflow B: `Approval webhook → Verify approver → Get proposal → Compare action_hash → Check expiry → Execute once → Audit log`.
Estados: `pending → approved/rejected/edited → executed/failed/expired`. En el registro guarda `proposal_id`, `target_id`, `payload`, `action_hash`, `state_version`, `approver_role`, `expires_at`, `rejection_reason` y `execution_id`.
{
"action": "send_quote",
"target_id": "deal_456",
"payload": {"amount": 150000, "discount": 10},
"requires_approval": true,
"expires_at": "2026-08-05T12:00:00Z"
}Qué debe ver una persona
Destinatario, importe, descuento, campos que cambiarán, vista previa del texto, fuente de datos y hora de caducidad. El botón no debe ejecutar la acción directamente desde la URL: solo pasa `proposal_id`, y el servidor recomprueba rol, hash y estado `executed`.
Dónde debe decidir una persona y dónde basta una regla
| Criterio | Pregunta | Buena señal |
|---|---|---|
| Entrada | ¿Qué entra exactamente en el workflow human-in-the-loop? | Define las acciones que requieren aprobación: enviar, reembolsar, borrar, publicar, cambiar permisos y operaciones financieras. |
| Acción | ¿Qué puede hacer el sistema por su cuenta? | Solo acciones prelistadas, sin acceso a toda la cuenta |
| Verificación | ¿Cómo sabes que el resultado es aceptable? | Detén el escenario en la aprobación, rechaza la acción, apruébala unos minutos después y revisa el log. |
| Fallo | ¿Adónde van los casos poco claros? | Persiste el estado en una tabla o base de datos y fija un plazo de escalado para que una aprobación atascada no se pierda. |
Qué debe cambiar después de la configuración
El personal revisa solo los casos de alto riesgo y, tras una pausa, el workflow continúa desde el mismo punto.
Por qué el “human in the loop” a menudo solo existe en palabras
Tratar la aprobación como una instrucción de texto en el prompt.
No guardar el estado entre el inicio y la confirmación.
Mostrar al personal solo el resultado sin la solicitud original.
Ejecutar automáticamente la acción tras un timeout.
Cuándo la aprobación necesita un estado aparte
Incorpora a un especialista si la aprobación implica dinero, actos jurídicos, varios roles o procesos largos con mucho estado.
Qué debe haber en la pantalla de confirmación
¿Para quién es este enfoque de workflow human-in-the-loop?
En un escenario de IA human-in-the-loop, el control humano no es una línea del prompt. El sistema debe detenerse, guardar el estado, mostrar la entrada y la propuesta de la IA, esperar una decisión y solo entonces ejecutar la acción.
¿Por dónde empiezas si todo sigue siendo manual?
Define las acciones que requieren aprobación: enviar, reembolsar, borrar, publicar, cambiar permisos y operaciones financieras.
¿Cómo compruebas que el setup no te va a perjudicar?
Detén el escenario en la aprobación, rechaza la acción, apruébala unos minutos después y revisa el log.
¿Y si el resultado no está claro?
Persiste el estado en una tabla o base de datos y fija un plazo de escalado para que una aprobación atascada no se pierda.
