La automatización se vuelve arriesgada cuando puede causar efectos irreversibles más rápido de lo que una persona logra entenderlos. Un botón de aprobar no basta: el flujo necesita una propuesta clara, el revisor adecuado, estado pendiente durable, caducidad, protección frente a replay y evidencia de lo ocurrido tras la decisión.
Guarda ID único, identidad del agente, recurso, operación solicitada, nivel de riesgo, instantánea de evidencia, versión de política, creación y vencimiento. La decisión debe apuntar a una propuesta inmutable. Si cambian las entradas, invalida la aprobación y solicita otra revisión; no apliques consentimiento antiguo a una acción distinta.
| Tipo de acción | Política posible | Control de ejemplo |
|---|---|---|
| Reversible y de bajo impacto | Automática con límites estrechos | Actualizar borrador interno o repetir una lectura |
| Efecto relevante para cliente | Un revisor autorizado | Enviar un aviso o cambiar una preferencia de cuenta |
| Alto impacto o financiero | Revisión fuerte, quizá dos personas | Reembolso elevado, datos de pago o bloqueo masivo |
| Prohibida o insegura | Denegación obligatoria, sin excepción | Evitar controles de identidad o extraer datos restringidos |
El riesgo depende del alcance, reversibilidad, importe, personas afectadas y calidad de evidencia, no solo de que la solicitud venga de una IA. La aprobación humana no sustituye autorización, validación de entradas ni mínimo privilegio. El ejecutor debe comprobar otra vez permisos y política después de la aprobación.
Muestra el cambio exacto, objetos afectados, consecuencia prevista, evidencia, incertidumbre, razón de política y una vista previa segura. Distingue explicaciones del modelo de hechos confirmados por el sistema. No preselecciones aprobar ni escondas rechazar. Si faltan datos o confianza, ofrece aplazar o pedir más información.
Autentica al revisor por separado, autorízalo para esa acción y tenant, y vincula el token a una sola propuesta. Usa expiración breve y consumo único; evita que los enlaces de callback se reenvíen o aparezcan en logs. Separa funciones cuando quien propone no deba aprobar acciones de riesgo alto. Registra quién decidió, cuándo, qué versión vio y qué ejecutó el sistema.
El trabajo pendiente requiere un workflow durable, no un proceso esperando en memoria. Al vencer, pasa a un estado seguro: rechazado o requiere atención. Un endpoint idempotente impide ejecutar dos veces un callback duplicado. Usa transición compare-and-swap para evitar que dos revisores consuman la misma propuesta. Si falla la ejecución tras aprobar, conserva la decisión y muestra el fallo: aprobar no equivale a completar.
Sigue tiempo de decisión, aprobaciones y rechazos por nivel de riesgo, vencimientos, excepciones, fallos de ejecución y carga de revisión. Aprobaciones siempre rápidas y sin rechazos pueden ser una simple firma automática. Audita muestras y comprueba que propuestas no aprobadas, vencidas o de otro tenant nunca se ejecuten.
Relacionado: identidad y autorización de agentes y límites de memoria para agentes.
Una aprobación fiable es una transición durable, basada en riesgo y auditable. Muestra exactamente qué ocurrirá, revalida la autoridad al ejecutar, caduca el consentimiento antiguo y evita efectos duplicados. El criterio humano solo ayuda si la persona tiene control y evidencia significativa.