AN-09 L3 Nivel de conformidad: Guard Grupo: Conocimiento

Cascade Forget olvido en cascada

Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer.

Definición

Cascade Forget es el borrado siguiendo el linaje: cuando se borra una fuente, o alguien pide que lo olviden, el NAS encuentra todo lo derivado de ella (resúmenes, embeddings, notas que la citan, cachés y enlaces compartidos), lo borra o lo vuelve a derivar sin esa fuente, y emite un informe: qué se hizo y qué no se pudo hacer.

v0.2 Borrador de especificación Actualizado

El problema

Borrar un archivo no borra sus embeddings, sus resúmenes ni los hechos que la memoria dedujo de él; las instantáneas y las copias de seguridad permanecen; y el contenido sigue en el historial de versiones.

“Recuperable” y “olvidable” son los dos extremos de un mismo eje, y la mayoría de los sistemas no ponen esa elección en manos de una persona. Si solo piensas en el olvido después de escribir, suele ser demasiado tarde.

Cómo funciona

  • Linaje. Cada derivado registra sus entradas; un índice inverso responde a “todo lo que depende de X”; el campo sources de una nota también es linaje.
  • La clase de retención se decide al escribir (porque después no se puede reescribir el historial): scratch (TTL corto, fuera de las copias de seguridad, se puede limpiar cuando termina la ejecución), normal (versionada, recuperable) y sensitive (su propio dominio de claves, que se puede destruir eliminando la clave).
  • La tensión entre recuperar y olvidar. Recuperable dentro de la ventana de borrado lógico; borrado definitivo solo después; una solicitud de olvido puede saltarse la ventana.
  • Proceso. Una solicitud (la plantea una persona o un operador; un agente solo puede pedirla, no ejecutarla), recorrido del linaje, borrado de los derivados y nueva derivación de los hechos de origen mixto, reescritura del historial de las rutas afectadas y limpieza de instantáneas para la clase normal, destrucción de claves para la clase sensitive y, por último, el informe.
  • El informe: el número de archivos borrados, de derivados eliminados, si se reescribió el historial, las claves destruidas, las instantáneas que aún no han caducado y una lista explícita de lo que no cubre: copias fuera del NAS, registros de los proveedores de modelos y pesos de los modelos.
  • Siempre pasa por una Human Gate (o una política de autorización previa); una retención legal bloquea el olvido y queda registrada.

Empezar en pequeño

  • Empieza con las clases de retención y el borrado lógico, y registra las entradas de cada derivado.
  • Llega primero a “cuando se borra un archivo de origen, listar y borrar todos sus derivados”.
  • Deja la destrucción criptográfica para la clase sensitive; no hace falta hacerla en todas partes al principio.

Esbozo de la interfaz

Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3.

forget-report.json
{
  "forget_id": "fgt_3b7c",
  "selector": { "paths": ["/shared/crm/acme/**"], "subject": "customer/acme" },
  "retention_class": "sensitive",
  "report": {
    "files_removed": 142,
    "derived_removed": { "embeddings": 3621, "summaries": 210, "notes_rewritten": 6 },
    "history": "rewritten (3 commits)",
    "keys_destroyed": ["key_acme"],
    "snapshots_pending": ["nightly-2026-11-10 (expires 2026-11-17)"],
    "not_covered": ["copies outside the NAS", "model provider logs", "model weights"]
  },
  "state": "pending_expiry"
}

Lo que pide la especificación

  • El olvido DEBE propagarse por el linaje desde la fuente hasta cada derivado.
  • La clase de retención DEBE asignarse al escribir (normal por defecto).
  • Un informe de olvido DEBE enumerar lo que no cubre: copias fuera del NAS, registros de los proveedores y pesos de los modelos.
  • Una retención legal DEBE bloquear el olvido y DEBE registrarse.
  • Un agente PUEDE solicitar el olvido pero NO DEBE ejecutarlo.
  • Un informe NO DEBE afirmar que un modelo ha “olvidado” algo.

Lo prestado y lo nuevo

Lo que sigue es todo ya establecido. Lo nuevo: tratar la clase de retención como una propiedad explícita del almacenamiento, y admitir que “recuperable” y “olvidable” son un compromiso en un mismo eje.

Límites honestos

  • Las copias de seguridad, las copias fuera del NAS y los registros de los proveedores de modelos quedan fuera del alcance.
  • Para los hechos inferidos de varias fuentes, el “alcance afectado” es difícil de definir.
  • Reescribir el historial es caro y conlleva riesgo.

Preguntas abiertas

  • ¿Cómo se define el alcance afectado de un hecho de origen mixto?
  • ¿Cuál debería ser el proceso cuando una retención legal choca con una solicitud de olvido?

Preguntas

¿Puede hacer que un modelo olvide?

No, y no pretende afirmarlo. Lo que sí puede es borrar archivos y derivados dentro del NAS y, para la clase sensitive, el historial y las claves; los registros de los proveedores de modelos y los pesos de los modelos quedan fuera del alcance, y el informe lo dice de forma explícita.

¿Por qué elegir la clase de retención al escribir?

Porque después es difícil reescribir el historial: lo que ya ha entrado en las copias de seguridad y en el historial solo se puede reescribir o esperar a que caduque. Decidir al escribir si algo es scratch, normal o sensitive es la condición previa para poder borrar limpiamente más tarde.

¿Puede un agente pedir por sí mismo que se olvide algo?

Puede plantear una solicitud pero no ejecutarla. El olvido es irreversible y debe pasar por una persona o por una política de autorización previa, y una retención legal puede bloquearlo.

Citar esta página

Direcciones estables y una cita sugerida para personas, buscadores y agentes.

Cita sugerida
Agent NAS project. “Cascade Forget (olvido en cascada).” agentnas.com, 2026-11-11. https://agentnas.com/es/concepts/cascade-forget/