Phase 15 - Lesson 15

Human-in-the-Loop: Propose-Then-Commit

El consenso de 2026 sobre HITL es específico. No es "el agente pregunta, el usuario hace clic en Aprovar". Es proponer y confirmar (propose-then-commit): la acción propuesta se persiste en un almacenamiento duradero con una clave de idempotencia; se presenta a un revisor con intención, linaje de datos (data lineage), permisos afectados, radio de impacto (blast radius) y un plan de rollback; se confirma (committed) solo tras un reconocimiento positivo; y se verifica después de la ejecución para confirmar que el efecto secundario realmente ocurrió. interrupt() de LangGraph con checkpointing de PostgreSQL, RequestInfoEvent de Microsoft Agent Framework y waitForApproval() de Cloudflare implementan exactamente el mismo esquema. El modo de falla canónico es la aprobación automatizada (rubber-stamp): se hace clic en "¿Aprobar?" sin revisión alguna. La mitigación documentada es el desafío y respuesta con una lista de verificación (checklist) explícita.

Tipo: Aprender Lenguajes: Python (stdlib, máquina de estado de proponer y confirmar con idempotencia) Prerrequisitos: Fase 15 · 12 (Ejecución duradera), Fase 15 · 14 (Tripwires) Tiempo: ~60 minutos

El Problema

Un agente realiza una acción. El usuario debe decidir: aprobar o no. Si la decisión es instantánea, probablemente no se trate de una revisión. Si la decisión es estructurada, es lenta pero confiable. La pregunta de ingeniería es cómo hacer que una revisión estructurada sea el camino de menor resistencia.

El patrón HITL de la era de 2023 era un prompt síncrono: "El agente quiere enviar un correo electrónico a X con el cuerpo Y —¿aprobar?". El usuario hace clic en Aprobar. Todos sienten que el sistema es seguro. En la práctica, esta interfaz es aprobada de forma automatizada (rubber-stamped): los usuarios aprueban rápido, las aprobaciones predicen poco y, cuando el agente falla, el registro de auditoría muestra un largo historial de aprobaciones que el usuario no puede recordar.

El patrón de 2026 —proponer y confirmar (propose-then-commit)— traslada el HITL a un sustrato duradero, adjunta metadados estructurados y requiere una confirmación positiva. Cada SDK de agente administrado incluye una versión: interrupt() de LangGraph, RequestInfoEvent de Microsoft Agent Framework, waitForApproval() de Cloudflare. Los nombres de las API difieren; el esquema no.

El Concepto

La máquina de estados de proponer y confirmar (propose-then-commit)

Proponer (Propose). El agente produce una acción propuesta. Se persiste en un almacenamiento duradero (PostgreSQL, Redis, Durable Object). Incluye:
- intención (por qué el agente está haciendo esto)
- linaje de datos (qué fuente llevó a esta propuesta)
- permisos afectados (qué alcances / archivos / endpoints)
- radio de impacto (cuál es el peor de los casos)
- plan de rollback (si se confirma, cómo lo deshacemos)
- clave de idempotencia (única por propuesta; el reenvío devuelve el mismo registro)
Presentar (Surface). El revisor ve la propuesta con todos los metadados. El revisor es una persona (not el agente revisándose a sí mismo).
Confirmar (Commit). Reconocimiento positivo. La acción se ejecuta.
Verificar (Verify). Después de la ejecución, el efecto secundario se vuelve a leer y se confirma. Si el paso de verificación falla, el sistema queda en un estado erróneo conocido y se activan las alertas.

La clave de idempotencia

Sin una clave de idempotencia, un reintento tras una falla transitoria puede ejecutar dos veces una acción aprobada. Ejemplo concreto: el usuario aprueba "transferir

00 de A a B". La red experimenta parpadeos. El workflow reintenta. El usuario aprobó una sola vez, pero la transferencia se ejecuta dos veces. La clave de idempotencia vincula la aprobación a un único efecto secundario exclusivo; la segunda ejecución se convierte en una operación sin efecto (no-op).

Este es el mismo patrón de idempotencia que utilizan las API de Stripe y AWS. Reutilizarlo para aprobaciones de agentes es explícito en la documentación de Microsoft Agent Framework.

Durabilidad: por qué las aprobaciones sobreviven a los procesos

La sala de espera de aprobación es un fragmento de estado que el agente no posee. El workflow se pausa (Lección 12). Cuando llega la aprobación, el workflow se reanuda exactamente desde ese punto. Esta es la razón por la cual LangGraph asocia interrupt() con checkpointing de PostgreSQL y no solo con el estado en memoria; una aprobación dos días después todavía encuentra el workflow intacto.

Aprobaciones automatizadas (rubber-stamp) y la mitigación mediante desafío y respuesta

La interfaz de usuario predeterminada para HITL (botones "Aprobar" / "Rechazar") produce aprobaciones rápidas sin una revisión real. Mitigación documentada: una lista de verificación de desafío y respuesta que requiere respuestas afirmativas a preguntas específicas antes de habilitar el botón Aprobar. Esquema concreto:

"¿Entiende qué recurso afecta esto? [ ]"
"¿Ha verificado que el radio de impacto es aceptable? [ ]"
"¿Tiene un plan de rollback si esto falla? [ ]"

