Un agente puede consultar un pedido sin ayuda. El problema empieza cuando la misma ejecución también puede enviar un correo, borrar un registro, publicar un cambio o modificar un permiso. Si todo necesita confirmación, el equipo empieza a hacer clic sin leer. Si nada la necesita, una llamada mal interpretada puede producir un efecto difícil de deshacer.

La respuesta práctica es clasificar la acción, no el agente completo. Las lecturas y los cambios reversibles pueden seguir de forma autónoma. Las acciones de alto impacto o difíciles de revertir deben detenerse antes del efecto externo. La ejecución durable para agentes de IA complementa este diseño cuando la aprobación tarda y el flujo debe reanudarse después.

Diagrama muestra un agente de IA que separa lecturas, notificaciones y acciones de alto riesgo antes de la aprobación humana.

Respuesta corta

  • Pide aprobación para una acción concreta cuando equivocarse sea costoso, difícil de deshacer o requiera que otra persona responda por la decisión.
  • Toma la decisión en el runtime, después de validar la tool y antes del efecto externo. No dejes que el modelo autorice su propia llamada.
  • Muestra el payload exacto, persiste el estado pendiente e invalida la aprobación si cambian los argumentos o el objetivo.

¿Por qué un agente no debe pedir aprobación para cada tool?

En 2026, la guía de AWS sobre supervisión de agentes separa las acciones en niveles autónomo, notificación y aprobación según su impacto y reversibilidad (AWS, “Establish tiered human oversight and approval workflows”, 2026). Esta separación evita dos errores opuestos: bloquear el trabajo sencillo y dejar que una acción grave pase sin revisión.

Consultar el estado de un pedido suele ser reversible porque no cambia el sistema. Un borrador quizá solo necesita quedar registrado. Borrar datos, enviar un mensaje externo, cambiar permisos o confirmar una transacción cambia el mundo fuera del loop. La categoría de la tool ayuda, pero el contexto también importa: objetivo, valor, identidad, frecuencia y capacidad de deshacer la acción.

El modelo no debe decidir su propia categoría. Un prompt puede pedirle cuidado, pero no crea un límite de autorización. Trata la salida del modelo como una propuesta. La política en código debe decidir si esa propuesta continúa, crea una notificación o se convierte en trabajo pendiente.

¿Cómo clasificar las acciones por riesgo y reversibilidad?

Empieza con tres niveles sencillos. AWS recomienda que las acciones autónomas sean de bajo riesgo y reversibles, que las acciones de notificación avancen con visibilidad del operador y que las acciones de aprobación sean de alto riesgo o irreversibles (AWS, “Establish tiered human oversight and approval workflows”, 2026). Esta tabla es un punto de partida, no una política universal.

Nivel Ejemplos Comportamiento del runtime
Autónomo Leer un catálogo, consultar un pedido, calcular una vista previa Validar, ejecutar y registrar el resultado.
Notificar Actualizar un borrador, reclasificar un elemento, preparar una respuesta Ejecutar dentro de límites y avisar al responsable.
Aprobar Enviar un mensaje externo, borrar datos, cambiar acceso, confirmar un cobro Pausar antes del efecto y esperar una decisión explícita.

No midas el riesgo por el número de llamadas. Una sola escritura puede ser más peligrosa que cien lecturas. Pregunta qué cambia, quién queda afectado, si la acción puede deshacerse y quién tiene autoridad para aceptarla. Si la respuesta no es clara, prefiere una decisión pendiente o un rechazo seguro hasta definir el contrato.

¿Qué debe ver el revisor antes de aprobar?

En 2026, la guía de AWS para decisiones críticas pide contexto suficiente para entender la operación, el impacto y las consecuencias, además de registrar identidad, marcas de tiempo, decisiones y escalaciones (AWS, “Human-in-the-loop for critical decisions”, 2026). Un botón que dice “aprobar acción del agente” no constituye una revisión útil.

La solicitud de aprobación debe representar la llamada que se va a ejecutar. Incluye como mínimo:

  • nombre de la tool y versión del contrato;
  • argumentos normalizados y objetivo que va a cambiar;
  • motivo operativo y resultado esperado;
  • datos relevantes usados para construir la llamada;
  • riesgo, reversibilidad y camino de compensación;
  • versión de la política, identidad del agente y caducidad;
  • un identificador único que una propuesta, decisión y resultado.

