Human-in-the-Loop: Cuándo tu Agente IA Debe Pausar

El agente funciona perfectamente en staging. Cincuenta casos de prueba, todos pasan. Lo despliegas a producción.

Tres semanas después: el agente de facturación generó un cargo duplicado para un cliente. El agente de soporte reembolsó 2.100€ que no correspondían. El clasificador de leads rechazó lo que resultó ser el mejor prospecto del trimestre.

No fueron bugs. No fue un fallo del modelo. El agente hizo exactamente lo que fue diseñado para hacer, correctamente, en escenarios que tus tests no cubrían.

La pieza que faltaba: supervisión humana en el momento justo.

El error de arquitectura más común

La mayoría de los equipos implementan agentes IA como flujos lineales: trigger → LLM → acción. Funciona en staging porque los inputs están controlados. Producción es diferente.

En producción el agente se encuentra con:

• Inputs ambiguos donde incluso la confianza del modelo es limítrofe
• Acciones irreversibles —cargos, eliminaciones, emails externos, mutaciones de API— que cuestan dinero real o relaciones si fallan
• Edge cases que no aparecen en tu dataset de prueba

La solución no son más tests. Es diseñar el agente para que se detenga y pregunte cuando debe detenerse y preguntar.

Los tres patrones HITL que funcionan en producción

1. Umbral de confianza en la decisión

La mayoría de LLMs, especialmente con structured outputs, pueden devolver un score de confianza junto a su decisión. Si ese score está por debajo de tu umbral, no ejecutes: interrumpe.

type AgentDecision = {
  action: "approve_refund" | "reject_lead" | "send_invoice";
  confidence: number; // 0.0 → 1.0, producido por el LLM
  reasoning: string;
  payload: Record<string, unknown>;
};

async function executeWithHITL(decision: AgentDecision): Promise<void> {
  if (decision.confidence < 0.85) {
    await requestHumanApproval(decision);
    return; // el agente pausa aquí
  }
  await executeAction(decision);
}

El 0.85 no es universal. Empieza en 0.90, mide la frecuencia de interrupciones, bájalo gradualmente a medida que validas el patrón con datos reales.

2. Reglas de negocio hardcodeadas

Algunas acciones deben requerir aprobación humana siempre, independientemente de la confianza del modelo:

type BusinessRule = (decision: AgentDecision) => boolean;

const ALWAYS_ESCALATE: BusinessRule[] = [
  (d) => d.action === "delete_record",
  (d) => (d.payload.amount as number) > 5_000,
  (d) => d.payload.isFirstPurchase === true,
  (d) => d.payload.accountAge === "new",
];

function requiresHuman(decision: AgentDecision): boolean {
  if (decision.confidence < 0.85) return true;
  return ALWAYS_ESCALATE.some((rule) => rule(decision));
}

Esto no es una limitación: es un contrato de seguridad. El agente sabe qué puede decidir de forma autónoma y qué debe escalar. Define tus reglas en función del riesgo de negocio, no de la complejidad técnica.

3. Aprobación asíncrona con checkpoint de estado

La parte difícil: el agente necesita pausar, persistir su estado, notificar a un humano y reanudar cuando se apruebe. Sin checkpoint, reanudar significa reiniciar desde cero, lo que puede tener efectos secundarios.

// 1. Guardar checkpoint antes de pausar
const checkpointId = await db.checkpoints.create({
  agentState: JSON.stringify(currentState),
  pendingDecision: decision,
  expiresAt: new Date(Date.now() + 24 * 60 * 60 * 1000),
  status: "pending",
});

// 2. Notificar al humano (Telegram, Slack o email)
await notify({
  to: process.env.APPROVER_CONTACT,
  message: `Decisión pendiente: ${decision.reasoning}`,
  approveUrl: `${BASE_URL}/api/hitl/approve?id=${checkpointId}`,
  rejectUrl:  `${BASE_URL}/api/hitl/reject?id=${checkpointId}`,
});

// 3. Webhook de aprobación — /api/hitl/approve/route.ts
export async function POST(req: Request) {
  const { id, approved } = await req.json();
  const cp = await db.checkpoints.findById(id);

  if (!cp || cp.status !== "pending") {
    return Response.json(
      { error: "checkpoint inválido o expirado" },
      { status: 400 }
    );
  }

  if (approved) {
    await executeAction(cp.pendingDecision);
    await db.checkpoints.update(id, { status: "approved" });
  } else {
    await db.checkpoints.update(id, { status: "rejected" });
  }

  return Response.json({ ok: true });
}

Un detalle clave: el checkpoint expira en 24 horas. Un agente esperando indefinidamente aprobación humana es un proceso bloqueado. Define la expiración y el fallback: auto-rechazo, escalado adicional o alerta urgente.

Lo que NO debes gatear

Cada interrupción tiene un coste: latencia, atención humana, complejidad de flujo. Gatear todo destruye el propósito de la automatización.

No uses HITL para:

• Acciones puramente informativas: leer datos, generar informes, resumir emails
• Flujos de alta confianza y bajo riesgo: acciones con 99%+ de confianza en patrones bien testeados
• Automatizaciones time-sensitive: si el valor es la velocidad, una ventana de aprobación de 30 minutos lo mata
• Acciones reversibles: si una acción se puede deshacer con un clic, deja que el agente actúe y corrige post-hoc

HITL es para irreversibilidad e incertidumbre. Úsalo con criterio quirúrgico.

La distribución real en producción

En los sistemas que implementamos desde DAILYMP para agentes en empresas, la distribución observada tras las primeras semanas es consistente:

• 3-5% de las decisiones terminan en aprobación humana
• 95% fluyen de forma autónoma sin intervención
• 100% quedan registradas en el audit log con el contexto completo de la decisión

Eso es exactamente lo que debería ser. El agente no decide todo: decide lo que puede decidir con garantías.

Cómo lo diseñamos desde el primer commit

Cuando implementamos integraciones IA para nuestros clientes, HITL no es un parche de producción: es parte del diseño inicial.

1. Mapeamos el riesgo: qué acciones son irreversibles, cuáles tienen impacto económico o relacional
2. Calibramos umbrales: monitorizamos distribuciones de confianza las primeras 2 semanas, luego ajustamos
3. Definimos el routing de notificaciones: quién aprueba qué, diferentes paths de escalado para diferentes equipos
4. Implementamos persistencia de estado: todo agente que pueda interrumpirse usa checkpoint desde el día uno
5. Construimos el audit trail: cada decisión —autónoma o aprobada por humano— queda registrada con el contexto completo

El resultado son agentes en los que confiar con carga real de producción porque el sistema sabe cuándo parar.

Conclusión

Un agente autónomo sin HITL no es un agente de producción: es un agente de staging que llegó accidentalmente a producción. El umbral de confianza, las reglas de negocio y los checkpoints asincrónicos descritos aquí no son complejidad opcional. Son la arquitectura de un sistema en el que se puede confiar.

Si estás construyendo agentes IA y todavía no has diseñado los puntos de interrupción, empieza por ahí. Todo lo demás —observabilidad, evals, memoria persistente— se construye sobre una base que incluye supervisión humana por diseño.

Diseñamos agentes con supervisión humana integrada desde el primer commit →