technology

Registro central vs datos descentralizados: qué almacena la UE

El registro DPP de la ESPR debe existir antes del 19 de julio de 2026: qué almacena, por qué los datos siguen descentralizados y cómo difieren las capas.

10/6/2026 · 9 min de lectura · InfoDPP

Estado en junio de 2026: El registro DPP de la UE debe establecerse antes del 19 de julio de 2026 en virtud del artículo 13 de la ESPR. El reglamento fija el plazo y el contenido mínimo (identificadores únicos y soportes de datos), pero los campos de datos exactos, una posible API pública y el proceso de incorporación todavía los está precisando la Comisión. Este artículo explica la arquitectura confirmada, no detalles técnicos internos no publicados, y se ampliará a medida que se publiquen los actos de ejecución y las especificaciones.

La versión en dos minutos

La UE no está construyendo una única base de datos gigante que almacene cada Pasaporte Digital de Producto. En virtud del artículo 13 de la ESPR, la Comisión Europea debe establecer un registro antes del 19 de julio de 2026, pero ese registro es un índice, no un almacén. Registra los identificadores únicos y los soportes de datos necesarios para encontrar un pasaporte. Los datos de producto en sí permanecen descentralizados, en manos del operador económico (el fabricante o el importador) o de un proveedor de servicios DPP que actúa en su nombre.

Esta distinción importa, porque el modelo mental equivocado lleva a decisiones equivocadas. Si supone una base de datos central, planea subirlo todo a Bruselas. Si entiende el modelo real, planea mantener el control de sus propios datos estructurados y conectarlos al registro mediante identificadores. El segundo modelo es el que el reglamento describe realmente.

Qué es el registro y qué no es

El artículo 13 de la ESPR da al registro una tarea estrecha y concreta. La Comisión debe almacenar, como mínimo, los identificadores únicos (definidos en el artículo 12) y los soportes de datos (artículo 10) que permiten localizar un pasaporte y vincularlo a su producto. La primera versión se pone en marcha para el pasaporte de baterías, añadiéndose una cobertura de producto más amplia de forma gradual.

Qué no es el registro:

No es una base de datos pública de todo el contenido de los pasaportes.
No es donde los consumidores leen la información del producto; ese papel corresponde al soporte de datos y, cuando existe, al portal web.
No es su almacenamiento de datos. Sus registros de producto estructurados permanecen con usted o con su proveedor.
No es un sustituto del pasaporte en sí. El pasaporte vive detrás del soporte de datos, no dentro del registro.

La lectura prudente hoy es que el registro cubre al menos identificadores y soportes, y cualquier alcance adicional se definirá más adelante mediante actos de ejecución y especificaciones técnicas.

Cuatro capas que la gente confunde

La mayor parte de la confusión viene de fundir cuatro cosas distintas en una sola palabra. La ESPR las mantiene separadas, y su arquitectura también debería hacerlo.

Capa	Base en la ESPR	Qué contiene	Quién la opera
Soporte de datos	Artículo 10	El enlace escaneable, como un código QR, en el producto, el envase o la documentación	Usted, el operador económico
El pasaporte (datos de producto)	Artículo 9	Los verdaderos datos de producto estructurados, mantenidos de forma descentralizada	Usted o su proveedor de servicios DPP
El registro	Artículo 13	Un índice de identificadores únicos y soportes de datos	La Comisión Europea
El portal web	Artículo 14	Un punto de acceso público para buscar y comparar datos DPP	La Comisión Europea

Un quinto elemento, el sistema DPP (artículo 11), es el conjunto de reglas de diseño técnico y funcionamiento que hacen interoperables estas capas. Rige cómo funciona el pasaporte, no dónde residen físicamente los datos.

Por qué los datos de producto siguen descentralizados

El modelo descentralizado es una elección de diseño deliberada, no un accidente del calendario. El operador económico sigue siendo responsable del producto y de su pasaporte, así que mantiene el control de los datos subyacentes. El registro se conecta a esos datos mediante identificadores; no los absorbe.

Las aportaciones de la industria a la Comisión se inclinaron claramente por este modelo. Grandes fabricantes e iniciativas de espacios de datos argumentaron que una base de contenido central crearía un punto único de fallo, riesgo de dependencia y problemas de confidencialidad. La recomendación constante fue que los proveedores externos actúen como una capa de interoperabilidad y alojamiento, mientras el operador conserva la propiedad y el control de los datos.