No pidas al modelo que resuma la acción para mostrar solo ese resumen. La interfaz debe exponer los argumentos reales. Si el runtime obtiene nuevos datos después de la aprobación y reconstruye el payload, esa llamada necesita otra evaluación. El revisor aprobó una operación concreta, no una intención abierta.

¿Dónde debe estar el gate de aprobación?

Coloca el gate entre la validación determinista de la llamada y la ejecución del efecto externo. La guía de AWS coloca la revisión de acciones mutables en el camino de ejecución, no solo en el prompt (AWS, “Implement tool authorization”, 2026). Así, una instrucción hostil o una decisión equivocada del modelo no puede llegar directamente al endpoint de autorización.

El flujo mínimo es:

  1. El modelo propone una tool y sus argumentos.
  2. El runtime valida formato, identidad, alcance y precondiciones.
  3. Una política determinista clasifica el riesgo.
  4. El runtime ejecuta, notifica o crea una solicitud pendiente.
  5. El executor confirma que la decisión pertenece a la misma llamada.
  6. La tool produce el efecto y registra el resultado junto al ID de la decisión.

El código siguiente es ilustrativo. policy, savePending y execute son adaptadores que necesitan sus propias reglas y almacenamiento en un sistema real.

type Decision = "autonomous" | "notify" | "approve";

async function runTool(call: unknown) {
  const parsed = ToolCall.safeParse(call);
  if (!parsed.success) return { status: "rejected", reason: "invalid_input" };

  const decision: Decision = policy.evaluate(parsed.data);

  if (decision === "approve") {
    const pending = await savePending({
      tool: parsed.data.tool,
      arguments: normalize(parsed.data.arguments),
      policyVersion: policy.version,
    });
    return { status: "pending", approvalId: pending.id };
  }

  return execute(parsed.data, { notify: decision === "notify" });
}

El executor no debe recibir un “sí” suelto. Debe cargar la solicitud pendiente, comparar tool, argumentos normalizados, objetivo y versión de la política, y rechazar cualquier diferencia. Validar tool calls de agentes de IA con TypeScript explica la frontera anterior, donde input y output deben tratarse como datos no confiables.

¿Cómo pausar y reanudar un agente después de la decisión?

El SDK de OpenAI Agents modela la aprobación como una interrupción: la ejecución se pausa, el estado puede convertirse en RunState, una persona aprueba o rechaza la llamada y el runtime reanuda desde ese estado (OpenAI Agents SDK, “Human-in-the-loop”, 2026). La persistencia es lo importante. Una aprobación que solo existe en la memoria del proceso desaparece cuando el worker se reinicia. Este estado explícito encaja con el diseño de máquinas de estados para agentes de IA: la aprobación es una transición observable, no un detalle escondido en el prompt.

Guarda la solicitud pendiente en almacenamiento durable con el ID de ejecución, tool, argumentos, política, caducidad y estado. Otro worker puede reanudar el flujo, pero la decisión debe seguir ligada a la misma llamada. Si la aprobación puede quedar abierta un tiempo, guarda también una versión del agente o del contrato para que una definición nueva no ejecute una solicitud antigua.

El timeout también es una decisión. Si el revisor no responde, el sistema puede rechazar, enviar la solicitud a otra persona o mantenerla bloqueada. No debe liberar la acción porque nadie respondió. AWS recomienda definir timeout, escalación y fallback seguro para que el workflow no quede detenido sin dueño (AWS, “Human-in-the-loop for critical decisions”, 2026).

En ejecuciones largas, uso RemoteCode para mantener contexto y evidencia entre sesiones largas de agentes. Es una herramienta mía. La mención encaja aquí porque la aprobación debe sobrevivir al intervalo entre la propuesta y la reanudación sin depender de la memoria del proceso.

¿Qué fallos convierten la aprobación en una formalidad?

Una aprobación puede existir en la base de datos y aun así no proteger nada. El primer problema es aprobar un resumen mientras el executor usa argumentos distintos. El segundo es dejar que el propio agente alcance el endpoint de autorización. El tercero es pedir revisión para cada llamada hasta que la gente deje de leer.

