Aprobación humana en agentes de IA: qué contratar

Antes de conectar un agente a una herramienta de escritura, definí tres momentos: preparar una propuesta, autorizar una acción concreta y comprobar su ejecución. Leer información para redactar un borrador requiere un alcance distinto de enviar ese borrador o cambiar un registro. La persona debe poder revisar el efecto antes de que ocurra.

La documentación de revisión humana de herramientas en n8n describe una pausa antes de ejecutar la herramienta elegida: aprobar permite ejecutar los parámetros propuestos y denegar cancela esa acción. Esa capacidad documentada no demuestra que tu flujo esté configurado correctamente.

Pedí al proveedor que identifique el punto de escritura y todas las rutas que llegan a él. Una instrucción en el prompt para pedir permiso no sustituye el control del sistema que ejecuta. OWASP recomienda limitar funciones y permisos, exigir aprobación para acciones de alto impacto y validar la autorización en los sistemas de destino.

Proponemos esta ficha para acordar la entrega con operaciones e IT. Es un criterio de diseño y aceptación: no una funcionalidad que todas las plataformas incluyan. La persona revisora tiene que entender el cambio sin reconstruir la conversación del agente.

La autorización debe corresponder al contenido revisado. Si después cambian el destinatario, los campos, los adjuntos o el alcance del lote, pedí que se prepare otra solicitud. El proveedor debe explicar cómo vincula la decisión con la versión que finalmente ejecuta y cómo trata un dato que cambió mientras esperaba.

Acordá quién puede aprobar cada acción, cómo se comprueba ese rol y quién cubre una ausencia. Tener acceso al canal donde llega el aviso no debe equivaler automáticamente a poder autorizar cualquier operación. El agente tampoco debe aprobar su propia solicitud.

Definí un vencimiento y una salida para cada solicitud: pendiente, rechazada, vencida o cancelada. Para las acciones que decidiste sujetar a autorización, el silencio conserva la pausa. Si necesitás otro comportamiento, tiene que aprobarse como regla del proceso y probarse antes de habilitarlo.

Incluí el trabajo de revisión en el alcance: información que recibe la persona, tiempo disponible y procedimiento para corregir una propuesta. Si todos los casos requieren reconstruir datos a mano, automatizaste la preparación pero todavía no resolviste la operación.

Después de autorizar, registrá si la herramienta ejecutó, si el destino confirmó el efecto y qué quedó pendiente. Una respuesta del modelo que diga «enviado» no reemplaza la confirmación del sistema de mensajes. Guardá un identificador del resultado cuando el destino lo provea.

El caso difícil aparece cuando el destino hizo el cambio, pero la conexión se cortó antes de devolver la confirmación. Pedí un procedimiento para consultar el estado antes de repetir. Acordá una clave estable por operación cuando la integración la admita y un tratamiento explícito cuando no exista: repetir una petición a ciegas puede duplicar su efecto.

Una reversión de archivos o del workflow no debe presentarse como recuperación automática de un mensaje enviado o de una modificación externa. Para cada efecto, pedí qué se puede compensar, quién lo hace y qué no puede deshacerse. La posibilidad de recuperar depende del sistema conectado y del alcance contratado.

Esta matriz usa un ejemplo ficticio: un agente prepara un correo sobre un ticket interno y una persona decide si enviarlo. Los datos y destinatarios de prueba deben estar autorizados y las salidas aisladas. No es un caso de cliente ni una implementación ya probada.

Fijá el resultado esperado antes de ejecutar cada prueba. Conservá versión del flujo, entrada, decisión, intento de herramienta y estado observado en el destino. Proponemos frenar la habilitación de escritura si se ejecuta una acción rechazada, no autorizada o diferente de la revisada; después de corregirla, repetí las pruebas afectadas.

Si tu plataforma ya permite revisar la acción y cumple los casos acordados, el trabajo puede ser configuración y pruebas. Si falta conectar el sistema de destino, vincular la autorización con la operación o verificar el resultado, necesitás una integración. Reservá un desarrollo a medida para las reglas que la plataforma elegida no pueda cubrir; no hace falta cambiar toda la herramienta.

Pedí una matriz de acciones y permisos, el flujo implementado, las reglas de aprobación y vencimiento, pruebas reproducibles, registros con acceso y retención definidos, y una guía para la persona que opera la cola. La propuesta debe identificar qué sistema impide una escritura sin autorización y quién responde ante un resultado incierto.

Separá el relevamiento contratado de la implementación cuando todavía falten datos para definir el alcance. Indicá sistemas, acciones incluidas, entorno, responsables, criterio de aceptación y exclusiones. Mantenimiento, guardia y nuevas integraciones necesitan condiciones propias; aprobar el proyecto no los incorpora automáticamente.

En Duotach desarrollamos agentes de IA conectados a procesos y sistemas de la empresa. Podés consultar por un proceso con una acción de escritura delimitada, una persona responsable y pruebas de aceptación acordadas. El relevamiento y la implementación forman parte del trabajo contratado; el alcance se define según las APIs y reglas disponibles.

Para iniciar la conversación, describí qué acción querés automatizar, en qué sistema termina y quién debe aprobarla. No envíes credenciales ni información sensible por el formulario. Si todavía estás eligiendo quién lo construye, la guía de proveedores de agentes con Claude compara esa decisión más amplia.