Para las empresas, la lección práctica es sencilla: construya registros de producto estructurados, exportables y basados en normas que usted controle, y conéctelos al registro mediante identificadores abiertos. Eso le mantiene portable entre proveedores y alineado con cómo funciona realmente el reglamento.

La copia de seguridad: continuidad sin centralización

La descentralización plantea una pregunta legítima: ¿qué pasa si un proveedor desaparece? La ESPR responde con una obligación de copia de seguridad. Una copia del pasaporte debe permanecer disponible a través de un tercero independiente, para que los datos sobrevivan si el operador económico original deja de existir o un proveedor cae.

Esto es continuidad, no centralización. La copia de seguridad es una red de seguridad para las autoridades y la cadena de valor, liberada bajo condiciones definidas como insolvencia o cese, no un espejo abierto de todos los datos del pasaporte. Las reglas detalladas para proveedores de servicios y copias de seguridad se esperan en un acto delegado específico, cuya adopción está prevista para finales de 2026.

Cómo codifican las normas esta arquitectura

Las normas DPP horizontales de CEN/CENELEC JTC 24, publicadas como normas EN en mayo de 2026, se corresponden casi directamente con las capas anteriores. Definen el marco, no los campos de datos de ningún sector concreto.

Norma	Alcance	Papel arquitectónico
EN 18219	Identificadores únicos	Cómo se identifican un producto, un operador y un pasaporte
EN 18220	Soportes de datos	Cómo un soporte apunta al pasaporte correcto
EN 18221	Almacenamiento, archivo y persistencia de datos	Cómo los datos descentralizados siguen disponibles con el tiempo
EN 18222	API para ciclo de vida y búsqueda	Cómo los sistemas crean, actualizan y encuentran registros
EN 18223	Interoperabilidad de sistemas	Cómo sistemas distintos entienden los mismos datos
EN 18216	Protocolos de intercambio de datos	Cómo se transmiten los datos entre las partes

Actualización editorial, 16 de julio de 2026: las referencias de estas seis normas se publicaron en el Diario Oficial el 15 de julio de 2026 mediante la Decisión de Ejecución (UE) 2026/1736. Un DPP conforme con una norma se beneficia de una presunción de conformidad con los artículos 10 y 11 del ESPR solo en la medida cubierta por esa norma. Qué cambia con la Decisión 2026/1736 →

La publicación como norma EN fue el primer hito; la publicación de las referencias en el Diario Oficial dio a estas seis normas el efecto previsto en el artículo 41, apartado 2, del ESPR. Otras dos normas, sobre derechos de acceso y autenticación de datos, siguen fuera del paquete publicado por la Decisión 2026/1736.

El proyecto de reglamento de ejecución del registro

La Comisión ha publicado un proyecto de reglamento de ejecución que establece las disposiciones de aplicación del registro en virtud del artículo 13 (referencia Ares(2026)4424976). Su periodo de aportaciones públicas se desarrolló del 29 de abril al 27 de mayo de 2026 y ya está cerrado, con 222 contribuciones recibidas. A junio de 2026 el acto todavía no está adoptado y no ha aparecido en el Diario Oficial, por lo que los puntos siguientes proceden del proyecto y pueden cambiar antes de la adopción.

El proyecto es el primer texto que describe una mecánica concreta del registro, y varios puntos importan para saber cómo se conectarán las empresas:

Operadores económicos verificados. Crear o modificar una entrada del registro queda restringido a operadores cuya identidad se haya verificado en el nivel de seguridad eIDAS «alto», por ejemplo mediante sellos electrónicos cualificados o atestaciones cualificadas de atributos por medios electrónicos.
Ciclo de reverificación. El estado de verificado no es permanente. Caduca tras un máximo de tres años, de modo que los operadores tienen que reverificarse periódicamente.
Comprobaciones automatizadas de conformidad. El registro ejecuta comprobaciones semánticas automatizadas antes de aceptar una entrada, en lugar de almacenar datos arbitrarios.
Descentralizado por diseño. En coherencia con la arquitectura anterior, el registro guarda identificadores, registros de verificación y registros de auditoría, mientras que el contenido del pasaporte permanece con el operador.

Estas reglas refuerzan el consejo práctico de este artículo: conserve la propiedad de datos estructurados y exportables, use identificadores abiertos y planifique un paso de verificación de identidad, y su renovación, para el momento en que la conexión con el registro pase a ser obligatoria.

