Política de acciones

Pone cada acción del agente en uno de tres niveles: automático, confirmar o prohibido. Define cómo se aprueba una acción: atada a la acción exacta, con vencimiento y una sola vez. También define qué queda en el registro. El ejemplo es el mismo caso de soporte que examples/policies/soporte.json.

Copiá el bloque con el botón de la esquina, o abrí el archivo en GitHub.

templates/es/politica-de-acciones.md

# Política de acciones: [nombre del agente]

<!--
Cómo usar esta plantilla:
- Listá cada acción que el agente puede proponer y ponele un nivel.
- El código aplica la política, fuera del modelo. Una regla en el prompt no es un control.
- El ejemplo es un agente de soporte. Es el mismo caso que examples/policies/soporte.json,
  con los mismos nombres de herramientas y operaciones.
-->

- Agente: [nombre]
- Dueño de la política: [nombre]
- Versión y fecha: [v1, AAAA-MM-DD]

## Los tres niveles

| Nivel | Qué significa | Cuándo va una acción acá |
|---|---|---|
| Automático | El agente la ejecuta sin una persona. | Lecturas. Escrituras baratas, reversibles y dentro del alcance. |
| Confirmar | Una persona aprueba esta acción exacta antes de que corra. | Dinero, mensajes hacia afuera, cambios difíciles de revertir. |
| Prohibido | El agente no la ejecuta nunca, aunque alguien apruebe. | Acciones irreversibles, masivas o fuera del alcance del agente. |

Acción que no está en la tabla: confirmar.

## Acciones

<!--
Una fila por herramienta y operación. La regla con herramienta y operación gana sobre la regla con solo herramienta.
soporte.json guarda la herramienta, la operación y el nivel. La política no puede expresar montos.
El tope del reembolso se aplica dos veces. Primero, la herramienta de reembolsos rechaza un monto mayor al tope.
Segundo, el monto es parte de la acción aprobada (entra en el hash).
-->

| Herramienta | Operación | Nivel | Condición | Por qué |
|---|---|---|---|---|
| pedidos | leer | automático | Solo pedidos del cliente que escribe. | Leer un pedido no cambia nada y no manda nada hacia afuera. |
| clientes | leer | automático | Solo el cliente que escribe. | Es una lectura. Igual queda en el registro, porque son datos personales. |
| clientes | cualquier otra | confirmar | Ninguna. | Una persona mira cualquier otro cambio sobre un cliente antes de que corra. |
| clientes | borrar | prohibido | Ninguna. | Borrar un cliente no se puede deshacer. Lo hace una persona, fuera del agente. |
| reembolsos | crear | confirmar | Hasta [tope] por pedido: la herramienta rechaza un monto mayor. Por encima del tope, lo hace una persona fuera del agente. | Mueve plata. Una persona aprueba el monto exacto antes de que salga. |
| correo | enviar | confirmar | Solo al dueño del pedido. | Comunica hacia afuera. Una persona ve el texto exacto antes de que salga. |
| [...] | [...] | [...] | [...] | [...] |
| cualquier otra | cualquier otra | confirmar | Ninguna. | Ante la duda, una persona decide. |

## Cómo se aprueba

- La aprobación queda atada a la acción exacta: herramienta, operación, destino y parámetros. El código calcula un hash (una huella única) de esos datos.
- Si cambia un parámetro, la aprobación no sirve. El agente pide una nueva.
- La aprobación vence a los [__] minutos.
- La aprobación sirve una sola vez. El código no ejecuta dos veces el mismo hash.
- Incluí en el hash un identificador del pedido de aprobación o de la corrida. Si no, dos acciones legítimas e iguales tienen el mismo hash y el código bloquea la segunda.
- Si algo falla o falta un dato, la acción no corre.
- Quien aprueba ve la acción, los parámetros, por qué la propone el agente y los datos que leyó para proponerla.
- Pueden aprobar: [roles]. No pueden aprobar: [roles, por ejemplo la persona que pidió la tarea].

## Qué se registra

| Campo | Ejemplo |
|---|---|
| Fecha y hora (UTC) | [2026-11-01T14:02:11Z] |
| Corrida e identidad del agente | [corrida 8812, agente-soporte] |
| Acción completa y su hash | [reembolsos.crear, pedido 4471, monto, hash] |
| Nivel y regla que aplicó | [confirmar, regla reembolsos.crear] |
| Propuesta: qué leyó el agente y por qué la propuso | [referencia a la traza, el registro paso a paso de la corrida] |
| Autorización: quién aprobó o rechazó, y cuándo | [nombre, hora] |
| Resultado | [ejecutada / bloqueada / vencida / error] |

- El agente no puede borrar ni editar el registro.
- Retención: [plazo], según [regla interna o ley].

## Revisión de la política

- Cada [periodo], el dueño revisa qué acciones pasaron de confirmar a automático y por qué.
- Medimos cuántas aprobaciones hace cada persona por hora y cuántas rechaza. Si nadie rechaza nada, revisamos si la gente lee lo que aprueba.

## Por qué está esto acá

- Si una sesión junta contenido no confiable, datos sensibles y acciones hacia afuera, el agente necesita supervisión humana: *Agents Rule of Two* (Meta, 2025). Una regla escrita en el prompt no es un control, así que la aprobación la aplica el código: *An AI agent deleted our production database* (Hacker News, 2026).
- Tres niveles (automático, confirmar, prohibido), y vigilar las acciones que pasan de confirmar a automático: *AI agents are easy to build. Accountability is harder.* (r/AI_Agents, 2026).
- Quien aprueba muchas acciones deja de leerlas. En un juego, los jugadores aprobaron 1 de cada 3 amenazas: *Humans missed 1 in 3 threats approving AI agent commands across 40k game runs* (Hacker News, 2026).
- Darle al agente más permisos o autonomía de los que la tarea necesita es un riesgo en sí mismo. Pedí mínimo privilegio por herramienta y aprobación humana para las acciones destructivas: *OWASP Top 10 for Agentic Applications for 2026* (OWASP, 2025).