GDPR en blockchain: borrado criptográfico y el derecho al olvido

El hombre que quiso desaparecer de internet: cuando la justicia europea colisionó con la memoria digital

El 13 de mayo de 2014, el Tribunal de Justicia de la Unión Europea dictó una sentencia que cambiaría para siempre la relación entre las personas y la información digital. El caso era aparentemente modesto: un ciudadano español llamado Mario Costeja González había solicitado a Google que eliminara de sus resultados de búsqueda un enlace a un anuncio publicado en La Vanguardia en 1998, donde aparecía una subasta de inmuebles relacionada con deudas a la Seguridad Social. Costeja González había saldado aquellas deudas hacía años, pero cada vez que alguien buscaba su nombre en Google, el primer resultado seguía siendo aquel anuncio de embargo. Su pasado financiero lo perseguía como una sombra digital que ningún pago podía borrar.

La sentencia del caso C-131/12 —Google Spain SL y Google Inc. contra la Agencia Española de Protección de Datos (AEPD) y Mario Costeja González— estableció un principio revolucionario: los ciudadanos europeos tienen derecho a solicitar que los motores de búsqueda eliminen enlaces a información personal que sea «inadecuada, no pertinente o ya no pertinente, o excesiva». Nació así lo que la prensa bautizó como el «derecho al olvido», un concepto jurídico que cuatro años después quedaría consagrado en el artículo 17 del Reglamento General de Protección de Datos (RGPD), el marco normativo más ambicioso que jamás se haya aprobado en materia de privacidad digital.

El 25 de mayo de 2018, cuando el RGPD entró en plena aplicación, la reacción fue cercana al pánico. Empresas de todo el mundo enviaron miles de millones de correos electrónicos pidiendo a sus usuarios que «actualizaran sus preferencias de privacidad». Bufetes de abogados especializados en protección de datos cuadruplicaron sus plantillas en meses. Y las multas empezaron a llover: Amazon recibió una sanción de 746 millones de euros en Luxemburgo por prácticas de publicidad dirigida; Meta fue multada con 1.200 millones de euros por la Comisión de Protección de Datos de Irlanda por transferir datos de ciudadanos europeos a Estados Unidos sin garantías adecuadas; WhatsApp pagó 225 millones; Google, 150 millones en Francia por el modo en que gestionaba las cookies. El mensaje era inequívoco: Europa hablaba en serio sobre la privacidad.

Pero en medio de esta revolución normativa, una tecnología estaba creciendo a velocidad exponencial cuya premisa fundamental parecía contradecir la esencia misma del derecho al olvido. Esa tecnología era la cadena de bloques —la blockchain—, un sistema diseñado, desde su concepción original en el documento de Satoshi Nakamoto de 2008, para que la información registrada en ella fuera permanente, inmutable e imborrable. Si el RGPD decía «tienes derecho a que te borren», la blockchain respondía «aquí no se borra nada, jamás». La colisión entre ambos mundos no era una cuestión teórica: era un problema real, urgente y sin solución evidente que afectaba a miles de empresas europeas que querían usar tecnología blockchain sin infringir la ley.

Este artículo explora esa colisión en profundidad. Pero, sobre todo, explora las soluciones —ingeniosas, elegantes y profundamente técnicas— que criptógrafos, juristas e ingenieros han desarrollado para hacer compatible lo que parecía incompatible. Porque la respuesta no es elegir entre privacidad e inmutabilidad. La respuesta, como veremos, es utilizar la criptografía como puente entre dos derechos fundamentales que la sociedad necesita proteger simultáneamente.

La paradoja fundamental: inmutabilidad frente a derecho de supresión

Dos filosofías enfrentadas

Para comprender la magnitud del conflicto, conviene visualizarlo con una analogía. Imagina un notario que trabaja con un libro de actas especial. Cada vez que registra una escritura, la tinta se funde químicamente con el papel de tal forma que resulta imposible borrarla, tacharla o modificarla. Si se comete un error, el notario no puede arrancar la página ni usar corrector: debe añadir una nueva acta que enmiende la anterior, pero la original permanece eternamente legible. Ese libro de actas indestructible es, en esencia, lo que hace una blockchain. Cada bloque de información que se añade a la cadena queda sellado criptográficamente y vinculado al bloque anterior, de modo que alterar o eliminar un registro requeriría reescribir toda la cadena desde ese punto hasta el presente —una operación computacionalmente inviable en cualquier blockchain pública de tamaño significativo—.

Ahora imagina que un ciudadano se presenta ante ese notario con una orden judicial que dice: «Borre la escritura número 4.723 de su libro de actas». El notario mira su libro, mira la orden, y responde: «La tinta es indeleble. Físicamente, no puedo hacerlo». El juez insiste: «La ley dice que debe borrar esa información. Si no lo hace, la sanción puede alcanzar el 4% de su facturación anual global». Esa escena, absurda en el mundo del papel, se repite cada día en el mundo digital cuando empresas que operan sobre blockchain reciben solicitudes de supresión de datos amparadas por el artículo 17 del RGPD.

La filosofía de la blockchain nació de la desconfianza. Satoshi Nakamoto diseñó Bitcoin para eliminar la necesidad de confiar en intermediarios financieros. La inmutabilidad era la garantía: si nadie puede alterar los registros, nadie puede cometer fraude. Si nadie puede borrar una transacción, nadie puede negar que ocurrió. La cadena de bloques es, por diseño, un archivo histórico perfecto donde cada dato queda grabado en piedra digital para la eternidad.

La filosofía del RGPD nació de la confianza excesiva. Décadas de abusos corporativos con datos personales —desde Cambridge Analytica hasta las filtraciones masivas de Equifax, Yahoo y Marriott— demostraron que las empresas, cuando se les permitía acumular información sin límite, terminaban abusándola o perdiéndola. El RGPD respondió con un principio radical: los datos personales pertenecen al individuo, no a la empresa que los recopila, y el individuo tiene derecho a recuperar el control total sobre su información, incluyendo el derecho a que esa información deje de existir.

El artículo 17 bajo la lupa: qué dice realmente el derecho de supresión

El artículo 17 del RGPD, titulado oficialmente «Derecho de supresión («el derecho al olvido»)», establece que el interesado tiene derecho a obtener del responsable del tratamiento la supresión de los datos personales que le conciernan. Los motivos que habilitan este derecho incluyen: que los datos ya no sean necesarios para los fines para los que fueron recogidos; que el interesado retire el consentimiento en que se basaba el tratamiento; que los datos hayan sido tratados ilícitamente; o que exista una obligación legal de supresión.

Sin embargo —y este matiz es crucial—, el propio artículo 17 incluye excepciones explícitas. El derecho de supresión no se aplica cuando el tratamiento sea necesario para el ejercicio de la libertad de expresión e información, para el cumplimiento de una obligación legal, por razones de interés público en el ámbito de la salud pública, con fines de archivo en interés público o para la formulación, el ejercicio o la defensa de reclamaciones. Estas excepciones abren una ventana que, como veremos, resulta determinante para ciertas aplicaciones blockchain.

Pero hay una pregunta aún más fundamental que la doctrina jurídica sigue debatiendo: ¿qué significa exactamente «supresión»? ¿Implica necesariamente la destrucción física de los bits que componen el dato? ¿O basta con que el dato se vuelva permanente e irreversiblemente inaccesible? Esta distinción, que puede parecer un tecnicismo, es en realidad la llave que abre la puerta a la solución del conflicto entre blockchain y RGPD.

El marco legal completo: los artículos clave del RGPD y sus implicaciones para blockchain

Artículo 5: los principios que lo rigen todo

El artículo 5 establece los principios que determinan cómo debe diseñarse cualquier sistema que trate datos personales. La limitación de finalidad exige que los datos solo se recojan con fines determinados y legítimos —un reto en blockchains públicas donde cualquier nodo puede acceder a las transacciones—. La minimización de datos obliga a registrar solo lo estrictamente necesario, chocando con la tendencia a almacenar «por si acaso»: si un dato personal no necesita estar en la cadena, no debe estar en la cadena. La limitación del plazo de conservación exige que los datos no se mantengan más tiempo del necesario —aparente oxímoron en una cadena diseñada para ser eterna, que el borrado criptográfico resuelve haciendo que los datos «expiren» funcionalmente—.

Artículo 25: protección de datos desde el diseño y por defecto

