Infraestructuras que olvidan: del cumplimiento al diseño

Guardar es fácil. Borrar es difícil. Durante décadas, los sistemas de datos se construyeron sobre esa asimetría silenciosa: conservar por defecto, borrar por excepción. Hoy, con datos personales acumulándose en cada capa del stack y la regulación europea apretando el paso, esa lógica se ha invertido — o debería. Diseñar infraestructuras que olvidan por defecto, y no como añadido tardío, es uno de los desplazamientos arquitectónicos más importantes que la ingeniería de datos está aprendiendo a asumir. Este artículo se centra en la capa clásica: bases de datos, lagos analíticos, backups. El problema paralelo de los modelos entrenados —donde borrar el dato no basta— es otro artículo distinto.

El punto de partida: la asimetría entre guardar y borrar

Un sistema tradicional acumula datos por sedimentación. Cada tabla, cada log, cada backup, cada índice, cada caché se comportan como capas geológicas que se depositan sin necesitar decisión activa para conservarse. Eliminarlas, en cambio, exige localizar cada copia y cada rastro derivado — un trabajo que, en la práctica, casi nunca se completa del todo.

Los datos de la Coordinated Enforcement Action de febrero de 2026, publicados por el European Data Protection Board, lo describen con precisión clínica. La revisión sobre implementación del derecho de supresión encontró respuestas incompletas que confirmaban haber recibido la solicitud pero no que la supresión se hubiera ejecutado, apoyo en excepciones sin identificar cuál se aplicaba, y retrasos sistemáticos más allá del plazo legal. No es mala voluntad. Es arquitectura: los sistemas no fueron diseñados para olvidar.

Y aquí aparece el desplazamiento que da nombre a este artículo. La pregunta ya no es “¿cómo cumplimos con las solicitudes cuando llegan?” — reactiva, tardía, cara. La pregunta es: ¿qué pasaría si el olvido fuera el estado por defecto, y la persistencia la excepción justificada?

Del principio jurídico al principio de diseño

El GDPR incorpora, en su artículo 25, el data protection by design and by default: los sistemas deben implementar medidas técnicas desde la fase de diseño, no como añadido posterior. El artículo 5 introduce el storage limitation principle: los datos personales solo se conservan mientras haga falta.

Sobre el papel, esto se lleva escribiendo desde 2016. En la práctica, la mayoría de arquitecturas siguen operando bajo la lógica anterior. La distancia entre principio y ejecución es exactamente donde vive el problema — y donde se abren tres cambios concretos.

El TTL como ciudadano de primera clase del esquema

En un sistema tradicional, la retención se gestiona con procesos externos: cron jobs que borran, scripts programados que se ejecutan de noche. Es frágil por naturaleza: el proceso falla, se olvida, queda obsoleto al cambiar el esquema.

La alternativa que va consolidándose en las bases modernas es declarar la retención dentro del propio esquema. ClickHouse permite hacerlo con la cláusula TTL a nivel de tabla o columna, evaluada durante las operaciones de merge. Firestore y Datastore de Google Cloud lo implementan con políticas TTL asociadas a un campo timestamp. Delta Lake incorpora la operación VACUUM con retención por defecto de 30 días —alineada explícitamente con el undue delay del GDPR—.

La diferencia no es solo técnica. Es existencial para el dato: en el modelo tradicional, el dato existe hasta que alguien lo borra; en el modelo declarativo, nace con fecha de caducidad y su persistencia más allá de esa fecha exige un acto positivo de renovación. Es la inversión de la carga de la prueba aplicada a la ingeniería de datos.

La anonimización como transformación verificable

Otra confusión frecuente es tratar la anonimización como una etiqueta administrativa —“este campo está anonimizado”— cuando debería ser una transformación técnica verificable. El paper conjunto de la AEPD y el EDPS de 2021 sobre malentendidos comunes en anonimización es contundente: gran parte de lo que las organizaciones llaman anonimización es en realidad seudonimización reversible, y por tanto sigue siendo dato personal a efectos del GDPR.

