Blockchain no es eIDAS: por qué una plataforma DPP sin QTSP tiene un problema legal, no técnico

En 2026, decenas de plataformas tecnológicas generan pasaportes digitales de producto (DPP) estructuralmente conformes con los requisitos de datos del Reglamento (UE) 2024/1781 (ESPR). Algunas de ellas se basan en arquitecturas de blockchain y presentan la inmutabilidad de la cadena de bloques como si fuera equivalente (o incluso superior) a un servicio de confianza cualificado bajo el marco eIDAS. 

Esa equivalencia es un error de categoría. Blockchain y eIDAS resuelven problemas distintos. Confundirlos deja a los operadores económicos con un problema legal, no técnico, en el momento en que su DPP se cuestione ante una autoridad de vigilancia del mercado, una autoridad aduanera o una contraparte comercial. 

Este artículo no pretende desacreditar ninguna plataforma ni ninguna tecnología. Blockchain es una herramienta legítima y útil dentro de una arquitectura de datos de DPP. Pero no es un sustituto de los servicios de confianza cualificados que el ordenamiento europeo reconoce con presunción legal. El mensaje es simple: ellos generan el contenido; un QTSP aporta la capa de confianza que falta. Juntos, el DPP está completo. 

Si necesitas contexto sobre el Registro DPP y su entrada en vigor, te recomendamos empezar por ahí. 

🔐 DPP · Capa de confianza ¿Tu plataforma DPP genera los datos pero todavía no incorpora servicios de confianza cualificados? EADTrust puede integrar sello cualificado, sello de tiempo y conservación electrónica sobre tu arquitectura actual sin sustituir la tecnología de la plataforma. →

¿Qué exige realmente el artículo 11 del ESPR sobre el pasaporte digital de producto? 

El artículo 11 del Reglamento (UE) 2024/1781 establece los requisitos esenciales de diseño técnico y funcionamiento del pasaporte digital del producto. Entre ellos, las letras g) y h) son las más relevantes para este análisis: 

• «g) se garantizarán la autenticación, la fiabilidad y la integridad de los datos.» 
• «h) los pasaportes digitales de productos se diseñarán y funcionarán de manera que se garantice un elevado nivel de seguridad y privacidad y se evite el fraude.» 

Estos no son requisitos genéricos de buena práctica técnica. Son requisitos esenciales de diseño legalmente exigidos. Su incumplimiento significa que un DPP puede ser estructuralmente correcto (los campos de datos exigidos están presentes y son conformes con el modelo semántico) pero jurídicamente deficiente: no se puede acreditar, con la garantía legal que el reglamento exige, quién introdujo esos datos, cuándo, y si han sido alterados. 

La pregunta que cada operador económico debe hacerse es: ¿mi DPP cumple la letra g) del artículo 11 (autenticación, fiabilidad e integridad de los datos) con una garantía que sea reconocida por el ordenamiento europeo como tal? 

¿Qué es exactamente la trazabilidad técnica que ofrece blockchain? 

Blockchain ofrece tres propiedades criptográficas reales y verificables: 

• Inmutabilidad técnica. Un hash registrado en una cadena de bloques no puede alterarse sin que la alteración sea detectable por cualquier nodo de la red. Si alguien modifica el dato subyacente, el hash deja de coincidir. 
• Descentralización. La cadena no depende de una autoridad central para su funcionamiento: múltiples nodos mantienen copias coherentes del registro, lo que reduce el riesgo de un punto único de fallo. 
• Trazabilidad de la cadena de transacciones. Cada operación queda registrada con una marca temporal del bloque y una referencia al estado anterior, lo que permite reconstruir la secuencia completa de modificaciones. 

Estas propiedades son reales. Blockchain es una herramienta legítima y útil dentro de una arquitectura de datos de un DPP. El problema no es lo que blockchain hace. El problema es lo que algunos interlocutores asumen que blockchain también hace, cuando en realidad no puede. 

¿Qué es lo que blockchain, por su propia naturaleza, no puede ofrecer? 

Tres límites estructurales que no son defectos de implementación, sino consecuencias de la propia naturaleza de la tecnología: 

1. No genera una presunción legal de integridad reconocida por el derecho de la Unión.

Un hash en una cadena de bloques prueba que un dato existía en un momento dado y no ha sido alterado dentro de esa cadena. Pero esa prueba técnica no constituye, por sí sola, la presunción de integridad y autenticidad del origen que el ordenamiento europeo reconoce expresamente a los servicios de confianza cualificados. Una presunción legal invierte la carga de la prueba: quien la cuestiona debe demostrar que es falsa. Un hash en blockchain no goza de esa inversión de carga por el mero hecho de existir. 