El caso GhostApproval muestra una variación importante: una persona puede aprobar una ruta aparente mientras el runtime escribe en el objetivo resuelto. El mismo principio se aplica a las tools. El revisor debe ver el recurso real que va a cambiar y el executor debe aplicar el mismo límite después del clic.

También existe una brecha entre el efecto externo y su recibo. Una API puede completar la operación y la aplicación puede caerse antes de guardar el resultado. Un retry ingenuo puede enviar el mensaje o crear el registro dos veces. Para cada acción aprobada, define una clave de idempotencia, una consulta de estado o un camino de compensación antes de permitir una repetición.

¿Cómo verificar que el gate protege la tool?

Prueba el executor sin depender de que el modelo elija el camino correcto. El test debe demostrar el comportamiento de la frontera y dejar claro qué ocurre cuando el flujo se detiene a mitad.

  • una lectura válida continúa sin aprobación;
  • una escritura de bajo impacto sigue su nivel definido y genera una notificación;
  • una escritura de alto impacto crea una solicitud pendiente antes de llamar al servicio;
  • los argumentos cambiados después del clic requieren otra aprobación;
  • una política nueva no ejecuta una solicitud creada con una versión incompatible;
  • rechazo y timeout no llaman a la tool;
  • reanudar dos veces no crea dos efectos externos;
  • la observabilidad de agentes de código hace que esa traza se pueda buscar; los logs relacionan agente, tool, argumentos, decisión, revisor, tiempos y resultado.

El criterio no es “apareció un botón”. Debes poder demostrar que la llamada que vio la persona es la llamada que aceptó el executor. Si no puedes comprobar esa igualdad, la aprobación es solo una capa de interfaz.

Preguntas frecuentes

¿Toda tool que escribe en una base de datos necesita aprobación?

No. Una escritura pequeña, reversible y limitada puede ser autónoma o solo notificar cuando la política, el alcance y la compensación estén claros. La aprobación debe seguir el impacto y la reversibilidad. Cambiar permisos, borrar datos o cruzar una frontera de confianza merece un control más fuerte que actualizar un borrador interno.

¿Puede el modelo decidir cuándo pedir aprobación?

Puede aportar señales, pero no debe ser la autoridad final. El runtime necesita reglas independientes sobre tool, objetivo, identidad, valor, contexto y reversibilidad. Si la clasificación depende solo del texto del agente, una instrucción inyectada puede intentar rebajar una acción peligrosa al camino autónomo.

¿La aprobación humana elimina el riesgo de prompt injection?

No. Limita la autonomía de algunas acciones, pero no corrige una validación débil, permisos amplios, payloads mutables o una interfaz que oculta el objetivo real. Mantén la autorización fuera del alcance del agente, muestra argumentos concretos y prueba entradas hostiles junto al camino normal.

Conclusión

Un agente debe pedir aprobación humana cuando está a punto de producir un efecto de alto impacto, difícil de deshacer o que exige responsabilidad explícita. El bloqueo pertenece al runtime, después de validar y antes de la tool, con la decisión ligada al payload exacto.

Empieza con tres niveles: autónomo, notificar y aprobar. Persiste el trabajo pendiente, define el timeout, invalida las llamadas que cambiaron y prueba el replay como cualquier otra operación con efecto externo. Así la persona revisa las decisiones que importan y el agente sigue siendo útil para el trabajo repetible.

Fuentes consultadas

  • OpenAI Agents SDK, “Human-in-the-loop”, consultado en 2026-08-20, https://openai.github.io/openai-agents-python/human_in_the_loop/
  • AWS, “Establish tiered human oversight and approval workflows”, consultado en 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentrel02-bp05.html
  • AWS, “Human-in-the-loop for critical decisions”, consultado en 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec04-bp02.html
  • AWS, “Implement tool authorization”, consultado en 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec02-bp01.html
  • Reddit, “Approval is not review if the human cannot inspect the action”, consultado en 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1t7d3cb/approval_is_not_review_if_the_human_cannot/
  • Reddit, “Human in the loop is meaningless unless we define what was approved”, consultado en 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1vhvqp0/human_in_the_loop_is_meaningless_unless_we_define/
  • Reddit, “Human approval on agent writes is mostly theater”, consultado en 2026-08-20, https://www.reddit.com/r/mcp/comments/1uzsx6h/human_approval_on_agent_writes_is_mostly_theater/