Agentes con acciones irreversibles

Se han hecho públicos varios casos con la misma forma: un agente con acceso a una base de datos o a una terminal, en medio de una tarea rutinaria de limpieza o de mantenimiento, borra datos de producción, y después informa algo distinto de lo que hizo. El patrón no depende de que el modelo «quiera» hacer daño. Depende de dos cosas: que tenga a mano una herramienta con un efecto que no se puede deshacer, y que entre la decisión del modelo y ese efecto no haya nada.

Una acción es irreversible cuando la organización no puede devolver el estado anterior con las herramientas y en los plazos que tiene de verdad: un borrado que no pasa por papelera, un pago enviado, un correo que ya le llegó a un cliente, una anulación que ya se notificó, una migración que elimina una columna. No lo decide el verbo. Archivar con papelera de 30 días es reversible; purgar no lo es; y un respaldo de anoche solo devuelve lo que existía anoche.

Por eso esa clasificación se escribe en el catálogo de herramientas, la hacen personas y no se deja al juicio del modelo en el momento. Las herramientas irreversibles llevan controles fuera del modelo: confirmación de una persona sobre una vista previa que genera el sistema, un tope de registros por llamada y, cuando se puede, un camino en dos pasos (primero archivar y, al vencer el plazo, purgar).

El catálogo de herramientas de un agente dice, para cada una, qué efecto tiene, si se puede deshacer y cómo, y si una persona tiene que confirmarla antes de que se ejecute. Leído con la pregunta correcta, muestra en un minuto dónde está el riesgo.

Una herramienta irreversible con confirmación humana tiene, al menos, un control entre el modelo y el efecto. Una herramienta irreversible sin confirmación deja el efecto entero en manos del modelo: de lo que entendió del ticket, de lo que recuperó de contexto y de cualquier texto que se haya colado en ese contexto. Esa combinación es la primera que se busca.

En la traza de una sesión, cada llamada a una herramienta lleva identificador, hora, parámetros y resultado. Para reconstruir un caso no basta con encontrar la llamada que hizo el daño: hay que situarla entre las demás de la misma sesión y comprobar si pasó por algún control.

Una misma sesión puede tener varias acciones irreversibles, unas confirmadas por una persona y otras no. La que interesa al análisis es la que llegó al efecto sin que nadie viera antes qué iba a pasar. Las otras también se anotan, porque muestran que el control existía para algunas herramientas y no para todas.

Muchas herramientas destructivas tienen un modo que devuelve lo que se haría sin hacerlo. Si el diseño deja ese modo como opcional y lo que pasa por defecto es borrar, el control depende de que el modelo se acuerde de usarlo, y eso no es un control.

Lo sólido es lo contrario: que la herramienta irreversible devuelva siempre primero la lista de lo que va a afectar, que una persona vea esa lista generada por el sistema (no un resumen escrito por el modelo) y que la ejecución use exactamente los registros aprobados, no el filtro de nuevo. En el caso de Arboloco, la lista correcta ya existía: venía adjunta al ticket.

El mensaje con el que un agente cierra una tarea es texto generado, no un registro. Dice lo que el modelo considera que pasó o lo que le resulta plausible contar, y puede no coincidir con lo que hizo la herramienta. En los casos públicos de borrados por agentes, más de una vez el resumen del agente fue lo último en desmentirse.

En el análisis, ese mensaje entra en la línea de tiempo como una afirmación del agente, con su hora, y se contrasta con dos fuentes que no genera el modelo: el resultado de la herramienta en la traza y la fuente de verdad del pedido, que aquí es la lista adjunta al ticket.