Agentes de IA: cuándo una acción debe poder deshacerse

Un agente de IA puede crear una tarea, preparar una cotización, actualizar un registro o enviar una comunicación. En una demostración, todas esas acciones parecen parte del mismo recorrido. Para la empresa, tienen consecuencias muy distintas.

Si una clasificación interna queda mal, alguien puede corregirla. Si el agente confirma un precio, elimina un documento o envía una promesa a un cliente, la corrección puede llegar tarde. La pregunta que conviene hacer antes de ampliar los permisos es sencilla: ¿qué ocurre si esta acción se equivoca y cuánto cuesta volver al estado anterior?

La capacidad de deshacer una acción no elimina el riesgo. Sí cambia la forma de probarla, autorizarla y responder cuando algo sale mal. El AI Risk Management Framework de NIST recomienda documentar responsabilidades, límites, evaluación y monitoreo del sistema durante su ciclo de vida. En un agente empresarial, eso incluye saber qué acciones pueden revertirse y bajo qué condiciones.

No todas las acciones dejan el mismo tipo de huella

Leer una política vigente deja una huella de consulta. Preparar un borrador deja un resultado que una persona puede revisar. Crear una etiqueta interna modifica un sistema, pero suele ser fácil de identificar y corregir. Enviar un correo, publicar una respuesta, borrar un registro o confirmar una obligación comercial afecta a otras personas y puede abrir consecuencias difíciles de recuperar.

Una clasificación útil debe mirar la huella que deja la acción, no lo sofisticado que sea el agente. Para cada capacidad conviene registrar:

• qué sistema cambia;
• quién puede verse afectado;
• qué evidencia queda guardada;
• cuánto tiempo existe para corregir;
• quién puede autorizar la acción;
• qué parte del resultado se puede revertir.

El artículo de OWASP sobre agencia excesiva recomienda limitar herramientas y permisos, ejecutar las acciones en el contexto del usuario y exigir aprobación humana para acciones de alto impacto. La recomendación es concreta: el agente no debe decidir por sí mismo que una acción está autorizada solo porque recibió una instrucción convincente.

Qué significa realmente poder deshacer

“Tenemos respaldo” no equivale a “podemos deshacer la acción”. Un respaldo puede recuperar una base completa, pero no necesariamente permite identificar qué cambió el agente, restaurar solo ese cambio y conservar las modificaciones legítimas que ocurrieron después.

Tampoco es lo mismo corregir un dato que revertir una consecuencia. Se puede cambiar de nuevo el estado de una oportunidad en el CRM, pero no borrar el mensaje que ya recibió el cliente. Se puede retirar una publicación, pero no controlar todas sus copias. Se puede anular una tarea, pero no recuperar el tiempo que otro equipo gastó trabajando con información incorrecta.

Por eso la reversibilidad tiene varios niveles. Una acción puede ser completamente reversible dentro del sistema, reversible solo mediante una revisión manual o imposible de deshacer una vez que sale hacia un tercero. Esa diferencia debe aparecer en el diseño y en la conversación comercial con el proveedor.

La primera autonomía debería dejar una salida clara

Para un primer piloto, suelen ser más razonables las acciones que permiten inspección y corrección. El agente puede clasificar una solicitud, proponer una respuesta, crear una tarea interna pendiente o señalar que faltan documentos. La empresa observa si el resultado es útil antes de permitirle confirmar, enviar o eliminar.

La salida debe estar visible para la persona responsable. Si un agente prepara una actualización para el CRM, la interfaz debería distinguir entre propuesta y cambio aplicado. Si crea un borrador de correo, debe mostrar destinatario, fuentes y supuestos antes del envío. Si detecta un expediente incompleto, debe indicar el faltante sin convertirlo automáticamente en rechazo.

La automatización de procesos aporta más cuando hace visibles esos estados. Un flujo con pendiente, revisión, aprobado, ejecutado y revertido permite saber qué pasó con cada caso. Sin esos estados, el agente puede parecer eficiente mientras esconde trabajo de corrección.

Las acciones difíciles de revertir necesitan otra barrera

Hay acciones que deberían requerir confirmación explícita porque su efecto alcanza a un cliente, a un tercero o a una condición económica. Entre ellas pueden estar publicar contenido, enviar comunicaciones externas, confirmar precios, aprobar pagos, modificar datos de identidad, eliminar información o cerrar un caso con implicaciones contractuales.

La confirmación no debe ser una pantalla vacía con un botón de aceptar. La persona que autoriza necesita ver qué se hará, con qué datos, para quién, desde qué fuente y qué condición activó la propuesta. Si el agente no puede explicar esos puntos, la acción todavía no está lista para ejecutarse.

También conviene separar al preparador del autorizador. El agente puede reunir la información y dejar el trabajo listo, mientras que la persona responsable confirma el cambio desde el sistema que lo ejecutará. Así la aprobación no depende de que el modelo interprete correctamente una frase dentro de la conversación.

La reversa también necesita pruebas

Un equipo puede probar que el agente ejecuta una acción y olvidar probar la vuelta atrás. Ese vacío aparece cuando hay reintentos, cambios simultáneos o una integración que confirma tarde.

Antes de ampliar permisos, la prueba debe responder preguntas como estas:

1. ¿Se puede identificar cada acción hecha por el agente?
2. ¿La reversión afecta solo al caso equivocado?
3. ¿Qué ocurre si otra persona modificó el registro después?
4. ¿La integración externa acepta una cancelación o solo una corrección posterior?
5. ¿Quién recibe el caso cuando la reversión falla?
6. ¿El cliente debe ser informado de la corrección?

Pruebe también un caso duplicado, un dato desactualizado y una interrupción a mitad del flujo. Un agente puede comportarse bien cuando todo ocurre en orden y producir duplicados cuando recibe un reintento. La idempotencia, el registro de versiones y la revisión de los resultados posteriores importan más que una demostración sin fricciones.

El permiso debe poder retirarse sin apagar todo

La reversibilidad no termina en la acción individual. La empresa necesita poder retirar una capacidad concreta cuando aparece un error. Si el agente puede consultar y preparar, la pausa de la función de envío debería dejar las otras capacidades disponibles. Si puede actualizar una etapa del CRM, debe existir una forma de bloquear esa escritura mientras continúa la clasificación.

La seguridad y gobernanza de IA debe definir quién puede pausar, qué evidencia se conserva y qué criterios permiten reactivar. El servicio de IA aplicada puede crecer por etapas, pero cada etapa necesita una frontera que la dirección pueda entender y revisar.

Una decisión que la dirección sí puede pedir

Antes de aprobar un agente, la dirección puede pedir una matriz sencilla: acción, consecuencia, autorización, evidencia, reversibilidad y responsable. No hace falta llenar un documento con promesas técnicas. Hace falta comprobar que la empresa sabe qué ocurrirá cuando la respuesta sea incorrecta, cuando el dato esté vencido o cuando alguien necesite detener el flujo.

Un agente gana utilidad cuando reduce trabajo sin convertir cada error en un incidente mayor. Si la organización puede revisar lo que hizo, retirar una capacidad concreta y volver a un estado conocido, tiene una base razonable para ampliar el piloto. Si no puede, conviene mantener el agente en lectura o preparación hasta resolver esa brecha.

Fuentes consultadas

• NIST, Artificial Intelligence Risk Management Framework 1.0.
• OWASP, LLM06:2025 Excessive Agency.