Memoria persistente y datos entre sesiones

Una memoria persistente guarda, de una sesión a otra, lo que el agente decide recordar: preferencias, atajos, datos de un caso. En una revisión de seguridad hay que verla como dos cosas a la vez. Es un almacén de datos, con todo lo que eso exige: qué guarda, de quién, cuánto tiempo, quién lo lee y cómo se borra. Y es una entrada al contexto del modelo: lo que se guardó en una sesión vuelve en otra como si fuera conocimiento, sin que nadie lo haya revisado.

Los errores de diseño típicos son tres. El ámbito: una sola memoria para todas las sesiones del agente, en vez de una por cliente o por caso, de modo que un dato de un cliente puede reaparecer ante otro. La retención: si nadie fijó cuándo vence, la memoria guarda para siempre. Y el olvido administrativo: la memoria no entra en el inventario de datos y queda fuera de los procesos que sí cubren las bases de datos.

Las notas de una memoria se revisan por su origen y por su contenido: de qué sesión y de qué cliente salió cada una, y qué guarda. Una nota de preferencia («prefiere respuestas cortas») no pesa lo mismo que una nota con los datos de contacto o de pago de un cliente.

Con una memoria compartida por todo el agente, la segunda es una fuga esperando turno: basta con que otro ticket se parezca lo suficiente para que la recuperación la traiga al contexto.

Para medir una fuga por memoria no basta con contar cuántas veces se recuperó la nota. Recuperar no es revelar: el modelo puede recibir la nota en su contexto y no usarla en la respuesta. Lo que cuenta es en qué respuestas apareció el dato y a qué clientes distintos del dueño.

Ese número no es un detalle estadístico: define a quién se avisa, qué se le dice al dueño del dato y qué alcance se declara en el informe.

Cuando un titular pide que se borren sus datos, la organización los borra de los almacenes que conoce. Si la memoria del agente no figura en el inventario, la supresión se da por cerrada y el dato sigue vivo, listo para volver en la próxima sesión que se parezca.

Por eso, al activar una memoria persistente, el procedimiento de supresión se actualiza el mismo día. Si el procedimiento es anterior a la memoria, casi seguro no la incluye.

Borrar la nota del caso es necesario, pero trata la instancia, no la causa: la próxima nota con datos de un cliente seguirá el mismo camino. La causa está en el diseño: el ámbito compartido, la falta de vencimiento, que el agente decida solo qué guarda y que la memoria esté fuera del inventario.