Infraestructures que obliden: del compliment al disseny

Guardar és fàcil. Esborrar és difícil. Durant dècades, els sistemes de dades es van construir sobre aquesta asimetria silenciosa: conservar per defecte, esborrar per excepció. Avui, amb dades personals acumulant-se a cada capa de l’stack i la regulació europea estrenyent el pas, aquesta lògica s’ha invertit — o hauria. Dissenyar infraestructures que obliden per defecte, i no com a afegit tardà, és un dels desplaçaments arquitectònics més importants que l’enginyeria de dades està aprenent a assumir. Aquest article se centra en la capa clàssica: bases de dades, llacs analítics, còpies de seguretat. El problema paral·lel dels models entrenats —on esborrar la dada no n’hi ha prou— és un altre article.

El punt de partida: l’asimetria entre guardar i esborrar

Un sistema tradicional acumula dades per sedimentació. Cada taula, cada log, cada còpia de seguretat, cada índex, cada memòria cau es comporten com capes geològiques que es depositen sense necessitar cap decisió activa per conservar-se. Eliminar-les, en canvi, exigeix localitzar cada còpia i cada rastre derivat — una feina que, a la pràctica, gairebé mai no es completa del tot.

Les dades de la Coordinated Enforcement Action de febrer de 2026, publicades per l’European Data Protection Board, ho descriuen amb precisió clínica. La revisió sobre implementació del dret de supressió va trobar respostes incompletes que confirmaven haver rebut la sol·licitud però no que la supressió s’hagués executat, suport en excepcions sense identificar quina s’aplicava, i retards sistemàtics més enllà del termini legal. No és mala voluntat. És arquitectura: els sistemes no van ser dissenyats per oblidar.

I aquí apareix el desplaçament que dóna nom a aquest article. La pregunta ja no és “com complim amb les sol·licituds quan arriben?” — reactiva, tardana, cara. La pregunta és: què passaria si l’oblit fos l’estat per defecte, i la persistència l’excepció justificada?

Del principi jurídic al principi de disseny

El GDPR incorpora, al seu article 25, el data protection by design and by default: els sistemes han d’implementar mesures tècniques des de la fase de disseny, no com a afegit posterior. L’article 5 introdueix el storage limitation principle: les dades personals només es conserven mentre calgui.

Sobre el paper, això es porta escrivint des de 2016. A la pràctica, la majoria d’arquitectures continuen operant sota la lògica anterior. La distància entre principi i execució és exactament on viu el problema — i on s’obren tres canvis concrets.

El TTL com a ciutadà de primera classe de l’esquema

En un sistema tradicional, la retenció es gestiona amb processos externs: cron jobs que esborren, scripts programats que s’executen de nit. És fràgil per naturalesa: el procés falla, s’oblida, queda obsolet en canviar l’esquema.

L’alternativa que va consolidant-se a les bases modernes és declarar la retenció dins del mateix esquema. ClickHouse permet fer-ho amb la clàusula TTL a nivell de taula o columna, avaluada durant les operacions de merge. Firestore i Datastore de Google Cloud ho implementen amb polítiques TTL associades a un camp timestamp. Delta Lake incorpora l’operació VACUUM amb retenció per defecte de 30 dies —alineada explícitament amb el undue delay del GDPR—.

La diferència no és només tècnica. És existencial per a la dada: al model tradicional, la dada existeix fins que algú l’esborra; al model declaratiu, neix amb data de caducitat i la seva persistència més enllà d’aquesta data exigeix un acte positiu de renovació. És la inversió de la càrrega de la prova aplicada a l’enginyeria de dades.

L’anonimització com a transformació verificable

Una altra confusió freqüent és tractar l’anonimització com una etiqueta administrativa —“aquest camp està anonimitzat”— quan hauria de ser una transformació tècnica verificable. El paper conjunt de l’AEPD i l’EDPS de 2021 sobre malentesos comuns en anonimització és contundent: gran part del que les organitzacions anomenen anonimització és en realitat pseudonimització reversible, i per tant continua sent dada personal a efectes del GDPR.