La consecuencia arquitectónica: la anonimización real requiere pérdida de información, no solo hash o cifrado. Y esa pérdida tiene que estar integrada en el pipeline como transformación explícita, no como propiedad declarada por el desarrollador que la implementó. Un dato “anonimizado” que puede reidentificarse cruzándolo con otras tablas del mismo sistema no es un dato anonimizado — es una promesa de anonimización que el sistema no cumple.

La retención por defecto se invierte

Una consecuencia natural de los dos puntos anteriores: en un sistema ephemeral-by-design, la ausencia de política declarada debería ser un error de esquema, no una política implícita de conservación.

Esto se traduce en linters de esquema que rechacen tablas sin cláusula TTL, en pipelines de CI/CD que verifiquen que cada nuevo tipo de dato personal tiene un tiempo de vida asignado, y en revisiones de código que traten “guardar por si acaso” como una decisión que exige justificación, no como el camino de menor resistencia. La ausencia de olvido pasa a ser el estado excepcional que hay que defender, no el estado por defecto que hay que asumir.

Casos que iluminan la práctica

Tres implementaciones actuales ayudan a entender cómo se está aterrizando esto en la industria real, más allá del principio abstracto.

Delta Lake y VACUUM. Databricks ha construido su respuesta al derecho al olvido sobre la operación VACUUM, que elimina físicamente los ficheros fuera del periodo de retención declarado. El valor por defecto de 30 días está alineado con la interpretación del undue delay del GDPR. Pero el propio artículo de Databricks reconoce un efecto colateral incómodo: VACUUM elimina también todas las versiones antiguas de la tabla, dejando al sistema en un estado que denominan “data amnesia” — pérdida de historial más allá del dato que se quería eliminar. El olvido tosco borra también lo que no debía olvidarse.

ClickHouse y el TTL declarativo. El enfoque de ClickHouse es más granular: permite declarar TTL a nivel de fila, de columna o de tabla, con acciones que van más allá de la eliminación —mover a almacenamiento más frío, agregar antes de eliminar—. Convierte el olvido en una parte del ciclo de vida gestionada por el motor, no en un proceso externo que hay que orquestar. Probablemente el modelo más maduro disponible hoy en bases analíticas.

LangSmith y las trazas de inferencia. El caso más reciente es especialmente relevante para la ingeniería de datos aplicada a IA: LangSmith incorpora TTL para las trazas de ejecución de agentes, extendiendo automáticamente el periodo según ciertas acciones. Es una señal de dónde va la industria: el olvido está bajando también a los sistemas de observabilidad de IA, donde el volumen de datos personales incidentales —fragmentos de conversaciones, prompts, resultados intermedios— puede ser masivo y sensible.

Lo que esta aproximación no resuelve

Conviene ser preciso. Diseñar infraestructuras que olvidan por defecto no resuelve el problema de qué se decide guardar en primer lugar. Un sistema con TTL declarativos perfectos puede seguir recogiendo datos personales que nunca debieron entrar. La minimización en la recogida es previa a la minimización en la retención.

Tampoco resuelve la tensión estructural con las capas inmutables. Los sistemas basados en blockchain, los logs de auditoría append-only, los repositorios de eventos inmutables — todos se construyeron sobre la premisa de que “lo escrito no se cambia”. Esa premisa entra en conflicto directo con el artículo 17 del GDPR, y no hay solución técnica limpia dentro del paradigma inmutable. Las salidas prácticas pasan por no almacenar dato personal en la capa inmutable, o por diseñar mecanismos criptográficos donde la destrucción de una clave equivale funcionalmente a la eliminación del dato.

Y queda una capa que este artículo no puede abordar: el olvido en los modelos entrenados. Un dato eliminado de una tabla desaparece; un dato eliminado de un modelo, no. Sigue disuelto en los pesos, difuso pero recuperable. Esa es una historia distinta, con su propia ingeniería y sus propias imposibilidades, y merece su propio artículo.

El otro lado: el olvido como derecho estructural

Hasta aquí, la ingeniería. Pero el olvido en los sistemas de datos toca algo que va más allá de la arquitectura: toca la cuestión de qué tipo de memoria colectiva estamos construyendo, y a quién sirve esa memoria.

Sobre la opacidad protectora

