Agentes de IA con supervisión humana: cómo se diseñan

Human in the loop es un patrón de arquitectura, no una promesa: el agente de IA produce una propuesta sin efecto propio, una persona identificada la aprueba o la rechaza, y el sistema registra de forma inalterable quién decidió, sobre qué versión y cuándo. Sin ese registro no hay supervisión: hay confianza. Y la confianza no se audita.

Este artículo describe cómo se implementa ese patrón en sistemas reales, qué campos necesita el registro para servir como evidencia y dónde suele fallar. No es una diapositiva de gobernanza: es lo que hay que construir.

¿Qué es exactamente la supervisión humana y en qué grados existe?

Conviene distinguir tres niveles, porque se usan como sinónimos y no lo son:

Nivel	Cómo funciona	Cuándo es adecuado
Human in the loop	La acción no se ejecuta hasta que una persona aprueba cada caso	Acciones irreversibles, con efecto jurídico, económico o reputacional
Human on the loop	El sistema ejecuta y una persona supervisa, con capacidad de detener o revertir	Volumen alto, efecto reversible, criterio estable
Human in command	La persona define el marco, activa y desactiva el sistema, pero no interviene caso a caso	Procesos internos de bajo impacto con salvaguardas

La pregunta de diseño no es «cuánta IA queremos», sino qué acciones no admiten deshacer. Enviar un correo a una lista completa, firmar un documento, publicar en nombre de una marca, aprobar un pago, cerrar un ticket con compromiso contractual: todo eso es irreversible en la práctica aunque técnicamente exista un botón de borrar. Ahí va el humano in the loop. En el resto, obligar a aprobar cada paso solo genera clics automáticos.

¿Por qué la autonomía excesiva es un fallo de diseño y no del modelo?

Cuando un agente hace algo dañino, la conversación se desvía al modelo: que alucinó, que lo engañaron con una instrucción escondida. Es un análisis incompleto. El modelo produjo texto; el daño lo causó el permiso que alguien le dio a ese texto.

OWASP lo cataloga con nombre propio: la agencia excesiva aparece cuando un sistema puede ejecutar acciones dañinas a partir de salidas inesperadas o ambiguas de un modelo, por exceso de funcionalidad, de permisos o de autonomía. Su recomendación es directa: usar control humano en el bucle para exigir aprobación antes de que la acción se ejecute. La ficha completa está en la documentación del proyecto OWASP GenAI.

Traducido a decisiones de arquitectura:

• Mínimo privilegio en las herramientas. Un agente que resume correos necesita permiso de lectura. No necesita permiso de envío ni de borrado.
• Herramientas específicas, no genéricas. «Ejecutar consulta SQL» es una superficie enorme; «obtener expediente por identificador» no lo es.
• Separación entre proponer y consumar. Deben ser dos operaciones distintas, con credenciales distintas, y la segunda no debe estar al alcance del agente.
• Entrada no confiable. Todo lo que el agente lee de fuera —una web, un correo, un documento del cliente— es dato, no instrucción.

¿Cómo se construye el punto de aprobación?

Un punto de aprobación bien construido tiene seis piezas. Si falta una, el patrón deja de ser demostrable.

1. La propuesta es un objeto inmutable. El agente escribe un borrador con contenido, destinatario, efecto previsto y una huella criptográfica del conjunto. No se edita en silencio: si cambia, es otra propuesta con otra huella.
2. La cola es explícita. Las propuestas pendientes viven en un lugar visible, con antigüedad y prioridad. Una aprobación que llega por correo y se pierde entre otros doscientos no es un control.
3. El aprobador está identificado. Cuenta nominal, con segundo factor. Nada de una cuenta compartida de «operaciones»: si tres personas usan el mismo acceso, el registro no identifica a nadie.
4. La decisión es binaria y motivada. Aprobar o rechazar. El rechazo exige motivo, porque el motivo es lo que después permite mejorar el agente.
5. La propuesta caduca. Si nadie decide en el plazo definido, se descarta y se notifica. Las colas eternas acaban aprobándose en bloque para vaciarlas.
6. El registro es de solo adición. Cada evento se añade; nada se reescribe. Un registro editable no prueba nada ante un auditor, y esa es precisamente la situación en la que uno querría tenerlo.

Qué campos debe guardar el registro

Campo	Por qué importa
Identificador de la propuesta	Une petición, decisión y ejecución en un mismo hilo
Huella de la versión revisada	Demuestra que se aprobó eso y no una versión posterior
Identidad del aprobador	Responsabilidad nominal, no de departamento
Marca de tiempo	Permite reconstruir el orden real de los hechos
Decisión y motivo	Convierte el rechazo en dato de mejora
Modelo y versión del agente	Sin esto no se puede investigar una regresión
Resultado de la ejecución	Cierra el círculo: aprobado no es lo mismo que ejecutado

Ese conjunto de campos es lo que convierte una automatización en algo defendible. Sin la huella de la versión revisada, cualquiera puede sostener que se aprobó un texto distinto del que se envió.

