El olvido en las máquinas: cuando borrar el dato no basta

Un dato eliminado de una tabla desaparece. Un dato eliminado de un modelo entrenado, no. Sigue ahí, disuelto en los pesos, difuso pero recuperable, alterando cada respuesta futura del sistema sin que ninguna consulta lo revele. Este artículo empieza donde termina el anterior sobre olvido en storage clásico: cuando el dato sale del almacenamiento, ha dejado ya rastros en índices, embeddings, cachés y —el más difícil de todos— en los propios pesos del modelo. Y frente a este panorama técnico, el olvido humano —biológico, adaptativo, funcional— aparece como el espejo que revela lo que las máquinas todavía no saben hacer.

Tres olvidos que no son el mismo

Cuando se habla de “olvidar” en sistemas de IA, se mezclan tres fenómenos técnicos completamente distintos. Antes de proponer cualquier cosa conviene separarlos, porque confundirlos oculta el problema real.

Olvido catastrófico. El más antiguo y el más conocido. Un modelo entrenado en una tarea A que se entrena después en una tarea B tiende a perder involuntariamente lo que sabía sobre A. No hay intención de borrar; ocurre solo, como efecto secundario de aprender. Un artículo de enero de 2026 sobre continual unlearning en LLMs lo confirma: los ejemplos vistos antes son gradual —o catastróficamente— olvidados a lo largo del entrenamiento, y esto es especialmente cierto para modelos de lenguaje.

Machine unlearning. El opuesto exacto: un olvido inducido a demanda. Cuando una regulación exige que un modelo “borre” la contribución de un dato específico —típicamente por una solicitud amparada en el artículo 17 del GDPR— la ingeniería necesita técnicas para eliminar ese aporte sin destruir todo lo demás. Es un campo joven y todavía frágil.

Retención implícita en los pesos. El menos discutido y probablemente el más incómodo. Un modelo entrenado con un dato conserva información sobre ese dato en sus parámetros aunque el dataset original se borre. El storage olvida; el modelo, no. Un dato personal que entró en un pipeline de entrenamiento puede seguir influyendo en las respuestas del modelo durante toda su vida útil, sin que ningún registro visible lo evidencie.

La confusión entre estos tres no es semántica. Es lo que permite que muchas organizaciones afirmen “hemos borrado sus datos” cuando lo que han hecho es borrar el registro primario y dejar intactas las contribuciones ya integradas.

El olvido como propagación, no como acto único

Aquí conviene detenerse en algo que el artículo sobre storage clásico apuntaba pero no desarrollaba: cuando llega una solicitud de supresión en un sistema de IA moderno, borrar el registro principal es el paso trivial. Lo difícil es todo lo demás.

Un artículo académico de arXiv de 2026 sobre faults and pitfalls en la implementación del derecho al olvido documenta el patrón: los sistemas modernos son arquitecturas distribuidas donde el dato personal deja rastros derivados en múltiples capas. En un sistema con componentes de IA, esas capas son especialmente traicioneras:

• Índices vectoriales con embeddings calculados sobre el dato
• Cachés semánticas de RAG que retienen fragmentos del contexto
• Logs de trazas con prompts y respuestas históricas
• Datasets derivados para fine-tuning, validación o evaluación
• Modelos entrenados con los pesos actualizados por el dato
• Backups incrementales que contienen versiones anteriores

Una eliminación en la capa primaria puede convivir durante meses con copias funcionales en capas subordinadas. El olvido, en un sistema distribuido con IA, no es un acto puntual — es una propagación que hay que orquestar. Y de todas las capas, la última es la más difícil de tratar: los pesos del modelo no tienen borrado limpio.

La ingeniería del machine unlearning: lo esencial

El estado del arte se ha desarrollado con velocidad, pero la fotografía honesta es que todavía nadie tiene una solución robusta y verificable a la vez. Vale la pena ver por qué, quedándonos en lo esencial.

La técnica exacta: verificable pero prohibitiva

La única técnica que garantiza olvido matemáticamente demostrable es reentrenar el modelo desde cero sin el dato a olvidar. Para un LLM contemporáneo esto significa millones de dólares, semanas de cómputo y una huella energética considerable por cada solicitud. Es una solución que no escala.

Una variante viable es SISA (Sharded, Isolated, Sliced, Aggregated): dividir el dataset en fragmentos aislados, entrenar submodelos independientes por fragmento, combinar sus salidas. Cuando llega una solicitud, solo hay que reentrenar el fragmento afectado. Es una solución arquitectónica: parte del olvido en el diseño del sistema, no como añadido posterior. Su límite: exige comprometer la arquitectura antes de entrenar, no después.

Las técnicas aproximadas: la familia frágil

