Tu IA dice «listo». ¿Quién comprueba que el pedido quedó bien?
Cómo aprobar, rechazar y detener acciones de IA sin revisar a ciegas ni crear otra cola. Límites concretos para pedidos, citas y atención al cliente.
Da autonomía a tareas concretas y comprobadas. Reserva la aprobación previa para acciones cuyas consecuencias lo justifiquen. La persona debe ver qué cambiará, tener autoridad para rechazarlo y disponer de una forma de detener la ejecución. La revisión también necesita tiempo y seguimiento.
Diseñar una revisión que detecte los errores importantes y permita continuar el trabajo con menos búsqueda, sin tratar una aprobación como prueba suficiente.
El permiso depende de la acción
El agente confirma un cambio de dirección. La supervisora pulsó aprobar. Almacén ya había despachado el pedido. Tres acciones parecen correctas por separado, pero el cliente recibe una promesa que nadie puede cumplir todavía. Este caso hipotético muestra por qué un botón de aprobación no garantiza control.
La supervisión humana empieza al separar esos pasos. Leer el pedido, proponer una dirección, modificarla y avisar al transportista tienen consecuencias distintas. Define permisos para cada acción, con el responsable del proceso, antes de dar al agente acceso a herramientas.
También importa el alcance: corregir un registro y modificar cientos merecen controles diferentes. Limita qué datos puede consultar y cuántos cambios puede ejecutar una solicitud. La seguridad con la que el agente redacta su respuesta no demuestra que tenga información suficiente ni autorización para actuar.
Tres formas de repartir el trabajo
Puedes combinar tareas automáticas, propuestas pendientes y acciones que ejecuta directamente una persona. No necesitas aplicar el mismo nivel de aprobación a todo. Empieza con permisos acotados y amplíalos según resultados observados y consecuencias aceptables.
La siguiente tabla es una propuesta para conversar con tu equipo. El volumen, los datos y las reglas de cada negocio pueden cambiar la decisión.
La objeción habitual tiene sentido: si hay que aprobarlo todo, ¿qué se ganó? La respuesta depende del paso. El agente puede reunir antecedentes y preparar el cambio, de modo que la persona decida con menos búsqueda. Si también automatizas etiquetas reversibles, su control puede ser distinto al de una devolución. Diseña la revisión alrededor de las consecuencias y mide si realmente facilita decidir.
| Acción | Control propuesto |
|---|---|
| Etiquetar una consulta interna | Puede ejecutarse automáticamente si es reversible; revisar una muestra y permitir corregir la etiqueta. |
| Preparar una respuesta al cliente | Guardar como borrador, con la fuente y las condiciones utilizadas. |
| Modificar un pedido | Mostrar el cambio exacto y pedir la aprobación correspondiente antes de ejecutarlo. |
| Aplicar una excepción comercial | La persona autorizada decide sobre precio, devolución o compromiso fuera de las reglas. |
| Borrar información o ampliar accesos | Mantener un circuito específico de autorización y recuperación; no concederlo por una petición ambigua. |
Una aprobación debe poder revisarse de verdad
«¿Apruebas el cambio?» aporta poco si tienes que abrir cuatro pantallas para entenderlo. Muestra el pedido original, el valor nuevo, el motivo y la información que se consultó. Una aprobación útil corresponde a una acción concreta; si esa acción cambia, la aprobación anterior debe dejar de servir.
Una guía de patrones de Microsoft plantea mostrar evidencia y cambios visibles, además de conservar el estado de borrador en el sistema de destino. La idea empresarial es sencilla: quien recibe el trabajo después debe distinguir una propuesta de una decisión terminada.
Define además quién recibe el aviso, quién lo reemplaza y qué pasa mientras esperan. El vencimiento de un plazo no debería convertirse por sorpresa en permiso. Elige expresamente si la solicitud queda pendiente, se cancela o pasa a otra persona.
| Dato visible | Qué recibe la supervisora |
|---|---|
| Cambio solicitado | Pedido P-104: dirección A → dirección B. No incluye permiso para cambiar otros pedidos. |
| Origen y vigencia | Mensaje del cliente vinculado al pedido; estado de almacén consultado a las 10:04, antes de ejecutar. |
| Dato decisivo | El pedido figura despachado. La aprobación de las 10:02 ya no basta para prometer el cambio. |
| Duda y decisión | Falta confirmar si el transportista admite el cambio. El agente detiene la modificación y solicita revisión. |
| Responsable y salida | Logística confirma la posibilidad; atención comunica el estado pendiente previsto. No se envía una confirmación de cambio realizado. |
Cuenta los errores que pasan después de aprobar
Supervisar cuesta atención. Si cada caso obliga a reconstruir toda la conversación, el equipo puede tardar tanto como antes o empezar a aprobar sin leer. Mide minutos por revisión y tiempo en la cola. Con esos datos puedes mejorar la pantalla, reducir el alcance o redistribuir responsables.
Registra también correcciones, rechazos y errores descubiertos después de aprobar. Si una persona acepta una dirección incompleta, el sistema de revisión tiene algo que mejorar, aunque haya quedado registrado un clic. Clasifica la causa para distinguir una fuente equivocada, una propuesta incorrecta o una revisión difícil.
Anthropic diferencia el relato del agente del resultado que existe en la herramienta. Cuando el cambio corresponda y esté autorizado, comprueba que se ejecute una sola vez; cuando deba detenerse, que no se modifique el pedido. Revisa también el mensaje previsto y la ausencia de acciones adicionales. Un texto que dice «listo» es solo una parte de la evidencia.
Repite el pedido inicial con estas variaciones y compara la respuesta observada con la esperada. Registra también los errores que escapan a la revisión: una aprobación registrada puede ser incorrecta. Pide a la supervisora que explique qué dato cambió su decisión.
| Situación de prueba | Resultado esperado |
|---|---|
| Despacho posterior a la aprobación | Detener el cambio; consultar a logística; conservar el motivo y el estado pendiente. |
| Solicitud duplicada | Identificar la acción ya registrada y no volver a modificar ni enviar el aviso. Si no puede comprobar el estado, escalar. |
| Dirección incompleta | Mostrar el dato faltante, pedirlo y mantener el borrador; no completar por suposición. |
Una revisión útil empieza por una entrega que se pueda comprobar
Si la supervisora no encuentra el estado de despacho, repetirle que tenga cuidado ayudará poco. Hamel Husain muestra ejemplos interactivos de cómo mejorar la entrega. Nuestra ficha aplica ese criterio al pedido hipotético.
Husain vincula la dificultad de evaluar una respuesta con el diseño del producto que la entrega. Presenta ejemplos de herramientas que producen análisis, planes o informes difíciles de comprobar. Su punto sitúa parte del problema en cómo se muestra el trabajo al usuario, antes de exigirle una revisión más rápida.
Ensaya cómo parar y continuar el trabajo
Antes del lanzamiento, prueba una solicitud incompleta, una conexión caída, una aprobación rechazada y una petición duplicada. Comprueba quién ve el problema y cómo sigue el pedido manualmente. El registro debe permitir saber qué se ejecutó y qué permanece pendiente, sin exponer información innecesaria.
El marco voluntario NIST AI RMF contempla responsabilidades de supervisión y mecanismos para desactivar sistemas cuando su funcionamiento se aleja de lo esperado. En una empresa pequeña puede traducirse en responsables claros, un control de pausa y un procedimiento de recuperación que el equipo haya ensayado.
El caso inicial termina cuando logística resuelve la posibilidad del cambio y atención comunica lo que efectivamente ocurrió. Ese cierre, y su registro en el pedido, es lo que permite aceptar el trabajo. Amplía la autonomía únicamente en los pasos que tu equipo ya puede revisar, detener y retomar.