El artículo 25 establece privacy by design y privacy by default: la protección de datos debe integrarse en el diseño desde el primer momento. La pregunta «¿cómo cumplimos con el derecho de supresión?» debe responderse antes de escribir la primera línea de arquitectura. Las Directrices 4/2019 del EDPB son explícitas: el responsable debe evaluar los riesgos al elegir la tecnología, no después de implementarla.

Artículo 6: las bases legales para el tratamiento en blockchain

Todo tratamiento requiere una base legal (artículo 6). Si es el consentimiento, el interesado puede retirarlo en cualquier momento —¿cómo se cesa un tratamiento en una cadena inmutable?—. Si es la ejecución de un contrato, el marco temporal es más claro pero persiste la cuestión de qué ocurre al finalizar. Si es una obligación legal —como la conservación antiblanqueo de diez años—, la blockchain puede ser aliada: su inmutabilidad garantiza que los registros no serán alterados durante el período obligatorio.

La siguiente tabla sintetiza las implicaciones de cada artículo clave del RGPD para los sistemas basados en blockchain:

Artículo RGPD	Principio o derecho	Reto para blockchain	Posible solución
Art. 5(1)(b)	Limitación de finalidad	Los datos en cadena pública son accesibles sin restricción de uso	Cifrado de datos personales; blockchains permisionadas
Art. 5(1)(c)	Minimización de datos	Tendencia a almacenar datos completos en la cadena	Almacenar solo hashes o referencias; datos fuera de cadena
Art. 5(1)(e)	Limitación del plazo de conservación	La blockchain es, por diseño, permanente	Borrado criptográfico; cifrado con claves temporales
Art. 6	Bases legales del tratamiento	Dificultad para cesar el tratamiento tras retirada de consentimiento	Capas de consentimiento gestionadas con contratos inteligentes
Art. 17	Derecho de supresión	Imposibilidad de borrar datos registrados en la cadena	Borrado criptográfico (destruir la clave de descifrado)
Art. 20	Derecho de portabilidad	Los datos cifrados pueden no ser «legibles por máquina»	Formatos estandarizados para la exportación; APIs de acceso
Art. 25	Privacidad desde el diseño	Muchas blockchains se diseñaron sin considerar la privacidad	Arquitecturas privacy-first; evaluaciones de impacto previas
Art. 35	Evaluación de impacto (DPIA)	La naturaleza distribuida dificulta la evaluación de riesgos	Marcos de evaluación específicos para blockchain

El borrado criptográfico: destruir la llave para hacer inaccesible la caja fuerte

La intuición fundamental

La técnica que resuelve el conflicto entre inmutabilidad y derecho de supresión se llama borrado criptográfico (crypto-shredding o cryptographic erasure), y su lógica es de una elegancia pasmosa. Para entenderla, piensa en esta analogía: imagina que guardas documentos confidenciales dentro de una caja fuerte de titanio. La caja es indestructible —ni el fuego, ni la presión, ni los ácidos más corrosivos pueden abrirla ni destruir su contenido—. Pero la caja solo puede abrirse con una única llave, y esa llave no tiene copia. Si quemas la llave, la caja sigue existiendo físicamente, pero su contenido se ha vuelto permanente e irreversiblemente inaccesible. Los documentos no se han destruido, pero a todos los efectos prácticos —legales, funcionales, operativos— han dejado de existir. Nadie puede leerlos, procesarlos, copiarlos ni utilizarlos de ninguna manera.

Eso es exactamente lo que hace el borrado criptográfico con los datos en una blockchain. En lugar de almacenar datos personales en texto plano (legible) en la cadena, se almacenan cifrados con una clave criptográfica robusta. El dato cifrado es, a ojos de cualquiera que no posea la clave, una secuencia aleatoria e incomprensible de caracteres —tan inútil como una sopa de letras sin sentido—. Mientras la clave exista, los usuarios autorizados pueden descifrar el dato y leerlo normalmente. Pero el día que un interesado ejerce su derecho de supresión, en lugar de intentar borrar el dato de la blockchain (algo imposible), se destruye la clave de cifrado. Sin la clave, el dato cifrado que permanece en la cadena es información ininteligible e irrecuperable. El dato personal ha sido, funcionalmente, borrado.

¿Acepta el RGPD esta interpretación?

La pregunta crítica es: ¿considera el RGPD que el borrado criptográfico equivale legalmente a la supresión? La respuesta, aunque no es absoluta, tiende firmemente al sí. Varias autoridades de protección de datos se han pronunciado al respecto.