Hay una idea que conviene nombrar. La ausencia de dato no es solo una obligación legal — puede ser una forma activa de protección. Cuando un sistema no guarda algo, no puede ser filtrado, no puede ser hackeado, no puede ser exigido por una autoridad, no puede ser comprado por un tercero. La retención construye superficie de riesgo; el olvido la reduce por sustracción.

La opacidad, tratada como principio de diseño, deja de ser un fallo de transparencia y pasa a ser una capa protectora para las personas cuyos datos podrían ser explotados si el sistema los conservara. No es opacidad hacia el usuario legítimo — es opacidad hacia el atacante potencial, hacia el uso futuro no autorizado, hacia el análisis derivado que nadie ha consentido. El desvanecimiento del dato, cuando se diseña con intención, es una forma de cuidado.

Sobre la asimetría entre quien recoge y quien es recogido

Los sistemas que acumulan datos personales son operados por organizaciones con recursos técnicos, jurídicos y comerciales. Las personas cuyos datos se acumulan son individuos con poca visibilidad sobre qué se guarda, dónde y por cuánto tiempo.

Cuando el olvido depende del acto reactivo de la persona —solicitar la supresión, argumentar, esperar, verificar—, la minoría dispuesta a invertir esfuerzo consigue que se le olvide; la mayoría sigue siendo recordada por defecto.

La ephemeralidad por diseño invierte esa asimetría. El olvido deja de exigir un acto positivo del sujeto y pasa a ser el comportamiento automático del sistema. La persistencia, en cambio, requiere justificación explícita de la organización. Esto es más que una decisión técnica: es una redistribución del esfuerzo entre las partes.

Sobre la responsabilidad de quien construye

Aquí cierra el círculo. La pregunta no es si un sistema debe olvidar. La pregunta es qué merece ser recordado, y por cuánto tiempo, y para qué. Cada decisión de retención es, implícitamente, una decisión sobre el poder que el sistema acumulará en el tiempo. Quien diseña acepta esa responsabilidad, o la ignora — pero no puede evitarla.

Y esa responsabilidad tiene tres dimensiones que conviene nombrar en triada: retención mínima (guardar solo lo necesario), caducidad explícita (declarar el fin de cada dato), verificación demostrable (comprobar que el olvido ha ocurrido de verdad). Las tres tienen que estar presentes. Ninguna sola basta.

Preguntas abiertas

• Si guardar es fácil y borrar es difícil, ¿en qué momento se decidió que ese sería el comportamiento por defecto de nuestros sistemas — y quién se benefició de esa decisión?
• ¿Puede un sistema afirmar que ha olvidado si no tiene forma de verificar que la eliminación se ha propagado a todas sus capas derivadas?
• ¿Estamos diseñando arquitecturas que sirvan a las personas que las usan hoy, o archivos permanentes que servirán a los poderes que las hereden mañana?

Las preguntas no tienen respuesta cerrada. Pero conviene una idea final: construir infraestructuras que olvidan no es una concesión al cumplimiento normativo. Es un acto de diseño consciente sobre qué tipo de memoria digital merece ser sostenida colectivamente — y qué tipo de memoria conviene, deliberadamente, dejar caer. Esa decisión no es solo técnica. Es cívica. Y le pertenece a quien la sostiene con su código.

Referencias

• European Data Protection Board — Coordinated Enforcement Action on the right to erasure (CEF 2025), febrero 2026. edpb.europa.eu
• Recording Law — GDPR Right to Be Forgotten: Article 17 Erasure (2026). recordinglaw.com
• AEPD y EDPS — Joint paper on 10 misunderstandings related to anonymisation (2021). edps.europa.eu
• Databricks — Implementing the GDPR ‘Right to be Forgotten’ in Delta Lake (2022). VACUUM y data amnesia. databricks.com/blog
• OneUptime — How to Implement ClickHouse TTL for Data Retention, enero 2026. oneuptime.com/blog
• Google Cloud — Manage data retention with TTL policies (Firestore, Datastore), 2026. cloud.google.com
• LangChain Docs — Enable TTL and data retention (LangSmith), julio 2026. docs.langchain.com
• arXiv — A Systematic Literature Review of the Tension between GDPR and Public Blockchain Systems (2022). arxiv.org/pdf/2210.04541