Intro
Cuando un agente puede leer, escribir, ejecutar herramientas o afectar sistemas reales, la discusión sobre approvals deja de ser teórica. Ya no alcanza con preguntarse si conviene meter a una persona “en el loop”. La pregunta útil es otra: ¿en qué punto la aprobación humana agrega control real y en qué punto solo agrega fricción?
Un sistema de approvals bien diseñado puede reducir errores costosos, frenar acciones ambiguas y mejorar la trazabilidad. Uno mal diseñado puede volver inútil al agente, cansar al operador y empujar a aprobar sin mirar.
Por eso conviene pensarlos como un mecanismo de control proporcional al riesgo, no como una barrera obligatoria para todo.
Cuándo tiene sentido pedir aprobación
No todas las acciones del agente merecen supervisión humana. En general, un approval empieza a tener sentido cuando aparece alguna de estas condiciones.
1. La acción es irreversible
Borrar datos, enviar comunicaciones externas, ejecutar cambios en producción o disparar procesos difíciles de deshacer son buenos candidatos para aprobación humana.
2. Hay datos sensibles o alcance delicado
Si el agente va a tocar información personal, credenciales, configuraciones críticas o activos con impacto de negocio, conviene que una persona valide la intención y el alcance.
3. El impacto sale del entorno local
Una cosa es leer estado o preparar un borrador. Otra muy distinta es publicar, desplegar, enviar, comprar, cerrar o modificar algo en un sistema externo.
4. Hay baja confianza o ambigüedad
Si el agente detecta conflicto entre instrucciones, contexto incompleto o señales mixtas sobre el siguiente paso, pedir aprobación puede ser mejor que improvisar.
La lógica importante es esta: el approval debería concentrarse en el borde de las acciones sensibles, no en cada paso del flujo.
Por qué aprobar todo es una mala idea
A primera vista, pedir aprobación para todo parece prudente. En la práctica suele generar el efecto contrario.
Fatiga de aprobación
Si el operador tiene que confirmar veinte acciones inocuas por día, deja de mirar con atención. Cuando llega una acción realmente riesgosa, la interfaz ya lo entrenó para hacer clic sin pensar demasiado.
Pérdida de velocidad sin ganancia real
Muchas tareas de bajo riesgo, como leer archivos, consultar estado o correr chequeos inocuos, pueden ejecutarse con controles automáticos y dejar evidencia sin necesidad de detener a una persona.
Requests vagos que no ayudan a decidir
Un mensaje como “el agente quiere continuar” no sirve. Tampoco ayuda demasiado “el agente necesita permisos”. Si no queda claro qué va a pasar, sobre qué recurso, con qué alcance y por qué, la aprobación es casi cosmética.
Incentivo a diseñar peor el resto del sistema
Cuando todo depende de que una persona apruebe, algunos equipos se relajan con permisos, sandboxing, validaciones y logs. Eso es un error. El approval no debería compensar una arquitectura floja.
Qué debe mostrar un approval útil
Para que la intervención humana sirva de verdad, la solicitud de aprobación tiene que ser concreta.
1. Acción exacta
La persona debería ver qué quiere hacer el agente. No una descripción abstracta, sino la acción concreta: publicar un artículo, ejecutar un comando, escribir en una ruta, invocar una API, borrar un recurso o enviar un mensaje.
2. Alcance y destino
No es lo mismo “actualizar un archivo” que “actualizar este archivo en producción”. Tampoco es lo mismo “consultar clientes” que “exportar toda la base”. El approval útil muestra alcance real.
3. Motivo y contexto
También conviene explicar por qué el agente llegó a esa acción. Qué intentó hacer antes, qué evidencia observó y qué resultado espera conseguir.
4. Efecto esperado y riesgo principal
No hace falta dramatizar, pero sí ser claro. ¿La acción es reversible? ¿Puede afectar usuarios? ¿Puede modificar datos? ¿Requiere credenciales? ¿Es un paso normal o una excepción?
5. Opciones más ricas que sí o no
Aprobar y rechazar es el mínimo. En muchos casos conviene permitir ajustar. Por ejemplo:
- aprobar solo en staging,
- limitar la ruta o el recurso,
- pedir más evidencia antes de seguir,
- o autorizar una sola ejecución en vez de una aprobación amplia.
Ese matiz mejora mucho el control sin obligar a reiniciar todo el flujo.
Un buen criterio es decidir por política, no por impulso
Los approvals funcionan mejor cuando nacen de una política legible. Eso evita arbitrariedad y hace que el agente, el operador y el equipo entiendan por qué ciertas acciones escalan y otras no.
Una política razonable suele combinar al menos cuatro dimensiones:
- impacto,
- irreversibilidad,
- sensibilidad del recurso,
- y nivel de confianza en el paso siguiente.
Con eso ya se puede construir algo bastante sano.
Riesgo bajo
Lectura de estado, chequeos locales, borradores no publicados, análisis sin efectos externos. En general, no requieren approval si hay límites claros y evidencia suficiente.
Riesgo medio
Escrituras acotadas, cambios recuperables, acceso acotado a información interna o acciones sobre entornos no productivos. Pueden pedir approval según contexto o política.
Riesgo alto
Cambios en producción, acciones irreversibles, acceso amplio a datos sensibles, publicación externa, gasto económico o eliminación de recursos. Acá la aprobación humana suele ser obligatoria.
Lo que los approvals no resuelven por sí solos
Este punto importa porque evita falsas sensaciones de seguridad.
No reemplazan permisos finos
Si el agente puede hacer demasiado, el approval llega tarde. El principio de mínimo privilegio sigue siendo necesario.
No reemplazan sandboxing
Si una herramienta puede dañar demasiado cuando se ejecuta, el entorno tiene que limitar ese daño incluso antes de pedir aprobación.
No corrigen alucinaciones o mala interpretación
La persona puede aprobar algo mal presentado. Si el request está incompleto o es opaco, el problema no desaparece por poner a un humano en el medio.
No sustituyen validaciones y evidencias
Un approval no debería ser el único control previo a una acción sensible. Siempre que se pueda, conviene acompañarlo con checks mecánicos, logs y trazabilidad.
Cómo se ve un diseño más sano en la práctica
Una arquitectura razonable suele separar el flujo en capas.
- acciones rutinarias y de bajo riesgo: avanzan solas con controles automáticos;
- acciones sensibles o ambiguas: escalan a un approval humano;
- acciones críticas: además del approval, requieren evidencia visible, política explícita y registro auditable.
Eso reduce fricción donde no aporta valor y reserva la atención humana para el punto donde sí cambia el resultado.
También conviene registrar:
- qué acción se pidió,
- quién la aprobó o rechazó,
- en qué contexto,
- con qué evidencia,
- y si las condiciones cambiaron después.
Sin ese rastro, el approval sirve poco cuando hay que auditar un incidente o entender por qué el agente terminó actuando de cierta manera.
Una regla práctica bastante útil
Si el costo de equivocarse es mayor que el costo de interrumpir el flujo, probablemente conviene pedir aprobación.
Si el costo de interrumpir es mayor y la acción es observable, reversible y de bajo impacto, probablemente conviene automatizar.
No es una fórmula perfecta, pero ayuda a evitar dos extremos igual de malos: la autonomía ciega y la aprobación permanente.
Entonces, ¿cómo se diseñan bien?
Una forma madura de pensar approvals en agentes es esta:
- pedirlos solo donde el riesgo lo justifica,
- mostrar acción, alcance, motivo y efectos esperados,
- permitir aprobar, ajustar o rechazar,
- dejar trazabilidad posterior,
- y combinarlos con permisos, sandboxing, validaciones y logs.
Ahí es donde el approval deja de ser un popup molesto y pasa a ser un control operativo útil.
La idea importante para llevarse
Los approvals no deberían existir para recordarnos que “hay un humano mirando”. Deberían existir para intervenir justo cuando el agente está por cruzar un umbral de riesgo que no conviene automatizar a ciegas.
Diseñarlos bien no significa aprobar más. Significa aprobar mejor, en menos momentos, con más contexto y con una política coherente detrás.