2. No constituye un servicio de confianza cualificado en el sentido del Reglamento eIDAS.

Un servicio de confianza cualificado no es una tecnología: es un estatus jurídico. Requiere que el prestador haya sido evaluado por un organismo de evaluación de la conformidad acreditado, supervisado por la autoridad nacional competente del Estado miembro, e incluido en una Lista de Confianza (Trusted List) con reconocimiento transfronterizo automático en toda la UE. Una cadena de bloques,por sofisticada que sea, no reúne estas condiciones porque no es un prestador, sino una infraestructura técnica. 

3. No identifica jurídicamente al operador económico responsable de los datos.

Blockchain identifica direcciones o claves criptográficas. Eso no es lo mismo que identificar a la persona física o jurídica con capacidad de representación legal cuya identidad debe poder verificarse conforme al derecho de la Unión. Un sello electrónico cualificado identifica de forma inequívoca a su creador mediante un certificado cualificado emitido por un QTSP que ha verificado previamente la identidad del titular conforme a procedimientos supervisados. Una dirección de blockchain no ofrece esa garantía. 

Esta es exactamente la diferencia entre trazabilidad técnica (demostrar que algo no ha cambiado desde que se registró) y valor probatorio cualificado (demostrar, con presunción legal reconocida y supervisión regulatoria, quién generó el dato y cuándo).

¿Qué añaden los efectos jurídicos de un sello o firma electrónicos cualificados que blockchain no aporta? 

El Reglamento eIDAS reconoce expresamente los siguientes efectos jurídicos a los servicios de confianza cualificados: 

Sello electrónico cualificado (arts. 35-38 eIDAS): no puede ver denegada su eficacia jurídica ni su admisibilidad como prueba por el mero hecho de tener formato electrónico. Goza de la presunción de integridad de los datos y de exactitud del origen que indica. Se basa en un certificado cualificado, vinculado unívocamente a su creador (la persona jurídica identificada), y creado mediante un dispositivo cualificado de creación de sellos. 

Sello de tiempo cualificado (arts. 41-42 eIDAS): goza de la presunción de exactitud de la fecha y hora que indica y de la integridad de los datos a los que se vincula. Debe vincular la fecha y hora a los datos de manera que se excluya razonablemente la posibilidad de modificación indetectable. 

Estas presunciones legales nacen de un lugar muy concreto: la supervisión regulatoria del prestador por parte de una autoridad nacional competente, su auditoría periódica por un organismo de evaluación de la conformidad acreditado, y su inclusión en una Lista de Confianza de la UE con reconocimiento transfronterizo automático en todos los Estados miembros. 

Ninguna cadena de bloques, por sí sola, puede replicar estas presunciones. No porque sea técnicamente inferior, sino porque la presunción legal no nace de la arquitectura técnica del dato: nace de la supervisión regulatoria del prestador que lo garantiza. Son planos distintos. 

¿Por qué esto no es una cuestión de preferencia tecnológica sino de encaje legal? 

Pongamos un ejemplo concreto. Una autoridad de vigilancia del mercado cuestiona un DPP y solicita al operador económico que acredite quién introdujo un dato concreto sobre la composición del producto y si ese dato permanece intacto desde su introducción. 

Con blockchain: el operador puede responder «este dato no ha cambiado desde que se registró en este bloque de la cadena, con este hash, en esta fecha del bloque». Es una prueba técnica de inmutabilidad, legítima y útil, pero no una presunción legal reconocida por el ordenamiento europeo. 

Con un sello electrónico cualificado: el operador puede responder «esta persona jurídica, identificada mediante un certificado cualificado emitido por un QTSP supervisado e incluido en la Trusted List, selló estos datos en esta fecha y hora acreditadas por un sello de tiempo cualificado con presunción legal de exactitud». La carga de la prueba se invierte: quien cuestione la integridad o el origen debe probar la falsedad. 

El artículo 15 del ESPR ya anticipa esta lógica: aclara expresamente que el despacho aduanero a libre práctica (que se basa en la comprobación automática del identificador y el código de mercancía contra el registro) «no se considerará una prueba del cumplimiento del presente Reglamento«. La responsabilidad de acreditar la autenticidad, fiabilidad e integridad de los datos del DPP (art. 11) sigue recayendo en el operador económico. Y esa responsabilidad exige herramientas con reconocimiento legal, no solo con robustez técnica. 

