El derecho al olvido frente al derecho a la eternidad: donde el RGPD y los registros inmutables chocan, y qué hacer al respecto
Dos leyes que no pueden tener razón a la vez
Un correo al que no hay nada que responder
Imagine una mañana cualquiera en una empresa que ha construido su servicio sobre una blockchain. En el buzón hay un mensaje de un usuario. El texto es breve y cortés: «Solicito la supresión de mis datos personales. Base jurídica: artículo 17 del RGPD».
Lo que ocurre a partir de ahí no lo ve la persona que está al otro lado.
El abogado mira el calendario: el artículo 12(3) concede un mes para responder y, si la solicitud es compleja, el plazo puede prorrogarse otros dos. Tres como máximo. El ingeniero mira la arquitectura y dice la frase tras la cual el hilo de correo suele quedarse en silencio: no se puede borrar. No «es complicado», ni «sale caro», ni «hace falta un sprint». No se puede, porque la anotación ya se ha propagado a nodos de la red que no pertenecen a la empresa, y todo el valor de esa red consiste precisamente en que de allí no se retira nada. La inmutabilidad no es un efecto colateral: es aquello por lo que se ha pagado.
Y conviene detenerse aquí, porque es justo a partir de este punto donde empieza lo interesante.
No es una discusión sobre «cómo hacerlo bien»
Estas situaciones suelen describirse como un conflicto entre la tecnología y la regulación: el derecho se ha quedado atrás respecto de la ingeniería, dicen, démosle tiempo y ya la alcanzará. Es un marco cómodo, pero equivocado.
Lo que chocan en realidad son dos normas vigentes, y las dos operan ahora mismo.
La primera es el artículo 17 del RGPD, cuyo título oficial es «Right to erasure ('right to be forgotten')» («Derecho de supresión ("derecho al olvido")»). Fíjese en las comillas: el «derecho al olvido» no es un derecho autónomo, sino un sinónimo no oficial. El término jurídico es derecho de supresión. El Reglamento es aplicable desde el 25 de mayo de 2018 y rige directamente en todos los Estados de la UE. El artículo 17(1) recoge seis causas de supresión, y la lista es cerrada: los datos ya no son necesarios para los fines para los que se recogieron; se ha retirado el consentimiento y no existe otra base jurídica; el interesado se ha opuesto al tratamiento y el responsable no tiene motivos legítimos que prevalezcan; el tratamiento fue ilícito; la supresión la impone la ley; los datos se obtuvieron de un menor en el contexto de la oferta de servicios en línea.
La segunda norma no es una ley, sino la física de los sistemas distribuidos, y actúa con la misma inflexibilidad. Los datos escritos en una blockchain están replicados en multitud de nodos independientes. Nadie dispone de un botón que anule una anotación: formalmente la cadena se puede modificar, pero para ello todos los nodos tendrían que actualizar o borrar su copia y aceptar el cambio, y en la práctica una parte de las copias seguirá igual. Es una propiedad del mismo orden que «una tortilla no vuelve a convertirse en huevos».
Formalmente, claro está, la ley gana a la física: una norma jurídica no decae porque sea difícil de cumplir. Pero es justamente por eso por lo que el conflicto no se resuelve solo: hay que cumplir la norma y no existe la manera de hacerlo.
Dos reguladores, dos respuestas distintas
Resulta significativo que ni siquiera las autoridades de control de la UE respondan igual a esta pregunta, y que con el tiempo respondan de forma cada vez más severa.
La francesa CNIL publicó ya en 2018 un informe sobre blockchain y RGPD en el que reconocía sin rodeos que atender una solicitud de supresión es técnicamente imposible cuando los datos están escritos en la cadena. A continuación, la CNIL proponía un rodeo: inscribir en la blockchain no los datos, sino una prueba criptográfica de su existencia, y conservar los originales y las claves fuera, para destruirlos cuando se solicite. Así, en la formulación de la CNIL, cabe acercarse al efecto de una supresión. Pero en ese mismo texto figura una salvedad honesta: descontados algunos esquemas criptográficos concretos, esas soluciones no son, en rigor, una supresión, porque los datos siguen en la blockchain. Y una conclusión que casi nunca se cita: la CNIL reconoce el valor de esas soluciones, pero duda de que sean capaces de garantizar el pleno cumplimiento del RGPD.
El organismo paneuropeo, el EDPB, formula una posición bastante más dura en sus directrices sobre el tratamiento de datos personales mediante blockchain (versión final adoptada el 7 de julio de 2026). La frase clave: la imposibilidad técnica no puede servir de justificación para incumplir los requisitos del RGPD. La lógica es sencilla e incómoda: la protección de datos debe incorporarse desde el diseño, de modo que elegir una arquitectura de la que no se borra nada es una decisión propia, tomada de antemano, y no un caso de fuerza mayor.
De ahí la recomendación general del EDPB: por regla general, no deben almacenarse datos personales en una blockchain, y desde luego no tienen sitio en el contenido de las transacciones. Se precisa además que escribir en la cadena texto en claro, datos cifrados o datos hasheados está igualmente desaconsejado: el cifrado no saca los datos del ámbito del RGPD.
La diferencia entre la postura de 2018 y la de 2026 es la que va de «entendemos que no puedan» a «que no puedan es consecuencia de su propia elección».
Por qué esto no afecta solo a la blockchain
Es fácil concluir que el problema es estrecho: no construyas sobre blockchain y no habrá conflicto. Pero la línea de fractura es más ancha.
Atraviesa cualquier sistema en el que la conservación a largo plazo sea un objetivo deliberado y no un efecto colateral. Atraviesa los archivos. Atraviesa las copias de seguridad, de las que —como muestran los análisis de la práctica sancionadora— muchas empresas excluyen la supresión por defecto, sin molestarse en justificarlo. Atraviesa el borrado criptográfico, ese recurso de ingeniería tan extendido en el que, en lugar de los datos, se destruye la clave y el texto cifrado se queda donde estaba. Y atraviesa cualquier intento de sustituir la supresión por la anonimización.
Y una cosa más: el propio RGPD no define en ningún sitio qué es la «erasure» (la supresión). Ni el artículo 17 ni los considerandos contienen definición alguna. El estudio elaborado para el Parlamento Europeo por su servicio de estudios, el EPRS (PE 634.445, julio de 2019), lo señala expresamente y añade que hay motivos para entender que no se exige una destrucción física: en el asunto Google Spain se consideró suficiente eliminar el enlace de los resultados de búsqueda, no la publicación misma. El periódico siguió ahí. El enlace desapareció.
Es decir, la discusión no va de qué tecnología es mejor. Va de qué significa exactamente la palabra «suprimir», y de la respuesta depende que su arquitectura sea legal o no.
Qué viene a continuación en este artículo
A partir de aquí desmonto el conflicto pieza a pieza, sin intentar reducirlo a una conclusión elegante.
Qué exige realmente el artículo 17: las seis causas, las cinco excepciones, los plazos reales. Qué resolvió el TJUE en el asunto Google Spain de 2014 y por qué su lógica sobre la caducidad de la información golpea a los almacenes eternos con más fuerza de lo que parece. Dónde están los límites territoriales del derecho al olvido tras la sentencia en el asunto Google contra CNIL de 2019, y por qué el tópico de que «el TJUE prohibió la supresión global» es inexacto.
Después, el lado técnico: qué es el borrado criptográfico según el estándar del NIST, por qué el estándar lo sitúa en el nivel «purge» y no en «destroy», y en qué condiciones no funciona. Y, por separado, por qué el EDPB considera datos personales tanto el texto cifrado como el hash, y cuál es la única construcción que, en opinión tanto de la CNIL como del EDPB, saca una anotación del ámbito del RGPD.
Y, por último, el precio de todo esto. La infracción del artículo 17 entra en el nivel superior de sanciones del artículo 83(5): hasta 20 millones de euros o, si el infractor es una empresa, hasta el 4% de su volumen de negocio anual global del ejercicio financiero anterior, aplicándose la mayor de las dos cuantías.
Al final no habrá una respuesta cerrada: no la tienen ni la CNIL, ni el EDPB, ni el TJUE. Habrá un mapa: dónde el terreno es firme, dónde se discute y dónde está el precipicio.
El derecho al olvido: de dónde viene
Historia de un anuncio de subasta
En marzo de 2010, el español Mario Costeja González presentó una reclamación ante la autoridad nacional de protección de datos. El motivo era prosaico hasta resultar incómodo: al teclear su nombre en Google, el buscador devolvía enlaces a dos páginas del diario La Vanguardia. Publicaciones del 19 de enero y del 9 de marzo de 1998, con un anuncio de subasta de inmuebles para saldar deudas con la Seguridad Social.
El procedimiento de apremio se había resuelto por completo y hacía muchos años. Pero el nombre de aquel hombre seguía pegándose a esas dos páginas en cada consulta: la de un posible empleador, un socio, un vecino. El reclamante escribió que la mención había quedado ya del todo irrelevante.
El 30 de julio de 2010, el regulador español, la AEPD, dictó una resolución que explica mucho sobre cómo está construido este derecho. La reclamación contra el diario la desestimó: la publicación era lícita y se había hecho por orden del Ministerio de Trabajo para dar a la subasta la máxima difusión. La reclamación contra Google, en cambio, la estimó.
La diferencia aquí no es técnica, sino de fondo. El diario hizo exactamente lo que debía hacer en 1998. El buscador hace otra cosa: reúne los rastros dispersos de una persona en una sola lista y la mantiene a mano doce años después.
Qué dijo el Tribunal de Justicia de la UE
El 13 de mayo de 2014, la Gran Sala del Tribunal de Justicia de la Unión Europea dictó sentencia en el asunto C-131/12, Google Spain SL and Google Inc. v AEPD and Mario Costeja González. Entonces el RGPD aún no existía: el Tribunal aplicó la Directiva 95/46/CE y los artículos 7 y 8 de la Carta de los Derechos Fundamentales de la UE.
El Tribunal estableció cuatro cosas, y ninguna era evidente.
La primera: la actividad de un buscador es tratamiento de datos personales, y quien lo explota es responsable del tratamiento. No una tubería neutral, sino un sujeto que responde por ese tratamiento.
La segunda: la jurisdicción de la UE alcanza a Google a través de su filial española, que vende publicidad. La venta de espacios publicitarios resultó ser un vínculo suficiente.
La tercera es la más importante. El operador está obligado a eliminar un enlace de los resultados de la búsqueda por el nombre de una persona incluso cuando la página en sí permanece intacta y incluso, llegado el caso, cuando la publicación que contiene es en sí misma lícita. La responsabilidad del buscador es autónoma respecto de la del editor. El diario permanece; el enlace desaparece.
La cuarta es el test de ponderación. Hay que comprobar si a esa persona le asiste el derecho a que la información «en el momento actual» deje de estar vinculada a su nombre. Y, literalmente, para reconocer ese derecho no se exige que la inclusión del enlace en la lista cause un perjuicio al interesado. No hay que probar el daño.
Por qué precisamente el buscador
La motivación del Tribunal explica la lógica mejor que cualquier paráfrasis. En el apartado 80 se afirma que un motor de búsqueda permite a cualquier usuario obtener una visión estructurada de la información relativa a una persona y elaborar así un perfil más o menos detallado de ella. El efecto se multiplica porque los buscadores hacen que esa información esté en todas partes.
El apartado 93 es el núcleo doctrinal de toda la construcción. Incluso un tratamiento inicialmente lícito de datos exactos puede devenir con el tiempo incompatible con la propia Directiva si esos datos ya no son necesarios para los fines para los que se recogieron. Sucede, en particular, cuando resultan inadecuados, no pertinentes o ya no pertinentes, o excesivos, habida cuenta del tiempo transcurrido.
Es una idea poco frecuente en el Derecho: la verdad sobre una persona no se estropea, pero su pertinencia sí. El anuncio de 1998 no se volvió falso. Dejó de decir nada sobre quién era Costeja en 2014. En el apartado 98, el Tribunal se remitió expresamente a que la publicación original se había producido dieciséis años antes.
Con todo, el Tribunal no repartió indulgencias. Los derechos de la persona, según la fórmula de la sentencia, prevalecen «como regla general» tanto sobre el interés económico del operador del buscador como sobre el interés del público en acceder a la información. Pero no siempre: si por razones especiales —por ejemplo, por el papel que esa persona desempeña en la vida pública— la injerencia en sus derechos está justificada por un interés preponderante del público, la respuesta será la contraria.
Cómo se convirtió en artículo de una ley
Casi dos años después, el 27 de abril de 2016, se aprobó el RGPD, el Reglamento (UE) 2016/679, aplicable desde el 25 de mayo de 2018. La lógica de Google Spain obtuvo allí un artículo propio.
El artículo 17 se titula «Right to erasure ('right to be forgotten')», «Derecho de supresión ("derecho al olvido")». Conviene fijarse en las comillas que aparecen dentro del propio título: «derecho al olvido» es un sinónimo no oficial, un nombre bonito para los titulares de prensa. El término jurídico es derecho de supresión.
Los motivos son exactamente seis, y la lista es cerrada:
- (a) los datos ya no son necesarios para los fines para los que se recogieron;
- (b) la persona retiró su consentimiento y no existe otra base jurídica;
- (c) la persona se opuso al tratamiento y no hay motivos legítimos que prevalezcan (frente a la mercadotecnia directa, la oposición opera de forma incondicional);
- (d) el tratamiento fue ilícito;
- (e) la supresión viene exigida por el Derecho de la Unión o de un Estado miembro;
- (f) los datos se obtuvieron de un menor en el marco de la prestación de servicios en línea.
El apartado 2 del artículo 17 es herencia directa del caso Costeja. Si el responsable ha hecho públicos los datos, está obligado a adoptar medidas razonables para informar a otros responsables de que el interesado exige la supresión de los enlaces, las copias y las réplicas. Con una salvedad honesta: «teniendo en cuenta la tecnología disponible y el coste de su aplicación». No es una obligación de resultado.
El plazo no lo fija el artículo 17, sino el artículo 12(3): sin dilación indebida y, en cualquier caso, en el plazo de un mes, prorrogable otros dos; tres en total.
Cinco puertas que siguen abiertas
Las excepciones están enumeradas en el artículo 17(3) y tienen una formulación importante: operan «en la medida en que» el tratamiento sea necesario. La excepción no mata la solicitud entera, le recorta una parte.
No hay obligación de suprimir cuando el tratamiento es necesario:
- (a) para ejercer la libertad de expresión e información, donde entra el periodismo;
- (b) para cumplir una obligación legal, cumplir una misión de interés público o ejercer poderes públicos;
- (c) por razones de interés público en el ámbito de la salud pública;
- (d) con fines de archivo en interés público, de investigación científica o histórica o estadísticos, pero solo si la supresión hiciera imposible u obstaculizara gravemente el logro de esos objetivos;
- (e) para la formulación, el ejercicio o la defensa de reclamaciones.
Aparte queda el artículo 85: los Estados miembros deben conciliar por ley la protección de datos con la libertad de expresión, incluido el tratamiento con fines periodísticos, académicos, artísticos y literarios. El derecho al olvido no se concibió como una herramienta para limpiar la historia, y la letra (d), la de los archivos, lo deja fijado sin rodeos.
Para qué sirve esto a las personas
La respuesta es más simple de lo que parece. Antes de internet, el olvido era la opción por defecto: el periódico amarilleaba, la colección encuadernada bajaba al sótano, la persona se mudaba a otra ciudad y empezaba de cero. Nadie tuvo que redactar ese derecho: surgía solo, de la imperfección de la memoria.
La búsqueda acabó con esa imperfección. Ahora, por defecto, hay recuerdo permanente, y además selectivo: no la biografía, sino sus peores cinco minutos, elevados a la primera línea de los resultados. Una deuda saldada en los noventa. Una acusación desestimada por un tribunal. Un error cometido a los diecinueve años.
El artículo 17 es un intento de devolver por medios jurídicos lo que antes daba la naturaleza. Y reconoce con honestidad que aquí chocan derechos: el derecho de una persona a su futuro contra el derecho de todos los demás a conocer el pasado. El RGPD no resuelve ese conflicto de una vez por todas. Solo ordena ponderar, cada vez de nuevo, atendiendo a cuánto tiempo ha pasado y a quién tenemos delante: un particular, o alguien cuyo papel en la vida pública la sociedad tiene derecho a recordar.
Inmutabilidad: por qué la cadena de bloques no sabe olvidar
Una base de datos convencional está pensada para que un registro pueda corregirse. Hay una fila, hay una orden de «actualizar», hay un botón de «eliminar». La cadena de bloques la construyeron personas que veían justo ahí la vulnerabilidad: si un registro puede modificarse en silencio, tarde o temprano alguien lo modificará en su propio beneficio.
El hash: una huella imposible de falsificar
En la base de todo está la función hash. Es una picadora matemática: a la entrada se le da cualquier cosa (una línea de texto, un archivo, un libro entero) y a la salida sale siempre una cadena corta de longitud fija. Tiene tres propiedades importantes:
- una misma entrada produce siempre la misma salida;
- cambiar un solo carácter de la entrada cambia la salida por completo: no «un poco», sino hasta hacerla irreconocible;
- a partir de la salida no se puede reconstruir la entrada.
El hash es la huella de los datos. No los guarda, pero los acredita de forma inequívoca: con el archivo y su hash en la mano, en una fracción de segundo se comprueba que el archivo no ha sido sustituido.
La cadena: por qué tocar un registro lo rompe todo
Después viene el truco sencillo sobre el que se sostiene toda la construcción. Cada bloque de registros contiene el hash del bloque anterior. El segundo remite al primero, el tercero al segundo, y así sucesivamente.
Imagine un libro de contabilidad en el que, en lo alto de cada página, está anotada la huella de la anterior. Si se retoca una cifra en la página 40, su huella cambia y deja de coincidir con la que figura en la página 41. Para tapar la falsificación habrá que reescribir la 41. Pero entonces se descuadra la 42. Y así hasta la última página.
Por eso no hay manera de editar un registro aislado dentro de una cadena de bloques. Solo cabe reescribir todo lo que viene después y conseguir que la nueva versión sea aceptada por quienes guardan copias de la cadena. En un estudio publicado en 2019 por el Servicio de Estudios del Parlamento Europeo, la propia palabra «inmutabilidad» se califica de engañosa: si los participantes se conciertan, los datos pueden modificarse; resulta extremadamente gravoso y caro, pero no imposible. La diferencia es de fondo: la inmutabilidad no es una ley física, sino una cerradura muy cara.
«Borrarlo en la copia propia» no significa nada
La segunda mitad de la respuesta se esconde en la palabra «distribuido». La cadena de bloques no reside en un único servidor, sino en multitud de máquinas independientes repartidas por todo el mundo, y muchas de ellas guardan una copia íntegra de la cadena.
De ahí una conclusión incómoda para cualquier jurista: aunque el responsable del tratamiento quiera de verdad suprimir un registro, no tiene acceso físico a las copias ajenas. Borrará la suya y quedarán todas las demás. A los demás puede pedírselo, pero no están obligados a hacerle caso. El CEPD lo describe sin dramatismo: técnicamente la modificación es posible, pero exige que todos los nodos actualicen o eliminen su copia de la cadena y estén de acuerdo con ello; en la práctica el cambio no llega a todas las copias y los datos originales siguen siendo accesibles. En eso consiste, precisamente, todo el sentido del diseño.
La autoridad francesa, la CNIL, ya lo dejó por escrito en 2018: satisfacer una solicitud de supresión cuando los datos están inscritos en una cadena de bloques es técnicamente imposible. El Comité Europeo de Protección de Datos (CEPD, EDPB por sus siglas en inglés), en sus Directrices 02/2025 —la versión final se adoptó el 7 de julio de 2026—, va más lejos: por regla general, no se recomienda almacenar datos personales en una cadena de bloques y, desde luego, no deben incluirse en el contenido de las transacciones. Y lo dice aparte, para que no quede resquicio: la imposibilidad técnica no sirve para justificar el incumplimiento del RGPD.
Ambas autoridades describen vías alternativas, y el contorno es común: en la cadena no se escriben los datos, sino la prueba de su existencia —un puntero, un compromiso criptográfico (commitment) o un hash con clave—, y todo lo necesario para verificar esa prueba se conserva fuera. La CNIL establece un orden de preferencia: primero el commitment, después el hash con clave, después el texto cifrado. El CEPD es más estricto: pone en el mismo plano el texto en claro, el texto cifrado y el hash, y desaconseja escribir datos personales en la cadena bajo cualquiera de esas formas; su sitio está fuera de ella. Los datos personales cifrados siguen siendo datos personales; e incluso un cifrado moderno implementado de forma impecable acabará cediendo ante el tiempo si la cadena se conserva de manera indefinida.
El único supuesto en el que ambas autoridades coinciden en que los datos han dejado de ser personales es el perfectly hiding commitment (compromiso perfectamente ocultador): si se borran tanto el valor original como el secreto auxiliar, el compromiso que permanece en la cadena resulta inútil, porque a partir de él no se pueden reconstruir ni identificar los datos de partida. Sobre todo lo demás, la CNIL dice exactamente aquello que suele omitirse al citarla: en rigor, esas soluciones no equivalen a una supresión, porque los datos siguen existiendo en la cadena de bloques; y añade que pone en duda su capacidad de garantizar el pleno cumplimiento del RGPD.
Arweave: la eternidad no como efecto secundario
Bitcoin y las redes de su estirpe son inmutables de paso: su cometido es contar dinero, no guardar archivos. Arweave se construyó precisamente para almacenar: el fichero se sube una vez, se paga una vez y a partir de ahí simplemente permanece ahí.
La economía funciona así. El pago se divide en dos: una parte va al minero de inmediato y la principal, a un fondo común del que se paga a quienes almacenan los datos con años de antelación. El cálculo se apoya en que el almacenamiento se abarata: según el yellow paper de Arweave, a lo largo de medio siglo el coste del gigabyte-hora ha caído de media algo más de un 30 % anual, y la documentación del proyecto sostiene que basta un medio por ciento anual para sostener el fondo de forma indefinida. La comisión de subida se calcula a precios actuales como el pago por doscientos años de almacenamiento en veinte copias.
Aquí hay que decir lo que no aparece en las descripciones publicitarias. Doscientos años es un parámetro de fijación de precios, no una promesa; el carácter indefinido se sostiene sobre dos supuestos: que el almacenamiento siga abaratándose y que el precio del token no se desplome. Los propios autores del protocolo lo escriben sin rodeos: no esperan que la red, tal como es hoy, produzca bloques eternamente; tras el último bloque, el incentivo económico para conservar los datos dejará paso a uno social y los datos, según sus cálculos, los recogerá un sistema sucesor. Y el protocolo no obliga a ningún nodo a guardarlo todo: cada uno decide qué conserva, y la preservación se garantiza de forma probabilística y a escala del conjunto de la red.
Hace falta una segunda matización. Ninguno de los documentos de las autoridades europeas que he leído analiza Arweave por separado: ni a él, ni a IPFS, ni a los demás sistemas de almacenamiento permanente. Todo lo que cabe decir de ellos en clave regulatoria es un traslado por analogía de los razonamientos sobre la cadena de bloques. La analogía parece sólida: la misma inmutabilidad, la misma distribución, la misma ausencia de un único botón de «eliminar». Pero sigue siendo una analogía, no la posición de una autoridad.
Y una tercera que sería deshonesto omitir: nuestro propio proyecto escribe su memoria precisamente en Arweave. Eso no invalida nada de lo anterior, pero usted tiene derecho a saber que quien firma este texto no es aquí un observador ajeno.
La conclusión es sencilla. El debate entre el derecho al olvido y la memoria eterna no va de quién tiene pereza para pulsar un botón. No hay botón. La arquitectura no lo contempla, y no lo contempla a propósito.
Dónde chocan exactamente
El conflicto «derecho al olvido frente a inmutabilidad» suena abstracto hasta que se descompone en puntos concretos. Son cuatro: qué ocurre jurídicamente con los datos, quién responde de ellos, cuánto cuesta el error y cómo acaban los datos personales en una cadena pública.
Punto primero: los datos entran y se quedan para siempre
El artículo 17 del RGPD es sencillo en su planteamiento. Hay seis supuestos tasados en los que el interesado puede exigir la supresión: los datos ya no son necesarios para el fin con el que se recogieron; se retira el consentimiento y no existe otra base jurídica; se presenta oposición al tratamiento y el responsable del tratamiento no acredita motivos legítimos que prevalezcan (frente a la mercadotecnia directa la oposición opera sin condiciones); el tratamiento fue ilícito; la supresión la impone la ley; los datos se recabaron de un menor en el marco de una oferta de servicios de la sociedad de la información. Si concurre cualquiera de los seis, el responsable está obligado a suprimir «without undue delay» (sin dilación indebida). El artículo 12(3) traduce eso a calendario: un mes, prorrogable por dos más.
Ahora imagine que los datos están inscritos en una blockchain. El mes corre y no hay nada que suprimir: la arquitectura no contempla el borrado, contempla la adición.
La CNIL —el regulador francés, que abordó el asunto en un informe de septiembre de 2018— lo formuló sin rodeos: es técnicamente imposible atender una solicitud de supresión cuando los datos están inscritos en una blockchain. A continuación, la CNIL describió una vía indirecta: si en la cadena no figura el texto en claro, sino un compromiso criptográfico, un hash con clave o un texto cifrado, destruyendo fuera de la cadena los datos de origen y los elementos de verificación cabe «acercarse al efecto de la supresión». Y matizó de inmediato: salvo en determinados esquemas de commitment, esas soluciones no constituyen, en rigor, una supresión, puesto que los datos siguen existiendo en la cadena. La valoración que la propia CNIL hace de su propia recomendación: reconocemos el valor de estas soluciones, pero dudamos de su capacidad para garantizar el pleno cumplimiento del RGPD.
Casi ocho años después, el EDPB —el Comité Europeo de Protección de Datos— se pronunció con más dureza. En la versión final de las Guidelines 02/2025 (adoptadas el 7 de julio de 2026) hay una frase que cierra la principal línea de defensa del sector: la imposibilidad técnica no puede servir de justificación para incumplir el RGPD. El razonamiento es este: el artículo 25 exige protección de datos «by design» (desde el diseño), es decir, en el momento de elegir los medios de tratamiento. Si usted ha optado por un almacenamiento inmutable, esa es su elección, no un caso de fuerza mayor.
De ahí la recomendación general del EDPB: por regla general, los datos personales no deberían almacenarse en una blockchain, ni incluirse en el contenido de las transacciones. El apartado 104 va más lejos y pone al mismo nivel tres formatos —texto en claro, datos cifrados y hashes—: no se recomienda inscribir datos personales en la cadena bajo ninguna de esas formas; su sitio está fuera de la cadena.
Esto último es lo que más sorprende a los ingenieros. «Pero si lo he cifrado» no es un argumento: el EDPB recuerda que los datos personales cifrados siguen siendo datos personales. Y añade algo en lo que rara vez se piensa al diseñar: incluso un cifrado moderno implementado de forma impecable acabará sucumbiendo al tiempo si la cadena se conserva de manera indefinida.
Punto segundo: quién es aquí el responsable del tratamiento
El RGPD parte del supuesto de que cada unidad de datos personales tiene al menos un responsable del tratamiento: el interesado sabe a quién dirigir su solicitud. El estudio elaborado para el Panel para el Futuro de la Ciencia y la Tecnología del Parlamento Europeo (EPRS, PE 634.445, julio de 2019; autora: Michèle Finck) lo señala como el primero de los dos conflictos de raíz: la blockchain sustituye a un actor único por una multitud de participantes, y la falta de consenso sobre cómo determinar quién es responsable impide repartir la responsabilidad.
La CNIL intentó repartirla. Se considera responsables del tratamiento a los participantes con derecho de escritura que deciden enviar datos a validación: la persona física, si el tratamiento guarda relación con una actividad profesional o comercial; la persona jurídica, si inscribe datos personales en la cadena. Los mineros no son responsables: se limitan a validar transacciones sin determinar fines ni medios. Quien compra bitcoin para sí mismo tampoco lo es; ahí opera la excepción de la actividad personal.
Pero la construcción se rompe en el paso siguiente. Los mineros, según la CNIL, pueden acabar siendo encargados del tratamiento. Y el encargado, conforme al artículo 28 del RGPD, actúa en virtud de un contrato con el responsable. ¿Cómo se firma un contrato con un minero anónimo de una red pública que ni siquiera sabe de quién es la transacción que incluye en el bloque? La CNIL reconoció la dificultad práctica y respondió con honestidad que mantiene sobre este punto una «reflexión en profundidad». En el informe no hay ninguna construcción cerrada.
Segunda trampa: si varios participantes tratan datos con un fin común, todos corren el riesgo de convertirse en corresponsables del tratamiento conforme al artículo 26. La CNIL aconseja designar de antemano a uno solo o crear una persona jurídica. Ambas salidas presuponen que el círculo de participantes se conoce por adelantado y que hay alguien que pueda actuar en su nombre.
Conviene recordar que, en el asunto Google Spain (C-131/12, Gran Sala, 13 de mayo de 2014), el Tribunal de Justicia de la UE consideró responsable del tratamiento al gestor de un motor de búsqueda: alguien que se limita a indexar páginas ajenas y que nada tiene que ver con la publicación original. Y esa responsabilidad resultó ser autónoma: está obligado a retirar el enlace incluso en aquellos casos en que la publicación en la página de origen es lícita en sí misma. El Tribunal no buscó a quién le resultaba más cómodo responder, sino quién determina los fines y los medios. Esa misma lógica, aplicada a un registro distribuido, no ofrece una buena respuesta. Ofrece muchas malas.
Punto tercero: el precio del error
La vulneración del derecho de supresión entra en el más alto de los dos niveles de multas. El artículo 83(5)(b) cubre los derechos de los interesados recogidos en los artículos 12 a 22, y el artículo 17 queda comprendido por entero. Techo: 20 000 000 de euros o el 4 % del volumen de negocio total anual global del ejercicio financiero anterior.
Tres detalles que suelen distorsionarse. La fórmula es «whichever is higher» (la mayor de las dos): se toma la cuantía más alta, no la más baja. El porcentaje se calcula sobre el volumen de negocio, no sobre el beneficio, y sobre el mundial, no sobre el europeo. El umbral porcentual se aplica a las empresas; a quienes no lo son, solo la cifra absoluta.
También hay una mecánica atenuante. Artículo 83(3): cuando se producen varias infracciones en el marco de operaciones vinculadas, la cuantía total no supera la prevista para la infracción más grave; las multas no se suman. El artículo 83(2) establece una lista tasada de once factores de obligada consideración; entre ellos, la naturaleza y la duración de la infracción, la intencionalidad o la negligencia, las medidas adoptadas para mitigar el daño, el grado de responsabilidad a la luz de los artículos 25 y 32, las infracciones previas, la cooperación con la autoridad de control, las categorías de datos y el beneficio obtenido. El techo es aquí el límite superior de la ponderación, no una tarifa.
El orden de magnitud real lo da el asunto Google v CNIL (C-507/17): la CNIL multó a Google con 100 000 euros por negarse a cumplir el requerimiento de retirar los enlaces en todas las extensiones de dominio. El Tribunal de Justicia de la UE resolvió, el 24 de septiembre de 2019, que Google no está obligada a retirarlos en todo el mundo: bastan las versiones correspondientes a todos los Estados miembros, con medidas que impidan efectivamente o, al menos, dificulten seriamente el acceso desde una búsqueda realizada en la UE. Pero en esa misma sentencia, en el apartado 72, hay una salvedad que a menudo se pierde: el Derecho de la Unión tampoco prohíbe la retirada global; una autoridad de control o un órgano judicial nacional pueden ordenarla con arreglo a los estándares nacionales de protección de los derechos fundamentales.
Punto cuarto: cómo llegan allí los datos
Aquí tengo que ser precisa. Los documentos de los reguladores examinados no ofrecen un catálogo de incidentes con redes y fechas concretas: describen mecanismos, no una crónica. Así que enumeraré los mecanismos.
El primero, y el más subestimado: los identificadores de los participantes. La CNIL considera que las claves públicas son datos que, en esencia, no admiten minimización, y que su plazo de conservación coincide con la vida de la propia cadena. Es decir, incluso una cadena sin un solo byte de datos personales «de contenido» ya está almacenando datos personales, y para siempre.
El segundo: el hash como dato personal. La intuición del ingeniero dice «el hash es irreversible, luego es anónimo». El WP29, en el Opinion 05/2014 —así lo cita el estudio del EPRS—, respondió que la simple aplicación de una función hash no convierte automáticamente los datos personales en anónimos; el hashing produce con más frecuencia datos seudonimizados que anónimos: es una medida de seguridad útil, pero no un método de anonimización. La razón es aritmética: si el conjunto de entradas posibles es conocido y finito —pongamos, todas las direcciones de correo electrónico existentes—, la búsqueda por fuerza bruta, según la observación de Edward Felten que recoge ese mismo estudio, le lleva a una máquina menos tiempo que preparar una taza de café. Los hashes con sal no salvan la situación; los hashes con clave ofrecen garantías más sólidas. El EDPB lo confirma: el hash se considerará dato personal, igual que cualquier otro identificador disponible, con una salvedad: si el algoritmo no está roto y la clave secreta o la sal se han eliminado y no se han filtrado, ya no debería ser posible vincular el hash con los datos de origen.
El tercero: el derecho de rectificación vuelto contra el propio interesado. Según la CNIL, la rectificación se materializa inscribiendo los datos actualizados en un bloque nuevo, pero la primera transacción, la errónea, permanece en la cadena. Formalmente, el derecho se ha satisfecho. En la práctica, los datos incorrectos sobre una persona se conservan eternamente, junto a los correctos.
La única arquitectura que ambos reguladores reconocen como salida es el compromiso criptográfico bajo un esquema perfectly hiding. La CNIL señala en una nota al pie que, una vez eliminados el witness y el propio valor comprometido, el commitment queda anonimizado hasta tal punto que ya no puede considerarse dato personal. El EDPB coincide en el apartado 53: el commitment que permanece en la cadena es inservible, pues los datos de origen no pueden reconstruirse ni identificarse. Es una puerta estrecha, pero existe.
Qué dicen los reguladores
La discusión sobre si se puede inscribir a las personas en un almacenamiento perpetuo no la mantienen solo los ingenieros. En Europa hay tres documentos a los que se suele acudir en este debate: el informe de la autoridad francesa, la CNIL; el estudio elaborado para el Parlamento Europeo por su servicio de estudios; y las directrices del Comité Europeo de Protección de Datos (CEPD). Su estatus es distinto —dos autoridades de control y un trabajo de expertos—, pero conviene leerlos seguidos: se ve cómo, en casi ocho años, la posición se ha endurecido en lugar de suavizarse.
CNIL, 2018: «técnicamente imposible» y qué hacer con eso
Conviene empezar por la autoridad francesa. En septiembre de 2018, la CNIL publicó el informe «Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data»: un análisis detallado, hecho por una autoridad de control, de cómo encaja el RGPD en un registro inmutable.
La frase que más se cita es esta: la CNIL constata que resulta técnicamente imposible atender una solicitud de supresión cuando los datos están inscritos en una cadena de bloques. Normalmente la cita termina ahí, y sale una conclusión muy cómoda: «el regulador ha reconocido que no se puede borrar; luego no hace falta borrar».
Pero la CNIL continúa, y esa parte se cita menos. La autoridad describe una vía indirecta: si en la cadena no se inscribe el texto en claro, sino un compromiso criptográfico, un hash con clave secreta o un criptograma, el responsable del tratamiento puede «aproximarse al efecto de la supresión» destruyendo fuera de la cadena los datos originales y los elementos de verificación. Y matiza acto seguido: salvo en determinados esquemas de compromiso, estas soluciones no son, en rigor, una supresión, porque los datos siguen existiendo en la cadena de bloques. Valoración final: la CNIL reconoce el valor de estas soluciones, pero duda de que puedan garantizar el pleno cumplimiento del RGPD.
Es decir: ya en 2018 el regulador no dijo «se puede», sino «vemos su maniobra de rodeo y no estamos seguros de que valga».
La parte práctica del informe, en cambio, es bastante concreta. La CNIL ordenó los formatos de inscripción de mayor a menor preferencia: primero el compromiso criptográfico, después el hash con clave, después el criptograma. El texto en claro o el hash sin clave, solo en casos excepcionales. Los datos, fuera de la cadena; en la cadena, únicamente la prueba de que esos datos existieron. Por separado, la CNIL admitió que formalizar con los mineros de una red pública un contrato de encargo del tratamiento conforme al artículo 28 resulta difícil en la práctica, y comunicó que estaba llevando a cabo una reflexión en profundidad sobre esta cuestión.
Estudio para el Parlamento Europeo, 2019: no tocar la ley, hacen falta aclaraciones
Un año después apareció el estudio «Blockchain and the General Data Protection Regulation» (PE 634.445, julio de 2019, de Michèle Finck), elaborado por el servicio de estudios del Parlamento Europeo para su panel de prospectiva científica y tecnológica. Es el trabajo de una experta externa, no la posición del Parlamento como institución, pero fue precisamente ese texto el que redujo el conflicto a dos presupuestos incrustados en el RGPD.
El primero: todo fragmento de datos personales tiene al menos un responsable del tratamiento al que se le puede reclamar. La cadena de bloques sustituye a ese único responsable por una multitud de participantes, y la falta de acuerdo sobre cuál de ellos es el responsable del tratamiento impide repartir la responsabilidad.
El segundo: los datos se pueden modificar o suprimir. La cadena de bloques está hecha adrede para que una modificación unilateral sea lo más difícil posible: en eso consiste toda la tecnología.
La conclusión del estudio, sin embargo, es suave: no hace falta cambiar el RGPD. El Reglamento se redactó con neutralidad tecnológica y se apoya en principios, no en la descripción de sistemas concretos. No hacen falta enmiendas a la ley, sino aclaraciones del regulador: unas directrices específicas del CEPD, códigos de conducta, mecanismos de certificación.
Merece la pena retener otra observación del estudio: el artículo 17 del RGPD no define en absoluto qué significa «supresión». No hay definición ni en el texto del artículo ni en los considerandos. Y en el asunto Google Spain se consideró suficiente eliminar los enlaces de los resultados de búsqueda, pese a que la propia página del periódico siguió en su sitio (eso sí, el reclamante tampoco pedía más). Es un argumento a favor de que la destrucción, como acto físico, no forma parte necesariamente del contenido del derecho. La práctica, no obstante, es inconsistente: en el asunto Nowak el TJUE habló de la supresión precisamente como destrucción.
CEPD, 2026: «técnicamente imposible» ha dejado de ser un argumento
Las aclaraciones que pedía el estudio de 2019 llegaron casi seis años después. Las Guidelines 02/2025 sobre el tratamiento de datos personales mediante tecnologías de cadena de bloques: la versión 1.1 se adoptó el 8 de abril de 2025 y la versión final, la 2.0, el 7 de julio de 2026, tras la consulta pública.
El tono cambió radicalmente. La frase clave (apdo. 50):
«The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements»
La imposibilidad técnica no justifica el incumplimiento. La lógica es simple y difícil de rebatir: la protección de datos desde el diseño (art. 25(1)) se aplica en el momento de elegir los medios del tratamiento. Si usted eligió una arquitectura en la que la supresión es imposible, esa imposibilidad la creó usted, y es problema suyo, no una circunstancia atenuante.
La orientación general es aún más dura (apdo. 48): con carácter general, no se recomienda almacenar datos personales en una cadena de bloques, y no deben figurar en el contenido de las transacciones. El apartado 104 pone en el mismo plano el texto en claro, el criptograma y el hash: no se recomienda inscribir datos personales en la cadena bajo ninguna de esas formas; su sitio está fuera de la cadena (off-chain). La recomendación 11 lleva la idea hasta el final: si no existe una solución técnica que garantice la supresión o la anonimización al vencer el plazo de conservación, no deben inscribirse datos personales en la cadena en absoluto.
Entre la CNIL de 2018 y el CEPD de 2026 la diferencia es de fondo. La CNIL describía cómo convivir con la cadena de bloques. El CEPD responde: casi siempre, de ninguna manera; si no necesita la integridad estricta de la cadena, use otra herramienta.
¿Se considera el hash un dato personal?
Aquí es donde más divergen las intuiciones de ingenieros y juristas. El ingeniero ve en el hash una transformación unidireccional e irreversible: del hash no se saca la cadena original. El regulador lo mira de otro modo: no le interesa la reversibilidad de la función, sino la posibilidad de vincular el registro con una persona.
La posición del CEPD (apdo. 52) es tajante: el hash se considerará dato personal, igual que cualquier otro identificador presente. También hay un matiz: una vez eliminada la clave secreta o la sal, el hash no debería poder vincularse con los datos originales, pero solo mientras el algoritmo no esté roto y ni la clave ni la sal se hayan visto comprometidas. Sobre el cifrado se dice algo igual de inequívoco (apdo. 51): los datos personales cifrados siguen siendo datos personales, y el cifrado no exime de las obligaciones del RGPD. Se añade una idea aparte sobre el tiempo: incluso un cifrado moderno impecablemente implementado acabará por ser vencido si la cadena de bloques se conserva indefinidamente.
No es una posición nueva. Ya en 2014, el Grupo de Trabajo del Artículo 29 clasificó en su Opinion 05/2014 el hash como seudonimización y no como anonimización: una medida de seguridad útil, pero no un método de anonimización. Los hashes con sal tampoco dan anonimato. Estas formulaciones se conocen sobre todo por las citas del estudio del EPRS, que se apoya precisamente en el dictamen del Grupo de Trabajo; el propio estudio dice lo mismo: aplicar una función hash no convierte por sí solo los datos personales en datos anónimos.
El porqué se entiende con un ejemplo. Un hash no hace falta «descifrarlo»: se puede adivinar. Si el conjunto de entradas posibles es limitado, basta con calcular el hash de todas ellas y comparar. Direcciones de correo electrónico hay en el mundo del orden de cinco mil millones: para un ordenador, eso no es tarea. El hash de un número de teléfono o de una fecha de nacimiento se saca por fuerza bruta de forma trivial, porque el espacio de valores es pequeño. Aquí la irreversibilidad de la función no protege nada.
La única construcción sobre la que ambos reguladores se pronuncian igual y en positivo es el compromiso criptográfico (commitment). La CNIL, en una nota a pie del informe: en un esquema perfectly hiding, eliminar el witness y el propio valor comprometido hace que el compromiso sea anónimo hasta el punto de que ya no puede considerarse un dato personal. El CEPD (apdo. 53) coincide: una vez eliminados los datos originales y el witness, el compromiso que queda en la cadena de bloques es inútil, pues los datos originales no se pueden ni reconstruir ni averiguar.
Dónde los reguladores no tienen respuesta
Conviene llamar a las cosas por su nombre.
No hay definición de «supresión». El artículo 17 no la da. Así lo reconoce también el estudio elaborado para el Parlamento Europeo. Toda la construcción del «hemos destruido la clave, dad los datos por suprimidos» no se sostiene en una norma, sino en la ausencia de norma.
No existe ni un solo acto que reconozca el borrado criptográfico como cumplimiento del art. 17. Hay un estándar de ingeniería (la NIST SP 800-88r2 sitúa el cryptographic erase entre las técnicas de nivel purge, no destroy). Hay una cautelosa «aproximación al efecto» de la CNIL. Hay una sentencia del TJUE en el asunto SRB en la que, a juzgar por los análisis jurídicos, se apunta un giro contextual. Pero no hay ningún documento vinculante que diga «destrucción de la clave = supresión». Es más: la revisión paneuropea de la aplicación del art. 17 —el informe CEF 2025 del CEPD, con 764 responsables del tratamiento encuestados— no menciona ni una sola vez el borrado criptográfico. En cambio, las autoridades de control critican allí abiertamente que se sustituya la supresión por la anonimización: la práctica extendida de que los responsables apliquen una seudonimización básica o un enmascaramiento parcial y lo presenten como supresión no cumple los requisitos del RGPD.
No hay respuesta sobre los almacenamientos permanentes. Ninguno de estos documentos aborda Arweave, IPFS ni sistemas similares por separado de las cadenas de bloques. Cualquier conclusión sobre ellos es una extrapolación, no la posición de un regulador.
No hay solución al problema de los mineros. La CNIL admitió que formalizar un contrato de encargo del tratamiento con los validadores de una red pública es difícil en la práctica y comunicó que estaba reflexionando sobre ello; en el informe no hay una respuesta cerrada.
El balance resulta incómodo, pero honesto: los reguladores han descrito lo que no se puede hacer con mucho más detalle que lo que sí se puede. La única arquitectura aprobada expresamente por ambos consiste en mantener los datos fuera de la cadena e inscribir en ella solo la prueba de su existencia. Todo lo demás es un terreno en el que, o bien no hay posición, o bien esta se reduce a un «dudamos de que esto valga».
Soluciones que no funcionan
Cuando alguien se topa por primera vez con la contradicción entre la cadena de bloques y el derecho de supresión, enseguida se le ocurre una idea que parece salvadora. Suele ser una de estas seis. Ninguna resiste del todo el examen: unas han sido desmontadas directamente por los reguladores, otras se rompen por su propia construcción. Vamos por orden, porque entender por qué falla un atajo resulta más útil que otra lista de prohibiciones.
«En la cadena solo ponemos el hash»
La solución más popular y el malentendido más extendido. La lógica es esta: el hash es una función unidireccional, de él no se pueden reconstruir los datos de partida, luego lo que hay en la cadena de bloques ya no son datos personales, sino una cadena de caracteres sin sentido.
Los reguladores lo ven de otro modo. El EDPB, en sus Guidelines 02/2025, lo formula sin rodeos: el hash también se considerará dato personal, igual que cualquier otro identificador que pueda existir junto a él. El Grupo de Trabajo del Artículo 29 ya en 2014 (Opinion 05/2014 on Anonymisation Techniques, WP 216) calificó las funciones hash de medida de seguridad útil, pero no de método de anonimización; lo cito a partir del estudio elaborado para el Parlamento Europeo que recoge ese dictamen, la fuente original no la he consultado. El propio estudio (PE 634.445, Michèle Finck, julio de 2019) añade por su cuenta la misma idea: el hash suele producir datos seudonimizados, no anónimos, y aplicar una función hash no convierte automáticamente en anónimos los datos personales.
La razón técnica es sencilla y desagradable. La unidireccionalidad del hash protege frente a la reconstrucción de una entrada arbitraria, pero no frente al recorrido exhaustivo de un conjunto conocido. Si se hashea una dirección de correo electrónico, un número de teléfono o una fecha de nacimiento, el conjunto de entradas posibles es finito y perfectamente abarcable. Edward Felten, citado por ese mismo estudio, observaba que recorrer un conjunto conocido de entradas le lleva a un ordenador menos tiempo que preparar una taza de café. Los hashes con sal, según la posición del GT29 que allí se cita, tampoco dan anonimato: la sal complica el ataque masivo, pero no vuelve anónimos los datos. El hash con clave secreta («con pimienta») ofrece garantías más sólidas, pero también él sigue siendo un seudónimo mientras la clave exista.
La conclusión práctica de la CNIL en 2018: si hay que escribir algo en la cadena, el orden de preferencia es compromiso criptográfico (commitment), después hash con clave y, por último, texto cifrado. La guía del EDPB conserva de esa lista solo la parte superior: en la cadena se admiten un puntero, un commitment o un hash con clave, mientras que el texto cifrado, en el punto 104, queda equiparado al texto en claro, y registrar datos personales de esa forma no se recomienda. El hash desnudo, sin clave, en una cadena de bloques pública el EDPB lo considera, con carácter general, insuficiente.
«Ciframos y luego destruimos la clave»
Es una técnica con nombre propio y con norma: el borrado criptográfico, cryptographic erase. NIST SP 800-88r2 (septiembre de 2025) lo define como la sanitización de las claves que hace inviable la recuperación de los datos descifrados. Desde el punto de vista de la ingeniería, todo es honesto.
Pero atención a la clasificación: NIST sitúa el borrado criptográfico en el nivel purge, no en destroy. No es una destrucción física, y la norma no lo oculta: el texto cifrado permanece en el soporte.
Jurídicamente, el EDPB responde de manera aún más directa: los datos personales cifrados siguen siendo datos personales, y el cifrado no exime de cumplir el RGPD. Y añade algo letal para un almacenamiento eterno: incluso un cifrado moderno implementado de forma impecable acabará venciéndolo el tiempo si la cadena se conserva de manera indefinida.
Conviene detenerse aquí en el listón mismo. La identificabilidad no se mide en términos absolutos: la cuestión es si la entrada puede vincularse a una persona «con medios que razonablemente puedan utilizarse», que es como el EDPB describe esta prueba en la sección dedicada al derecho de supresión. Y esa «probabilidad razonable» es una magnitud atada a un momento concreto: lo que hoy exige los recursos de un Estado, mañana cabe en el presupuesto de un curioso. Los datos que van a permanecer cien años hay que valorarlos con ese horizonte, y no por su resistencia el lunes por la mañana.
A ello se suman las advertencias más terrenales de la propia norma. El borrado criptográfico no es aplicable si los datos sensibles estuvieron alguna vez en el soporte en claro. No conviene fiarse de él si se hicieron copias de seguridad del soporte o si las claves se depositaron en custodia, salvo que la organización sepa con certeza cómo y dónde se guardaron esas claves y quién las gestionó. Las claves desplegadas pueden quedar en la memoria operativa y en los registros del motor de cifrado. Y en la versión anterior de la norma, hoy retirada, se menciona un inconveniente más: el resultado no se puede verificar, porque tras el borrado no hay nada con lo que comparar el contenido del soporte.
Hay también un argumento en sentido contrario, y lo expongo con honestidad. La sentencia del Tribunal de Justicia de la UE en el asunto C-413/23 P (EDPS contra SRB, 4 de septiembre de 2025) consagró el enfoque relativo: unos mismos datos seudonimizados pueden ser personales para quien dispone de la clave y no serlo para el destinatario que no puede reidentificarlos. Es hoy el argumento más fuerte a favor del borrado criptográfico. Pero se refiere a la calificación de los datos en manos del destinatario sin clave, no a que el responsable del tratamiento que ha destruido la clave haya cumplido el art. 17 respecto del texto cifrado que conserva. Y hago una salvedad: el texto de esta sentencia no lo he cotejado con la fuente original.
«Tenemos una red privada, ahí no entran extraños»
Una cadena de bloques privada o de consorcio sí elimina parte del problema: el círculo de participantes es conocido, resulta más fácil acordar procedimientos y no hay acceso público. El EDPB escribe expresamente que las cadenas públicas solo deberían emplearse si el acceso público es necesario al menos para uno de los fines del tratamiento, con remisión al art. 25(2) del RGPD sobre la inaccesibilidad por defecto de los datos a un número indeterminado de personas.
Pero el carácter privado de la red resuelve la cuestión del acceso, no la de la inmutabilidad. Si una entrada no puede retirarse de la cadena, no se retira, con independencia de cuánta gente vea esa cadena: diez mil o diez. El derecho de supresión no se convierte en un derecho a limitar el acceso por el hecho de que la audiencia se haya estrechado.
Segundo: una red privada no elimina la pregunta de quién es el responsable del tratamiento. Según la lógica de la CNIL, se convierten en responsables los participantes con derecho de escritura: una persona jurídica que inscribe datos personales en la cadena es responsable del tratamiento sin discusión. Si varios participantes llevan a cabo el tratamiento con una finalidad común y no han determinado de antemano quién responde, todos corren el riesgo de resultar corresponsables del tratamiento conforme al art. 26 del RGPD. En un consorcio eso no es una circunstancia atenuante, sino la descripción de la situación típica.
«Bifurcamos la cadena y limpiamos la entrada»
La idea es radical: si la entrada no se puede borrar, reescribamos la historia entera a partir del bloque que interesa y pidamos a la red que se pase a la nueva versión.
Técnicamente es posible, y precisamente por eso no funciona como mecanismo jurídico. Una bifurcación exige el consenso de la red. Es decir, el ejercicio del derecho de una persona concreta depende de la buena voluntad de multitud de participantes independientes que no tienen ninguna obligación frente a ella. El RGPD, en cambio, da al interesado derecho a dirigirse al responsable del tratamiento y obtener un resultado «sin dilación indebida»: según el art. 12(3), en el plazo de un mes, prorrogable como máximo por otros dos. Un mecanismo que exige coordinar a toda la red para cada solicitud individual no cabe en esos plazos y, en el fondo, no escala: está pensado para un suceso extraordinario y raro, mientras que las solicitudes de supresión son rutina.
Además, la bifurcación destruye justo la propiedad por la que se eligió la cadena de bloques. Si la historia puede reescribirse a demanda, el valor probatorio de la cadena desaparece. Queda un sistema que ya no ofrece garantías de inmutabilidad, pero que sigue soportando todos los costes del consenso distribuido.
«Los datos están anonimizados» y «simplemente no los borraremos»
Las dos últimas variantes conviene analizarlas juntas, porque en la práctica la segunda se esconde a menudo detrás de la primera.
El informe del EDPB sobre la aplicación del derecho de supresión (se encuestó a 764 responsables del tratamiento) recoge esto como una práctica extendida: los responsables se apoyan en la anonimización como sustituto de la eliminación definitiva. Y constata que en algunos casos solo se aplica una seudonimización básica o un enmascaramiento parcial, un proceso que no satisface los requisitos del RGPD en materia de supresión. Allí mismo se señala que muchos excluyen por defecto del borrado las copias de seguridad, sin motivar por qué.
«Anonimizado» no es una autocertificación. La prueba es sustantiva: si los datos todavía pueden vincularse a una persona «con medios que razonablemente puedan utilizarse», que es exactamente como el EDPB describe el listón en la sección sobre el derecho de supresión, no ha habido anonimización, se llame como se llame en la documentación interna.
La variante «no borrar y esperar que no pase nada» se apoyaba hasta hace poco en una formulación de la CNIL de 2018: es técnicamente imposible atender una solicitud de supresión cuando los datos están escritos en una cadena de bloques. De ahí se extraía la conclusión de que, si es imposible, no hay obligación.
El EDPB ha retirado ese apoyo. En las Guidelines 02/2025 (la versión final 2.0 se adoptó el 7 de julio de 2026) se dice sin rodeos: la imposibilidad técnica no puede servir de justificación para incumplir los requisitos del RGPD. Con remisión al art. 25(1), la protección de datos desde el diseño se aplica ya en la fase en que se determinan los medios del tratamiento. Es decir, la decisión arquitectónica que hizo imposible cumplir la ley es una elección propia, no un caso de fuerza mayor.
El precio no es abstracto. La vulneración de los derechos de los interesados recogidos en los arts. 12 a 22 entra en el nivel superior del art. 83(5): hasta 20 000 000 de euros o, tratándose de una empresa, hasta el 4 % del volumen de negocio total anual global del ejercicio financiero anterior, whichever is higher, es decir, se toma la mayor de las dos cuantías.
El denominador común de los seis enfoques es el mismo: todos cambian la accesibilidad de los datos, pero ninguno responde a qué hacer con los datos en sí. La única arquitectura en la que los reguladores admiten que cese la condición de datos personales es el perfectly hiding commitment: una vez eliminados los datos de partida y el witness, el compromiso que queda en la cadena resulta, en palabras del EDPB, inútil, porque los datos de partida no pueden ni reconstruirse ni reconocerse. Pero eso ya no es esquivar el problema, sino otra forma de diseñar, adoptada antes de escribir el primer bloque y no después.
Borrado criptográfico
Imagine una caja fuerte empotrada en hormigón. No hay forma de sacarla, ni de volarla, ni de llevársela. Lo que sí puede hacerse es fundir la única llave. El contenido seguirá dentro para siempre, pero no habrá nada con que abrirlo.
En eso consiste el borrado criptográfico, también llamado crypto-shredding. La idea es de una sencillez casi indecente: los datos están cifrados desde el primer momento y, cuando llega la hora de «suprimirlos», no se destruyen los datos, sino la clave.
Qué dice la norma
El método tiene una definición canónica: la NIST SP 800-88r2, «Guidelines for Media Sanitization» (septiembre de 2025). Literalmente:
«cryptographic erase (CE): A purge sanitization technique in which key sanitization is applied to one or more keys providing confidentiality protections for the encrypted target data, making recovery of the decrypted target data infeasible.»
Fíjese en la palabra purge. En la clasificación del NIST existe un nivel Destroy: la destrucción física del soporte, cuando del disco solo quedan virutas. El borrado criptográfico no llega ahí. Es el nivel de «purga», y el NIST lo advierte con honestidad: «The encryption itself acts to sanitize the data» —el propio cifrado hace las veces de borrado—, pero siempre que se cumplan las condiciones que el documento enumera. El texto cifrado permanece físicamente en el soporte.
Conviene saber, además, que la edición anterior de la norma —la SP 800-88r1, de 2014, a la que siguen remitiendo nueve de cada diez artículos y blogs sobre crypto-shredding— fue retirada el 26 de septiembre de 2025 y sustituida por completo por la r2. Si alguien le enseña una referencia a la r1 como norma vigente, hace tiempo que no lee el documento.
Las condiciones en las que esto funciona
El NIST no dice «destruya la clave y duerma tranquilo». El §3.2 de la norma enumera unas condiciones previas estrictas, y cada una de ellas es un punto de fallo potencial.
Robustez de la criptografía. Con remisión a la ISO/IEC 27040: el algoritmo y el modo, al menos 128 bits de seguridad; la entropía del generador de números aleatorios, no inferior a la longitud de la clave. El modo ECB está expresamente prohibido.
Los datos nunca estuvieron en claro. Si la información sensible llegó a escribirse una sola vez sin cifrar en el soporte, el borrado criptográfico no la eliminará: lo que barre son las claves, no los datos.
Se han destruido todas las copias de la clave. No una: todas, incluidas las claves situadas por debajo en la jerarquía. La técnica recomendada es la puesta a cero conforme a la ISO/IEC 19790.
No queda rastro de la clave en memoria. Un matiz sutil que suele pasarse por alto: si la clave envuelta se desenvolvió alguna vez y se cargó en la memoria RAM o en el registro del motor de cifrado, esos rastros también hay que eliminarlos. El NIST admite que para ello puede hacer falta un reinicio en frío o dejar el dispositivo sin alimentación durante un tiempo.
Los puntos débiles, sin adornos
El método es elegante, pero tiene vulnerabilidades de las que la norma habla abiertamente y los materiales de marketing suelen callar.
El cifrado puede no aguantar. No es paranoia, sino una advertencia expresa del NIST: si en el futuro se descubren debilidades criptográficas del algoritmo o la capacidad de cálculo (por ejemplo, la computación cuántica) hace viable la recuperación de las claves, los datos volverán a ser accesibles; y en esos casos «CE may not be an acceptable sanitization technique» (el borrado criptográfico puede no ser una técnica de saneamiento aceptable).
De ahí se sigue algo incómodo: el ataque «harvest now, decrypt later» (recolectar ahora, descifrar después). Una copia del texto cifrado tomada antes de destruir la clave vive para siempre y espera su momento. Contra la destrucción física del soporte, ese ataque carece de sentido. Contra el borrado criptográfico es una estrategia perfectamente viable.
El EDPB formula la misma idea aplicada a la cadena de bloques: incluso el cifrado más moderno, implementado a la perfección, acabará vencido por el tiempo si la cadena se conserva de forma indefinida. Para un disco corporativo corriente, que dentro de unos años irá a la chatarra, el margen de robustez sobra. Para un registro pensado para siglos, ese mismo margen no significa nada.
Las copias de seguridad de la clave. El problema más prosaico y más frecuente. El NIST: no cabe confiar en el borrado criptográfico en soportes cuyas claves se hayan respaldado o depositado en custodia, salvo que la organización tenga un grado alto de certeza sobre cómo y dónde se han almacenado y gestionado esas claves fuera del soporte.
Traduzcámoslo a lenguaje llano. La clave vive en un KMS. El KMS se replica en tres regiones. Hay una copia nocturna del KMS. Hay una copia en custodia en manos de un segundo administrador, por si el primero se marcha. Hay una instantánea de la máquina virtual tomada justo cuando la clave estaba desenvuelta en memoria. Usted pulsa «destruir la clave» y la clave sigue en otros cinco sitios. El efecto del borrado es nulo y, mientras tanto, el informe de cumplimiento de la solicitud del usuario ya se ha enviado.
El resultado no se puede verificar. Este es, quizá, el problema más infravalorado. La retirada edición r1 lo describía sin rodeos: tras el borrado criptográfico, en el soporte queda un texto cifrado cuyo contenido se desconoce y con el que no hay nada que comparar; y si la organización no puede comprobar que el CE ha funcionado, debe emplear otro método que sí sea verificable.
La r2 vigente exige documentar el procedimiento con arreglo a diez apartados obligatorios, pero acto seguido añade algo que baja los humos: «CE's effectiveness as a purge sanitization technique does not depend on documentation» (la eficacia del CE como técnica de purga no depende de la documentación). La eficacia no depende de los papeles. Los papeles son cuestión de trazabilidad, no de hechos.
Y un apunte aparte sobre los gestores de claves externos: el soporte sencillamente no ve qué ocurre con la clave dentro del KMS. Ha enviado una orden. Lo que pasara después es una cuestión de confianza en un sistema ajeno.
La irreversibilidad como riesgo. La destrucción de una clave no admite marcha atrás. Un error del operador, un fallo del script, una acción malintencionada, y los datos se pierden de forma definitiva, sin ninguna posibilidad de recuperación. Y si la arquitectura contempla una clave distinta para cada usuario, con un millón de usuarios uno gestiona un millón de claves, cada una de las cuales hay que guardar en algún sitio de forma segura y destruir a su debido tiempo.
Por qué esto se considera supresión, y si de verdad se considera
Aquí hay que separar dos cosas: el reconocimiento técnico y el jurídico.
Por el lado técnico, todo en orden. El borrado criptográfico está descrito en la NIST SP 800-88r2, se apoya en las ISO/IEC 27040, ISO/IEC 19790 e ISO/IEC 24759, y las técnicas afines se han trasladado a la IEEE 2883-2022. Es un método de saneamiento reconocido, con condiciones de aplicación claras.
Por el jurídico, la cosa está mucho más turbia, y conviene decirlo sin rodeos. Para empezar, el propio término «erasure» no está definido en el artículo 17 del RGPD, ni en el texto del artículo ni en los considerandos del Reglamento. De ahí la disparidad de la práctica: el Grupo de Trabajo del Artículo 29, en su dictamen sobre computación en la nube, admitía la destrucción del equipo; la autoridad de control austriaca, en una resolución de 5 de diciembre de 2018, reconoció la anonimización como forma de dar cumplimiento al derecho de supresión; el regulador británico aplica desde hace tiempo el concepto de «putting beyond use» (poner fuera de uso): los datos no se eliminan físicamente, pero quedan retirados de circulación. Nunca ha llegado a formarse una interpretación común a todos los Estados miembros.
Ninguno de estos enfoques, sin embargo, tiene que ver con la criptografía. En el derecho europeo no existe un reconocimiento específico del borrado criptográfico, y el EDPB recuerda algo que más bien apunta en la dirección contraria: los datos personales cifrados siguen siendo datos personales, y el cifrado no exime de las obligaciones del RGPD.
Un detalle revelador: en la mayor revisión europea de aplicación del derecho de supresión, que abarcó a 764 responsables del tratamiento, se analizan las copias de seguridad y la anonimización, pero el borrado criptográfico no figura como categoría propia. El método sobre el que tanto escriben los ingenieros, para las autoridades de control sencillamente todavía no existe.
La brecha entre «técnicamente fiable» y «jurídicamente válido» es aquí real, y por ahora no hay con qué cerrarla.
Cómo lo hemos hecho nosotros
A partir de aquí, ingeniería. Voy a describir cómo funcionan en CODE el almacenamiento de la memoria y el borrado, por qué se eligió justo eso, cuál era la alternativa y qué contrapartidas siguen ahí, dichas con honestidad. Sin prometer que hemos resuelto un problema que los reguladores todavía consideran sin resolver.
Regla básica: al almacenamiento eterno no llega texto en claro
La conversación del usuario con el asistente vive en tres capas. La operativa: el contexto de la sesión en curso. La semántica: los embeddings en una base de datos con búsqueda vectorial. La eterna: Arweave.
La bifurcación decisiva está en la frontera de la tercera capa. Todo lo que va al almacenamiento permanente se cifra antes de enviarse: AES-256-GCM, cifrado en el lado del cliente; a la red solo sale el texto cifrado. La clave se guarda en dos sitios: en poder del usuario y en un almacén gestionado de claves (KMS). En la propia cadena no hay ni un nombre, ni un texto, ni nada que pueda leerse sin la clave.
¿Por qué así y no «simplemente, no meter datos personales en una blockchain»? Porque entonces no queda producto. El sentido de la memoria eterna es que el archivo sobreviva al servicio, a la empresa y a mí. Guardarlo solo en nuestros servidores significa hacer que la eternidad dependa de si seguimos pagando el hosting en 2040.
Borrar = destruir la clave
Una solicitud de supresión, en nuestro caso, no intenta borrar los datos de Arweave. Es físicamente imposible, y fingir que se puede es engañar.
Lo que se destruye es la clave: la copia del usuario y la copia del KMS, incluidas las claves derivadas y todas las copias de seguridad a las que alcanzamos. Después, en la cadena queda un texto cifrado que nadie, nosotros incluidos, puede leer. En nuestro registro interno queda constancia del hecho: algo existió, se escribió en tal fecha, se suprimió en tal otra. Sin contenido.
La técnica se llama borrado criptográfico. Tiene norma propia: NIST SP 800-88 (la edición vigente es la r2, de septiembre de 2025; la anterior, la r1, fue oficialmente retirada el 26 de septiembre de 2025, y nueve de cada diez artículos y blogs sobre borrado criptográfico la siguen citando). La definición que recoge: sanear las claves que protegen los datos cifrados de destino, de modo que la recuperación de los datos descifrados resulte inviable.
Un detalle importante que suele pasarse por alto: NIST clasifica esta técnica en el nivel Purge, no en el nivel Destroy. No es una destrucción física. Y la norma tampoco le da un visto bueno general: fija las condiciones previas bajo las cuales es admisible aplicarla y enumera aparte los casos en los que no cabe confiar en ella.
Cuál era la alternativa
Tres opciones que estudiamos y descartamos.
No escribir nada en el almacenamiento eterno. En rigor, esa es la posición del EDPB: por regla general no se recomienda guardar datos personales en una blockchain, y menos aún en el contenido de las transacciones. Es una posición fundada. Pero equivale a renunciar a la idea del proyecto. Nosotros no elegimos renunciar, sino describir los riesgos con honestidad.
Guardar un hash en lugar del texto cifrado. Parece más limpio, pero no resuelve el problema. El EDPB lo formula sin rodeos: el hash también se considerará dato personal, igual que cualquier otro identificador que esté junto a él. Sí hace una salvedad: una vez destruidas la clave secreta o la sal, ya no debería ser posible vincular el hash con los datos de origen, siempre que el algoritmo no esté roto y que la clave y la sal no se hayan comprometido, no se hayan filtrado y se hayan elegido correctamente. Son condiciones exigentes. Ya en 2014, el Grupo de Trabajo de Protección de Datos calificaba el hash de medida de seguridad útil, pero no de método de anonimización: así recoge su posición un estudio del Parlamento Europeo. El motivo es aritmético: recorrer por fuerza bruta un conjunto conocido de entradas (todas las direcciones de correo electrónico del mundo, del orden de 5.000 millones) le lleva a una máquina menos tiempo que preparar una taza de café. La formulación es de Edward Felten.
El compromiso criptográfico (commitment). Este sí es el único esquema que los reguladores señalan expresamente como vía de salida de la condición de dato personal. La CNIL, en una nota a pie de página de su informe, y el EDPB, en su punto 53, dicen lo mismo: en un esquema perfectly hiding, destruir el witness y el valor original deja en la cadena un rastro inútil, a partir del cual los datos originales no pueden ni recuperarse ni averiguarse. Técnicamente es la mejor opción, y en el orden de preferencia de la CNIL está por encima tanto del hash con clave como del texto cifrado.
No lo usamos, de momento. La razón es prosaica: un commitment sirve para demostrar la existencia, no para restaurar un archivo. Al usuario no le hace falta el hecho de que «tu correspondencia existió», sino la correspondencia misma. El texto cifrado se puede devolver; el compromiso, no. Es un intercambio consciente de privacidad por utilidad, y prefiero decirlo en voz alta antes que esconderlo detrás de la palabra «innovación».
Dónde quedan las contrapartidas
Son cuatro, y ninguna la doy por cerrada.
El texto cifrado permanece para siempre. Los datos no desaparecen; lo único que cambia es su accesibilidad. De ahí el escenario «recoge ahora, descifra después»: una copia tomada antes de destruir la clave vive eternamente. El propio NIST lo advierte: si se descubren debilidades del algoritmo o llega la computación cuántica, los datos pueden volver a ser recuperables, y entonces el borrado criptográfico puede resultar una técnica de saneamiento inaceptable. El EDPB lo formula con más dureza: incluso un cifrado moderno implementado a la perfección será vencido por el tiempo si la cadena se conserva de forma indefinida.
Las copias de las claves son un punto ciego. La norma exige destruir todas las copias de la clave de destino y de todas las claves situadas por debajo en la jerarquía, incluidas las copias desplegadas en memoria y en registros. Y avisa aparte: allí donde las claves se hayan respaldado o depositado en escrow, no conviene confiar en el borrado criptográfico, salvo que la organización sepa con alta certeza cómo y dónde se guardaron esas claves y cómo se gestionaron. Para nuestro propio perímetro podemos garantizarlo. Por el usuario que se guardó la clave, no.
El resultado no se puede verificar. Tras el borrado criptográfico se desconoce el contenido del soporte y no hay nada con lo que compararlo: la verificación habitual del borrado no le es aplicable. Así lo describía la edición retirada de la norma, que prescribía pasar en ese caso a un método verificable. Nosotros no tenemos un método verificable para el almacenamiento eterno.
El estatuto jurídico no está confirmado. Es lo más honesto que puedo decir. Los datos personales cifrados siguen siendo datos personales: formulación literal del EDPB. El análisis de la aplicación del derecho de supresión publicado en febrero de 2026 (764 responsables del tratamiento encuestados) no menciona ni una sola vez el borrado criptográfico: ni como práctica aprobada ni como práctica prohibida. En cambio, las autoridades de control critican ahí mismo que se sustituya la supresión por la anonimización. Y el EDPB insiste por separado: la imposibilidad técnica no puede servir de excusa para incumplir los requisitos.
Es decir: nuestra arquitectura no está amparada por la interpretación de nadie. Solo la ampara el hecho de que hace todo lo técnicamente posible y no miente sobre lo que no hace.
Qué se deduce de esto en la práctica
Diseñamos para no acabar en la situación de «los datos están ahí y no se puede hacer nada con ellos». Al usuario se le dice exactamente lo que ocurre: la supresión destruye la clave, el texto cifrado permanece, no se puede leer, y garantías a un horizonte de décadas no las puede dar nadie: ni nosotros, ni el NIST, ni el EDPB.
La solución de ingeniería aquí es una sola, y es aburrida: prever la posibilidad de anonimizar desde la fase de diseño, en lugar de buscarla después de la primera solicitud de supresión. Es justo lo que exige el EDPB. Todo lo demás tiene que ver con dónde pasa la línea entre «hemos hecho todo lo que se podía» y «hemos prometido más de lo que sabemos hacer». Lo primero es ingeniería. Lo segundo es marketing, y en este texto no lo va a haber.
Un mismo derecho, países distintos
El derecho a la supresión de datos no existe en un único ejemplar. En cada jurisdicción es un derecho distinto: con fundamentos distintos, excepciones distintas y un precio del error distinto. Un servicio con usuarios en Berlín, Los Ángeles, Shenzhen y São Paulo no se enfrenta a un requisito, sino a cuatro, y no coinciden entre sí.
Una advertencia de entrada: lo que tengo verificado con mayor profundidad es el derecho de la UE: el texto de los artículos, dos sentencias del Tribunal, la escala de multas. De California, China y Brasil he cotejado las normas de supresión en sí: número, denominación, construcción. Los plazos de respuesta, el alcance territorial y la cuantía de las sanciones no los he verificado allí en las fuentes originales. Abajo me apoyo en lo comprobado y, donde no lo está, lo digo abiertamente en vez de tapar el hueco con una fórmula bonita.
Lo que se sabe con certeza: la Unión Europea
En el RGPD es el Article 17 — «Right to erasure ('right to be forgotten')». Fíjense en las comillas dentro del propio título: «derecho al olvido» es un sinónimo no oficial. El término jurídico es derecho de supresión.
Los motivos son exactamente seis y la lista es cerrada: los datos ya no son necesarios para el fin con el que se recogieron; se ha retirado el consentimiento y no existe otra base; se ha formulado oposición conforme al art. 21(1) y el responsable del tratamiento no tiene motivos legítimos que prevalezcan (la oposición al marketing directo del art. 21(2) opera de forma incondicional); el tratamiento fue ilícito; la supresión la exige la ley; los datos se obtuvieron de un niño en relación con la prestación de un servicio en línea.
El plazo para responder no lo fija el propio art. 17, sino el art. 12(3): «without undue delay and in any event within one month of receipt of the request», con una prórroga posible de dos meses más si la solicitud es compleja. Es decir, un mes; tres como máximo.
Las excepciones también son cinco, y su fórmula es quirúrgica: «shall not apply to the extent that processing is necessary». No «la solicitud se deniega», sino «en la medida en que». La libertad de expresión e información. El cumplimiento de una obligación legal y el ejercicio de poderes públicos. La salud pública. El archivo en interés público, la investigación científica e histórica y la estadística, pero solo si la supresión hace imposible u obstaculiza gravemente el logro de esos fines. Y la formulación o defensa de reclamaciones.
La multa por vulnerar los derechos del interesado va por el nivel superior del art. 83(5): hasta 20 000 000 de euros o, si el infractor es una empresa, hasta el 4 % del volumen de negocio anual global del ejercicio financiero anterior, whichever is higher, es decir, se toma la cifra mayor. No sobre el beneficio: sobre el volumen de negocio.
Los límites del derecho: lo que mostró Luxemburgo
Dos sentencias del Tribunal de Justicia de la UE perfilaron el contorno de este derecho con más precisión que el texto del reglamento. La primera se dictó todavía bajo la Directiva 95/46 —la predecesora del RGPD—, pero fue justamente ella la que fijó el marco en el que después se redactó el art. 17.
Google Spain (C-131/12, 13 de mayo de 2014). El español Mario Costeja González descubrió que la búsqueda de su nombre devolvía enlaces a dos páginas del diario La Vanguardia de enero y marzo de 1998: el anuncio de la subasta de un inmueble suyo por deudas con la Seguridad Social. El embargo se había saldado por completo muchos años antes. La autoridad española desestimó la reclamación contra el diario (la publicación era lícita, se hizo por orden del ministerio) y estimó la dirigida contra Google.
El Tribunal resolvió algo que a mucha gente sigue sorprendiendo: el enlace debe eliminarse «even, as the case may be, when its publication in itself on those pages is lawful». El diario permanece, el enlace desaparece. La responsabilidad del buscador es autónoma respecto de la del editor. Y al solicitante no se le exige demostrar un perjuicio. En el apartado 93 el Tribunal formuló la doctrina de la obsolescencia: incluso un tratamiento inicialmente lícito de datos exactos puede llegar a ser, «in the course of time», «incompatible with the directive» —incompatible con la Directiva entonces vigente— cuando los datos pasan a ser «inadequate, irrelevant or no longer relevant, or excessive».
De esa misma sentencia sale un límite enunciado sin rodeos: los derechos del interesado prevalecen «as a rule», pero el equilibrio depende de la naturaleza de la información, de su sensibilidad y de «the role played by the data subject in public life». Una figura pública está menos protegida.
Google v CNIL (C-507/17, 24 de septiembre de 2019). La autoridad francesa exigió retirar los enlaces en todos los dominios del buscador en el mundo entero y multó a Google con 100 000 euros. El Tribunal resolvió: no existe obligación de retirarlos globalmente, pero hay que hacerlo en las versiones correspondientes a todos los Estados miembros de la UE y, además, aplicar medidas que «effectively prevent or, at the very least, seriously discourage» el acceso desde la UE.
Y aquí un detalle que las paráfrasis pierden con regularidad. Apartado 72: el Derecho de la UE no exige la retirada global, pero «it also does not prohibit such a practice»: una autoridad de control o un órgano judicial nacional puede ordenarla con arreglo a los estándares nacionales. La frase «el Tribunal de Justicia de la UE prohibió la retirada global» es falsa.
Comparación entre jurisdicciones
Aquí estoy obligada a ser precisa sobre qué es exactamente lo verificado. De California, China y Brasil tengo cotejadas las normas en sí: número de artículo, denominación, construcción del derecho, lista de excepciones. Los plazos de respuesta, el alcance territorial y las sanciones, no, y en la tabla esas celdas quedan vacías.
| Parámetro | UE (RGPD) | California / China / Brasil |
|---|---|---|
| Denominación de la norma | Right to erasure, art. 17 | § 1798.105 Civil Code, «Consumers' Right to Delete Personal Information»; art. 47 de la PIPL; arts. 18 y 16 de la LGPD, término: eliminação |
| Construcción del derecho | derecho del interesado más obligación de suprimir del responsable del tratamiento | California: supresión de lo recogido del propio consumidor; China: el tratante de información personal está obligado a suprimir por iniciativa propia, y el derecho a exigirlo nace si no lo hace; Brasil: la supresión a instancia del titular solo alcanza a los datos tratados sobre la base del consentimiento |
| Motivos | lista cerrada de 6 | China: las cinco circunstancias del art. 47; California y Brasil no construyen una lista al estilo del RGPD |
| Plazo de respuesta | 1 mes + 2 meses de prórroga (art. 12(3)) | no lo he verificado |
| Excepciones | 5, operan «to the extent that» | California: ocho en el texto vigente del § 1798.105(d); en los análisis suele decirse nueve, que es el recuento de la redacción de 2018 |
| Obligación de informar a terceros | sí, art. 17(2), «reasonable steps» atendiendo a la tecnología y al coste | California: sí, § 1798.105(c), salvo imposibilidad o esfuerzo desproporcionado; China y Brasil: no lo he verificado |
| Alcance territorial de la retirada en los buscadores | todos los Estados miembros; globalmente no es obligatorio, pero tampoco está prohibido | no lo he verificado |
| Multa máxima | 20 millones de euros o, para una empresa, el 4 % del volumen de negocio global, whichever is higher | no lo he verificado |
Dos líneas de estas leyes merecen destacarse aparte, porque hablan directamente de nuestro asunto. El párrafo segundo del art. 47 de la PIPL: si el plazo legal de conservación no ha vencido o la supresión es técnicamente difícil de llevar a cabo, el tratante cesa todo tratamiento salvo el almacenamiento y las medidas de seguridad. Y en la LGPD brasileña la limitación técnica está incorporada a la obligación misma: el art. 16 exige eliminar los datos al término del tratamiento «no âmbito e nos limites técnicos das atividades», en el ámbito y dentro de los límites técnicos de la actividad. Ni una salvedad ni la otra tienen equivalente directo en el art. 17 del RGPD. El texto europeo sencillamente no contempla la respuesta «no podemos».
Más allá de esto no voy a completar la tabla de memoria. Un error en el número de un artículo o en un plazo de respuesta no es un desliz de estilo: es algo en lo que alguien puede apoyarse para tomar una decisión real.
Qué hacer cuando un servicio opera en todas partes a la vez
Por suerte, la conclusión práctica depende de lo completa que esté la tabla mucho menos de lo que parece.
Diseñar según el régimen más estricto. Si la arquitectura aguanta el art. 17 del RGPD —con su plazo de un mes, su obligación de informar a otros responsables sobre copias y enlaces y su multa, que para una empresa se calcula sobre el volumen de negocio global—, es muy probable que aguante también requisitos menos duros. Al revés no funciona: adaptar al RGPD un servicio construido para un régimen laxo suele significar reescribir el almacenamiento.
No apoyarse en el «es técnicamente imposible». El EDPB, en sus Guidelines 02/2025 (versión final 2.0, de 7 de julio de 2026), lo formula sin ambages: «technical impossibility cannot be invoked to justify non-compliance with GDPR requirements». Con remisión al art. 25(1): la protección de datos desde el diseño (by design) se aplica en el momento en que uno elige los medios del tratamiento, no después.
Considerar datos personales lo cifrado. Otra cita literal del EDPB: «encrypted personal data is still personal data and encryption does not remove the need for GDPR compliance». Y ahí mismo, una advertencia digna de colgar sobre la pizarra de arquitectura: incluso un cifrado moderno implementado de forma impecable «will be overtaken by time if the blockchain is retained indefinitely». El hash el EDPB también lo cuenta como dato personal —«the hash will also be considered personal data»— con una salvedad: el vínculo con los datos de origen se rompe solo si la clave secreta o la sal se han borrado, el algoritmo no está roto y ni la clave ni la sal se han filtrado. En un estudio del Parlamento Europeo de 2019, que cita el Opinion 05/2014 del Grupo de Trabajo del Artículo 29, el hashing se califica de «a useful security measure but not a method of anonymisation»: los datos quedan seudonimizados, no anónimos.
Distinguir entre «inaccesible» y «suprimido». La CNIL lo describió ya en 2018. Destruyendo la clave y los datos fuera de la cadena se puede «move closer to the effects of data erasure», acercarse al efecto de la supresión. Pero acto seguido: «Excluding the specific case of some commitment schemes, these solutions do not, strictly speaking, result in an erasure of the data, insofar as the data would still exist in the blockchain». La excepción importa y suele perderse: en un perfectly hiding commitment, cuando se han destruido tanto el witness como el propio valor comprometido, la CNIL admite que el registro ha dejado de ser dato personal. En todos los demás casos, acercarse no es cumplir, y la propia CNIL «questions their ability to ensure a full compliance with the GDPR».
Un régimen único en lugar de una matriz de regímenes. La tentación se entiende: a los europeos, borrado de verdad; al resto, algo más suave. En la práctica eso significa mantener varias vías de supresión, cada una con sus propios fallos, y estar decidiendo sin parar de quién es el usuario que tienes delante: ¿por el país de registro?, ¿por la IP?, ¿por la nacionalidad? Sale más barato y más fiable una única vía estricta para todos. De paso desaparece la cuestión del asunto C-507/17: si borras en todas partes, la discusión sobre el alcance territorial no existe para ti.
Hay también un reverso que conviene decir con honestidad. Un régimen único y estricto implica renunciar a datos que en parte de las jurisdicciones se pueden conservar de forma lícita y provechosa. Habrá quien lo considere un coste superfluo. El argumento a favor: ese coste es previsible y se paga una sola vez, en la fase de diseño, mientras que la multa es un porcentaje del volumen de negocio y llega de golpe.
Qué hacer si usted está construyendo algo así
La decisión importante se toma una sola vez: sobre el papel, antes de la primera línea de código. El artículo 25(1) del RGPD exige la protección de datos «by design» ya en el momento de determinar los medios del tratamiento, y el EDPB, en sus Directrices 02/2025 (versión 2.0, 7 de julio de 2026), cierra la única escapatoria de forma directa: «technical impossibility cannot be invoked to justify non-compliance with GDPR requirements» (apdo. 50). Decirle al regulador «no podemos suprimirlos, tenemos una blockchain» no es un argumento: es admitir que la arquitectura está mal diseñada.
Qué no se escribe nunca en un almacenamiento inmutable
La posición del EDPB (apdo. 48): «in general, it is not advisable to store personal data on the blockchain, and it should not be stored in the content of transactions». El apartado 104 lo precisa y sitúa al mismo nivel tres formatos: el texto en claro, los datos cifrados y los datos hasheados; en los tres casos se desaconseja escribirlos en la cadena y conviene mantenerlos off-chain.
Es aquí donde la intuición de ingeniería falla con más frecuencia. El cifrado no saca los datos del ámbito de la norma: «encrypted personal data is still personal data» (apdo. 51). El EDPB considera que el hash también es un dato personal (apdo. 52), con la matización de que, una vez eliminadas la clave secreta o la sal, el vínculo con los datos de origen se pierde, mientras el algoritmo no se rompa y ni la clave ni la sal se filtren. La idea no es nueva: ya en 2014 el Grupo de Trabajo del Artículo 29, en su Opinion 05/2014 —según la cita recogida en el estudio del EPRS—, calificó las funciones hash de «a useful security measure but not a method of anonymisation»; los hashes con sal no proporcionan anonimato, y el hash con clave secreta ofrece garantías más sólidas, pero tampoco convierte los datos en anónimos.
El EDPB (apdo. 49) admite una cadena pública solo si el acceso público resulta necesario para al menos uno de los fines del tratamiento, y remite al artículo 25(2), según el cual los datos no deben quedar accesibles por defecto a un número indeterminado de personas.
Qué sí se puede escribir
La arquitectura objetivo del apartado 54: en la cadena, únicamente una forma que sirva de prueba de existencia (un puntero, un compromiso criptográfico, un hash con clave); los datos que permiten verificar esa prueba, fuera de la cadena y con un alto nivel de confidencialidad. La CNIL ya estableció en 2018 un orden de preferencia: commitment → hash con clave → texto cifrado.
El único punto en el que ambos reguladores afirman que los datos dejan de ser personales es el perfectly hiding commitment. Una vez eliminados el witness y el propio valor comprometido, el compromiso que permanece en la cadena es, en la formulación del EDPB (apdo. 53), «neither possible to recover nor to recognise the original personal data». Todo lo demás es una aproximación al efecto de la supresión, no una supresión.
Las claves
El borrado criptográfico es una técnica de ingeniería reconocida (NIST SP 800-88r2), pero está clasificada como purge, no como destroy. El estándar fija condiciones que resulta fácil incumplir:
- no escribir ni una sola vez los datos sensibles en claro; de lo contrario, no hay nada que borrar;
- una fortaleza no inferior a 128 bits y prohibición del modo ECB;
- puesta a cero de todas las copias de la clave y de todas las claves situadas por debajo en la jerarquía; las claves expandidas que residen en memoria y en registros pueden exigir un reinicio por hardware;
- si las claves han pasado alguna vez por una copia de seguridad o por un depósito (escrow), solo cabe confiar en el borrado criptográfico si se tiene una certeza alta sobre dónde y cómo se han almacenado y gestionado esas copias;
- un KMS externo es un punto ciego: el soporte no ve si la clave se ha puesto realmente a cero.
Y un inconveniente aparte, descrito ya con detalle en la primera edición del estándar, hoy retirada (r1, §4.7.2): el resultado del borrado criptográfico no hay con qué verificarlo; después de aplicarlo, el contenido del soporte es desconocido y no hay nada con lo que compararlo.
De ahí la práctica: una clave por interesado, un registro de claves con identificadores, un procedimiento aparte de puesta a cero con confirmación y ni una sola copia de la clave en un almacenamiento que usted no controle. La recomendación 11 del EDPB cierra el razonamiento: si no existe un mecanismo que garantice la supresión o la anonimización una vez vencido el plazo de conservación, «then no personal data should be stored on the chain».
La política de privacidad
Tres cosas deben figurar en ella de forma explícita.
La primera, el responsable del tratamiento. La CNIL aconseja determinarlo de antemano: constituir una persona jurídica o designar a uno de los participantes. De lo contrario, todos los participantes corren el riesgo de acabar siendo corresponsables del tratamiento con arreglo al artículo 26.
La segunda, una descripción honesta de qué acaba en el almacenamiento inmutable y por qué es irreversible. No «suprimiremos sus datos cuando lo solicite», sino qué se suprime exactamente, qué permanece y en qué forma.
La tercera, la base jurídica. Recomendación 9 del EDPB: el consentimiento no debe emplearse como base si la arquitectura no ofrece ninguna forma de suprimir los datos.
La respuesta a una solicitud de supresión
El plazo no lo fija el artículo 17, sino el artículo 12(3): un mes desde la recepción, prorrogable en dos meses más en función de la complejidad o del número de solicitudes.
El orden de actuación: comprobar la causa invocada (la lista del artículo 17(1) es cerrada, exactamente seis); suprimir de verdad la parte off-chain, copias de seguridad incluidas —en el informe del EDPB de 2025 sobre la aplicación de la normativa, las autoridades de control señalaron expresamente que muchos responsables excluyen por defecto las copias de seguridad de la supresión, sin justificación alguna—; poner a cero la clave o el witness; comprobar las excepciones del artículo 17(3): la fórmula «to the extent that» significa que la excepción opera solo en la medida en que el tratamiento sea necesario y no bloquea la solicitud en su conjunto. Si los datos se han hecho públicos, el artículo 17(2) obliga a adoptar medidas razonables para informar a otros responsables de que deben suprimir enlaces, copias y réplicas.
Y decirle al solicitante la verdad sobre lo que queda. Ese mismo informe del EDPB critica abiertamente que la supresión se sustituya por una anonimización: «in some cases, they only apply basic pseudonymisation or partial masking».
Los registros
El estándar exige documentar cada borrado criptográfico: el §3.2.5 enumera diez puntos y, ahí mismo, se reconoce con franqueza que la eficacia de la técnica en sí no depende de la documentación. De ella depende su defensa. Por encima de la lista del NIST, mantenga un mínimo operativo para cada solicitud de supresión: la fecha de recepción y la de respuesta, la base invocada, qué se ha suprimido y dónde, el identificador de la clave y la constancia de su puesta a cero, quién lo autorizó y los resultados de la evaluación de impacto (DPIA). El artículo 83(2) incluye expresamente entre los factores a valorar las medidas para mitigar el daño y la cooperación con la autoridad de control; y la vulneración de los derechos de los artículos 12 a 22 se sitúa en el tramo superior de las sanciones: hasta 20 millones de euros o, en el caso de una empresa, hasta el 4 % del volumen de negocio total anual global del ejercicio financiero anterior, optándose por la de mayor cuantía.
El derecho a ser olvidado y el derecho a ser conservado
Hemos analizado ambos derechos por separado, como si fueran los dos bandos de una disputa en la que uno tiene que imponerse. Pero comparten una misma raíz, y conviene decirlo sin rodeos.
Los dos derechos hablan de lo mismo: del control de una persona sobre su propio rastro. El derecho a exigir la supresión y el derecho a exigir la conservación no son contrarios. Son la misma capacidad de disponer de la propia historia, orientada en direcciones distintas. Lo contrario de ambos no es el uno del otro, sino la situación en la que decide un tercero: la plataforma, el heredero, el algoritmo que ordena los resultados, el plazo de conservación fijado en la política de privacidad de otro.
Una misma persona en años distintos
La historia de Mario Costeja González es la de un hombre cuyo inmueble se subastó para saldar deudas con la Seguridad Social. Los anuncios se publicaron en La Vanguardia el 19 de enero y el 9 de marzo de 1998. El procedimiento de embargo, según señaló después en su reclamación, se había resuelto hacía muchos años. Pero la búsqueda de su nombre en Google seguía mostrando aquellas páginas, y el Tribunal de Justicia de la UE, en su sentencia de 13 de mayo de 2014, hizo notar que habían transcurrido dieciséis años desde la publicación.
Dieciséis años es la cifra clave, no un adorno. El Tribunal formuló la idea que sostiene toda la construcción: incluso un tratamiento inicialmente lícito de datos exactos puede volverse con el tiempo incompatible con la Directiva —entonces regía la Directiva 95/46, el RGPD todavía no se había escrito— si los datos ya no son necesarios: pasan a ser inadecuados, no pertinentes o excesivos «habida cuenta del tiempo transcurrido».
No es que «los datos resultaran falsos». Ni que «la publicación fuera ilícita»: la reclamación contra el periódico ya había sido desestimada por el regulador español en julio de 2010, porque los anuncios se imprimieron por orden del ministerio, para dar a la subasta la máxima difusión. El Tribunal entró por otro lado: el enlace se retira de los resultados con independencia de la fuente, «incluso, en su caso, cuando esa publicación en dichas páginas sea en sí misma lícita».
Lo que cambió fue la persona. O, con más precisión, la distancia entre la persona y su pasado.
Quien pide que se retire un enlace de los resultados casi siempre trae consigo la otra mitad de la petición: que algo permanezca. Fotografías. Cartas. Lo que le dijo a sus hijos. Pedir que se borre una página no es pedir borrarse entero. Es pedir que esa página deje de ser lo primero que los demás saben de uno.
Ahí está lo esencial. El deseo de desaparecer y el deseo de permanecer no corresponden a dos tipos de personas. Son la misma persona, que mantiene relaciones distintas con distintos trozos de su propia biografía. Y esas relaciones cambian: lo que hoy avergüenza puede ser dentro de veinte años un simple hecho. Lo que hoy parece una nimiedad puede acabar siendo lo único que queda de alguien querido.
Por qué el sistema no debe decidir por la persona
El Tribunal de Justicia hizo en esa misma sentencia algo importante: no exigió demostrar un daño. El derecho a la supresión se reconoce «sin que la apreciación de la existencia de tal derecho presuponga que la inclusión de la información en cuestión en la lista de resultados causa un perjuicio al interesado».
Nadie está obligado a explicar por qué quiere desaparecer de un buscador. Ni a presentar un certificado de sufrimiento. Basta con quererlo; a partir de ahí opera la ponderación de intereses, y por regla general sus derechos prevalecen tanto sobre el interés comercial del buscador como sobre el interés del público en la información. Salvo que concurran razones particulares, como el papel de esa persona en la vida pública.
Esa construcción —una presunción a favor de la persona, no del sistema— pesa más que cualquier detalle técnico. Significa que, por defecto, decide ella.
El reverso es idéntico. Si alguien quiere que su correspondencia, su voz, su manera de pensar sobrevivan a su muerte, tampoco está obligado a justificarlo ante la arquitectura del almacenamiento. No tiene que demostrar que su vida es lo bastante relevante como para conservarla.
Pero aquí empieza lo incómodo.
La elección no se puede dar a medias
El derecho a elegir existe solo si ambas opciones son técnicamente viables. Y es aquí donde la conversación honesta choca contra un muro.
El EDPB, en sus directrices sobre blockchain (versión 2.0, adoptada el 7 de julio de 2026), lo formula sin ambages: la imposibilidad técnica no puede servir de excusa para incumplir el RGPD. Y añade una recomendación directa: por regla general no se recomienda almacenar datos personales en una cadena de bloques, y si no existe una solución técnica que garantice su supresión o anonimización una vez vencido el plazo de conservación, entonces los datos personales no deben almacenarse en la cadena en absoluto.
La CNIL ya dijo lo mismo en 2018, en un tono más suave: es técnicamente imposible atender una solicitud de supresión cuando los datos están inscritos en una cadena de bloques. Cabe aproximarse al efecto de la supresión —destruyendo la clave o el testigo fuera de la cadena—, pero, salvo en determinados esquemas de compromiso criptográfico, «en rigor, eso no supone la supresión de los datos, ya que estos siguen existiendo en la cadena de bloques».
¿Qué se sigue de todo esto en la práctica? Un sistema que promete eternidad y no puede olvidar nada no ofrece elección. Ofrece una sola opción y la llama libertad. Un sistema que lo borra todo según un calendario tampoco ofrece elección: simplemente ha elegido otra cosa por usted.
La elección real exige una arquitectura en la que la decisión sobre el destino de unos datos concretos se tome antes de escribirlos, no después. Es una mala noticia para los ingenieros: no se puede meterlo todo en un mismo sitio y ya se verá luego. Pero es la única forma de que tanto «olvidadme» como «conservadme» sigan siendo opciones reales y no promesas de marketing.
Qué llevarse de aquí
La supresión y la conservación tienen físicas distintas. Se puede borrar aquello que está bajo el control de alguien; se puede conservar aquello que ha escapado al control de cualquier participante concreto. Esas dos propiedades no conviven en un mismo almacén, y por eso la decisión hay que tomarla de antemano, cuando los datos todavía no se han escrito en ninguna parte.
Así que la pregunta no es «qué vencerá, el olvido o la eternidad». La pregunta es si la persona llegó a elegir antes de que la arquitectura eligiera por ella.
No hay una respuesta que valga para todos. Los reguladores no la buscaron en el texto de la ley: un estudio elaborado para el Parlamento Europeo ya en 2019 concluía que no hacía falta modificar el RGPD —el reglamento se redactó de forma tecnológicamente neutra—, sino que hacían falta aclaraciones. Las aclaraciones llegaron: el EDPB publicó sus directrices sobre blockchain en abril de 2025 y la versión final en julio de 2026. Y no resultaron ser un compromiso, sino una exigencia: si una arquitectura no permite ni suprimir los datos ni anonimizarlos, los datos personales no tienen sitio en ella.
Pero hay algo que sí puede afirmarse con firmeza. Cada vez que un sistema decide por una persona —olvidarla o recordarla—, le arrebata aquello que ambos derechos son en realidad. Ni memoria ni olvido. La autoría de la propia historia.