No es burocracia por el simple hecho de serlo, sino una función de inducción (forcing function). El revisor que no puede marcar las casillas debe solicitar una aclaración (escalamiento) o rechazar (valor seguro predeterminado). La investigación de seguridad de agentes de Anthropic cita explícitamente el HITL guiado por listas de verificación como una mitigación para los patrones de aprobación automatizada (rubber-stamp).

Qué se considera consecuente

No todas las acciones necesitan proponer y confirmar. La guía de 2026 establece:

Acciones consecuentes (siempre HITL): escrituras irreversibles, transacciones financieras, comunicación saliente, cambios en la base de datos de producción y operaciones destructivas en el sistema de archivos.
Acciones reversibles (a veces HITL): ediciones de archivos locales, cambios en el entorno de pruebas (staging) y escrituras reversibles con rollback claro.
Lecturas e inspecciones (nunca HITL): leer un archivo, listar recursos, llamar a una API de solo lectura.

Verificación posterior a la acción

"Que se haya ejecutado la confirmación (commit)" no es lo mismo que "que haya ocurrido el efecto secundario". Las particiones de red y las condiciones de carrera pueden producir un workflow que cree haber tenido éxito mientras que el backend no persistió el cambio. El paso de verificación vuelve a leer el recurso de destino después de confirmar para asegurarlo. Este es el mismo patrón que las transacciones de base de datos con cláusulas RETURNING o GetObject de AWS después de PutObject.

Artículo 14 de la Ley de IA de la UE (EU AI Act)

El Artículo 14 exige una supervisión humana eficaz para los sistemas de IA de alto riesgo en la UE. "Eficaz" no es decorativo. El lenguaje regulatorio excluye específicamente los patrones de aprobación automatizada (rubber-stamp). Proponer y confirmar con desafío y respuesta es el esquema que supera el escrutinio del Artículo 14 en los documentos de conformidad de Microsoft Agent Governance Toolkit.

Úselo

code/main.py implementa una máquina de estados de proponer y confirmar en Python estándar (stdlib). El almacenamiento duradero es un archivo JSON. La clave de idempotencia es un hash de (thread_id, action_signature). El controlador simula tres casos: un flujo de aprobación limpio, un reintento tras una falla transitoria (que no debe ejecutarse dos veces) y una aprobación automatizada por defecto frente a un flujo de desafío y respuesta.

Envíelo a Producción

outputs/skill-hitl-design.md revisa un flujo de trabajo HITL propuesto para comprobar el esquema de proponer y confirmar y señala capas faltantes de metadatos, idempotencia, verificación o desafío y respuesta.

Ejercicios

Ejecute code/main.py. Confirme que un reintento de una propuesta aprobada utiliza el registro duradero y no se vuelve a ejecutar. Ahora cambie la clave de idempotencia para que incluya una marca de tiempo (timestamp) y muestre que el reintento se ejecuta dos veces.
Extienda el registro de la propuesta con un campo rollback. Simule una ejecución cuyo paso de verificación falle. Muestre el rollback activándose automáticamente.
Lea la documentación de RequestInfoEvent de Microsoft Agent Framework. Identifique un campo de metadados que incluya la API y que le falte a nuestro motor simplificado. Agréguelo y explique contra qué protege.
Diseñe una lista de verificación de desafío y respuesta para una acción específica (por ejemplo, "publicar en una cuenta pública de Twitter"). ¿Qué tres preguntas debe responder el revisor? ¿Por qué esas tres?
Elija un caso en el que un prompt síncrono de "¿Aprobar?" sería suficiente (sin necesidad de almacenamiento duradero). Explique por qué y mencione el tipo de riesgo que está aceptando.

Términos Clave

Término	Lo que la gente dice	Lo que realmente significa
Propose-then-commit	"Aprobación en dos fases"	Propuesta persistida + confirmación positiva + verificación
Idempotency key	"Token seguro contra reintentos"	Única por propuesta; la segunda ejecución no tiene efecto (no-op)
Data lineage	"De dónde vino"	El contenido de origen específico que condujo a la propuesta
Blast radius	"Peor de los casos"	Alcance del efecto si la acción sale mal
Rubber-stamp	"Aprobación rápida"	Hacer clic en "Aprobar" sin una revisión real
Challenge-and-response	"Lista de verificación obligatoria"	El revisor debe responder positivamente a preguntas específicas
RequestInfoEvent	"Primitiva de MS Agent Framework"	Solicitud duradera de HITL con metadados estructurados
`interrupt()` / `waitForApproval()`	"Primitivas de frameworks"	Equivalentes en LangGraph / Cloudflare de la misma estructura

Lecturas Adicionales

Microsoft Agent Framework — Human in the loop — RequestInfoEvent, aprobaciones duraderas.
Cloudflare Agents — Human in the loop — waitForApproval() and Durable Objects.
Anthropic — Measuring agent autonomy in practice — HITL como mitigación para el riesgo de largo plazo.
EU AI Act — Article 14: Human oversight — base regulatoria para sistemas de alto riesgo.
Anthropic — Claude's Constitution (January 2026) — marco constitucional sobre la supervisión.