Human-in-the-loop para agentes de IA: diseño de puntos de aprobación que no frenan la operación

Poner un humano "en el loop" suena a control sólido, pero mal diseñado produce lo contrario: un aprobador saturado que hace clic sin leer. Esta guía es el detalle del control número cinco del marco de gobernanza de agentes de IA: cómo decidir qué requiere humano, cómo evitar que la aprobación se vuelva ceremonia, y qué evidencia dejar de cada decisión.

Qué decisiones requieren humano: tiers por reversibilidad

La pregunta "¿esto necesita aprobación humana?" tiene una respuesta objetiva si la ordenás por reversibilidad, no por instinto o por tipo de sistema. Tres tiers cubren la práctica totalidad de los casos:

• Tier 1 — read-only. Consultar un log, leer un estado, listar recursos. No hay nada que deshacer. Ejecución automática, con registro.
• Tier 2 — reversible. Crear un archivo, abrir un ticket, escalar una réplica, actualizar un registro que se puede revertir. Automático dentro de política, con límites de tasa y monitoreo activo — no aprobación por adelantado, pero sí visibilidad si el volumen o el patrón se sale de lo esperado.
• Tier 3 — irreversible o fuera de política. Borrar datos sin backup, enviar comunicación externa, ejecutar un pago, modificar permisos de producción. Aprobación humana previa, siempre, sin atajos por urgencia.

Esta clasificación tiene que vivir en la capa de política, evaluada por el punto de control en el momento de la acción —no como una convención que cada equipo interpreta a su manera. El detalle técnico de dónde y cómo se evalúa está en control de ejecución de agentes de IA.

Por qué la IA nunca se autoriza a sí misma

Un principio no negociable del diseño: ningún sistema de IA puede ser la autoridad que aprueba sus propias acciones de tier 3, ni directa ni indirectamente. No importa cuán bien calibrado esté el modelo ni cuántas capas de razonamiento adicional le agregues antes de "confirmar" — un segundo modelo revisando al primero sigue siendo IA aprobando IA, y el problema de fondo (no determinismo, vulnerabilidad a instrucciones inyectadas, ausencia de responsabilidad legal) no desaparece por agregar una capa más.

La aprobación de tier 3 tiene que llegar a una identidad humana con nombre, con capacidad de entender el contexto de la acción y con responsabilidad real sobre la decisión. Esto no es desconfianza hacia el modelo: es la misma lógica por la que un sistema financiero no deja que un empleado apruebe su propio reembolso, aunque el empleado sea intachable. La separación de roles entre quien propone y quien autoriza es lo que hace que la aprobación signifique algo.

El enemigo silencioso: rubber-stamping y approval fatigue

El diseño más intuitivo —"pidamos aprobación para todo, así estamos seguros"— es también el que más rápido se rompe. Un operador que recibe cuarenta pedidos por día, de los cuales treinta y nueve son triviales y evidentemente correctos, aprende en la primera semana a aprobar sin leer. Eso es rubber-stamping: el control sigue existiendo en el diagrama de arquitectura, pero ya no existe en la práctica, porque la persona que debía ejercer criterio dejó de ejercerlo.

La approval fatigue no es un problema de disciplina del aprobador, es un problema de diseño del sistema. Se combate con dos decisiones: reducir el volumen de pedidos acotando la aprobación humana a lo que realmente la necesita (tier 3, no todo), y hacer que cada pedido que sí llega traiga el contexto suficiente para decidir en segundos, no en minutos de investigación. Un aprobador que tiene que abrir tres pestañas para entender qué le están pidiendo, también termina aprobando por cansancio.

Diseño del punto de aprobación: contexto y SLA

Un pedido de aprobación bien diseñado responde, sin que el aprobador tenga que buscar nada más, estas preguntas: qué acción concreta se está pidiendo, sobre qué recurso, con qué parámetros, qué agente y qué tarea la originaron, y por qué el sistema la clasificó como tier 3 en vez de dejarla pasar. Sin ese contexto, aprobar es adivinar.

Tan importante como el contenido es el tiempo. Cada pedido necesita un SLA de aprobación explícito: un plazo razonable para el tipo de acción (minutos para algo urgente y acotado, horas para algo que puede esperar), y una regla clara de qué pasa si se vence. Esa regla tiene que ser denegación por timeout, no ejecución automática — dejar pasar por defecto anula todo el sentido de haber pedido aprobación. Enrutar el pedido a la persona correcta también es parte del diseño: un buzón compartido sin dueño claro es donde los pedidos van a morir sin que nadie decida nada, ni sí ni no.