El grueso de la investigación reciente se ha volcado en técnicas que no reentrenan, sino que modifican los pesos existentes para reducir la influencia del dato a olvidar. La más representativa es Gradient Ascent, que aumenta la pérdida sobre el conjunto a olvidar hasta que el modelo deja de predecir correctamente sobre él. Otras variantes usan adapters LoRA aislados, task vector negation o contrastive decoding en inferencia.

Todas son elegantes. Todas tienen el mismo problema.

El problema que nadie está resolviendo bien: la reversibilidad

Un paper de mayo de 2026 titulado Unlearning Isn’t Deletion documenta lo que la investigación empieza a llamar fragilidad del olvido: la mayoría de los métodos actuales producen un olvido aparente que se puede revertir con relativa facilidad. Un modelo “desaprendido” puede recuperar el conocimiento suprimido mediante fine-tuning ligero sobre datos aparentemente inocuos —el llamado benign relearning—, mediante cuantización a baja precisión, o mediante prompting adversarial.

Traducido: gran parte de lo que hoy se llama unlearning es en realidad una supresión superficial que oculta el recuerdo sin eliminarlo. La analogía dolorosa es que el modelo aprende a no decir lo que sabe, no a no saberlo. Esa diferencia es exactamente la que separa el cumplimiento real del cumplimiento performativo.

Y hay una dimensión adicional que la conversación pública apenas menciona: el mantenimiento continuo degrada el modelo. En un entorno de solicitudes acumuladas —continual unlearning—, cada nueva operación de olvido interfiere con las anteriores, produciendo drift en los parámetros hasta que el modelo puede colapsar funcionalmente. Un sistema comprometido a olvidar bajo demanda es un sistema que se degrada por diseño con cada solicitud atendida.

Lo que esto cambia en la ingeniería de datos aplicada a IA

Tres decisiones concretas emergen de este panorama.

Minimización en el entrenamiento, no solo en el storage. Si un dato personal no debería ser recordable después, probablemente no debería haber entrado al entrenamiento. Cada dato personal integrado crea una obligación futura difícil de honrar. Y “difícil de honrar” aquí significa técnica cara, verificación imposible y degradación progresiva del modelo.

Arquitecturas modulares para olvido localizado. Si el olvido total del modelo es prohibitivo y el aproximado es frágil, la salida viable es diseñar la arquitectura para que el olvido sea localizado. SISA es la propuesta más conocida, pero la lógica se aplica en general: adapters LoRA por lote de datos con descarte independiente, RAG con memoria externa que retenga los datos personales fuera del modelo y permita eliminación por índice, y separación deliberada entre modelos base entrenados sin datos personales y capas adaptativas que sí los incorporen.

Aceptación explícita de los límites. Hay solicitudes de olvido que hoy la ingeniería no puede satisfacer con garantía. Un modelo grande entrenado hace un año con datos que no se aislaron por lotes no puede olvidar limpiamente un dato específico. Reconocer esto es una llamada a la arquitectura futura: los modelos de aquí en adelante deben diseñarse asumiendo que el olvido bajo demanda es un requisito, no una funcionalidad opcional que se añade después.

Lo que esta aproximación no resuelve

Ninguna de las técnicas actuales resuelve el problema de fondo: que los modelos generativos son sistemas cuya inteligencia emerge precisamente de la integración masiva de datos, y esa integración es intrínsecamente resistente a la eliminación quirúrgica. Es como pedirle a un río que devuelva las gotas que un afluente le aportó hace un año.

Tampoco resuelve la asimetría de auditoría: verificar que un modelo ha olvidado exige acceso a los pesos, cómputo y expertise que solo tienen el proveedor y unos pocos investigadores. La confianza en el olvido depende, en la práctica, de la buena fe del operador.

El otro lado: el olvido humano como espejo funcional

Hasta aquí, la ingeniería. Pero es en la comparación con el olvido biológico donde este problema técnico se convierte en algo más grande — y donde se revela la magnitud de lo que las máquinas todavía no saben hacer.

El olvido biológico no es un fallo

Durante décadas, la neurociencia trató el olvido como un déficit. La investigación de los últimos quince años ha demolido esa lectura. Estudios publicados en Nature y en Nature Communications han mostrado que el cerebro suprime memorias específicas de forma intencional cuando compiten con objetivos actuales de recuperación, y que este proceso depende críticamente del córtex prefrontal. La revisión de 2024 en Annual Review of Psychology lo resume sin ambigüedades: la memoria existe para servir a un propósito adaptativo, y ese propósito exige olvidar tanto como recordar.

El olvido biológico tiene tres funciones documentadas: regulación emocional (limita el acceso a memorias negativas), adquisición de conocimiento (permite generalizar al abstraer y automatizar), y sintonía contextual (orienta el procesamiento hacia el presente relevante).

