Una política de pagos pasa de exigir un revisor a exigir dos. Un agente recupera un resumen redactado antes del cambio. El resumen puede describir con exactitud la política anterior. Que pueda usarse hoy en una decisión de pago depende de qué política está autorizada y en vigor para este cliente y esta acción.
La memoria persistente convierte esa distinción en un problema de ingeniería. La información almacenada puede servir para una explicación histórica, para la planificación o para la ejecución, y cada finalidad necesita una regla que determine qué registros se aplican. Este artículo revisa investigación reciente, presenta siete pequeñas pruebas sobre un filtro de memoria publicado y propone una hoja de trabajo para la aplicabilidad de las políticas. Este artículo forma parte de una serie de investigación en tres partes sobre la autoridad de los agentes, publicada el 26 de octubre de 2026: evidencia de detención, políticas en la memoria del agente y estándares de control de agentes.
La investigación reciente da al problema una forma concreta
En Revoked but Still Authoritative, un preprint de septiembre de 2026, Yi Ting Shen, Kentaroh Toyoda y Alex Leung estudian cómo la información revocada reaparece en los flujos de trabajo con memoria de agentes. El artículo abarca varios sistemas de memoria y métodos de inserción, con experimentos sobre reescritura en memoria, almacenes compartidos y uso de herramientas. Leer el artículo.
La configuración influye en los resultados. El artículo distingue la recuperación predeterminada de Graphiti de una condición de mem0 que anula el filtro de caducidad que mem0 trae de serie. Otros sistemas se comportan de forma distinta según cómo entra en la memoria una actualización de la política y si el estado de revocación llega a quien hace la consulta. Lea los resultados del estudio teniendo en cuenta esas condiciones.
Los autores también publican un filtro de recuperación. Usa los metadatos de revocación disponibles y una detección heurística de conflictos para decidir qué registros excluir de la selección. Inspeccionamos la implementación y la ejecutamos en local en un commit fijado. Su autocomprobación integrada pasó. Después le dimos siete pequeños casos sintéticos diseñados para mostrar dónde la selección de políticas necesita más contexto. Filtro publicado.
Lo que mostraron las siete pruebas
Los tres primeros casos coinciden con el comportamiento documentado del filtro. Excluyó de la selección un registro revocado de forma explícita. Prefirió el más reciente de dos registros contradictorios con marca de tiempo. Cuando ninguno de los dos registros tenía una marca de tiempo utilizable, conservó ambos e informó de un conflicto sin resolver.
Los otros cuatro casos añaden contexto que una decisión de política necesita y que este filtro no resuelve:
| Tarea sintética | Selección observada | Contexto que necesita quien realiza la consulta |
|---|---|---|
| Dos políticas se aplican a clientes distintos | La política más reciente permanece en kept | El alcance por cliente, antes de comparar sustituciones |
| Una nota más reciente sin aprobar contradice una política aprobada | La nota más reciente permanece en kept | Qué fuente puede autorizar un cambio de política |
| Un registro más reciente entra en vigor en 2099 | La política futura permanece en kept | El intervalo de vigencia en la fecha de la decisión |
| Una consulta de auditoría necesita la política anterior | La política actual permanece en kept; la anterior está en withheld | Una recuperación histórica adecuada a la consulta |
Cómo interpretar estos resultados
Son observaciones deterministas de una única función de filtrado. Los campos de cliente, autoridad y fecha de vigencia quedan fuera de sus reglas de selección documentadas, y la función no recibe ningún parámetro sobre la finalidad de la consulta. Los casos describen responsabilidades de la aplicación que integra el filtro. No muestran una vulnerabilidad en el filtro ni en los sistemas de memoria en general, y siete casos elegidos no dicen nada sobre frecuencia. No se ejecutó ningún modelo, servicio de memoria ni herramienta de pagos.
El caso histórico requiere atención. El filtro mantiene el registro excluido de la selección en su salida, de modo que una aplicación todavía puede leerlo. La decisión de integración es si una consulta de auditoría debe usar el mismo contexto filtrado que una solicitud para ejecutar la política vigente.
Haga explícita la aplicabilidad
El diseño que proponemos parte de la tarea. Una pregunta sobre la aprobación del mes pasado puede necesitar una política sustituida. Una solicitud para liberar un pago necesita la política en vigor para esa acción en este momento. Mantener explícita la finalidad permite a un sistema conservar el historial útil y seleccionar a la vez el contexto adecuado para la ejecución.
El paso siguiente es resolver el alcance y la autoridad. Un registro de política debe identificar el cliente o tenant, la acción gobernada, el emisor, el estado de aprobación, el intervalo de vigencia y lo que sustituye. Una marca de tiempo más reciente ayuda a ordenar los registros una vez conocidas esas relaciones. No puede aportar una aprobación que nunca se produjo.
Por último, el componente que puede provocar una acción con consecuencias debe evaluar la autorización aplicable. Un resumen recuperado puede llevar un identificador de política y explicar una acción propuesta. La decisión de ejecución debe vincularse a una versión oficial de la política y registrarse junto con su resultado. Es una recomendación de diseño; no la hemos medido con pruebas comparativas.
- 1. Finalidad: explicación histórica, planificación o ejecución.
- 2. Alcance: cliente o tenant, recurso y acción gobernada.
- 3. Autoridad y tiempo: emisor, registro de aprobación, inicio y fin de vigencia, sustitución.
- 4. Selección: la política aplicable y cualquier excepción aprobada.
- 5. Decisión: evalúe la acción propuesta frente a la versión oficial y conserve la referencia.
Una hoja de trabajo para la aplicabilidad de las políticas
Hay investigación relacionada que cubre problemas próximos. MINJA estudia cómo la interacción puede contaminar la memoria de un agente, y VersionRAG examina preguntas sobre documentos con versiones cambiantes. MINJA, VersionRAG.
Para el responsable de una política, un registro útil responde a cuatro preguntas: de dónde procede la política, quién la aprobó, cuándo y dónde se aplica y qué decisiones se basaron en ella. La hoja de trabajo de aplicabilidad de políticas (en inglés) convierte esas preguntas en campos que un equipo puede comprobar.
| Campo de decisión | Qué registrar |
|---|---|
| Finalidad de la tarea | Explicación histórica, planificación o ejecución; el momento de la decisión y cualquier fecha histórica solicitada |
| Alcance | Cliente o tenant, recurso y acción gobernada |
| Política | Identificador y versión |
| Autoridad | Autoridad emisora y registro de aprobación |
| Vigencia | Inicio y fin de vigencia; estado de retirada o sustitución; relación de sustitución explícita |
| Excepciones | Excepción aprobada, su alcance y su caducidad |
| Fuentes | Documentos de origen y los resúmenes derivados que los referencian |
| Conflictos | Evidencia contradictoria y el responsable de la política |
| Ejecución | La comprobación frente a la política oficial y su resultado registrado |
Dónde evalúa KLA las políticas
En KLA, el KLA Policy Engine evalúa cada acción gobernada en el punto de ejecución, con uno de cuatro resultados: allow, warn, require_approval o block. Cuando la evaluación falla, el motor devuelve su decisión de fallo cerrado (fail-closed), require_approval por defecto, y la validación de paquetes de políticas rechaza una política cuya decisión predeterminada sea de fallo abierto (fail-open). El resumen de políticas que un agente recuerda puede orientar su propuesta. La decisión procede de la versión publicada de la política.
Las pruebas de este artículo se ejecutaron solo contra el filtro publicado. No contienen ningún resultado de KLA.
Preguntas frecuentes
¿Por qué los agentes de IA usan políticas desactualizadas de su memoria?
Un almacén de memoria puede contener un resumen redactado antes de que cambiara una política. La recuperación puede situarlo en una posición alta, y un registro más reciente puede referirse a otro cliente, carecer de aprobación o no estar todavía en vigor. Si la aplicación no resuelve el alcance, la autoridad y las fechas de vigencia, el agente puede actuar conforme a una política que ya no se aplica.
¿Una marca de tiempo más reciente significa que un registro de política es el vigente?
No. Una marca de tiempo ordena los registros una vez que se sabe que cubren el mismo alcance y que el más reciente se aprobó y está en vigor. En nuestras pruebas, un filtro publicado conservó una nota más reciente sin aprobar y una política con fecha de 2099, porque su contrato no cubre la aprobación ni los intervalos de vigencia.
¿Debe un agente borrar de su memoria las políticas sustituidas?
Consérvelas como historial y diríjalas según la finalidad. Una consulta de auditoría puede necesitar la política anterior; una solicitud de ejecución necesita la que está en vigor. El filtro que probamos mantiene los registros excluidos de la selección en su salida por ese motivo.
¿Dónde debe producirse la comprobación final de la política?
En el componente que puede provocar la acción con consecuencias, frente a una versión oficial de la política, con la versión y el resultado registrados. La memoria puede explicar una propuesta. La comprobación de la política decide si la acción se ejecuta.
Conclusiones clave
Una política recordada es un contexto útil y una autoridad poco fiable. Decida la finalidad de cada recuperación, resuelva el alcance, la aprobación y las fechas de vigencia antes de basarse en la fecha más reciente, y realice la comprobación de ejecución frente a la versión oficial. Use la hoja de trabajo de aplicabilidad de políticas para registrar esas decisiones.
Las fuentes se comprobaron el 26 de octubre de 2026. Los siete casos son sintéticos, se ejecutaron contra una única función publicada y no miden nada sobre sistemas desplegados.