Evidencia firmada de cada aprobación

Cada aprobación o rechazo es, en sí mismo, una decisión que necesita quedar en el registro con el mismo rigor que la acción que autorizó: quién aprobó (identidad humana, no un rol genérico), cuándo, con qué contexto tenía disponible en ese momento, y con qué resultado. Esa entrada del audit trail tiene que estar protegida contra alteración posterior —firmada o encadenada criptográficamente al resto del registro— porque si se puede editar después de los hechos, no prueba que la aprobación haya ocurrido como dice haber ocurrido.

Esta evidencia cumple dos funciones distintas. Hacia adentro, es la que te permite reconstruir con precisión qué pasó cuando algo sale mal. Hacia afuera, es exactamente lo que un auditor pide para verificar que la supervisión humana no es una declaración de intenciones sino un proceso demostrable — el detalle de qué constituye evidencia suficiente para un auditor está en auditoría técnica de agentes de IA.

Antipatrones: aprobar todo o no aprobar nada

Dos errores simétricos aparecen una y otra vez en implementaciones reales:

• Aprobar todo. Tratado arriba: satura al aprobador, produce rubber-stamping y termina siendo peor que no tener aprobación, porque además genera una falsa sensación de control ante un auditor o un directorio.
• No aprobar nada. El extremo opuesto: la presión por velocidad de entrega hace que el equipo clasifique casi todo como tier 1 o 2 para no frenar la operación, hasta que una acción genuinamente irreversible pasa sin que nadie la haya mirado. Suele justificarse con "confiamos en el agente", que no es un argumento técnico.

El punto medio no es un promedio entre los dos extremos: es una clasificación honesta por reversibilidad, revisada periódicamente a medida que cambian las capacidades del agente, y con un dial que puede ajustarse —más supervisión para un agente nuevo, menos a medida que acumula historial limpio sin incidentes.

Cómo lo implementa NexusOS

En NexusOS, el gate de aprobación es un paso explícito del pipeline de ejecución —identidad → capability → contrato → política → permisos → riesgo → aprobación → PEP → ejecución → auditoría— y se activa según la clasificación de riesgo por reversibilidad de cada capability. Ninguna acción irreversible atraviesa ese gate sin una identidad humana que la haya autorizado, y esa decisión queda en el mismo audit trail append-only que registra el resto del pipeline. Podés ver el flujo de aprobación operando sobre acciones reales en la demo interactiva.

Preguntas frecuentes

¿Cuántos niveles de aprobación conviene tener?

Con tres alcanza en la gran mayoría de los casos: automático (read-only), automático con límites y monitoreo (reversible dentro de política) y aprobación humana obligatoria (irreversible o fuera de política). Agregar más niveles no mejora el control, lo diluye: cada tier extra es una decisión más para calibrar y una fuente más de ambigüedad sobre a quién le toca aprobar qué. Si un caso no encaja bien en los tres, casi siempre la solución es reclasificar la acción, no inventar un cuarto tier.

¿Quién debería tener permiso para aprobar acciones de un agente?

Alguien con criterio real sobre el dominio de esa acción, nunca el propio agente ni un sistema automatizado que actúe en su nombre. Si un agente de infraestructura pide borrar una base, aprueba quien entiende qué hay en esa base y qué depende de ella —no un aprobador genérico que solo mira un botón "aceptar". Rotar la responsabilidad entre gente sin contexto es la forma más rápida de convertir la aprobación humana en un trámite vacío.

¿Qué pasa si nadie responde a tiempo un pedido de aprobación?

La acción se deniega por defecto. Un timeout que resuelve en ejecución automática convierte la aprobación en una formalidad: cualquier acción irreversible terminaría pasando igual con solo esperar. El costo de una acción legítima demorada es casi siempre menor que el costo de una acción irreversible ejecutada sin que nadie la haya revisado. Denegar por timeout, además, deja evidencia clara de que nadie aprobó, que es justamente lo que un auditor necesita poder distinguir.

¿El human-in-the-loop frena la velocidad de los agentes?

Bien diseñado, no: porque solo interviene en la fracción de acciones irreversibles o fuera de política, y esa fracción suele ser chica frente al volumen total de lo que un agente ejecuta. Lo read-only y lo reversible dentro de política fluye sin fricción. Lo que sí frena la operación es un diseño mal calibrado —pedir aprobación para todo— porque ahí la fricción se vuelve constante y el aprobador deja de leer. La velocidad se protege acotando bien qué requiere humano, no eliminando el control.