¿Qué distingue una aprobación real de un botón decorativo?

Tres síntomas revelan una supervisión ficticia:

• Fatiga de aprobación. Si un operador recibe cientos de decisiones al día, aprobará en bloque. El control existe en el diagrama y no en la realidad. La solución es subir el umbral: solo llega a aprobación lo que supera un criterio de riesgo definido.
• Contexto insuficiente. Aprobar un texto sin ver a quién se envía, con qué datos se ha construido y qué pasará después no es supervisión: es firmar a ciegas. La pantalla de aprobación debe mostrar el efecto, no solo el contenido.
• Rechazo sin consecuencias. Si rechazar no cambia nada —ni bloquea, ni alimenta el ajuste del agente, ni genera revisión— el operador aprende que su opinión es irrelevante.

Un cuarto indicador, más sutil: si nadie ha rechazado nunca nada, o el agente es perfecto o el control no funciona. Medir la tasa de rechazo es la forma más barata de saber si la supervisión está viva.

¿Qué relación tiene esto con los marcos de gobernanza de IA?

La supervisión humana no es una preferencia estética: aparece de forma explícita en los marcos que hoy se usan para evaluar sistemas de IA.

• El AI Risk Management Framework del NIST organiza la gestión de riesgo alrededor de funciones de gobierno, mapeo, medición y gestión, e incorpora la trazabilidad y la responsabilidad como propiedades de un sistema fiable. Está publicado en el sitio del NIST.
• El Reglamento (UE) 2024/1689, conocido como Reglamento de Inteligencia Artificial, dedica un artículo específico a la supervisión humana de los sistemas de alto riesgo. El texto oficial está en EUR-Lex.
• ISO/IEC 42001 describe un sistema de gestión de IA: políticas, roles, controles y evidencia de que se aplican. Aquí está la clave práctica: un auditor no pregunta si tienes una política de supervisión humana. Pregunta que se la enseñes funcionando, y pide muestras.

El estado exacto de cada marco en nuestro caso —qué está certificado, qué está implementado sin certificación de tercero y qué es simplemente marco de referencia— está publicado sin adornos en /trust. Es una decisión deliberada: para una firma que vende cumplimiento, un badge que insinúa lo que no existe es un riesgo mayor que no tener el badge.

¿Cómo aplicamos este patrón en producción?

No escribimos sobre esto en abstracto. Operamos agentes propios en producción dentro de nuestro ecosistema y el punto de aprobación está construido, no dibujado.

El caso más claro es el conector de agentes de Veritas UGC, nuestro producto de certificación probatoria de contenido. Un agente puede preparar un depósito: recoger el archivo, calcular su huella, redactar la descripción y dejarlo todo listo. Lo que no puede hacer es sellarlo. El sellado —el acto que produce un certificado con valor probatorio— exige aprobación humana explícita, y el sistema conserva quién aprobó y sobre qué huella.

La razón es evidente en cuanto se piensa: un certificado emitido por un agente sin control humano sería un documento que nadie querría presentar en ningún sitio. La supervisión no frena el producto; es lo que lo hace utilizable.

Ese mismo patrón es el que trasladamos a los flujos de cliente en automatización: el agente hace el trabajo pesado, la persona decide lo irreversible y el sistema deja rastro. Cuando esos flujos se orquestan sobre herramientas como n8n, aparecen problemas operativos propios —reintentos que duplican efectos, ejecuciones huérfanas, credenciales sin rotar— que tratamos aparte en n8n en producción: qué falla cuando el flujo crece.

Errores frecuentes al implementar el patrón

• Poner la aprobación después de la acción, como confirmación cosmética.
• Aprobar en una herramienta y ejecutar en otra sin identificador común: el rastro se rompe justo donde hace falta.
• Guardar el registro en el mismo sistema que el agente puede modificar.
• Usar una cuenta de servicio como aprobador «temporal» que se queda tres años.
• No versionar el prompt ni la configuración del agente: cuando algo se tuerce, no hay forma de saber qué cambió.
• Confundir logs técnicos con evidencia. Un log rotado a los siete días no sirve para responder por una decisión de hace cuatro meses.

Qué hacer ahora

1. Haz el inventario de acciones irreversibles que tu automatización puede ejecutar hoy. Esa lista define dónde va la supervisión.
2. Revisa los permisos reales de cada herramienta conectada al agente y recórtalos al mínimo. Es la corrección más rápida y la que más riesgo elimina.
3. Separa proponer de consumar con credenciales distintas, aunque el flujo siga siendo el mismo.
4. Comprueba si tu registro es de solo adición y si guarda la huella de la versión aprobada. Si no la guarda, no prueba nada.
5. Mide la tasa de rechazo. Si es cero, investiga por qué antes de presumir de control.

Si quieres que auditemos tus agentes actuales y te digamos qué acciones están ejecutándose hoy sin aprobación humana, escríbenos desde /contacto. El diagnóstico se hace sobre tus flujos reales y sale con la lista de permisos que hay que cerrar esta semana, no con un plan a doce meses.