Memoria de agentes de IA: separar contexto, preferencias y hechos persistentes, y decidir cuándo caducan

Recordar no significa conservar el historial

Un agente que atiende a una misma persona o equipo en varias ocasiones necesita continuidad: puede resultar razonable recordar un idioma preferido, el formato habitual de una entrega o el nombre de un proyecto. Sin embargo, convertir todas las conversaciones, documentos recuperados e inferencias del modelo en memoria reutilizable introduce un problema de gobierno. El sistema puede recuperar información irrelevante, obsoleta, incorrecta, sensible o aplicable únicamente a una circunstancia anterior.

La cuestión de arquitectura no es si el agente tiene memoria, sino qué afirmación concreta conserva, quién puede usarla, con qué fin y durante cuánto tiempo. Una frase como «el cliente prefiere aprobar los cambios por correo» puede ser una preferencia declarada, una observación deducida de un único intercambio o una regla operativa vigente. Esas interpretaciones tienen distinto valor y no deberían almacenarse ni aplicarse del mismo modo.

La memoria persistente tampoco adquiere autoridad por haber sido almacenada. Una instrucción que aparece en una conversación pasada, en un documento importado o en un resultado de recuperación sigue siendo contenido de la fuente que la aportó. No debe desplazar instrucciones de mayor autoridad ni habilitar acciones que el agente no puede realizar en el contexto actual. Esta separación es especialmente importante cuando el contenido recuperado no ha sido validado o puede estar manipulado.

Para orientar esta guía conviene distinguir entre hechos de diseño y decisiones de política. Es un hecho operativo que un sistema puede asignar fechas de creación, revisión o expiración a registros. En cambio, decidir que una preferencia expire a los noventa días es una política de la organización: debe justificarse por el riesgo, la volatilidad del dato y la experiencia esperada, no presentarse como una regla universal.

Cuatro objetos que conviene separar

La palabra «memoria» suele mezclar componentes con ciclos de vida muy diferentes. Separarlos reduce recuperaciones indebidas y hace más comprensible el comportamiento del agente. El contexto de sesión contiene el intercambio inmediato que permite interpretar la petición actual. Debería estar acotado a la sesión y desaparecer o quedar inaccesible al terminarla, salvo que una parte se promueva de forma deliberada a otra categoría.

El estado de tarea representa el progreso de un trabajo concreto: identificador de una solicitud, elementos ya procesados, borrador en curso, resultado parcial o paso pendiente. Puede necesitar sobrevivir a una interrupción breve, pero no por ello es una preferencia ni un hecho que deba estar disponible en tareas futuras. La documentación de herramientas de ejecución para agentes de Google ofrece un ejemplo de estado de flujo de trabajo vinculado a una sesión y de limpieza explícita o mediante tiempo de vida al concluir la tarea o la conversación.

La memoria declarada es la información que una persona o un equipo ha proporcionado para continuidad, como el idioma preferido, una zona horaria o una convención de nombres. Debe conservar la declaración original o una referencia a ella, además de su ámbito. Un ajuste indicado para un proyecto no tiene por qué extenderse a todos los proyectos, ni una preferencia de un miembro del equipo debe atribuirse a toda la organización.

El conocimiento recuperable reúne afirmaciones obtenidas de fuentes identificadas: una política interna vigente, el estado de un servicio o una lista de responsables. Su diseño se parece menos a un perfil de usuario y más a un registro de procedencia: fuente, versión o momento de consulta, responsable, alcance y condiciones de actualización. La ontología PROV-O del W3C proporciona conceptos para representar entidades, actividades y agentes, así como relaciones de generación, derivación e invalidación. No obliga a adoptar una base de datos determinada, pero sí ayuda a hacer explícita la trazabilidad.

El registro mínimo de un recuerdo gobernable

Un registro no necesita guardar texto conversacional completo para ser útil. En muchos casos basta con una afirmación normalizada y metadatos. Por ejemplo, en lugar de conservar un diálogo entero, un registro podría expresar que una persona eligió recibir resúmenes en español para un espacio de trabajo concreto. La reducción de contenido no elimina todos los riesgos, pero limita la exposición y facilita la inspección.

Como mínimo, cada elemento debería incluir un identificador estable; contenido o referencia al contenido; propietario o sujeto al que se atribuye; finalidad permitida; ámbito de aplicación; fuente y modo de obtención; nivel de confianza; fecha de creación; fecha de última verificación; regla de caducidad; y estado de borrado o restricción. Si se deriva de otros datos, también debe guardar sus dependencias. Así se puede localizar qué recuerdos deben revisarse cuando cambia una fuente o cuando una persona solicita rectificación.

Conviene distinguir el nivel de confianza de la autorización de uso. Una preferencia declarada directamente por la persona puede tener alta confianza sobre lo que expresó, pero un ámbito limitado. Un dato extraído automáticamente de un documento puede ser potencialmente útil, pero requerir validación humana o consulta de la fuente primaria antes de activar una acción. La confianza no debe convertirse en una puntuación opaca que sustituya la procedencia.