La conseqüència arquitectònica: l’anonimització real requereix pèrdua d’informació, no només hash o xifratge. I aquesta pèrdua ha d’estar integrada al pipeline com a transformació explícita, no com a propietat declarada pel desenvolupador que la va implementar. Una dada “anonimitzada” que es pot reidentificar creuant-la amb altres taules del mateix sistema no és una dada anonimitzada — és una promesa d’anonimització que el sistema no compleix.

La retenció per defecte s’inverteix

Una conseqüència natural dels dos punts anteriors: en un sistema ephemeral-by-design, l’absència de política declarada hauria de ser un error d’esquema, no una política implícita de conservació.

Això es tradueix en linters d’esquema que rebutgin taules sense clàusula TTL, en pipelines de CI/CD que verifiquin que cada nou tipus de dada personal té un temps de vida assignat, i en revisions de codi que tractin “guardar per si de cas” com una decisió que exigeix justificació, no com el camí de menor resistència. L’absència d’oblit passa a ser l’estat excepcional que cal defensar, no l’estat per defecte que cal assumir.

Casos que il·luminen la pràctica

Tres implementacions actuals ajuden a entendre com s’està aterrant això a la indústria real, més enllà del principi abstracte.

Delta Lake i VACUUM. Databricks ha construït la seva resposta al dret a l’oblit sobre l’operació VACUUM, que elimina físicament els fitxers fora del període de retenció declarat. El valor per defecte de 30 dies està alineat amb la interpretació del undue delay del GDPR. Però el mateix article de Databricks reconeix un efecte col·lateral incòmode: VACUUM elimina també totes les versions antigues de la taula, deixant el sistema en un estat que anomenen “data amnesia” — pèrdua d’història més enllà de la dada que es volia eliminar. L’oblit tosc esborra també el que no s’havia d’oblidar.

ClickHouse i el TTL declaratiu. L’enfocament de ClickHouse és més granular: permet declarar TTL a nivell de fila, de columna o de taula, amb accions que van més enllà de l’eliminació —moure a emmagatzematge més fred, agregar abans d’eliminar—. Converteix l’oblit en una part del cicle de vida gestionada pel motor, no en un procés extern que cal orquestrar. Probablement el model més madur disponible avui en bases analítiques.

LangSmith i les traces d’inferència. El cas més recent és especialment rellevant per a l’enginyeria de dades aplicada a IA: LangSmith incorpora TTL per a les traces d’execució d’agents, estenent automàticament el període segons certes accions. És un senyal d’on va la indústria: l’oblit també està baixant als sistemes d’observabilitat d’IA, on el volum de dades personals incidentals —fragments de converses, prompts, resultats intermedis— pot ser massiu i sensible.

El que aquesta aproximació no resol

Cal ser precisos. Dissenyar infraestructures que obliden per defecte no resol el problema de què es decideix guardar en primer lloc. Un sistema amb TTL declaratius perfectes pot continuar recollint dades personals que mai no haurien d’haver entrat. La minimització en la recollida és prèvia a la minimització en la retenció.

Tampoc resol la tensió estructural amb les capes immutables. Els sistemes basats en blockchain, els logs d’auditoria append-only, els repositoris d’esdeveniments immutables — tots es van construir sobre la premissa que “el que està escrit no es canvia”. Aquesta premissa entra en conflicte directe amb l’article 17 del GDPR, i no hi ha solució tècnica neta dins del paradigma immutable. Les sortides pràctiques passen per no emmagatzemar dada personal a la capa immutable, o per dissenyar mecanismes criptogràfics on la destrucció d’una clau equival funcionalment a l’eliminació de la dada.

I queda una capa que aquest article no pot abordar: l’oblit als models entrenats. Una dada eliminada d’una taula desapareix; una dada eliminada d’un model, no. Continua dissolta als pesos, difusa però recuperable. Aquesta és una història diferent, amb la seva pròpia enginyeria i les seves pròpies impossibilitats, i mereix el seu propi article.

L’altre costat: l’oblit com a dret estructural

