¿Qué acciones de los agentes someten los equipos a aprobación humana y con qué frecuencia un control detiene realmente algo?

Pregunta abierta

La especificación del Model Context Protocol (citada) indica que siempre debería haber una persona en el circuito capaz de denegar las invocaciones de herramientas y que las aplicaciones deberían mostrar avisos de confirmación; la entrada «Excessive Agency» de OWASP (citada) recomienda un control con intervención humana (human-in-the-loop) para las acciones de alto impacto. Ambas son pautas de diseño; ninguna informa de cómo se comportan estos controles en producción. El modo de fallo que se menciona con más frecuencia es la fatiga de aprobación: quien debe confirmar cada llamada acaba dejando de leerlas. Lo que falta son datos de operación de agentes en uso habitual (agentes de programación, automatización de soporte, pipelines de datos, agentes de navegación):

• Qué llamadas a herramientas se someten a control: por nombre de la herramienta, por patrón de argumentos (una ruta fuera del espacio de trabajo, un destinatario ajeno a la organización), por umbral de importe o mediante un motor de políticas que evalúa cada llamada.
• Cuántas aprobaciones gestiona una persona por hora o por tarea y cuánto tarda una aprobación típica.
• Qué proporción de las solicitudes se deniega y en cuántos casos la denegación evitó una acción que habría causado daño, en contraposición a una acción inofensiva que el agente luego reformuló.
• Si los equipos que pasaron los controles de nombres de herramientas a patrones de argumentos o umbrales vieron menos avisos sin detectar menos casos.
• Si una aprobación se trata como consentimiento para el resto de la sesión y qué ocurrió cuando así fue.

Sin estas cifras, toda política de control es una conjetura sobre el equilibrio entre rendimiento y la única llamada que debería haberse detenido.

Qué contiene una respuesta útil

La tarea del agente y su conjunto de herramientas; la regla de control exactamente tal como está configurada, incluidas las condiciones a nivel de argumentos; el periodo de observación y el número de ejecuciones; el recuento de avisos, aprobaciones y denegaciones; ejemplos de lo que detectaron las denegaciones y de lo que se coló a través de una aprobación; cualquier medición del tiempo dedicado a las aprobaciones; y los cambios que se hicieron después en las reglas, con su motivo. Los informes de un solo equipo son útiles si lo indican; las propuestas sin experiencia operativa deben etiquetarse como propuestas.