Para información personal, el Reglamento General de Protección de Datos de la Unión Europea establece principios de limitación de la finalidad, minimización, exactitud y limitación del plazo de conservación, junto con derechos relacionados con rectificación, supresión y limitación del tratamiento en las condiciones aplicables. Un producto que opere bajo ese marco debe traducir esos principios a procesos reales; añadir un campo denominado «TTL» no demuestra por sí solo cumplimiento jurídico.

Qué puede persistir y qué debería desaparecer

La persistencia debe decidirse por necesidad funcional y riesgo, no por facilidad de almacenamiento. Una preferencia explícita y de bajo impacto puede persistir si tiene un dueño claro, una finalidad concreta y una forma accesible de editarla. Un estado de tarea suele eliminarse al terminar el trabajo. Un hecho externo cambiante, como una tarifa, una política o la disponibilidad de un servicio, puede conservarse como pista de recuperación, pero no debería tratarse como prueba vigente cuando se va a tomar una decisión relevante.

Las inferencias merecen una categoría separada. Que el modelo haya deducido que alguien prefiere comunicaciones breves no equivale a que esa persona lo haya declarado. Si el producto decide guardar inferencias, debería etiquetarlas como tales, reducir su ámbito, fijar una revisión breve y ofrecer un mecanismo sencillo para confirmarlas, corregirlas o descartarlas. En escenarios de impacto elevado, es más prudente no convertir inferencias conductuales en memoria persistente sin una decisión explícita de producto y una evaluación de riesgos.

Los datos sensibles requieren una evaluación más estricta que los ajustes de presentación. La sensibilidad depende tanto de la naturaleza del dato como del contexto, el destinatario, la finalidad y la jurisdicción. Esta guía no sustituye el análisis jurídico ni de seguridad. Como criterio de producto, la presencia de un dato sensible no justifica su persistencia: el equipo debe demostrar una finalidad concreta, controles de acceso, una conservación limitada y un proceso efectivo para atender cambios o eliminación cuando corresponda.

También es importante no ocultar esta clasificación tras una sola etiqueta de «memoria». La interfaz y las APIs internas deberían reflejar las diferencias: un usuario puede querer editar una preferencia, cancelar una tarea pausada o cuestionar la exactitud de un hecho procedente de una fuente externa. Son operaciones distintas y requieren trazas distintas.

Caducidad: expiración, revisión y eventos

Una fecha de expiración responde a la pregunta de cuándo dejar de recuperar un dato automáticamente. Una revisión obligatoria responde a otra: cuándo debe comprobarse de nuevo antes de considerarlo válido. Ambas pueden coexistir. Por ejemplo, una preferencia de formato puede seguir disponible hasta que la persona la modifique o la elimine, mientras que una política operativa puede mantenerse indexada pero exigir una consulta de su fuente antes de utilizarla para aprobar una acción.

Las reglas basadas en eventos complementan al reloj. Un cambio de proyecto, de rol, de proveedor, de cuenta o de versión documental puede invalidar recuerdos asociados. Si una afirmación depende de una fuente concreta, actualizar o retirar esa fuente debería disparar una revisión de sus derivados. Modelar derivaciones e invalidaciones permite encontrar el conjunto afectado en vez de esperar a que cada elemento expire por separado.

La expiración no debe confundirse con borrado físico inmediato. Por motivos operativos o normativos puede haber estados distintos, como «no recuperable», «pendiente de supresión» o «retenido bajo una política específica». Lo esencial para el comportamiento del agente es que un elemento expirado o restringido no vuelva a entrar silenciosamente en el contexto de respuesta. La implementación debe documentar quién puede acceder a cada estado y con qué propósito.

Los plazos concretos no pueden deducirse de una fuente técnica general. Deben surgir de la finalidad, el tipo de dato, el riesgo de desactualización, obligaciones aplicables y necesidades operativas. Un equipo puede definir clases de retención, pero debería medir sus efectos: cuántos recuerdos vencen sin uso, cuántos se corrigen y cuántas recuperaciones se bloquean por falta de vigencia.

Conflictos: instrucciones actuales, preferencias y fuentes

Un conflicto frecuente aparece cuando una preferencia recordada contradice la petición presente. La regla operativa más simple es que la solicitud actual de la persona, dentro de los límites de autorización y seguridad del sistema, prevalece sobre una preferencia anterior. Si alguien pidió antes respuestas breves pero ahora solicita un análisis detallado, el agente debe atender la petición actual y, si corresponde, ofrecer la actualización de la preferencia en lugar de modificarla silenciosamente.

La jerarquía de instrucciones es independiente de la memoria. La especificación de modelos de OpenAI describe niveles de autoridad para las instrucciones y señala que el contenido no confiable no adquiere autoridad por aparecer en datos proporcionados o recuperados. Por tanto, una instrucción almacenada en memoria declarada o incorporada desde un documento no puede anular reglas de mayor autoridad. El diseño debe conservar el origen de cada instrucción y evitar que la recuperación la presente como una orden del sistema.

