# Aprobación de acciones de un agente: cómo pedir permiso sin frenar el trabajo > La aprobación de acciones es el paso donde una persona autoriza lo que hará un agente de IA antes de que ocurra. Cómo diseñar la pregunta y evitar la fatiga. *Tags: ia, agentes, permisos, ux* --- > [!info] Definición Rápida > La **aprobación de acciones de un agente** es el paso en el que el sistema se detiene antes de ejecutar una acción sensible y pide a una persona que la autorice o la rechace. La acción no ocurre hasta que hay una decisión registrada, y esa decisión puede ser de una sola vez o quedar como regla para casos parecidos. ## ¿Qué se aprueba exactamente? Un agente hace muchas cosas, pero no todas merecen una pregunta. Se aprueban las acciones que tienen efecto difícil de revertir o que salen del sistema: escribir en un archivo del proyecto, ejecutar un comando de terminal, enviar un correo, crear un pago, borrar un registro. En Claude Code, por ejemplo, el modo Manual (el predeterminado) separa tipos de herramienta. Leer archivos dentro del directorio de trabajo no pide aprobación. Editar archivos sí, y los comandos de terminal también, salvo un conjunto integrado de comandos de solo lectura. Las búsquedas web también piden permiso. Esa separación es un buen punto de partida: no todo lo que hace un agente tiene el mismo riesgo. Para decidir qué puntos de control poner en el flujo completo, revisa [[human-in-the-loop|human-in-the-loop]]. Y para las reglas que limitan lo que el agente puede hacer aunque nadie apruebe, [[guardrails|guardrails]] es la capa de fondo. ## ¿Cómo debe ser la pregunta? Una pregunta de aprobación que solo dice "¿Permitir esta acción?" no le sirve a nadie. La persona necesita decidir con información. La pregunta debe mostrar cuatro cosas: 1. **La acción exacta.** El comando completo, el correo con destinatario, el monto, el archivo y el cambio que va a hacer. 2. **El motivo.** Por qué el agente quiere hacerla, en una frase, dentro del plan. 3. **Lo que cambia o sale.** Qué queda modificado, a quién llega, qué no se puede recuperar. 4. **Las opciones.** Aprobar esta vez, rechazar, modificar la acción antes de aprobarla, y en algunos casos recordar la decisión para ese tipo de acción. El aviso de Claude Code cumple parte de esto: muestra la descripción de la acción y el comando exacto (por ejemplo, `npm test`) y ofrece "Yes", "Yes, and don't ask again for: npm test *" y "No". La segunda opción guarda una regla: para comandos de terminal, de forma permanente en ese repositorio; para ediciones de archivos, hasta que termina la sesión. Por eso conviene leer el patrón antes de aceptarla y preferir los estrechos. Además, con la tecla Tab puedes adjuntar una nota al aprobar o rechazar. ## ¿Cómo evitar la fatiga? La fatiga de aprobaciones ocurre cuando la persona aprueba tanto que deja de leer. Es un riesgo conocido de este diseño: el control parece existir y no existe. Tres prácticas ayudan: - **Pide aprobación solo por lo que importa.** Si todo pide permiso, nada lo tiene. Revisa qué acciones son irreversibles o externas y deja el resto automático. - **Agrupa acciones parecidas.** Diez ediciones en diez archivos del mismo cambio se pueden aprobar como un paquete, con su diferencia visible, en vez de diez preguntas seguidas. - **Ofrece reglas acotadas.** Una regla como "permitir comandos de tests de este repositorio" es razonable. Una regla como "permitir todo" anula el sistema. El SDK de agentes de OpenAI permite decisiones persistentes (`always_approve` y `always_reject`) que valen para las llamadas futuras de la misma herramienta; en una herramienta de función, además, quedan atadas al agente que pidió la aprobación. Claude Code también ofrece modos que cambian qué se pregunta. En `acceptEdits`, las ediciones dentro del directorio de trabajo se aprueban solas. En `auto`, un clasificador revisa las acciones en lugar de la persona, pensado para tareas largas y para reducir la fatiga. Son atajos útiles, pero mueven la decisión de lugar: antes de usarlos, confirma qué sigue pidiendo permiso. ## ¿Qué pasa al rechazar? Un rechazo es información útil, no un fallo. El agente debe recibirlo y cambiar de camino: proponer una alternativa, preguntar qué cambiar o detenerse. Lo que no debe hacer es intentar la misma acción con otro nombre o con otra herramienta, porque eso burla la decisión de la persona. Si la acción ya fue aprobada y luego resulta mala, el problema pasa a otra página: [[deshacer-acciones-de-agentes|deshacer lo que hizo un agente]]. Por eso conviene que el rechazo pueda llevar un motivo corto. "No, este correo va al cliente equivocado" le sirve al agente para corregir el plan, y deja un registro de por qué se detuvo. Claude Code lo permite: el comentario de un "No" le llega a Claude como motivo del rechazo y sigue trabajando; si rechazas sin comentario, el turno se detiene. El SDK de OpenAI acepta un `rejection_message` en cada rechazo. ## Ejemplo Ejemplo ilustrativo: un agente prepara un cambio en el código de una página de precios. Lee los archivos y propone cambios sin pedir permiso, porque no tocan nada todavía. Cuando llega a la hora de editar el archivo de configuración de pagos, se detiene y muestra: "Editar `config/pagos.ts`: cambia el precio del plan anual de 96 a 120 dólares. Motivo: el plan se actualizó en el brief. Opciones: aprobar, rechazar, o editar el valor antes de aplicar". La persona corrige el valor a 110 y aprueba. El agente aplica ese valor, no el que propuso. La decisión quedó registrada con el cambio exacto. ## ¿Cuándo NO conviene pedir aprobación? - **En acciones reversibles y de bajo riesgo,** como crear un borrador o leer un archivo. La pregunta solo añade ruido. - **Cuando la aprobación llega después del efecto.** Si el aviso aparece después de enviar el correo, es notificación, no control. - **Cuando la persona no tiene contexto para decidir.** Una pregunta sin motivo ni detalle no protege a nadie; solo traslada la responsabilidad. ## ¿Qué conviene registrar de cada decisión? Guarda quién decidió, cuándo, qué acción exacta se aprobó, si la persona la modificó antes de aprobarla y, en el rechazo, el motivo. Esa bitácora sirve para tres cosas: auditar un incidente, ver qué tipos de acción se rechazan con más frecuencia y ajustar las reglas. Si el registro solo dice "aprobado", no sirve para aprender de los errores. ## Errores comunes - Pedir permiso para todo, y terminar con aprobaciones automáticas. - Mostrar solo el nombre de la herramienta, sin el comando o el destinatario. - Ofrecer "permitir siempre" sin acotar a qué aplica. - Reintentar la misma acción tras un rechazo, con otro nombre. - No guardar la decisión: no se puede auditar qué se aprobó. ## Fuentes - [Configure permissions (Claude Code, documentación)](https://code.claude.com/docs/en/permissions) - [Choose a permission mode (Claude Code, documentación)](https://code.claude.com/docs/en/permission-modes) - [Human-in-the-loop (OpenAI Agents SDK, documentación)](https://openai.github.io/openai-agents-python/human_in_the_loop/) --- Source: https://www.fernandoux.com/es/wiki/ia/aprobacion-de-acciones/