Quién lee realmente el registro

El registro está construido para la verificación, no para la navegación de los consumidores. Las autoridades aduaneras y de vigilancia del mercado son los usuarios principales: necesitan una forma fiable de confirmar que un producto que entra o circula en la UE tiene un pasaporte válido, y de llegar a los datos correctos mediante sus identificadores.

Por eso el registro se conecta con la infraestructura de aplicación y no con un escaparate de marketing. Los consumidores llegan a la información del producto escaneando el soporte de datos; las autoridades usan el registro y los identificadores que hay detrás. Mantener separados estos públicos es parte del diseño.

Qué queda por precisar

Un texto explicativo honesto debe marcar los límites de lo confirmado. A junio de 2026, lo siguiente todavía no está fijado públicamente en detalle:

Los campos de datos exactos que el registro almacenará más allá de identificadores y soportes.
Si habrá una API pública, un entorno beta o un proceso de incorporación completo el 19 de julio de 2026. El plazo del artículo 13 es una fecha legal de establecimiento, no la promesa de una interfaz pública terminada.
El alcance y el calendario del portal web en virtud del artículo 14.
Los requisitos finales y un posible esquema de certificación para proveedores de servicios DPP, esperados en un acto delegado más adelante en 2026.

Ampliaremos este artículo a medida que se publiquen esos actos y especificaciones. La arquitectura anterior es estable; los detalles técnicos internos todavía no son públicos.

Qué hacer ahora

Conserve la propiedad de sus datos: almacene registros de producto estructurados que pueda exportar, no datos encerrados en un solo proveedor.
Use identificadores abiertos: un identificador al estilo de GS1 Digital Link mantiene su soporte portable y listo para el registro.
Separe las capas en sus propios sistemas: soporte, datos del pasaporte, identificadores y derechos de acceso son cuestiones distintas.
Haga al proveedor la pregunta correcta: no “¿almacena mis datos?”, sino “¿puedo exportarlos y cambiar sin romper mis códigos QR?”.
Planifique la copia de seguridad y la continuidad: entienda cómo gestiona su proveedor la copia de seguridad obligatoria y las condiciones de liberación de datos.
Siga los actos de ejecución: el detalle del registro, el portal web y las reglas para proveedores llegarán en actos posteriores.

FAQ

¿Es el registro DPP de la UE una base de datos central de todos los datos de producto?

No. En virtud del artículo 13 de la ESPR, el registro almacena al menos los identificadores únicos y los soportes de datos necesarios para localizar un pasaporte. Los datos de producto en sí permanecen descentralizados en el operador económico o su proveedor de servicios DPP. El registro es un índice, no un almacén.

¿Qué ocurre realmente el 19 de julio de 2026?

Es el plazo legal para que la Comisión establezca el registro, con una primera versión orientada al pasaporte de baterías. La fecha fija el establecimiento, no la garantía de que ese día haya una API pública completa, una beta o un proceso de incorporación.

¿Dónde residen los verdaderos datos del pasaporte?

En el operador económico o un proveedor de servicios DPP que actúa en su nombre. El soporte de datos del producto apunta a ese registro descentralizado. La ESPR también exige una copia de seguridad a través de un tercero independiente para la continuidad.

¿Cuál es la diferencia entre el registro y el portal web?

El registro (artículo 13) es un índice de identificadores y soportes, usado sobre todo por las autoridades. El portal web (artículo 14) es un punto de acceso público para buscar y comparar datos DPP. Son elementos separados con finalidades separadas.

¿Los datos descentralizados significan que dependo de un solo proveedor?

Debería significar lo contrario. Si conserva registros estructurados y exportables y usa identificadores abiertos como GS1 Digital Link, puede cambiar de proveedor sin reemitir sus soportes de datos. La dependencia viene de los formatos propietarios, no del registro.

¿Subo mis pasaportes a la Comisión?

Usted registra los identificadores y soportes necesarios para conectar con su pasaporte, no todo el contenido de cada pasaporte. La mecánica de registro precisa se fijará en actos de ejecución y especificaciones técnicas.

Sigue leyendo

Fuentes oficiales

¿Construye registros DPP que de verdad le pertenecen? Empiece gratis en OriginPass.eu y conserve la propiedad de sus datos de producto estructurados, listos para el registro y portables por diseño.

Seguir leyendo

Guías relacionadas