Uno de nuestros clientes — una empresa manufacturera con un ERP de tamaño medio — desplegó un agente de IA para procesar pedidos. Las primeras tres semanas funcionó perfectamente: agrupaba solicitudes, verificaba la disponibilidad y generaba propuestas. Entonces llegó un caso que no estaba en los datos de entrenamiento — un cliente con condiciones de pago no estándar. El agente estimó que la situación era estándar y confirmó el pedido. Sin aprobación. Sin escalado. Con las condiciones incorrectas.
Al agente no se le ocurrió detenerse y preguntar. No tenía reglas para ello.
Esto no es un argumento contra los agentes de IA. Es un argumento a favor de un diseño human-in-the-loop (HITL) bien pensado — un conjunto de reglas que determinan cuándo el agente actúa por sí solo y cuándo espera a una persona. Este artículo es un marco de decisión para la práctica: dónde trazar la línea, cómo implementar técnicamente el flujo de aprobación y cómo ampliar la autonomía del agente de forma progresiva y segura.
Por qué HITL no es solo un "parche de seguridad"
El error más frecuente al diseñar agentes: el HITL se añade al final como filtro. La salida del agente — una decisión, una acción, un documento — pasa por una ventana de aprobación y, si la persona hace clic en "OK", continúa.
Este enfoque solo trata el síntoma. No se ve lo que el agente hizo antes. No se sabe si la decisión siguió lógicamente de los pasos correctos o si el agente llegó al resultado correcto por el camino equivocado. Y cuando algo falla, el audit trail está vacío.
El HITL correcto es un patrón arquitectónico, no un complemento. Se define antes del despliegue, no después del primer incidente. Incluye:
- Clasificación de acciones según el nivel de riesgo e irreversibilidad
- Puntos de interrupción explícitos en el grafo del agente — no solo en la salida, sino directamente en el flujo de decisión
- Audit trail de cada paso: qué vio el agente, qué decidió, quién aprobó
El artículo 14 de la Ley de IA de la UE exige supervisión humana para sistemas de IA de alto riesgo a partir del 2 de agosto de 2026. Si vuestro sistema entra en esta categoría — toma de decisiones automatizada en asuntos laborales, puntuación crediticia, gestión de infraestructura crítica — el HITL no es una recomendación. Es una obligación.
Acciones que siempre requieren aprobación
No todas las acciones de un agente conllevan el mismo riesgo. El criterio clave es la irreversibilidad: ¿se puede deshacer la acción? Si no, la aprobación es obligatoria.
El segundo criterio es el alcance del impacto: a quién afecta la acción, cuánto dinero o datos están en juego, cuál es la exposición regulatoria.
Acciones en las que recomendamos siempre detener y solicitar aprobación:
- Transacciones financieras — envío de pagos, emisión de facturas, cambio de tarifas, pedidos a proveedores por encima del límite definido
- Operaciones irreversibles con datos — eliminación de registros, copia de seguridad antes de sobrescribir, exportación a un sistema externo
- Comunicación externa en nombre de la empresa — correo electrónico a clientes, respuesta a reclamaciones, documento legal
- Cambios en sistemas de terceros — escritura en ERP, CRM, SCADA; modificación de configuraciones del entorno de producción
- Decisiones de escalado con exposición legal — rechazo de reclamaciones, rescisión de contratos, aceptación de compromisos
En la práctica, vemos que las empresas subestiman estas categorías al principio. Mientras el agente trabaja solo con un sandbox interno, todo parece seguro. Los problemas llegan cuando el agente obtiene acceso a las herramientas de producción.
Human-on-the-loop vs. Human-in-the-loop
Una distinción importante que condicionará todo el diseño:
Human-in-the-loop (HITL) — el agente se detiene y *espera* la aprobación antes de ejecutar la acción. El flujo queda bloqueado. El tiempo de respuesta depende de la disponibilidad del operador. Apropiado para acciones irreversibles o de alto riesgo.
Human-on-the-loop (HOTL) — el agente actúa de forma autónoma, pero registra cada paso y el operador puede intervenir de forma asíncrona. El flujo no está bloqueado. Apropiado para acciones fácilmente reversibles o de bajo impacto.
La mayoría de los sistemas en producción necesitan ambos modos. Un árbol de decisión sencillo:
- 1.¿Es la acción irreversible? → HITL obligatorio
- 2.¿El impacto financiero supera el límite (p. ej., 1 000 EUR)? → HITL obligatorio
- 3.¿Hay exposición regulatoria (GDPR, contrato, responsabilidad)? → HITL obligatorio
- 4.¿Es la acción rutinaria y reversible? → HOTL es suficiente
Esta no es una decisión puntual. Los límites cambian a medida que el agente acumula historial y confianza.
Implementación técnica: LangGraph interrupt()
La implementación técnica más limpia de HITL para agentes con estado es mediante LangGraph y su mecanismo interrupt(). El principio es sencillo: en el grafo del agente se definen nodos en los que el flujo se pausa y espera una entrada externa — aprobación, corrección, rechazo.
El patrón básico:
- El agente procesa la entrada y decide qué acción quiere ejecutar
- Antes de ejecutar la acción, alcanza el nodo de interrupción: guarda el estado actual (checkpointing), genera una descripción de la acción propuesta para el operador y espera
- El operador recibe una notificación (correo electrónico, Slack, panel de UI integrado)
- Tras la aprobación, el flujo se reanuda desde el checkpoint exacto — el agente recuerda todo el contexto, no solo el último mensaje
- Ante un rechazo o modificación, el agente recibe retroalimentación y puede replanificar
La propiedad clave del checkpointing de LangGraph: el estado del agente se serializa en almacenamiento persistente. La aprobación puede llegar una hora después o al día siguiente — el agente "despierta" con el contexto completo. Esta es la diferencia fundamental frente al enfoque naïve, donde habría que implementar la interrupción manualmente mediante una base de datos y Redis.
Para un audit trail fiable, cada nodo de interrupción registra: identificador del agente, hora, acción propuesta, argumentos de la herramienta, y posteriormente también la decisión del operador y su justificación.
Explicamos con más detalle el aspecto de las arquitecturas de agentes en la práctica en el artículo Arquitecturas de agentes de IA: ReAct, Plan-and-Execute, cuándo usar cada una.
Diseño del flujo de aprobación
Un buen flujo de aprobación tiene tres propiedades: contextualidad (el operador ve por qué el agente propone esta acción, no solo cuál), velocidad de respuesta (cuanto más tiempo espera el agente, más se acumulan las tareas bloqueadas) y escalado (si el operador no responde en el tiempo definido, la tarea escala o se cierra de forma segura).
Estructura recomendada de la notificación para el operador:
- Contexto: En qué se basa la decisión — la solicitud original, los datos relevantes, los pasos previos a la acción
- Acción propuesta: Qué quiere hacer exactamente el agente, incluidos los argumentos (p. ej., "Pedir 500 unidades de SKU-4421 al proveedor X al precio Y")
- Motivo: Por qué el agente llegó a esta decisión
- Alternativas: Si el agente consideró varias opciones, mostrarlas (ayuda al operador a la hora de corregir)
- Acciones: Aprobar / Rechazar / Modificar con comentario / Escalar
Este no es solo un detalle de UX. El operador que solo ve "¿Confirmar acción?" aprueba la mayoría de las veces de forma refleja. El operador que ve el contexto completo toma una decisión informada — y a la vez desarrolla la intuición sobre dónde comete errores el agente.
Abordamos el tema de la seguridad y los guardrails para agentes con más detalle en el artículo Guardrails para agentes de IA.
Confianza vs. velocidad: el trade-off principal
El HITL tiene un coste. Cada punto de interrupción añade latencia — la espera de una respuesta humana puede ser de minutos u horas. Si un agente tiene diez pasos y cada uno espera aprobación, el sistema no es un agente. Es un flujo de trabajo en formularios con fachada de IA.
Por eso la confianza en el agente es una variable escalable, no una decisión binaria.
Marco práctico para la ampliación progresiva de la autonomía:
Fase 1 — Ejecución en sombra (shadow mode): El agente propone acciones, pero siempre es una persona quien las ejecuta. Se recopilan datos: con qué frecuencia acertó el agente, dónde se equivocó, cuál fue el contexto de los errores. Duración: 2–4 semanas o 100–200 acciones.
Fase 2 — Autonomía selectiva: A partir de los datos de la fase 1, se definen las categorías de acciones en las que el agente tuvo una precisión > 95 % y se pasan al modo HOTL. Se sigue monitorizando. Las categorías de alto riesgo permanecen en HITL.
Fase 3 — Autonomía limitada con umbrales: Autonomía en categorías de bajo riesgo con límites explícitos (p. ej., pedidos inferiores a 500 EUR sin aprobación). Cada límite tiene justificación y fecha de revisión.
Fase 4 — Autonomía adaptativa: El sistema monitoriza el rendimiento en tiempo real. Si la tasa de error supera el umbral, regresa automáticamente a un modo más restrictivo. Si se mantiene baja, el límite puede ampliarse.
Este no es un proyecto puntual. Es un proceso continuo de calibración de la confianza — similar a la incorporación de un nuevo empleado.
La cuestión de los costes y el retorno de la inversión desde la perspectiva de los agentes se aborda en Costes del agente de IA en producción.
Qué no resuelve el HITL: límites del enfoque
El HITL es necesario, pero no suficiente. Hay algunas cosas que el flujo de aprobación por sí solo no resuelve:
Prompt injection — un atacante inserta instrucciones en la entrada del agente (por ejemplo, en un documento que se está procesando) que el agente ejecuta sin que resulte evidente en la ventana de aprobación. El operador ve una acción "normal" que en realidad responde a un flujo manipulado. OWASP LLM Top 10 sitúa el prompt injection en el primer puesto en producción.
Alcance de herramientas demasiado amplio — si el agente tiene acceso a un conjunto de herramientas demasiado amplio, el HITL solo protege para las acciones que están explícitamente marcadas. Las acciones fuera del alcance explícitamente vigilado pueden pasar desapercibidas. Solución: principio de mínimo privilegio para cada herramienta.
Velocidad de aprobación como cuello de botella — si un solo operador aprueba decenas de solicitudes al día, la calidad de sus decisiones decrece. Las solicitudes rutinarias se aprueban de forma refleja, las anomalías reales pasan sin ser detectadas. El HITL debe complementarse con un sistema de triaje: no todas las aprobaciones tienen la misma importancia.
Deriva del agente — el rendimiento del agente cambia con el tiempo si cambian los datos o el contexto de los prompts. Una acción que hace seis meses era autónoma de forma segura puede ser hoy arriesgada. Por eso las fechas de revisión de los límites son una obligación, no una recomendación.
La observabilidad del agente — el seguimiento de trazas, tasa de errores y latencias en tiempo real — es un requisito previo para que el HITL funcione. Sin ella, no se sabe cuándo se produce la deriva. Sobre las herramientas de seguimiento de agentes escribimos en Observabilidad de agentes de IA.
Recomendaciones prácticas para el despliegue
Desde la experiencia en decenas de proyectos:
- 1.Comienza con HITL completo para todas las acciones. No por precaución, sino para recopilar datos. Sin historial no se pueden tomar decisiones informadas sobre dónde ampliar la autonomía.
- 2.Categoriza las acciones de forma explícita. La lista de categorías con el riesgo y el límite definidos debe ser aprobada por el responsable del proceso — no solo por el equipo de TI.
- 3.Registra todo, no solo los incidentes. Las aprobaciones rutinarias son igual de importantes para el análisis de tendencias que los rechazos.
- 4.Configura el escalado automático. Si el operador no responde en X minutos, la tarea escala a un suplente o se cierra de forma segura con una notificación. Un agente en espera nunca debe bloquear el proceso de producción.
- 5.Prueba entradas incorrectas. Simula entradas en las que el agente podría querer realizar una acción problemática. Verifica que la interrupción funciona correctamente.
- 6.Ciclo de revisión cada 3 meses. Revisa las estadísticas de aprobaciones. Donde el índice de errores es bajo y el historial es bueno — considera ampliar la autonomía. Donde surgen sorpresas — restringir.
Preguntas frecuentes
¿Necesitamos HITL también para un chatbot interno que solo responde preguntas?
Si el agente solo lee y responde — sin herramientas con acceso de escritura, sin acciones hacia el exterior — el HITL no es imprescindible. Es suficiente con HOTL: se monitorizan las salidas, se configuran guardrails de contenido y se tiene la posibilidad de intervenir. El HITL es relevante donde el agente *actúa*, no solo *responde*.
¿Cómo evitar que los operadores aprueben sin reflexionar?
Dos técnicas probadas: en primer lugar, mostrar el contexto completo (por qué el agente propone la acción), no solo la acción en sí. En segundo lugar, para las categorías críticas, exigir al operador una breve justificación de la aprobación — al menos una frase. La justificación obligatoria reduce drásticamente las aprobaciones reflexivas.
¿Puede el HITL hacer que el agente sea demasiado lento para uso en producción?
Sí, si está mal diseñado. La clave es la selectividad: HITL solo para acciones realmente de alto riesgo, todo lo demás en HOTL. En la práctica, la categoría de acciones verdaderamente críticas representa entre el 5 y el 15 % del volumen total en un agente empresarial típico — el resto puede funcionar de forma autónoma con monitorización.
¿Qué pasa si el agente necesita aprobación en mitad de una tarea larga — pierde el contexto?
Precisamente por eso es importante el checkpointing de LangGraph. El agente serializa el estado en cada punto de interrupción. Si la aprobación llega una hora después o incluso al día siguiente, el agente reanuda el flujo desde el punto exacto sin perder el contexto. Sin checkpointing habría que reiniciar toda la tarea desde el principio.
¿Cómo se relaciona el HITL con la Ley de IA de la UE?
El artículo 14 de la Ley de IA de la UE exige supervisión humana para los sistemas de IA de alto riesgo. A partir del 2 de agosto de 2026, esta obligación aplica a sistemas en ámbitos como el empleo, la educación, la infraestructura crítica, la gestión del acceso a servicios esenciales y otros. Si vuestro agente pertenece a alguna de estas categorías, el HITL no es una opción — es un requisito legal que debéis ser capaces de demostrar también en una auditoría.
*Diseñar y configurar un flujo HITL para un agente concreto no es un proyecto de semanas — es una decisión arquitectónica que influye en todo el ciclo de vida del sistema. En MP Industrial Solutions ayudamos a las empresas a identificar exactamente dónde se encuentra la línea entre autonomía y supervisión, a configurar el flujo de aprobación acorde con su entorno regulatorio y a construir progresivamente la confianza en el rendimiento del agente. Si estáis considerando un despliegue o tenéis un agente existente sin un diseño HITL bien pensado — contactadnos para una consulta.*