La CNIL (Commission Nationale de l'Informatique et des Libertés), la autoridad francesa de protección de datos, publicó en septiembre de 2018 un informe titulado Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data donde explicitamente reconoció el borrado criptográfico como un enfoque válido. La CNIL indicó que, cuando los datos se almacenan cifrados y la clave de cifrado se destruye de forma verificable, el resultado se aproxima lo suficiente a la supresión como para ser considerado una solución aceptable, especialmente cuando la eliminación física es técnicamente imposible. La CNIL añadió una precaución importante: el algoritmo de cifrado utilizado debe ser lo suficientemente robusto como para que el dato resulte inaccesible no solo hoy, sino también frente a los avances tecnológicos previsibles. Es decir, no basta con un cifrado que sea difícil de romper ahora; debe ser prácticamente imposible de romper también dentro de diez, veinte o cincuenta años.

La ICO (Information Commissioner's Office), la autoridad británica equivalente, ha emitido orientaciones similares. En su guía sobre borrado criptográfico, la ICO reconoce que «si la destrucción de la clave hace que los datos sean irrecuperables con un esfuerzo razonable, puede considerarse una forma eficaz de supresión». El énfasis está en «esfuerzo razonable»: la ICO reconoce implícitamente que la seguridad absoluta no existe, pero que un cifrado suficientemente robusto sitúa la barrera de recuperación tan alta que la destrucción de la clave equivale, a efectos prácticos, a la destrucción del dato.

El EDPB (Comité Europeo de Protección de Datos) ha abordado la cuestión en sus directrices sobre protección de datos desde el diseño, donde recomienda que los responsables del tratamiento evalúen las técnicas de pseudonimización y cifrado como herramientas para facilitar el cumplimiento de los derechos de los interesados, incluido el derecho de supresión. Sin declarar explícitamente que el borrado criptográfico es equivalente a la supresión, el EDPB lo sitúa dentro del abanico de soluciones técnicamente aceptables cuando la eliminación física no resulta viable.

La ENISA (Agencia de la Unión Europea para la Ciberseguridad) publicó en 2019 un informe técnico titulado Blockchain and GDPR donde analizó en detalle las opciones disponibles. ENISA recomendó el borrado criptográfico como la técnica más prometedora para conciliar la inmutabilidad de la blockchain con el derecho de supresión, siempre que se cumplan condiciones estrictas de gestión de claves, robustez del cifrado y documentación del procedimiento.

Métodos de supresión: una comparativa

El borrado criptográfico no es la única técnica que se ha propuesto para abordar la supresión de datos en blockchain. La siguiente tabla compara los enfoques principales:

Método	Descripción	Preserva inmutabilidad	Aceptación regulatoria	Complejidad técnica
Borrado criptográfico	Cifrar datos y destruir la clave cuando se solicita supresión	Sí	Alta (CNIL, ICO)	Media
Almacenamiento fuera de cadena	Solo almacenar hashes en blockchain; datos en base de datos convencional	Sí	Alta	Baja
Cadenas editables (redactable blockchains)	Permitir la modificación de bloques mediante mecanismos criptográficos	Parcial	Incierta	Muy alta
Bifurcación (hard fork)	Crear nueva cadena que excluya los datos a eliminar	No	Teóricamente completa	Muy alta; disruptiva
Datos efímeros (pruning)	Permitir que nodos descarten datos antiguos tras cierto período	Parcial	Moderada	Media
Anonimización irreversible	Eliminar todo vínculo entre dato y persona identificable	Sí	Alta (si es verdadera anonimización)	Alta

De todas estas opciones, el borrado criptográfico es la que mejor equilibra los tres requisitos críticos: preservar la inmutabilidad de la cadena (los datos cifrados siguen ahí, manteniendo la integridad estructural), cumplir con las expectativas regulatorias (el dato personal se vuelve inaccesible) y resultar técnicamente implementable sin rediseñar la blockchain desde cero. Pero su eficacia depende enteramente de dos factores: la robustez del algoritmo de cifrado y la gestión segura de las claves. Ambos merecen una exploración detallada.

Los cimientos del borrado criptográfico: algoritmos de cifrado y por qué importan

AES-256-GCM: el estándar que protege secretos de estado

Cuando la CNIL y la ICO hablan de «cifrado suficientemente robusto», se refieren a algoritmos como AES-256-GCM. AES (Advanced Encryption Standard) es el estándar de cifrado simétrico adoptado por el gobierno de Estados Unidos en 2001 tras un proceso de selección público que duró cinco años y en el que participaron criptógrafos de todo el mundo. El número 256 se refiere a la longitud de la clave en bits, y GCM (Galois/Counter Mode) es el modo de operación que, además de cifrar los datos, genera una etiqueta de autenticación que permite detectar cualquier intento de manipulación.

Para intuir la robustez de AES-256, consideremos las cifras. Una clave de 256 bits significa que existen 2 elevado a 256 claves posibles. Ese número es tan descomunalmente grande que resulta difícil de comprender. Para ponerlo en perspectiva: se estima que el número total de átomos en el universo observable es aproximadamente 2 elevado a 266. Es decir, el número de claves AES-256 posibles es del mismo orden de magnitud que el número de átomos del universo. Aunque reunieras todos los ordenadores del planeta y los pusieran a probar claves sin descanso, el tiempo necesario para encontrar la correcta por fuerza bruta superaría la edad del universo por un factor inimaginable.

La parte GCM añade una capa adicional de protección. Pensemos en ello como un sobre lacrado: no solo cifra el contenido del sobre (confidencialidad), sino que añade un sello de lacre (autenticidad) que se rompe visiblemente si alguien intenta abrir el sobre o manipular su contenido. Si un atacante modifica aunque sea un solo bit del dato cifrado, la verificación de autenticidad falla y el sistema rechaza el dato como corrupto. Esto es especialmente importante en el contexto blockchain, donde los datos cifrados residen en un entorno compartido y potencialmente hostil.

ChaCha20-Poly1305: la alternativa moderna

ChaCha20-Poly1305 es un algoritmo de cifrado desarrollado por el criptógrafo Daniel J. Bernstein que ha ganado adopción acelerada en los últimos años. Google lo implementó como alternativa a AES en el protocolo TLS (el que protege las conexiones HTTPS), y es el cifrado que utiliza WireGuard, la VPN de nueva generación. Su principal ventaja sobre AES-256-GCM es el rendimiento en dispositivos que carecen de instrucciones hardware especializadas para AES. En un servidor moderno con soporte hardware para AES, ambos algoritmos ofrecen velocidades comparables. Pero en dispositivos móviles, sensores IoT o nodos ligeros de blockchain, ChaCha20 puede ser significativamente más rápido porque su diseño se basa en operaciones aritméticas simples (sumas, rotaciones de bits y operaciones XOR) que cualquier procesador ejecuta eficientemente, sin necesidad de circuitos especializados.

A efectos de borrado criptográfico, ambos algoritmos ofrecen garantías de seguridad equivalentes:

Característica	AES-256-GCM	ChaCha20-Poly1305
Longitud de clave	256 bits	256 bits
Nivel de seguridad	128 bits (post-cuántica: 128 bits con Grover)	128 bits (post-cuántica: 128 bits con Grover)
Autenticación integrada	Sí (GHASH)	Sí (Poly1305)
Rendimiento con hardware AES-NI	Muy alto	Alto
Rendimiento sin hardware AES-NI	Moderado	Muy alto
Vulnerabilidad a ataques de canal lateral	Requiere implementación en tiempo constante	Inherentemente resistente
Estandarización	NIST, ISO, gobierno de EE. UU.	IETF (RFC 8439), TLS 1.3
Adopción en blockchain	Amplia	Creciente

La amenaza cuántica y la agilidad criptográfica

Los ordenadores cuánticos, cuando alcancen suficiente madurez, podrán ejecutar el algoritmo de Grover, que reduce a la mitad la seguridad efectiva de los cifrados simétricos. AES-256 pasaría de ofrecer 256 bits de seguridad a «solo» 128 bits frente a un ataque cuántico —un nivel que sigue siendo abrumadoramente robusto frente a cualquier tecnología previsible—. El NIST ya ha seleccionado los primeros algoritmos post-cuánticos (CRYSTALS-Kyber para cifrado, CRYSTALS-Dilithium para firmas), y las arquitecturas bien diseñadas deben incorporar la agilidad criptográfica —la capacidad de cambiar de algoritmo sin rediseñar el sistema— como requisito fundamental.

Gestión de claves: el verdadero campo de batalla

Por qué la gestión de claves es más importante que el algoritmo

Hay un dicho entre los criptógrafos que resume décadas de experiencia: «Los algoritmos no se rompen; las claves se pierden, se roban o se gestionan mal». El cifrado más robusto del mundo es inútil si la clave está anotada en un post-it pegado al monitor, almacenada sin protección en un servidor accesible o compartida por correo electrónico. En el contexto del borrado criptográfico, la gestión de claves no es un detalle técnico secundario: es la pieza que determina si el sistema funciona o fracasa.

Pensemos en ello con una analogía. Si el borrado criptográfico consiste en quemar la llave de una caja fuerte de titanio, la gestión de claves es el sistema que controla dónde se guarda esa llave antes de quemarla, quién tiene acceso a ella, cómo se verifica que la llave quemada era realmente la única copia, y cómo se documenta todo el proceso para demostrarlo ante un regulador o un tribunal. Un fallo en cualquiera de estos eslabones invalida toda la cadena.

Derivación de claves: un maestro cerrajero que crea llaves únicas a partir de una plantilla maestra

En un sistema con miles o millones de registros de datos personales, cifrar cada registro con una clave diferente generada aleatoriamente crearía una pesadilla logística. Habría que almacenar y gestionar millones de claves independientes, cada una asociada a un registro específico, con el riesgo de perder alguna o de confundir cuál corresponde a qué. La solución estándar a este problema es la derivación jerárquica de claves, un mecanismo que funciona como un maestro cerrajero que, a partir de una plantilla maestra, puede fabricar llaves únicas para cada puerta del edificio.

El mecanismo se basa en funciones como HKDF (HMAC-based Key Derivation Function), estandarizada en el RFC 5869. HKDF toma tres ingredientes: una clave maestra (el «secreto raíz» del que se derivan todas las demás), un valor de sal (un número aleatorio que añade variabilidad) y un contexto (información específica del registro, como el identificador del interesado o la fecha). Con estos tres ingredientes, HKDF produce una clave derivada única para cada combinación de parámetros.

La analogía del cerrajero funciona así: la plantilla maestra es la clave raíz. Cada habitación del edificio tiene un número (el contexto). El cerrajero introduce la plantilla y el número de habitación en su máquina, y obtiene una llave única que solo abre esa habitación. No necesita almacenar cada llave individualmente: le basta con la plantilla maestra y el número de habitación para reproducir cualquier llave en cualquier momento. Pero —y aquí está la ventaja para el borrado criptográfico— si destruye una llave específica y el registro de su contexto de derivación, esa habitación queda permanentemente sellada, sin afectar al resto del edificio.

En la práctica, la jerarquía de claves puede organizarse en varios niveles. En el nivel superior está la clave maestra del sistema, custodiada con las máximas medidas de seguridad (idealmente en un módulo de seguridad hardware o HSM). Del segundo nivel se derivan claves por categoría de datos: una para datos médicos, otra para datos financieros, otra para datos de identificación. Del tercer nivel se derivan claves por interesado individual: una clave específica para cada persona cuyos datos se almacenan. Y del cuarto nivel pueden derivarse claves por registro individual o por período temporal. Esta estructura jerárquica permite realizar borrados granulares: destruir la clave de un interesado específico borra funcionalmente todos sus datos sin afectar a los de ningún otro interesado.

Rotación de claves: cambiar las cerraduras periódicamente

La rotación periódica de claves consiste en generar nuevas claves de cifrado a intervalos regulares, recifrar los datos activos con la nueva clave y destruir la antigua. Es la versión digital de cambiar las cerraduras preventivamente. Tiene dos beneficios complementarios: limita la ventana de exposición (si una clave se compromete, solo afecta a los datos de ese período) y facilita el borrado criptográfico temporal (los datos asociados a una clave expirada pueden «borrarse» simplemente no recifrándolos con la nueva clave). Es como si, al cambiar las cerraduras del edificio, deliberadamente no fabricaras nueva llave para una habitación cuyos contenidos ya no necesitas conservar.

Compartición de secretos de Shamir: rasgar el mapa del tesoro

Un problema persistente en la gestión de claves es el del punto único de fallo. Si la clave de cifrado está en manos de una sola persona o almacenada en un solo lugar, basta un accidente, un robo o una coerción para que el sistema se derrumbe. En 1979, el criptógrafo israelí Adi Shamir —la «S» del célebre algoritmo RSA— publicó un artículo titulado How to Share a Secret que proponía una solución elegante a este problema.

Imaginemos un mapa del tesoro. Si dejas el mapa entero en una única caja fuerte, quien acceda a esa caja tiene el tesoro. Si lo rasgas en cinco pedazos y repartes un pedazo a cada uno de cinco custodios, necesitas reunir los cinco pedazos para reconstruir el mapa —pero si uno de los custodios pierde su pedazo o no está disponible, el tesoro se vuelve inaccesible para siempre—. El esquema de Shamir resuelve ambos problemas simultáneamente: permite dividir un secreto (la clave de cifrado) en cinco fragmentos de tal forma que cualesquiera tres de ellos basten para reconstruir la clave, pero dos cualesquiera —por mucho que sus poseedores colaboren— no proporcionen absolutamente ninguna información sobre la clave original. Ni un solo bit de información útil.

En el contexto del borrado criptográfico, la compartición de secretos de Shamir añade una capa de seguridad operativa fundamental. La clave de cifrado nunca existe como objeto único en ningún lugar. Está fragmentada entre múltiples custodios —quizá el responsable de protección de datos, el director de tecnología, un notario externo y un servicio de custodia automatizado—, y solo cuando un número mínimo de ellos coopera puede la clave reconstruirse para descifrar datos o, inversamente, para confirmar su destrucción. Para destruir la clave, basta con que suficientes custodios destruyan sus fragmentos. Si tres de cinco custodios destruyen sus fragmentos de forma verificable, la clave se vuelve matemáticamente irreconstruible —el mapa del tesoro ha quedado incompleto para siempre—.

Esta propiedad es particularmente valiosa para generar evidencia legal de la supresión. Cada custodio puede documentar y certificar la destrucción de su fragmento, creando un registro distribuido de pruebas que demuestra, ante un regulador o un tribunal, que la clave fue irrevocablemente eliminada y que los datos cifrados asociados son, en consecuencia, permanentemente inaccesibles.

Cifrado multicapa: las muñecas rusas de la protección de datos

La analogía de la matrioshka

En las tiendas de recuerdos de Moscú y San Petersburgo se venden matrioshkas: conjuntos de muñecas de madera que encajan unas dentro de otras. Al abrir la muñeca exterior, aparece una más pequeña dentro. Al abrir esa, otra más pequeña. Y así sucesivamente, hasta llegar a la más diminuta, que contiene el «tesoro». Ahora imagina que cada muñeca tiene su propia cerradura, y que cada cerradura requiere una llave diferente. Para acceder al tesoro, necesitas abrir todas las muñecas en orden, con todas las llaves correctas. Si pierdes cualquiera de las llaves, el contenido de esa muñeca y de todas las que están dentro se vuelve inaccesible.

El cifrado multicapa aplica esta misma lógica a la protección de datos. En lugar de cifrar los datos una sola vez, se cifran en múltiples capas sucesivas, cada una con una clave diferente, gestionada por una entidad diferente y con una política de retención diferente. Es como envolver un regalo en varias capas de papel, cada una con su propio sello: para llegar al regalo, hay que romper todos los sellos en orden.

Las tres capas en la práctica

En una arquitectura blockchain orientada al cumplimiento del RGPD, el cifrado multicapa típicamente se organiza en tres niveles.

La capa de cliente es la primera. Antes de que el dato personal salga del dispositivo o entorno del interesado (o de la aplicación que actúa en su nombre), se cifra con una clave controlada por el propio interesado o por la aplicación cliente. Es como si el remitente de una carta metiera su mensaje en un sobre sellado antes de entregarlo al servicio postal. Aunque el servicio postal examine el paquete, lo único que verá es un sobre cerrado. Esta capa garantiza que ni siquiera los operadores de la infraestructura blockchain pueden acceder al dato en texto plano.

La capa de red es la segunda. Cuando el dato cifrado viaja por la red blockchain, se protege con el cifrado de transporte (típicamente TLS 1.3 o protocolos similares). Es como si el sobre sellado del remitente se metiera dentro de una valija diplomática para su transporte. Esta capa protege contra interceptaciones durante la transmisión, asegurando que nadie pueda leer el dato mientras viaja entre nodos.

La capa de cumplimiento es la tercera y la más relevante para el borrado criptográfico. Una vez que el dato llega a la blockchain, se cifra nuevamente con una clave gestionada específicamente para el cumplimiento normativo. Esta clave está vinculada a la política de retención del dato: cuando expira el plazo de conservación o cuando el interesado solicita la supresión, esta clave se destruye. Es como si, una vez que el sobre sellado llega a la bóveda de seguridad, se guardara dentro de una tercera caja fuerte cuya llave está programada para autodestruirse en una fecha determinada.

La ventaja del enfoque multicapa es la defensa en profundidad. Si una de las capas se compromete —por ejemplo, si un atacante obtiene la clave de la capa de red—, las otras dos siguen protegiendo el dato. Para acceder al dato personal en texto plano, un atacante necesitaría romper las tres capas simultáneamente, lo que multiplica exponencialmente la dificultad. Y para el borrado criptográfico, basta con destruir la clave de cualquiera de las capas (típicamente la de cumplimiento) para hacer el dato inaccesible, sin necesidad de que todas las capas participen en el proceso de supresión.

Clasificación de datos: no toda información merece el mismo trato

El triaje hospitalario como modelo

En urgencias de un hospital, los pacientes no se atienden por orden de llegada. Un sistema llamado triaje clasifica a cada paciente según la gravedad de su estado: los pacientes críticos pasan inmediatamente al quirófano; los que tienen lesiones moderadas esperan en una sala de observación; los que presentan dolencias leves pueden esperar en la sala de espera general. Cada nivel de gravedad tiene un protocolo de atención distinto, unos recursos asignados diferentes y unos tiempos de respuesta específicos. Tratar a todos los pacientes con el mismo nivel de urgencia sería no solo ineficiente, sino peligroso: los recursos dedicados a atender una uña rota podrían estar salvándole la vida a alguien con una hemorragia interna.

La clasificación de datos aplica exactamente esta lógica a la información almacenada en una blockchain. No todos los datos que pasan por un sistema blockchain son datos personales, y no todos los datos personales tienen el mismo nivel de sensibilidad. Tratar toda la información con el máximo nivel de protección —cifrado multicapa, gestión de claves distribuida, políticas de retención complejas— sería técnicamente costoso e innecesario. Y tratar información altamente sensible con el nivel mínimo de protección sería una violación del RGPD.

Las cuatro categorías y sus implicaciones

En el contexto del RGPD, la información que puede aparecer en una blockchain se divide típicamente en cuatro categorías.

La primera son los datos anonimizados: información que ha sido procesada de tal manera que ya no puede vincularse, ni directa ni indirectamente, a una persona física identificada o identificable. Una estadística agregada sobre el número total de transacciones en un período, por ejemplo, o un hash de un dato cuya correspondencia con el dato original se ha destruido. Los datos verdaderamente anonimizados quedan fuera del ámbito de aplicación del RGPD: el reglamento no se aplica a información que no identifica ni puede identificar a nadie. Estos datos pueden almacenarse directamente en la blockchain sin restricciones especiales.

La segunda son los datos seudonimizados: información donde los identificadores directos (nombre, DNI, dirección) se han sustituido por seudónimos (códigos, tokens, direcciones criptográficas), pero donde existe alguna posibilidad de revertir la seudonimización y vincular el dato a una persona concreta. Las direcciones de blockchain son un ejemplo clásico: aunque una dirección como «0x7a3b...» no contiene un nombre, técnicas de análisis de patrones pueden vincularla a una identidad real. Los datos seudonimizados sí están sujetos al RGPD, aunque el reglamento reconoce que la seudonimización reduce el riesgo y puede ser considerada una medida técnica adecuada.

La tercera son los datos personales directos: nombre, número de identificación, correo electrónico, número de teléfono, dirección postal. Cualquier información que, por sí sola, permita identificar a una persona. Estos datos requieren el nivel máximo de protección y, como regla general, nunca deberían almacenarse directamente en una blockchain pública, ni siquiera cifrados. La estrategia recomendada es almacenarlos fuera de la cadena (en bases de datos convencionales con capacidad de borrado real) y registrar en la blockchain solo una referencia criptográfica (un hash o un compromiso) que permita verificar la integridad del dato sin revelarlo.

La cuarta son las categorías especiales de datos (lo que antes se llamaba «datos especialmente protegidos»): información relativa a salud, orientación sexual, opiniones políticas, creencias religiosas, origen étnico, datos genéticos y datos biométricos. El artículo 9 del RGPD prohíbe, como regla general, el tratamiento de estas categorías, con excepciones tasadas. En un contexto blockchain, estos datos exigen el máximo nivel de protección posible: cifrado multicapa, gestión de claves con compartición de Shamir, almacenamiento exclusivamente fuera de cadena y políticas de retención estrictas con borrado criptográfico automatizado al expirar el plazo de conservación.

Escenarios reales: cuando la teoría se encuentra con la urgencia

El hospital que no puede olvidar ni puede recordar

Imaginemos el Hospital Clínico de Barcelona, un centro de referencia que ha implementado un sistema de historial clínico electrónico basado en blockchain para garantizar la integridad y trazabilidad de los registros médicos. Cada entrada en el historial de un paciente —diagnósticos, tratamientos, resultados de pruebas, prescripciones— se registra como una transacción en una blockchain permisionada, creando un registro inalterable que ningún médico, administrador ni hacker puede modificar retroactivamente. Para un sistema sanitario, esta inmutabilidad es extraordinariamente valiosa: garantiza que un diagnóstico no puede ser alterado después del hecho, que las prescripciones de medicamentos tienen un historial verificable, y que cualquier negligencia médica puede ser documentada de forma irrefutable.

Un día, un paciente ejerce su derecho de supresión bajo el artículo 17 del RGPD. Quiere que se borren los registros de un tratamiento psiquiátrico que recibió hace tres años y que, según él, ya no es relevante y le causa perjuicio profesional. El hospital se enfrenta a un dilema con múltiples dimensiones. Por un lado, el RGPD le obliga a suprimir los datos. Por otro lado, la normativa sanitaria española (Ley 41/2002 de autonomía del paciente) exige conservar el historial clínico durante un mínimo de cinco años desde el último episodio asistencial. Además, si se borrara el historial y el paciente sufriera una reacción adversa a un medicamento que fue prescrito en función de aquel diagnóstico psiquiátrico, la ausencia del registro podría poner en riesgo su vida.

La solución mediante borrado criptográfico funciona así: los datos clínicos detallados (el contenido del historial) están almacenados fuera de la cadena, cifrados con una clave específica para ese paciente y esa categoría de datos. En la blockchain solo consta un registro estructurado que indica «el paciente con identificador seudonimizado X recibió un tratamiento de categoría Y entre las fechas A y B», sin detalles clínicos. Cuando el paciente solicita la supresión y el hospital verifica que el período de conservación obligatoria ha expirado, la clave de cifrado del historial detallado se destruye mediante el protocolo de Shamir (tres de cinco custodios autorizados confirman la destrucción de sus fragmentos). Los datos detallados se vuelven permanentemente inaccesibles. El registro en la blockchain sigue existiendo —preservando la integridad de la cadena y la trazabilidad básica—, pero sin posibilidad de vincular esa entrada a datos clínicos específicos.

La fintech que recibe una solicitud de borrado

NeoBank, una fintech con sede en Ámsterdam, utiliza blockchain para registrar transferencias internacionales entre sus clientes europeos. Cada transferencia queda registrada en una cadena permisionada que comparten NeoBank, el banco receptor y un auditor independiente. Un día, un cliente cierra su cuenta y solicita, invocando el artículo 17, que se supriman todos sus datos personales, incluyendo su historial de transferencias.

NeoBank se encuentra en una situación compleja. La Cuarta Directiva contra el Blanqueo de Capitales (Directiva 2015/849/UE) obliga a las entidades financieras a conservar los registros de transacciones durante cinco años tras la finalización de la relación comercial. Es decir, la ley que obliga a borrar (RGPD) y la ley que obliga a conservar (directiva antiblanqueo) se aplican simultáneamente. ¿Cuál prevalece?

El propio artículo 17 resuelve el conflicto: el apartado 3(b) establece que el derecho de supresión no se aplica cuando el tratamiento sea necesario para el cumplimiento de una obligación legal. Por tanto, NeoBank puede —y debe— conservar los registros de transacciones durante el período de cinco años. Pero el borrado criptográfico entra en juego de forma elegante: los datos del cliente que no están sujetos a la obligación de conservación antiblanqueo (perfil personal, preferencias, historial de navegación, comunicaciones) se suprimen inmediatamente mediante destrucción de sus claves de cifrado. Los datos sujetos a conservación legal (registros de transacciones) se mantienen cifrados con claves que tienen fecha de expiración programada: exactamente cinco años después del cierre de la cuenta, las claves se destruyen automáticamente y los registros de transacciones se vuelven funcionalmente inaccesibles.

La cadena de suministro con socios europeos

FreshTrace es una empresa que utiliza blockchain para rastrear productos agroalimentarios desde el campo hasta el supermercado. Cada eslabón de la cadena —el agricultor en Almería, la cooperativa en Murcia, el distribuidor logístico en Lyon, el supermercado en Berlín— registra en la cadena información sobre el producto: fecha de recolección, temperatura de transporte, certificaciones sanitarias, origen de la parcela. El problema surge cuando algunos de estos registros contienen datos personales: el nombre del agricultor certificado, la matrícula del conductor del camión frigorífico, el email del responsable de calidad de la cooperativa.

La dimensión transfronteriza añade complejidad. Los datos del agricultor español están sujetos a la AEPD, los del distribuidor francés a la CNIL, y los del supermercado alemán al Bundesdatenschutzgesetz (BDSG) y la autoridad de Berlín. Aunque todos comparten el paraguas del RGPD, las interpretaciones nacionales varían. La solución de FreshTrace se basa en tres principios. Primero, minimización radical: en la blockchain solo se almacenan los datos estrictamente necesarios para la trazabilidad del producto, y los datos personales se sustituyen por identificadores seudonimizados. Segundo, almacenamiento fuera de cadena por jurisdicción: los datos personales de cada actor se almacenan en servidores de su jurisdicción correspondiente, cifrados con claves gestionadas localmente. Tercero, borrado criptográfico diferenciado: cuando un agricultor deja la cooperativa y solicita el borrado de sus datos, solo se destruyen las claves de sus datos personales en los servidores españoles. Los registros de trazabilidad en la blockchain —que solo contienen un identificador seudonimizado, no datos personales directos— permanecen intactos, preservando la integridad de la cadena de suministro.

El sistema de voto verificable pero anónimo

Un consorcio de universidades europeas quiere implementar un sistema de votación electrónica basado en blockchain para elecciones a rector. Los requisitos son aparentemente contradictorios: cada votante debe poder verificar que su voto fue contado correctamente (verificabilidad), pero nadie —ni siquiera el administrador del sistema— debe poder saber qué votó cada persona (secreto del voto). Además, al finalizar el período de impugnación, el vínculo entre votante y voto debe destruirse irreversiblemente.

La solución combina cifrado multicapa con borrado criptográfico temporizado. Cada voto se cifra con dos capas: una clave individual del votante (que le permite verificar su propio voto durante el período de impugnación) y una clave del comité electoral (que permite el recuento). El recuento se realiza mediante técnicas homomorficas que permiten sumar los votos cifrados sin descifrarlos individualmente —es como poder pesar sobres cerrados para determinar cuántos votos hay por cada opción sin abrir ningún sobre—. Al finalizar el período de impugnación, las claves individuales de los votantes se destruyen mediante Shamir (el comité electoral, compuesto por cinco miembros, destruye tres de cinco fragmentos). El resultado queda registrado en la blockchain de forma permanente y verificable, pero el vínculo entre cada persona y su voto ha desaparecido para siempre.

La aseguradora y las reclamaciones de salud

HealthInsure, una aseguradora paneuropea, procesa reclamaciones de salud sobre una blockchain permisionada que comparte con una red de hospitales y clínicas. Cuando un asegurado presenta una reclamación por un tratamiento oncológico, la blockchain registra la transacción: el identificador seudonimizado del paciente, la clínica que prestó el servicio, el importe, la fecha y un hash del informe médico que justifica la reclamación. El informe médico completo —que contiene datos de categoría especial bajo el artículo 9 del RGPD— se almacena fuera de la cadena, cifrado con AES-256-GCM y con una clave derivada específicamente para ese paciente y esa categoría de datos.

Cuando el asegurado cambia de compañía y solicita la supresión de sus datos, HealthInsure activa un protocolo en tres fases. Primera fase: portabilidad. Antes del borrado, se ofrece al asegurado la exportación de sus datos en formato estructurado y legible por máquina, cumpliendo con el derecho de portabilidad del artículo 20. Segunda fase: borrado criptográfico selectivo. Se destruyen las claves de cifrado de los informes médicos detallados (datos de categoría especial, máximo nivel de sensibilidad). Se destruyen también las claves de los datos personales directos. Se mantienen, por obligación legal, los registros financieros de las transacciones durante el período requerido por la normativa contable. Tercera fase: registro de la supresión. Se añade a la blockchain un registro que documenta que el borrado criptográfico se ha ejecutado, incluyendo la fecha, los custodios que participaron en la destrucción de claves y un hash del certificado de destrucción. Paradójicamente, la inmutabilidad de la blockchain se convierte aquí en aliada del cumplimiento: el registro del borrado es inalterable, lo que proporciona una prueba irrefutable de que la supresión se ejecutó conforme a la normativa.

Gestión del consentimiento en cadena: el poder notarial revocable

De la casilla de aceptación al contrato inteligente

En la mayoría de sitios web, la empresa controla tanto el texto de la política de privacidad como el registro del consentimiento del usuario —un conflicto de intereses evidente—. ¿Qué impide que la empresa modifique retroactivamente el texto y afirme que el usuario aceptó la nueva versión?

La gestión del consentimiento basada en blockchain resuelve este problema al crear un registro inmutable de qué consintió cada persona, cuándo y sobre qué texto exacto de política. Es como un poder notarial: un documento formal ante testigo imparcial —la propia blockchain— que otorga autorización para un fin específico y puede ser revocado en cualquier momento. Cada consentimiento se registra como transacción que contiene: el hash de la política de privacidad, el identificador seudonimizado del usuario, la fecha precisa, el alcance del consentimiento y una firma criptográfica del usuario. La revocación se registra como nueva transacción que referencia la original, sin borrarla pero dejando constancia inequívoca de que el consentimiento ya no está vigente.

Pruebas criptográficas de consentimiento

Imagina que la AEPD investiga a una empresa: «¿Tenía usted consentimiento válido del señor García para tratar sus datos de salud el 15 de octubre de 2024?». Con un sistema basado en blockchain, la empresa puede proporcionar la transacción de consentimiento original, firmada criptográficamente por el propio señor García, con sello temporal verificable —una prueba que no puede fabricarse retroactivamente—. El sistema puede incluso incorporar pruebas de conocimiento cero que demuestren la validez de un consentimiento sin revelar la identidad del interesado: poder probar ante un juez que «un ciudadano dio su consentimiento informado para el tratamiento X el día Y» sin revelar quién es.

Políticas inteligentes de cumplimiento: el guardia de seguridad que nunca duerme

Automatización frente a error humano

El mayor riesgo en protección de datos no es el hacker sofisticado: es el error humano. Un empleado que olvida ejecutar el borrado, un administrador que no rota claves a tiempo, un responsable que pasa por alto un período de retención expirado. Las políticas inteligentes de cumplimiento funcionan como un guardia de seguridad que nunca duerme ni se distrae: cuando se cumple una condición predefinida, se dispara una acción específica, sin excepción, sin retraso, sin posibilidad de olvido.

Disparadores y acciones: la arquitectura del cumplimiento automatizado

Una política inteligente de cumplimiento se compone de tres elementos: un disparador (el evento que activa la política), una condición (la verificación que debe cumplirse) y una acción (la operación que se ejecuta).

Ejemplo de política de retención temporal: el disparador es la llegada de una fecha límite (cinco años después del registro del dato). La condición es que no exista una obligación legal activa que extienda el período de conservación. La acción es la destrucción de la clave de cifrado asociada a ese dato y el registro de la destrucción en la blockchain.

Ejemplo de política de respuesta a solicitud de supresión: el disparador es la recepción de una solicitud válida de supresión (verificada mediante firma criptográfica del interesado). La condición es que no se aplique ninguna de las excepciones del artículo 17(3). La acción es la activación del protocolo de borrado criptográfico: notificación a los custodios de claves, destrucción coordinada de fragmentos Shamir, registro de la supresión en cadena y notificación al interesado.

Ejemplo de política de rotación de claves: el disparador es el transcurso de un período predeterminado (por ejemplo, 90 días). La condición es que la clave actual siga activa y no haya sido comprometida. La acción es la generación de nueva clave derivada, el recifrado de los datos activos con la nueva clave, la destrucción de la clave antigua y el registro de la rotación.

Ejemplo de política de reacción a brecha de seguridad: el disparador es la detección de un acceso no autorizado o anómalo. La condición es que el patrón de acceso supere un umbral de riesgo predefinido. La acción es la rotación inmediata de todas las claves potencialmente comprometidas, la notificación a la autoridad de protección de datos (conforme al artículo 33, que exige notificación en un plazo de 72 horas) y la notificación a los interesados afectados (conforme al artículo 34).

Contratos inteligentes como motor de cumplimiento

En blockchains que soportan contratos inteligentes, estas políticas se implementan como lógica programada que se ejecuta automáticamente en la propia cadena: mantener fechas límite, comprobar expiraciones y emitir instrucciones de destrucción de clave cuando corresponda. El contrato es público y auditable. Es la diferencia entre un contrato verbal («confía en mí, borraré tus datos en cinco años») y un contrato notarial con cláusula de ejecución automática («el sistema borrará tus datos en cinco años, y puedes verificar ahora mismo que el mecanismo está en marcha»).

La pista de auditoría inmutable: cuando la blockchain se convierte en aliada del RGPD

El taquígrafo que nunca deja de registrar

En un juicio, el taquígrafo judicial tiene una responsabilidad crítica: registrar fielmente cada palabra que se pronuncia en la sala, sin omisiones, sin adornos, sin interpretaciones. Su transcripción es la memoria oficial del proceso. Si alguien cuestiona lo que se dijo, la transcripción del taquígrafo es la referencia definitiva. La integridad del sistema judicial depende, en última instancia, de que esa transcripción sea completa, precisa e inalterable.

Una pista de auditoría basada en blockchain funciona exactamente como ese taquígrafo, pero para las operaciones de tratamiento de datos personales. Cada vez que se accede a un dato personal, se registra: quién accedió (identificador seudonimizado del empleado), cuándo (marca temporal criptográficamente verificable), a qué dato (referencia del registro), con qué finalidad (código de autorización vinculado a una base legal específica) y qué resultado tuvo la operación (lectura, modificación, exportación, supresión). El registro es inmutable: una vez que la entrada queda en la blockchain, nadie —ni el empleado, ni el administrador, ni el director general— puede borrarla ni modificarla.

La auditoría como herramienta de defensa

El artículo 5(2) del RGPD establece el principio de responsabilidad proactiva (accountability): el responsable del tratamiento no solo debe cumplir con el reglamento, sino que debe poder demostrar que cumple. Es la diferencia entre ser inocente y poder probar que eres inocente. Una pista de auditoría inmutable basada en blockchain proporciona exactamente esa prueba.

Cuando una autoridad de protección de datos investiga a una empresa, una de las primeras cosas que solicita es el registro de las operaciones de tratamiento. ¿Quién accedió a los datos del reclamante? ¿Con qué frecuencia? ¿Con qué finalidad? ¿Se ejecutó la supresión solicitada dentro del plazo de un mes que establece el artículo 12(3)? Con una pista de auditoría convencional (un archivo de logs en un servidor), la empresa presenta registros que ella misma controla y que podría haber manipulado. Con una pista de auditoría basada en blockchain, los registros son matemáticamente verificables e infalsificables. Cada entrada lleva una firma criptográfica y un sello temporal vinculado a la cadena de bloques, de modo que alterar un registro requeriría reescribir toda la cadena posterior —algo computacionalmente inviable—.

La ironía es deliciosa: la misma propiedad de la blockchain que genera el conflicto con el derecho de supresión (la inmutabilidad) se convierte, en el contexto de la auditoría, en la mejor herramienta de cumplimiento del RGPD. La blockchain registra de forma permanente e inalterable qué datos se trataron, cómo se trataron y cuándo se suprimieron. Es como si el libro de actas indestructible del notario incluyera no solo las escrituras, sino también un registro de cada vez que alguien consultó, copió o destruyó una escritura. El mecanismo que crea el problema es, al mismo tiempo, el mecanismo que documenta la solución.

Auditoría de la propia supresión

Quizá el uso más elegante de la pista de auditoría inmutable es registrar el propio proceso de borrado criptográfico. Cuando se destruye una clave de cifrado para suprimir datos, el evento queda registrado en la blockchain: la fecha y hora de la destrucción, los identificadores de los custodios que participaron (en un esquema de Shamir, qué tres de cinco custodios confirmaron la destrucción de sus fragmentos), el hash del certificado de destrucción emitido por cada custodio y la referencia a los registros de datos que han quedado funcionalmente inaccesibles.

Este registro de supresión sirve como prueba ante un regulador de que el borrado se ejecutó conforme al artículo 17 y dentro del plazo legal. También protege a la empresa ante reclamaciones posteriores: si un interesado alega que sus datos no fueron suprimidos, la empresa puede presentar el registro inmutable en blockchain que demuestra lo contrario. Y como la blockchain no distingue entre «registros de datos» y «registros de supresión de datos» en términos de integridad criptográfica, ambos tipos de registros gozan de la misma garantía de infalibilidad.

Más allá del borrado: los otros derechos del interesado

Derecho de acceso (artículo 15): saber qué saben de ti

El derecho de acceso permite solicitar una copia de todos los datos personales que una organización tiene sobre una persona. La clave derivada específica del interesado (vía HKDF) permite este acceso selectivo: el interesado puede leer sus propios datos, pero no los de nadie más. La pista de auditoría inmutable facilita la completitud: al registrar cada operación, proporciona un índice de todos los datos tratados para cada interesado.

Derecho de rectificación (artículo 16): corregir sin borrar

En una blockchain inmutable, la rectificación se implementa como en contabilidad: no se borra el asiento erróneo, sino que se añade un contraasiento. Una nueva transacción con los datos corregidos referencia y sustituye funcionalmente a la original, con firma criptográfica del responsable. Las aplicaciones usan siempre la versión más reciente, pero la cadena conserva el historial completo para fines de auditoría.

Derecho de portabilidad (artículo 20): llevar tus datos a otra parte

El interesado tiene derecho a recibir sus datos en formato estructurado y lectura mecánica. La capa de cifrado de cliente es especialmente útil: como el interesado controla su propia clave, puede descifrar y exportar sus datos independientemente de la cooperación de la empresa.

Derecho de oposición (artículo 21) y limitación del tratamiento (artículo 18)

Ambos derechos se implementan mediante marcadores de estado en contratos inteligentes: transacciones que actualizan el estado de procesamiento de «activo» a «limitado» o «opuesto». Las políticas inteligentes verifican estos marcadores antes de cualquier operación y rechazan automáticamente las que violen la restricción registrada.

Hoja de ruta para empresas europeas: de la teoría a la implementación

Fase 1: evaluación y diseño (meses 1-3)

El punto de partida es una evaluación de impacto relativa a la protección de datos (DPIA), obligatoria según el artículo 35 del RGPD. La DPIA debe identificar qué datos personales van a tratarse, con qué base legal, dónde se almacenarán (en cadena o fuera de cadena), cómo se protegerán y cómo se ejercerán los derechos de los interesados. Es en esta fase donde se toman las decisiones arquitectónicas críticas: ¿blockchain pública (cifrado imprescindible), permisionada (riesgo reducido pero no eliminado) o privada (cumplimiento simplificado pero menos descentralización)?

Fase 2: implementación técnica (meses 3-9)

La implementación comprende cuatro bloques: el sistema de cifrado (clave raíz en HSM, derivación HKDF, fragmentos Shamir entre custodios); el almacenamiento (separación estricta entre datos en cadena y fuera de cadena); las políticas inteligentes (programadas, probadas y auditadas por tercero independiente); y la pista de auditoría (registro completo de todas las operaciones de tratamiento).

Fase 3: formación y gobernanza (meses 6-12)

La formación debe cubrir tres públicos: el equipo técnico (gestión de claves y procedimientos de borrado), el equipo jurídico (implicaciones legales de cada decisión técnica) y la dirección (riesgos, responsabilidades e inversiones). La gobernanza incluye la designación de custodios Shamir, los procedimientos de respuesta a solicitudes de interesados y los protocolos de gestión de brechas.

Fase 4: auditoría continua y adaptación (permanente)

El cumplimiento del RGPD no es un hito sino un proceso continuo. El entorno regulatorio evoluciona, la tecnología avanza y el negocio cambia. La auditoría continua —tanto técnica como jurídica— detecta desajustes antes de que se conviertan en infracciones.

Precedentes legales y orientación regulatoria: el mapa jurídico

La CNIL y el informe de referencia de 2018

El informe de la CNIL Blockchain and the GDPR, publicado en septiembre de 2018, sigue siendo el documento de referencia más completo emitido por una autoridad de protección de datos sobre la intersección entre blockchain y RGPD. La CNIL distinguió tres escenarios según el tipo de blockchain: pública (mayor riesgo, más restricciones), permisionada (riesgo medio, recomendada para la mayoría de usos empresariales) y privada (menor riesgo, pero con menos ventajas de la descentralización). La CNIL recomendó explícitamente almacenar los datos personales fuera de la cadena siempre que sea posible, cifrar los datos que deban almacenarse en la cadena, y utilizar el borrado criptográfico como mecanismo de supresión cuando la eliminación física no sea viable.

Un aspecto crucial del informe de la CNIL fue la identificación de los roles del RGPD en un contexto blockchain. ¿Quién es el «responsable del tratamiento» en una red descentralizada donde no hay una autoridad central? La CNIL concluyó que los participantes que deciden registrar datos personales en la blockchain actúan como responsables del tratamiento, mientras que los mineros o validadores que procesan las transacciones actúan como encargados del tratamiento. Esta clasificación tiene implicaciones directas para la asignación de responsabilidades: es el participante que registra datos personales quien debe garantizar el cumplimiento del RGPD, no el validador que simplemente procesa la transacción.

La resolución del Parlamento Europeo

El Parlamento Europeo ha mantenido una posición consistente: blockchain ofrece oportunidades significativas para la protección de datos, pero debe diseñarse conforme al RGPD desde el primer momento. Ha instado a la Comisión a proporcionar orientación más detallada y a fomentar la investigación en técnicas de privacidad compatibles con registros distribuidos.

La doctrina académica: Finck y Politou

La profesora Michels Finck, en su influyente artículo de 2018, argumentó que la solución requiere un enfoque técnico-jurídico integrado y que el concepto de «supresión» debe interpretarse de forma funcional: lo que importa no es la destrucción física del dato, sino la eliminación efectiva de la capacidad de acceder a él. Politou, Alepis y Patsakis (2019) sistematizaron las técnicas de mutabilidad controlada en blockchain y concluyeron que no existe solución única: la mejor estrategia depende del tipo de blockchain, del tipo de datos y del marco regulatorio específico.

Google Spain v. AEPD: la sentencia que lo inició todo

El caso C-131/12 tiene implicaciones técnicas profundas. El TJUE estableció que el derecho al olvido no exige la destrucción del dato original (el anuncio seguía en La Vanguardia), sino la eliminación del enlace entre el dato y la persona. Trasladado a blockchain: no es necesario destruir el dato cifrado; basta con destruir la capacidad de vincularlo con la persona —exactamente lo que logra el borrado criptográfico—. El consenso emergente es que la «supresión» del artículo 17 debe interpretarse en términos de resultado funcional (el dato deja de ser accesible), no de mecanismo físico (eliminación del soporte).

Desafíos pendientes y fronteras abiertas

La cuestión de los hashes como datos personales

¿Es un hash de datos personales, por sí mismo, un dato personal? No se puede reconstruir el dato original a partir del hash, pero si alguien conoce el dato original, puede verificar la correspondencia. El Grupo de Trabajo del Artículo 29 consideró (Dictamen 05/2014) que los datos seudonimizados —incluidos los hashes— siguen siendo datos personales cuando existe posibilidad de vincularlos a una persona identificable. La contraargumentación: un hash aislado, sin tabla de correspondencia, es funcionalmente aleatorio. La resolución definitiva probablemente requerirá un pronunciamiento del TJUE o una directriz del EDPB.

Gobernanza descentralizada y responsabilidad legal

En las blockchains descentralizadas, ¿a quién dirige el interesado su solicitud de supresión? El RGPD asigna obligaciones al «responsable del tratamiento», pero en una red donde nadie tiene capacidad individual de eliminar datos, la atribución de responsabilidad es problemática. Las soluciones van desde fundaciones de gobernanza que actúen como responsables formales, hasta la corresponsabilidad del artículo 26, pasando por el enfoque pragmático: quien introduce datos personales en la blockchain responde de su cumplimiento.

Interoperabilidad y estándares

No existe aún un estándar universal para el borrado criptográfico en blockchain. La ISO/TC 307 está trabajando en la estandarización, pero la tecnología avanza más rápido que los comités de normalización, y cada organización desarrolla su propia solución con sus propias convenciones.

El Reglamento MiCA y la convergencia regulatoria

La entrada en vigor del Reglamento de Mercados de Criptoactivos (MiCA) en la Unión Europea añade una nueva capa al paisaje normativo. MiCA y RGPD se aplican simultáneamente, creando un entorno donde las empresas deben cumplir requisitos de transparencia (MiCA exige que cierta información sea pública) y de privacidad (RGPD exige que cierta información sea protegida o borrada). El cifrado selectivo y el borrado criptográfico son las herramientas que permiten satisfacer ambos conjuntos de requisitos: los datos que deben ser públicos permanecen accesibles, mientras que los datos personales se gestionan mediante las técnicas criptográficas que hemos descrito.

El factor humano: cultura de privacidad

La implementación del borrado criptográfico requiere cambios culturales profundos. Los desarrolladores deben internalizar la minimización de datos como reflejo automático. Los gestores de negocio deben aceptar que el «guardar por si acaso» no es un activo sino un pasivo. Los equipos jurídicos deben aprender suficiente criptografía para distinguir soluciones genuinas del teatro de cumplimiento. Y la dirección debe entender que la privacidad es ventaja competitiva, no coste. Las empresas que lideran esta adopción suelen tener un DPO que comprende tanto tecnología como normativa y que influye en las decisiones de diseño desde el primer día. Como dijo una directiva de una fintech holandesa: «El momento de pensar en la privacidad no es cuando recibes la primera solicitud de supresión. Es cuando estás dibujando el primer diagrama de arquitectura en una pizarra».

Hacia una síntesis: privacidad y transparencia como complementos

A lo largo de este artículo hemos explorado un conflicto que, a primera vista, parecía irresoluble: la inmutabilidad de la blockchain frente al derecho de supresión del RGPD. Hemos visto cómo el borrado criptográfico ofrece una solución elegante al destruir la llave de una caja fuerte indestructible. Hemos analizado cómo la gestión jerárquica de claves, la compartición de Shamir y el cifrado multicapa proporcionan las herramientas técnicas para implementar esa solución de forma robusta. Hemos examinado cómo las políticas inteligentes automatizan el cumplimiento, cómo la pista de auditoría inmutable documenta cada paso, y cómo los distintos derechos del interesado pueden ejercerse en un entorno blockchain. Hemos recorrido escenarios reales —hospitales, fintechs, cadenas de suministro, sistemas de voto, aseguradoras— donde estas técnicas se aplican a problemas concretos. Y hemos revisado el marco legal y regulatorio que sustenta todo el edificio.

Pero hay una reflexión final que trasciende la técnica y la norma. Durante demasiado tiempo, el debate sobre blockchain y privacidad se ha planteado como una elección binaria: o inmutabilidad o derecho al olvido; o transparencia o privacidad; o descentralización o cumplimiento. Esta dicotomía es falsa. La criptografía moderna demuestra que la privacidad y la transparencia no solo son compatibles, sino que se refuerzan mutuamente. Un sistema que puede demostrar criptográficamente que ha borrado un dato (transparencia del proceso) mientras hace inaccesible el contenido de ese dato (privacidad del individuo) ofrece más garantías que cualquiera de las dos propiedades por separado.

La inmutabilidad de la blockchain, lejos de ser un obstáculo para la privacidad, puede ser su mejor garantía: un registro inalterable de que los derechos del interesado se han respetado, de que las políticas de privacidad se han aplicado, de que cada acceso y cada supresión han quedado documentados de forma irrefutable. El conflicto entre RGPD y blockchain no se resuelve sacrificando una de las partes, sino encontrando la capa de ingeniería que permite que ambas coexistan y se complementen.

«La privacidad y la transparencia no son los polos opuestos de un dilema irreconciliable. Son las dos caras de la misma moneda: el derecho de las personas a controlar su información y el derecho de la sociedad a verificar que ese control se respeta. La criptografía no elige un bando; construye el puente que permite cruzar de un lado a otro sin renunciar a ninguno de los dos.»

Para saber más: referencias y lecturas recomendadas

1. Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (Reglamento General de Protección de Datos). Diario Oficial de la Unión Europea, L 119, 4 de mayo de 2016. Texto completo disponible en EUR-Lex.
2. CNIL (2018). Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data. Commission Nationale de l'Informatique et des Libertés. Septiembre de 2018. El informe de referencia de la autoridad francesa sobre la intersección entre blockchain y protección de datos.
3. Parlamento Europeo (2019). Blockchain and the General Data Protection Regulation: Can distributed ledgers be squared with European data protection law? Servicio de Estudios del Parlamento Europeo (EPRS). Estudio exhaustivo que identifica las dos tensiones fundamentales entre blockchain y RGPD: la dificultad de asignar un responsable del tratamiento en redes descentralizadas y la incompatibilidad entre inmutabilidad y derecho de supresión.
4. Finck, M. (2018). «Blockchains and Data Protection in the European Union». European Data Protection Law Review, 4(1), pp. 17-35. Análisis jurídico seminal sobre las tensiones entre la inmutabilidad de blockchain y los derechos de los interesados bajo el RGPD.
5. ICO (Information Commissioner’s Office, Reino Unido). Guía sobre cifrado y protección de datos, que incluye orientaciones sobre el uso de cifrado como medida de seguridad bajo el UK GDPR y considera el borrado criptográfico en el contexto del derecho de supresión (artículo 17).
6. Shamir, A. (1979). «How to Share a Secret». Communications of the ACM, 22(11), pp. 612-613. El artículo fundacional que describe el esquema de compartición de secretos basado en interpolación polinomial que sustenta la gestión distribuida de claves.
7. ENISA (2019). Distributed Ledger Technology & Cybersecurity: Improving information security in the financial sector. Agencia de la Unión Europea para la Ciberseguridad. Informe técnico que analiza los beneficios y desafíos de seguridad de las tecnologías de registro distribuido, incluyendo la gestión de claves criptográficas y la compatibilidad con el marco regulatorio europeo de protección de datos.
8. Tribunal de Justicia de la Unión Europea. Sentencia de 13 de mayo de 2014, asunto C-131/12, Google Spain SL y Google Inc. contra Agencia Española de Protección de Datos (AEPD) y Mario Costeja González. La sentencia que estableció el «derecho al olvido» en el Derecho europeo.
9. EDPB (Comité Europeo de Protección de Datos). Directrices 4/2019 sobre la protección de datos desde el diseño y por defecto (artículo 25 del RGPD). Orientaciones sobre cómo integrar la privacidad en el diseño de sistemas, aplicables a arquitecturas basadas en blockchain.
10. Politou, E.; Casino, F.; Alepis, E.; Patsakis, C. (2019). «Blockchain Mutability: Challenges and Proposed Solutions». IEEE Transactions on Emerging Topics in Computing. Revisión sistemática de las técnicas para introducir mutabilidad controlada en blockchain, evaluando su viabilidad técnica y su compatibilidad con el RGPD.