Blockchain + eIDAS: por qué no son alternativas sino capas complementarias 

Nada impide, y en muchos diseños resulta razonable, combinar ambas capas: 

• Capa de trazabilidad técnica (blockchain): ofrece inmutabilidad, descentralización y trazabilidad de la cadena de transacciones. Es la infraestructura de datos. 
• Capa de confianza jurídica (servicios cualificados eIDAS): ofrece presunción legal de integridad y origen, identificación jurídica del operador económico, sello de tiempo con fecha cierta, y supervisión regulatoria del prestador. Es la capa de garantía legal. 

Cuando el ESPR exige en su artículo 2.32 un «tercero independiente» que trate los datos del DPP con las garantías del artículo 11, esa función de garante solo puede ser desempeñada, con reconocimiento legal pleno, por un prestador cualificado de servicios de confianza (QTSP). Una plataforma blockchain, por sofisticada que sea, no sustituye esa función porque no es (ni pretende ser) un QTSP supervisado. 

El modelo que funciona es el de complementariedad: 

• La plataforma genera el contenido del DPP (datos de producto, estructura semántica, interfaz de acceso). 
• Un QTSP garantiza la autenticidad, integridad y disponibilidad de esos datos (sello cualificado, sello de tiempo, archivo electrónico cualificado). 
• Juntos, ofrecen un DPP que es estructuralmente conforme Y jurídicamente robusto. 

La integración técnica es directa: la plataforma envía el documento o dataset al QTSP mediante API, el QTSP aplica el sello electrónico cualificado y, opcionalmente, deposita el documento sellado en un servicio de archivo electrónico cualificado para custodia a largo plazo. No hay que cambiar de tecnología: hay que añadir una capa. 

Qué debería preguntarse un operador económico antes de confiar en una plataforma DPP 

Antes de asumir que tu plataforma DPP cumple los requisitos del artículo 11 del ESPR, pregunta: 

• ¿Cómo se identifica al operador económico? ¿Mediante un servicio de confianza cualificado conforme a eIDAS (sello electrónico cualificado basado en certificado cualificado emitido por un QTSP) o solo mediante una clave o dirección criptográfica sin respaldo regulatorio? 
• ¿El sello o marca de tiempo aplicado a los datos está respaldado por un certificado cualificado? ¿El prestador que lo emite está incluido en una Lista de Confianza de la UE y supervisado por una autoridad nacional competente? 
• ¿La plataforma puede demostrar supervisión regulatoria de su capa de confianza? Ante una autoridad de vigilancia del mercado, ¿puede acreditar que la garantía de integridad y autenticidad de los datos proviene de un servicio de confianza cualificado, o solo de una arquitectura técnica? 
• ¿En caso de disputa, qué puede aportar la plataforma? ¿Una presunción legal de integridad y origen (con inversión de carga de la prueba) o únicamente una prueba técnica de inmutabilidad (sin presunción legal)? 
• ¿La arquitectura permite incorporar una capa de confianza cualificada sin rediseño? ¿Es posible integrar un QTSP mediante API para añadir sello cualificado, sello de tiempo y archivo sin cambiar la plataforma subyacente? 

Preguntas frecuentes 

EADTrust: la capa de confianza cualificada para cualquier plataforma DPP 

EADTrust es un prestador cualificado de servicios de confianza (QTSP) incluido en la EU Trusted List, supervisado por el Ministerio de Asuntos Económicos y Transformación Digital de España. 

EADTrust no compite con las plataformas generadoras de DPP. Las complementa, aportando la capa de confianza jurídica cualificada que el artículo 11 del ESPR exige: 

• Sello electrónico cualificado (QSealC). Identifica jurídicamente al operador económico y garantiza la autenticación e integridad de los datos del DPP con presunción legal reconocida en toda la UE. 
• Sello de tiempo cualificado. Fija con presunción legal la fecha y hora de cada operación sobre los datos del DPP (introducción, modificación, actualización). 
• Archivo electrónico cualificado (Cartulario). Garantiza la disponibilidad e integridad del DPP a largo plazo, conforme al artículo 45 decies del Reglamento eIDAS 2.0, incluso tras insolvencia o cese de actividad del operador. 

Esta capa de confianza puede integrarse en la arquitectura de datos de cualquier plataforma DPP, incluidas las basadas en blockchain, sin necesidad de sustituir su tecnología. La integración es mediante API y es transparente para el usuario final de la plataforma.