IA con humano en el circuito: qué acciones de un agente necesitan a una persona, 2026
Clasifica las acciones de un agente de IA por reversibilidad: deja correr las lecturas y exige a una persona para envíos, pagos, borrados y publicaciones.
Un agente necesita a una persona cuando una acción no se puede deshacer o sale de tus sistemas. Leer, buscar y redactar borradores puede ocurrir solo. Enviar, pagar, borrar y publicar deben esperar aprobación.
Esa regla importa cuando un agente trabaja con el correo, los pagos, los datos de clientes o una base de datos de producción. Incluso un modelo que acierta casi siempre se equivoca en algunas llamadas, y el costo de esos errores depende de lo que el agente tenía permitido tocar. Este artículo muestra cómo clasificar las acciones, elegir una barrera para cada grupo y mantener los avisos lo bastante pocos como para que alguien siga leyéndolos.
Qué significa la IA con humano en el circuito para un agente
La IA con humano en el circuito (human in the loop) significa que una persona puede aprobar, modificar o rechazar una acción del agente antes de que se ejecute. La barrera está en la llamada a la herramienta, el momento en que el agente pide hacer algo en el mundo exterior.
Dónde se coloca la barrera
La especificación del Model Context Protocol, versión 2025-06-18, enuncia el principio de forma directa: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." Añade que las aplicaciones deben mostrar qué herramientas puede usar el modelo, señalar con claridad cuándo se invoca una herramienta y presentar avisos de confirmación para que un humano siga en el circuito.
La misma página indica que los clientes deben pedir confirmación en las operaciones sensibles y mostrar al usuario los datos de entrada de la herramienta antes de llamar al servidor, para evitar una filtración de datos maliciosa o accidental. Por eso la barrera no es una aprobación general del agente. Es una revisión de una llamada concreta con sus argumentos reales.
Lo que no es
Un informe semanal de lo que hizo el agente no es una barrera. Cuando lo lees, el correo ya salió y el registro ya no existe. La aprobación después del hecho es solo una notificación. Control significa que la decisión llega primero.
Clasifica cada acción según el daño que puede causar
Empieza por la reversibilidad. Pregunta por cada acción: si está mal, ¿se puede deshacer y quién la ve antes de que puedas hacerlo?
Tres niveles: nunca, quizá y siempre irreversible
El sistema de investigación Magentic-UI, creado por un equipo de Microsoft Research, usa una heurística de irreversibilidad de tres valores que el desarrollador define para cada acción. Desplazarse por una página nunca es irreversible. Hacer clic en un botón quizá sea irreversible. Subir un archivo es siempre irreversible. Las acciones siempre irreversibles piden al usuario una decisión binaria de aprobar o rechazar. Las que quizá sean irreversibles pasan a un juez basado en un LLM que decide si una persona debe aprobarlas. Las nunca irreversibles se ejecutan automáticamente.
Puedes copiar la forma sin copiar el sistema. Lo esencial es que la clasificación la hacen de antemano las personas que construyen el agente, acción por acción. No se deja al modelo en el momento.
Una clasificación práctica para agentes de negocio
Para agentes dentro de una empresa, tres grupos cubren la mayoría de los casos:
| Grupo | Ejemplos | Barrera |
|---|---|---|
| Leer y redactar | Buscar, leer archivos, resumir, escribir un borrador que no se envía | Se ejecuta solo |
| Escrituras reversibles | Actualizar un ticket interno, crear un registro en borrador, mover un archivo que se puede restaurar | Se ejecuta, se registra y se revisa después |
| Irreversibles o hacia afuera | Enviar correos o mensajes, gastar dinero, borrar datos, publicar, cambiar permisos | Aprobar primero |
La última fila es la que merece a una persona. Cada acción en ella llega a alguien fuera de tu equipo, cuesta dinero o elimina algo que no puedes recuperar.
Cuidado con las acciones que parecen pequeñas
El riesgo está en la herramienta, no en el verbo. Un botón de "enviar" puede significar un correo a un cliente. Un "actualizar" puede sobrescribir la única copia de un registro. Un "ejecutar" puede iniciar un pago. Cuando listes las herramientas del agente, clasifica lo que cada una hace en el mundo exterior, no cómo se llama.
Elige la barrera después de clasificar la acción
Una vez clasificadas las acciones, cada grupo recibe una regla. La mayoría de las herramientas de agentes expresan esto como permitir, preguntar y denegar.
Permitir, preguntar, denegar
Un ejemplo público es un agente de programación muy usado. Su documentación de permisos describe reglas de permiso que se ejecutan sin aprobación, reglas de pregunta que piden confirmación cada vez y reglas de denegación que bloquean la herramienta. Las reglas se evalúan en el orden denegar, preguntar y permitir, y la primera coincidencia decide. Una denegación amplia no se puede anular con una regla de permiso más específica.
Los valores por defecto siguen la misma lógica que la tabla anterior. En modo manual, leer archivos dentro del directorio de trabajo no requiere aprobación. Editar archivos, ejecutar comandos de shell (salvo un conjunto integrado de comandos de solo lectura), descargar páginas web y buscar en la web sí piden confirmación.
Traslada tus propios grupos a las tres reglas:
- Permitir: las acciones de leer y redactar.
- Preguntar: envíos, gastos, borrados, publicaciones y cambios de permisos.
- Denegar: todo lo que el agente nunca debe hacer, como tocar la configuración de facturación o leer archivos de credenciales.
Aprobación del plan y del límite
Los avisos por acción no son la única barrera. Magentic-UI también exige aprobación explícita del usuario para los planes nuevos y para cualquier sitio fuera de una lista de permitidos. Aprobar un plan es rápido y sirve para fijar el rumbo. No sustituye la aprobación de la llamada, porque un plan puede parecer correcto mientras un argumento está mal. Para ver con más detalle los controles que lo rodean, consulta permisos, puertas de aprobación y registros de auditoría.
Qué debe mostrar el aviso de aprobación
Un aviso que dice "El agente quiere enviar un correo. ¿Permitir?" se aprueba sin más. Un aviso que muestra el destinatario, el asunto y el cuerpo completo se lee.
Una solicitud de aprobación útil muestra:
- La herramienta exacta y los argumentos exactos, no un resumen de la intención.
- El destino: qué cuenta, qué cliente, qué registro o importe.
- Qué cambia y si se puede revertir.
- Tres opciones: aprobar, editar o rechazar.
Editar importa. Si quien revisa puede corregir un destinatario equivocado y aprobar en un solo paso, es menos probable que deje pasar una llamada en la que solo confía a medias. Una solicitud que nadie responde debe rechazarse por defecto, no ejecutarse.
Aquí también cobra sentido la guía de MCP sobre mostrar los datos de entrada de la herramienta. Las personas solo pueden detectar un error en un argumento si pueden verlo.
Mantén las aprobaciones lo bastante escasas para que importen
Si un agente pregunta por todo, la gente deja de leer. Pulsa aprobar para seguir con su día y la barrera se convierte en decoración. Apunta a menos avisos, pero con peso real.
Algunos hábitos ayudan:
- Deja que las acciones de solo lectura se ejecuten sin aviso, de modo que las aprobaciones que sí veas sean las arriesgadas.
- Recuerda las aprobaciones de forma estrecha. La opción "no volver a preguntar" de un agente de programación, por ejemplo, se guarda por repositorio y comando en el caso de los comandos de shell, no como un permiso general. Sigue ese patrón: aprueba un comando o un dominio, no una herramienta entera.
- Registra cada acción que se ejecutó sin aviso y revisa muestras del registro. Una barrera que nunca auditas se desvía.
- Trata un aumento en la cantidad de avisos como un fallo de diseño. Si quienes revisan ven veinte avisos al día por la misma acción segura, pásala a permitida. La preocupación relacionada de mantener los costos bajo control se trata en control de costos de agentes de IA.
Conclusión
Clasifica las acciones por lo que pueden deshacer, no por lo capaz que parezca el agente. Deja que las lecturas y los borradores se ejecuten, registra y revisa las escrituras reversibles, y pon a una persona delante de todo lo que salga hacia afuera, cueste dinero o sea permanente. Muestra los argumentos reales, rechaza por defecto y mantén los avisos escasos. Kallos Labs construye este tipo de barreras como parte de su trabajo de automatización con IA, y la misma regla se aplica tanto si lo construyes tú como si lo compras.
Preguntas frecuentes
¿Qué significa humano en el circuito para los agentes de IA?
Una persona puede aprobar, modificar o rechazar una acción del agente antes de que se ejecute, en lugar de leer solo un informe después. La barrera está en la llamada a la herramienta, donde el agente pide hacer algo fuera de su propio razonamiento.
¿Qué acciones de un agente deben requerir siempre aprobación?
Las que no se pueden deshacer o que salen de tus sistemas: enviar mensajes, gastar dinero, borrar datos, publicar contenido y cambiar permisos. Si una llamada equivocada llegaría a un cliente o costaría dinero, una persona debe verla primero.
¿Debe un agente preguntar antes de cada acción?
No. Pedir confirmación para todo entrena a quienes revisan a aprobar sin leer. Deja que las acciones de solo lectura se ejecuten y reserva los avisos para las que implican riesgo, de modo que cada aviso reciba atención real.
¿Humano en el circuito es lo mismo que humano sobre el circuito?
No. En el circuito significa que una persona decide antes de que se ejecute la acción. Sobre el circuito significa que una persona observa y puede intervenir. Usa lo primero para acciones irreversibles y lo segundo para acciones de bajo riesgo y reversibles.