Human-in-the-Loop (HITL)

1. Visión general del concepto y problema sistémico

La plena autonomía de los agentes (Fully Autonomous Agents) enfrenta una limitación fundamental: la indeterminación de los grandes modelos de lenguaje. Incluso si el modelo muestra una precisión del 98%, la probabilidad acumulativa de error en una cadena de ejecución de 20 pasos se aproxima al 33%. Si un agente tiene acceso directo al shell del sistema, bases de datos de producción, APIs financieras o infraestructura en la nube, un solo fallo o alucinación puede resultar en la pérdida de datos o pérdidas millonarias.

Human-in-the-Loop (HITL) es un principio arquitectónico para construir sistemas de agentes confiables. En lugar de confiar ciegamente en la máquina para todo el proceso de principio a fin, el sistema se diseña de tal manera que las acciones más arriesgadas requieren verificación consciente por parte de un humano. HITL combina la velocidad del trabajo de la inteligencia artificial con la responsabilidad y el juicio contextual de un ingeniero senior.

2. Taxonomía arquitectónica y modelo mental

La arquitectura HITL se divide en tres modelos clave de interacción según el protocolo y la criticidad:

┌─────────────────────────────────────────────────────────────┐
│                 HITL INTERACTION TAXONOMY                   │
├─────────────────────────────────────────────────────────────┤
│ 1. Synchronous CLI Gate (Block on STDIN: [y/N] Prompt)      │
│    Herramientas locales de desarrollador (Claude Code, Cline)│
├─────────────────────────────────────────────────────────────┤
│ 2. Asynchronous Durable Gate (State Checkpointing / Webhook)│
│    Cadenas de procesos prolongados (LangGraph, Temporal, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Escalation & Tiered RBAC Policy                          │
│    • Read-only ➔ Auto-approved (Nivel 0)                    │
│    • Local Mutate ➔ Dev approved (Nivel 1)                  │
│    • Production / Money ➔ Lead / Multi-sig approved (Nivel 2)│
└─────────────────────────────────────────────────────────────┘

1. Barreras locales sincrónicas (Synchronous Approval):
   • Utilizadas en agentes CLI e IDE. El agente bloquea el flujo de ejecución, muestra en consola el comando shell planeado o diff y espera la pulsación de una tecla por parte del usuario.
2. Barreras duraderas asincrónicas (Durable Asynchronous Gate):
   • Utilizadas en agentes de backend. Al alcanzar un punto crítico, el agente guarda su estado de trabajo en la base de datos (Checkpointer), genera un evento (por ejemplo, un mensaje en Slack o un correo electrónico con botones de "Aprobar" / "Rechazar") y se pone en espera.
3. Matriz granular de permisos (Tiered Action Policies):
   • Las acciones se clasifican según el nivel de riesgo potencial (Blast Radius). Las operaciones seguras no requieren aprobación, mientras que las operaciones irreversibles requieren una aprobación en múltiples niveles.

3. Pipeline técnico y mecánica interna

El ciclo de vida de un proceso asincrónico con participación humana (ejemplo con LangGraph):

1. Ejecución de pasos hasta el punto de control: El agente analiza la solicitud, formula un plan y realiza cálculos preparatorios (por ejemplo, genera una consulta SQL para migrar datos).
2. Intercepción de herramientas (Tool Interceptor): La capa de seguridad verifica la llamada: si se invoca la herramienta execute_production_migration, se activa la interrupción interrupt().
3. Serialización y guardado de estado (State Persisting): El gráfico de memoria actual, el historial de mensajes y los argumentos de la llamada a la herramienta se registran en el almacenamiento de estados.
4. Enrutamiento al operador: El servicio envía un mensaje interactivo al canal de Slack del equipo con una descripción de los cambios y botones de confirmación.
5. Revisión y modificación humana: El ingeniero puede:
   • Aprobar: enviar la señal para reanudar la ejecución.
   • Rechazar: interrumpir la sesión y registrar la razón del rechazo.
   • Modificar (Human-in-the-Edit): ajustar parámetros (por ejemplo, reducir el tamaño del batch de la consulta) antes de la ejecución.
6. Reanudación de la ejecución (Resume Thread): El motor carga el estado desde la base de datos, aplica la decisión del ingeniero y continúa el ciclo autónomo.

4. Escenarios prácticos de ingeniería en producción

01. Control de migraciones SQL peligrosas en una base de datos en vivo

El agente analiza una nueva funcionalidad y propone un cambio en el esquema de PostgreSQL:

• En lugar de ejecutar directamente ALTER TABLE users ADD COLUMN status text NOT NULL, el agente presenta una solicitud de aprobación.
• El DBA observa que agregar una columna sin valor por defecto en una tabla de 20 millones de filas bloqueará las lecturas. El ingeniero ajusta el comando para crear el campo con DEFAULT a través de un patrón de migración seguro y aprueba la ejecución.

02. Aprobación de eliminación de recursos en la nube para optimización de costos

El agente de FinOps realiza una auditoría de la infraestructura de AWS:

• Encuentra 14 instancias RDS y discos EBS no utilizados, acumulando costos de $2,000 al mes.
• El agente no los elimina por sí mismo, sino que envía un informe estructurado al líder técnico en el mensajero corporativo con enlaces a cada recurso. El líder técnico o el médico presiona "Terminate All", después de lo cual el agente realiza la limpieza.

03. Generación de respuestas legales o de cumplimiento personalizadas

La IA formula respuestas a las solicitudes de los usuarios sobre la eliminación de datos personales (GDPR Derecho a ser olvidado):

• El agente encuentra todas las entidades relacionadas en los servicios, genera un script de eliminación y prepara una carta oficial para el cliente.
• Un empleado del departamento de seguridad verifica la corrección de los documentos antes del envío.

5. Errores comunes, trampas y seguridad

• Fatiga de aprobaciones (Approval Fatigue): Si el agente solicita confirmación en cada pequeño paso (por ejemplo, leer cada archivo individual), el desarrollador deja de prestar atención y aprueba automáticamente todas las solicitudes. Configure umbrales de sensibilidad inteligentes.
• Vulnerabilidad de sustitución de intención a través de Prompt Injection: Si el agente procesa datos externos no verificados (por ejemplo, texto de una página web), un atacante puede hacer que el modelo formule una descripción engañosa de la acción para el operador ("Esta es una actualización segura de caché", aunque en el fondo se está ejecutando un robo de tokens).
• Pérdida de transaccionalidad en caso de timeouts: Si el flujo se queda esperando la respuesta de un humano durante varias horas o días, las transacciones abiertas en las bases de datos o los tokens de acceso temporales pueden caducar, causando un fallo del sistema tras el regreso del humano.
• Falta de registro de auditoría (Audit Logging): Cada decisión humana sobre la aprobación o rechazo de la acción del agente debe ser registrada en un registro seguro vinculado al ID del usuario para garantizar la transparencia y la investigación de incidentes.