Cómo diseñar aprobaciones de agentes de IA que sí se puedan revisar

Un botón de aprobación sirve cuando la persona entiende qué autoriza y el sistema respeta esa decisión. En una operación comercial, un “¿continuar?” puede esconder un cambio de precio, un mensaje externo o una edición del expediente del cliente. Diseña la revisión alrededor de una acción de negocio concreta. Después comprueba que la acción ejecutada sea exactamente la que se presentó al responsable.

Lleva la política al trabajo cotidiano

Una política de supervisión establece responsables y límites. El flujo de aprobación los convierte en una bandeja operativa: quién revisa cada acción, qué información recibe, cuánto dura su decisión y qué ocurre si cambian las condiciones. Este artículo desarrolla esa capa práctica. Complementa nuestra guía de supervisión de agentes y permite evaluar cómo se aplica una política durante el trabajo cotidiano.

Imagina un flujo ilustrativo de ventas. Un agente prepara un seguimiento para el responsable de una cuenta con una oferta aprobada y contexto reciente del CRM. La persona puede aprobar el mensaje exacto, pedir cambios o rechazarlo. Preparar, aprobar y enviar son estados distintos. El diseño debe impedir que un borrador o una revisión terminada se registren como una comunicación ya entregada.

Usa una propuesta concreta como plantilla

Este expediente ficticio se puede adaptar al trabajo del equipo. Propuesta: seguimiento de la cuenta A-104, versión 3. Acción: enviar el mensaje mostrado al contacto identificado. Evidencia: solicitud del contacto y registro de oferta aprobada, con sus fechas. Parámetros fijos: destinatario, texto exacto, archivo y condiciones comerciales. Revisor: responsable de la cuenta. Vencimiento: el primero entre el cierre de la oferta y el plazo de revisión definido.

La persona compara el mensaje con el respaldo y elige aprobar, devolver para cambios o rechazar. Su aprobación corresponde únicamente a la versión 3. Cambiar el archivo crea otra versión. El expediente identifica además quién investigará un resultado de entrega incierto. Estos campos forman una especificación reutilizable para conversar con tecnología; incluirlos en un documento no demuestra que un sistema aplique esos límites.

Prepara un expediente de revisión comprensible

Presenta el cambio propuesto y su fundamento en un mismo lugar. Para un mensaje, muestra destinatario, contenido exacto, hechos relevantes y archivos previstos. Para una edición del CRM, compara valor actual y propuesto. Destaca conflictos pendientes y explica por qué se solicita revisión. Una transcripción extensa del agente puede servir de respaldo, pero no debe ocultar la información necesaria para decidir.

Ajusta la extensión al volumen real de trabajo y permite consultar el respaldo cuando haga falta. Prueba la presentación con quienes atenderán la bandeja. Pídeles explicar qué creen estar autorizando antes de pulsar el botón. Si su interpretación difiere de la acción definida, mejora la información y las etiquetas antes de extender el uso. La claridad se debe comprobar, no presumir.

¿Qué acción exacta ocurrirá y en qué sistema?
¿Qué cliente, registro u oferta quedará afectado?
¿Qué evidencia respalda la propuesta y de cuándo es?
¿Qué parámetros quedan fijados por esta aprobación?
¿Qué incertidumbre o excepción debe resolver la persona?
¿Qué sucede si rechaza la propuesta o no responde?

Vincula la decisión con la versión revisada

La aprobación debe identificar una versión específica de la propuesta y las condiciones que mantienen su validez. Si cambia destinatario, oferta, contenido o información relevante, determina cuándo se requiere otra revisión. Define una vigencia adecuada. Una excepción de precio aprobada ayer puede dejar de aplicar cuando termina una promoción o cambia una condición de inventario.

Especifica cómo verificará el sistema esas condiciones antes de actuar. “Aprobado” no debe convertirse en autorización para tareas adicionales. Si una conexión falla después de que el destino aceptó la operación, repetirla sin comprobar puede duplicarla. Solicita al responsable técnico explicar cómo confirma el resultado y trata reintentos. Una respuesta ambigua debe generar una excepción investigable, en lugar de convertirse automáticamente en éxito.

Define estados y próximas acciones permitidas

Utiliza este modelo propuesto como especificación de trabajo. Asigna una persona a cada función y acuerda qué eventos provocan un cambio de estado. Los nombres importan menos que asegurar un responsable y un siguiente paso permitido para cada solicitud.

Observa tiempo por estado, propuestas devueltas y ambigüedades repetidas. Define sustitutos y una ruta de escalación para solicitudes detenidas. Revisar muestras de registros cerrados permite comprobar si la operación conserva este modelo. Un porcentaje alto de aprobación no demuestra por sí solo que las personas entendieron lo que autorizaron.

Pendiente — el revisor decide; puede inspeccionar, devolver o rechazar. Todavía no se permite ejecutar.
Aprobada — el responsable de ejecución verifica versión, vigencia y condiciones; realiza únicamente la acción aprobada si siguen válidas.
Rechazada — el dueño de la propuesta registra el motivo; detiene esa versión. Una propuesta modificada necesita otra revisión.
Vencida — el dueño actualiza la evidencia y solicita otra decisión. La aprobación anterior no autoriza la ejecución.
Resultado ambiguo — el responsable operativo inspecciona el destino; concilia lo ocurrido antes de reintentar y arriesgar una duplicación.
Finalización verificada — el responsable registra evidencia del destino y cierra el caso, sin confundirlo con un resultado comercial.

Prueba también los casos que salen mal

Usa un entorno de prueba acotado y define el resultado esperado de cada escenario. Incluye aprobación válida, rechazo, vencimiento, cambio de evidencia, destino no disponible y respuesta de ejecución ambigua. Verifica tanto la interfaz de revisión como el sistema receptor. Un registro que dice “terminado” no basta cuando el mensaje o la modificación esperada no aparecen donde deberían.

La guía de construcción de agentes de Anthropic aborda puntos de control humano y condiciones de detención. Su guía de evaluación explica la utilidad de probar comportamientos con varios intentos. Son referencias técnicas; el diseño concreto de la bandeja que planteamos aquí es una propuesta operativa editorial. Construcción de agentes, evaluación de agentes.

Conserva evidencia útil y revisa el alcance

Guarda la información necesaria para reconstruir propuesta, decisión y resultado observado en el destino. Define acceso y conservación según los datos involucrados; el historial no debe convertirse en otra copia innecesaria de información sensible. Conserva identificadores y versiones relevantes para investigar una acción en disputa. Suspender nuevas ejecuciones no revierte automáticamente lo que ya ocurrió en otro sistema.

Empieza con un flujo y revisa la evidencia antes de ampliar su alcance. El AI Risk Management Framework de NIST aporta contexto voluntario de gestión de riesgos; seguir este artículo no constituye certificación. NIST AI RMF. Para evaluar AIOS con Nextriad, lleva una acción real, una regla de aprobación y un escenario de fallo. Solicita demostrar los límites aplicados, la información del revisor y la verificación del resultado en el entorno propuesto.