Fins aquí, l’enginyeria. Però l’oblit als sistemes de dades toca alguna cosa que va més enllà de l’arquitectura: toca la qüestió de quin tipus de memòria col·lectiva estem construint, i a qui serveix aquesta memòria.

Sobre l’opacitat protectora

Hi ha una idea que cal anomenar. L’absència de dada no és només una obligació legal — pot ser una forma activa de protecció. Quan un sistema no guarda alguna cosa, no pot ser filtrada, no pot ser hackejada, no pot ser exigida per una autoritat, no pot ser comprada per un tercer. La retenció construeix superfície de risc; l’oblit la redueix per sostracció.

L’opacitat, tractada com a principi de disseny, deixa de ser un fracàs de transparència i passa a ser una capa protectora per a les persones les dades de les quals podrien ser explotades si el sistema les conservés. No és opacitat cap a l’usuari legítim — és opacitat cap a l’atacant potencial, cap a l’ús futur no autoritzat, cap a l’anàlisi derivada que ningú ha consentit. L’esvaïment de la dada, quan es dissenya amb intenció, és una forma de cura.

Sobre l’asimetria entre qui recull i qui és recollit

Els sistemes que acumulen dades personals són operats per organitzacions amb recursos tècnics, jurídics i comercials. Les persones les dades de les quals s’acumulen són individus amb poca visibilitat sobre què es guarda, on i per quant de temps.

Quan l’oblit depèn de l’acte reactiu de la persona —sol·licitar la supressió, argumentar, esperar, verificar—, la minoria disposada a invertir esforç aconsegueix que se l’oblidi; la majoria continua sent recordada per defecte.

L’ephemeralitat per disseny inverteix aquesta asimetria. L’oblit deixa d’exigir un acte positiu del subjecte i passa a ser el comportament automàtic del sistema. La persistència, en canvi, requereix justificació explícita de l’organització. Això és més que una decisió tècnica: és una redistribució de l’esforç entre les parts.

Sobre la responsabilitat de qui construeix

Aquí tanca el cercle. La pregunta no és si un sistema ha d’oblidar. La pregunta és què mereix ser recordat, i durant quant de temps, i per a què. Cada decisió de retenció és, implícitament, una decisió sobre el poder que el sistema acumularà en el temps. Qui dissenya accepta aquesta responsabilitat, o la ignora — però no la pot evitar.

I aquesta responsabilitat té tres dimensions que cal anomenar en tríada: retenció mínima (guardar només el necessari), caducitat explícita (declarar la fi de cada dada), verificació demostrable (comprovar que l’oblit ha passat de veritat). Les tres han de ser presents. Cap sola n’hi ha prou.

Preguntes obertes

• Si guardar és fàcil i esborrar és difícil, en quin moment es va decidir que aquest seria el comportament per defecte dels nostres sistemes — i qui es va beneficiar d’aquesta decisió?
• Pot un sistema afirmar que ha oblidat si no té manera de verificar que l’eliminació s’ha propagat a totes les seves capes derivades?
• Estem dissenyant arquitectures que serveixin a les persones que les fan servir avui, o arxius permanents que serviran als poders que les heretaran demà?

Les preguntes no tenen resposta tancada. Però convé una idea final: construir infraestructures que obliden no és una concessió al compliment normatiu. És un acte de disseny conscient sobre quin tipus de memòria digital mereix ser sostinguda col·lectivament — i quin tipus de memòria convé, deliberadament, deixar caure. Aquesta decisió no és només tècnica. És cívica. I pertany a qui la sosté amb el seu codi.

Referències

• European Data Protection Board — Coordinated Enforcement Action on the right to erasure (CEF 2025), febrer 2026. edpb.europa.eu
• Recording Law — GDPR Right to Be Forgotten: Article 17 Erasure (2026). recordinglaw.com
• AEPD i 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 i data amnesia. databricks.com/blog
• OneUptime — How to Implement ClickHouse TTL for Data Retention, gener 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), juliol 2026. docs.langchain.com
• arXiv — A Systematic Literature Review of the Tension between GDPR and Public Blockchain Systems (2022). arxiv.org/pdf/2210.04541