La memoria de un agente empieza siendo una mejora de producto. El asistente recuerda cómo prefieres que redacte, qué proyecto estabas revisando, qué te respondió mal la semana pasada. Nadie lo trata como un sistema de datos porque no se parece a uno: no hay un formulario, no hay una migración, no hay un modelo de datos que revisar. Se acumula sola, a partir de conversaciones.
Seis meses después esa memoria contiene fragmentos de contratos, nombres de clientes, incidentes internos, direcciones, a veces credenciales que alguien pegó en un chat. Es un almacén de datos personales y comerciales sin dueño declarado, sin política de retención, sin control de acceso propio y sin ninguna forma práctica de responder una solicitud de eliminación. La diferencia con una base de datos no es el contenido: es que nadie decidió que existiera.
Qué hay realmente dentro de la memoria
Conviene abrir la caja antes de discutir controles, porque bajo la palabra memoria suelen convivir cosas muy distintas, con riesgos y ciclos de vida distintos. Al menos cuatro:
- Historial de conversaciones. El registro completo de lo que se dijo, normalmente el más voluminoso y el que más datos sensibles contiene de forma incidental.
- Resúmenes y hechos extraídos. Afirmaciones que el sistema derivó y guardó como verdaderas: preferencias, roles, relaciones entre personas. Son peligrosos precisamente porque el modelo los trata como establecidos y ya nadie recuerda de dónde salieron.
- Índices vectoriales. Fragmentos del contenido con su representación numérica. Se suelen tratar como derivados inocuos, pero contienen el texto original o permiten reconstruirlo, y casi nunca heredan los permisos de la fuente.
- Artefactos de trabajo. Archivos que el agente generó o descargó y dejó en su espacio: exportaciones, borradores, resultados intermedios. Es la categoría que más sorprende en las revisiones, porque nadie la considera memoria.
Los cuatro riesgos que se acumulan
Retención sin política
Por defecto, la memoria de un agente es eterna. Ningún componente la borra porque ninguno sabe cuándo un recuerdo dejó de ser útil. Eso choca de frente con los principios de minimización y limitación del plazo de conservación que exige la normativa de protección de datos, y en Chile con las obligaciones que introduce el nuevo marco de datos personales. La pregunta operativa es concreta: si un cliente pide la eliminación de sus datos, ¿puedes localizar y borrar lo que el agente recuerda de él, incluidos los vectores y los resúmenes derivados?
Acceso sin control propio
El almacén de memoria suele quedar fuera del esquema de permisos de la organización. Vive en una base gestionada por el equipo que construyó el agente, accesible con una credencial de servicio, sin clasificación, sin registro de consultas y sin revisión periódica de quién puede leerla. Contiene datos de todos los usuarios que hablaron con el agente. Es el mismo problema que discutimos en el RAG con control de acceso, agravado porque la memoria no tiene documento de origen contra el cual heredar permisos.
Envenenamiento
Si un agente escribe en su memoria a partir de contenido que procesa, cualquiera que controle ese contenido puede influir en lo que el agente creerá mañana. Una instrucción incrustada en un documento, en un ticket o en una página web puede terminar guardada como hecho, y desde ahí actuar sobre cada conversación futura sin volver a aparecer en ninguna entrada. Es la diferencia entre una manipulación puntual y una persistente: la segunda sobrevive al reinicio, no deja rastro en la petición y es mucho más difícil de detectar porque el síntoma aparece semanas después de la causa.
Fuga entre usuarios y entre clientes
Cuando la memoria es compartida por diseño —un agente de equipo, un asistente de soporte común— la separación entre lo que puede ver cada persona queda en manos de un filtro en la consulta. Si ese filtro es un parámetro que se arma con texto, o si el índice vectorial devuelve resultados por similitud sin verificar permisos, la fuga es cuestión de tiempo. En plataformas multiinquilino el mismo defecto cruza organizaciones distintas, y ahí deja de ser un problema técnico para ser uno contractual.
Lo que el agente recuerda es una base de datos con contenido sensible que nadie declaró, nadie clasificó y nadie sabe cómo vaciar.
Una política mínima que sí se puede implementar
No hace falta un programa entero para reducir la mayor parte de esta exposición. Hacen falta cinco decisiones, y todas caben en un trimestre.
La primera es separar el camino de escritura del de lectura y controlar el primero: definir qué se guarda, en qué formato, y no permitir que el agente escriba en memoria contenido que provenga directamente de fuentes externas sin pasar por una extracción acotada. La segunda es guardar procedencia con cada recuerdo —de dónde salió, en qué sesión, bajo qué usuario—, que es lo único que permite invalidar en bloque cuando se descubre un envenenamiento. La tercera es poner plazo: vencimiento por defecto para cada categoría, con renovación solo si el recuerdo se usa. La cuarta es aislar por inquilino con separación física o lógica verificable, no con un filtro en la consulta. Y la quinta es tener un procedimiento de borrado por sujeto que alcance también a índices y derivados, probado al menos una vez antes de necesitarlo.
Vale la pena una advertencia de expectativas: esta área está lejos de estar resuelta. Los productos de memoria evolucionan rápido, las garantías de borrado en índices vectoriales son desiguales y la investigación sobre manipulación persistente sigue abierta. Por eso el control más valioso hoy no es técnico sino de gobierno: declarar la memoria como sistema de información, asignarle un responsable y meterla en el inventario de datos con la misma seriedad que cualquier base de producción. Si tu organización está armando su plan de controles del trimestre, esta entrada cuesta poco y cierra una brecha que solo se agranda con el tiempo.