Cuando dos fuentes de conocimiento difieren, el agente no debería resolver la discrepancia inventando una síntesis. Debe identificar que hay conflicto, preferir una fuente primaria o más reciente conforme a una política definida, o pedir intervención humana si la decisión tiene consecuencias relevantes. El registro de memoria debe marcar los elementos cuestionados para que no se reutilicen como hechos asentados.

La corrección tiene dos dimensiones. Corregir el registro principal evita que el dato siga apareciendo en nuevas recuperaciones. Corregir sus derivados evita que sobreviva en resúmenes, índices, cachés, evaluaciones o datos de entrenamiento de recuperación, según la arquitectura. Un proceso de rectificación o borrado que solo actualiza una tabla visible pero deja el dato en los índices que alimentan al agente no cumple el objetivo operativo de impedir su reutilización.

Revalidar antes de una acción externa

La memoria puede ayudar a formular una respuesta, pero no siempre basta para realizar una acción externa. Si el agente va a enviar información, modificar un registro, iniciar una transacción, cambiar permisos o tomar una decisión con impacto, debe evaluar la vigencia del dato que condiciona esa acción. Cuanto mayor sea el impacto y más cambiante sea la fuente, mayor debe ser la exigencia de consulta o confirmación.

La evidencia de vigencia no es una afirmación genérica de que el registro tiene «alta confianza». Puede ser una consulta reciente a la fuente primaria autorizada, una confirmación explícita de la persona competente o un dato firmado y todavía válido según las reglas del dominio. El sistema debería registrar qué comprobación se hizo, cuándo, contra qué fuente y qué decisión permitió. Si no puede comprobarlo, debe abstenerse, reducir el alcance de la acción o solicitar confirmación.

El proyecto OWASP Gen AI Security identifica riesgos asociados al envenenamiento de memoria y contexto en aplicaciones agénticas. En términos de diseño, esto refuerza la necesidad de separar el contenido recuperado de las instrucciones autorizadas, registrar procedencia y observar qué recuerdos influyeron en una acción. Un filtro semántico por sí solo no garantiza que un recuerdo sea fiable ni que sea apropiado para el objetivo actual.

NIST propone en su marco de gestión de riesgos de IA actividades de gobierno, mapeo, medición y gestión, incluida la monitorización y la documentación durante la operación. Aplicado a memoria, esto sugiere tratar las recuperaciones fallidas, los recuerdos obsoletos y las correcciones repetidas como señales medibles de riesgo, no solo como incidencias aisladas de calidad.

Controles de producto y pruebas operativas

Una vista de memoria no es solo una página de configuración. Debe permitir entender qué datos utiliza el agente y distinguir, al menos, preferencias declaradas, hechos recuperables, inferencias y estados de tarea cuando sean visibles para la persona. Para cada elemento, una presentación útil incluye contenido comprensible, fuente o modo de obtención, ámbito, última revisión, fecha de expiración y opciones de edición, restricción o eliminación cuando correspondan.

El registro de uso es el complemento técnico de esa vista. Ante una respuesta problemática, el equipo necesita reconstruir qué elementos se recuperaron, cuáles se descartaron, cuáles influyeron en la decisión y si hubo revalidación. No es necesario exponer internamente todos los datos a todos los operadores: los propios registros requieren controles de acceso, minimización y plazos de conservación. La trazabilidad debe apoyar la investigación sin convertirse en otra memoria ilimitada.

Las pruebas deben cubrir más que la recuperación correcta. Incluya casos donde un recuerdo viejo contradice la petición actual; una fuente ha cambiado; una inferencia es incorrecta; una preferencia pertenece a otro proyecto; y un elemento eliminado aparece en un resumen o en una caché. Para acciones externas, pruebe que la ausencia de evidencia vigente bloquea la acción o solicita una confirmación apropiada.

Mida las tasas de recuperación de recuerdos expirados o fuera de ámbito, conflictos detectados y no resueltos, rectificaciones, borrados completados, bloqueos por falta de revalidación y acciones que dependieron de memoria. Estas métricas no prueban por sí solas que el sistema sea seguro o conforme, pero revelan dónde la memoria se está convirtiendo en una fuente de decisiones defectuosas.

Checklist de despliegue

Antes de activar memoria persistente, el equipo debería poder responder de forma verificable a varias preguntas: qué clases de datos guarda; quién es su propietario; qué finalidad justifica cada clase; cómo se identifica la fuente; cuándo caduca; qué eventos la invalidan; quién puede verla o cambiarla; y qué ocurre en los índices, cachés y resúmenes cuando se corrige o elimina.

La arquitectura no necesita resolver todos los riesgos mediante automatización. En algunos dominios, la respuesta correcta es restringir la memoria a preferencias de bajo impacto, mantener los hechos sensibles fuera de la persistencia del agente o exigir revisión humana para cambios de alto impacto. La continuidad operativa no depende de recordar más, sino de recordar solo lo que puede gobernarse.

Para ampliar el marco, relacione esta práctica con los contenidos de Learn sobre diseño de agentes, con Seguridad para riesgos operativos y con el Glosario para acordar términos como procedencia, retención, ámbito y revalidación. Mantener un vocabulario común evita que producto, ingeniería, datos y seguridad usen «memoria» para referirse a mecanismos incompatibles.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.