La formulación clave, repetida en la literatura con variantes: un cerebro que retuviera todo con igual peso no pensaría mejor. No pensaría en absoluto. El olvido no compite con la cognición; la habilita.

La asimetría que este espejo revela

Puesto en paralelo con lo que las máquinas hacen hoy, el contraste es incómodo:

El cerebro olvida por función; el modelo olvida por accidente. El olvido catastrófico no responde a ningún criterio de relevancia. Se olvida lo que se pisa al aprender lo nuevo, sin importar si era importante o trivial, útil o dañino.

El cerebro selecciona qué olvidar; el modelo no distingue. El córtex prefrontal decide, en función de objetivos actuales, qué memorias suprimir. Un modelo generativo actual no tiene equivalente: cuando se le fuerza a olvidar, aplica la técnica de forma homogénea, sin criterio funcional.

El cerebro olvida para poder generalizar; el modelo se apoya en la retención para razonar. La abstracción biológica es la contrapartida del olvido de detalles específicos. Un modelo que retiene el detalle sin olvidar no está generalizando — está memorizando. Y esa memorización es lo que hace tan difícil borrarlo después.

Un survey reciente sobre olvido en machine learning apunta a la dirección más prometedora: integrar mecanismos de olvido adaptativo inspirados en el cerebro no como añadido de compliance, sino como principio de diseño para mejorar la propia inteligencia del sistema. No olvidar para cumplir con el GDPR; olvidar porque olvidar bien es parte de pensar bien.

La responsabilidad de quien construye

La pregunta útil no es “¿cómo hacemos que las máquinas olviden como los humanos?” — es antropomorfa y probablemente equivocada. La pregunta es: ¿cómo diseñamos sistemas que integren mecanismos de olvido con criterio funcional, no solo con presión regulatoria?

Eso implica pensar el olvido en tres dimensiones simultáneas: selectividad (olvidar lo específico sin borrar lo estructural), funcionalidad (olvidar para mejorar el sistema, no para cumplir obligaciones externas), y verificabilidad (demostrar que el olvido ha ocurrido bien). Las tres tienen que estar. Ninguna sola basta.

Preguntas abiertas

• Si un modelo entrenado retiene información sobre datos personales en sus pesos aunque los datos se borren, ¿en qué momento se puede afirmar honestamente que ha olvidado?
• Cuando la técnica actual de unlearning produce olvidos reversibles con fine-tuning ligero, ¿estamos cumpliendo con el derecho al olvido o estamos escenificándolo?
• ¿Puede un sistema de IA aspirar a la inteligencia sostenida sin desarrollar mecanismos de olvido funcional, o la retención acumulativa es la asíntota que lo detendrá?
• Si el olvido humano es una función y el olvido máquina es un accidente, ¿qué le estamos pidiendo en realidad a la ingeniería cuando le exigimos que las máquinas “olviden como nosotros”?

Las preguntas no tienen respuesta cerrada. Pero conviene una idea final: el olvido bien diseñado no es la ausencia de memoria — es una forma de memoria más madura. Y esa forma más madura, hoy, es un territorio donde los cerebros biológicos llevan millones de años de ventaja sobre los cerebros artificiales. Reconocer esa asimetría no es humildad; es la condición previa para construir sistemas que algún día puedan cerrar el hueco.

La memoria digital ilimitada no es un logro. Es una carencia disfrazada de capacidad. Y esa distinción le pertenece a quien la sostenga con su código.

Referencias

• arXiv — Wuerkaixi et al. FIT: Defying Catastrophic Forgetting in Continual LLM Unlearning (enero 2026). arxiv.org/html/2601.21682v1
• arXiv — Rezaei et al. Unlearning Isn’t Deletion: Investigating Reversibility of Machine Unlearning in LLMs (mayo 2026). arxiv.org/html/2505.16831v3
• EmergentMind — Machine Unlearning for LLMs (febrero 2026). emergentmind.com
• Bourtoule et al. — Machine Unlearning (SISA architecture, 2021). Propuesta arquitectónica original.
• arXiv — Faults and Pitfalls in Implementing the Right to be Forgotten (2026). arxiv.org/pdf/2605.27171
• Nature — The forgotten part of memory (2019). El olvido como función adaptativa. nature.com
• Nature Communications — A retrieval-specific mechanism of adaptive forgetting in the mammalian brain (2018). nature.com
• Annual Review of Psychology — Anderson & Hulbert. Active Forgetting: Adaptation of Memory by Prefrontal Control (2024). annualreviews.org
• arXiv — “Forgetting” in Machine Learning and Beyond: A Survey (2024). arxiv.org/html/2405.20620v1
• Artículo anterior de esta serie: Infraestructuras que olvidan.