CEN y CENELEC publican las primeras normas de la UE para el Pasaporte Digital de Producto

EN 18216 a EN 18223: CEN y CENELEC sientan las bases técnicas del Pasaporte Digital de Producto conforme a ESPR y al Reglamento sobre baterías. Qué regulan concretamente las normas.

por QR3 Redaktion

CEN y CENELEC publican las primeras normas de la UE para el Pasaporte Digital de Producto

El pistoletazo de salida para la tecnología armonizada de DPP

El 27 de mayo de 2026, CEN y CENELEC publicaron las primeras normas europeas armonizadas para el Pasaporte Digital de Producto (DPP): la serie de normas EN 18216:2026 a EN 18223:2026. No se trata de un acontecimiento rutinario. Hasta ahora, aunque existían marcos políticos —ante todo el Reglamento de diseño ecológico ESPR y el Reglamento sobre baterías (UE) 2023/1542—, no había una especificación técnica vinculante sobre cómo debía estructurarse, direccionarse y consultarse concretamente un DPP. Las nuevas normas colman esta laguna.

El 25 de junio de 2026, CEN y CENELEC celebraron un webinario público para explicar las normas y responder a las preguntas de la industria. La respuesta fue muy positiva, lo que demuestra la presión a la que están sometidos fabricantes, importadores y proveedores de software.

Qué regulan las normas EN 18216–18223

Identificadores inequívocos y soportes de datos

El núcleo de la serie de normas se centra en tres ámbitos: identificadores inequívocos de productos, soportes de datos (es decir, códigos QR, RFID, DataMatrix y similares), así como API para el acceso automatizado a los datos. Las normas se han concebido deliberadamente de forma independiente del producto. No se aplican únicamente a las baterías, sino que establecen la base técnica para todas las futuras obligaciones de DPP en virtud de ESPR, desde los textiles y la electrónica hasta los materiales de construcción.

En concreto, la serie de normas establece cómo debe identificarse inequívocamente un producto durante todo su ciclo de vida. Para ello, se basa en estándares consolidados: el GS1 Digital Link está previsto como formato preferente para vincular el producto físico con el registro de datos digital. Esto significa que un código QR colocado en el producto no tiene que ser una URL estática, sino una dirección estructurada y legible por máquinas, a través de la cual los servicios de resolución puedan proporcionar distintos puntos de datos, según el solicitante y el contexto.

Interfaces API e interoperabilidad

Uno de los objetivos centrales de las normas es la interoperabilidad: las autoridades, las empresas de reciclaje, los consumidores y los proveedores deben poder consultar el mismo DPP mediante interfaces estandarizadas, independientemente de la plataforma que aloje el pasaporte. Para ello, las normas definen perfiles de API basados en REST. Los fabricantes y los proveedores de plataformas de DPP deben garantizar que sus sistemas implementen correctamente estas interfaces.

Para los desarrolladores, esto significa concretamente que la API debe admitir determinados puntos de acceso y formatos de respuesta. Un ejemplo simplificado de una consulta conforme de DPP podría ser el siguiente:

GET /dpp/v1/passport/{digitalLinkId}
Accept: application/json
Authorization: Bearer <token>

La respuesta debe proporcionar metadatos estructurados sobre el producto, incluidas referencias a documentos, certificados y, en el caso de las baterías, datos dinámicos sobre su estado.

El Reglamento sobre baterías como pionero: datos estáticos y dinámicos

El Reglamento sobre baterías (UE) 2023/1542, que entró en vigor en agosto de 2023, es el primer caso de aplicación concreto para el DPP. Implícitamente, distingue entre dos categorías de datos:

Los datos estáticos quedan establecidos en el momento de la introducción en el mercado: composición química, fabricante, capacidad nominal y huella de CO₂ de la producción. Estos valores no cambian y pueden registrarse una sola vez.

Los datos dinámicos, en cambio, deben poder actualizarse durante todo el ciclo de vida. Entre ellos se encuentran, en particular, el State of Health (SoH) y el State of Charge (SoC); ambos indicadores varían con cada ciclo de carga y descarga. El Reglamento establece expresamente que estos puntos de datos deben actualizarse. Esto plantea a fabricantes y operadores un reto de arquitectura de sistemas: el DPP no puede ser un PDF estático, sino que debe estar conectado a fuentes de datos activas.

Las nuevas normas de CEN/CENELEC abordan precisamente este requisito al definir perfiles de API que permiten tanto el acceso de lectura como el de escritura, con la autorización correspondiente.

Nuevas herramientas: entorno de pruebas y validación de código abierto

Paralelamente a la publicación de las normas, en la práctica también se han producido avances importantes.

Entorno de pruebas BatteryPass-Ready

El 24 de junio de 2026, el consorcio BatteryPass-Ready puso en marcha un entorno público de pruebas para el Pasaporte Digital de Baterías. Los fabricantes y proveedores de software pueden comprobar allí sus implementaciones con datos de prueba reales antes de que entren en vigor los plazos legales. El entorno cuenta con la participación del Fraunhofer IPK y está disponible sin necesidad de registrarse.

Digital Passport Assessment Workbench (DP-AWB)

En julio de 2026, unos investigadores publicaron la Digital Passport Assessment Workbench (DP-AWB) como herramienta de código abierto. La herramienta calcula resultados de evaluación deterministas directamente a partir de especificaciones de modelos SHACL y permite validar formalmente las estructuras de datos de DPP. Esto es relevante para todos aquellos que deben garantizar que sus conjuntos de datos no solo sean correctos en cuanto al contenido, sino también conformes con las normas desde el punto de vista estructural.

SHACL (Shapes Constraint Language) es un estándar del W3C para validar grafos RDF. En el contexto de DPP, esto significa que quienes modelen sus datos de producto como Linked Data pueden utilizar DP-AWB para comprobar automáticamente si están presentes todos los campos obligatorios y si están correctamente tipificados, sin listas de comprobación manuales.

La cuestión pendiente: el registro de DPP a escala de la UE

Las normas y las herramientas no resuelven un problema: ¿cómo se encuentra un DPP cuando solo se tiene delante un producto físico? La Comisión Europea trabaja en un registro central a través del cual deberán registrarse y poder localizarse todos los DPPs. Sin embargo, el diablo está en los detalles.

Orgalim, la asociación industrial europea de empresas tecnológicas, ha formulado requisitos claros al respecto: el registro debe admitir procesos de registro automatizados de gran volumen. Si se tiene en cuenta que solo en la UE se comercializan anualmente miles de millones de productos, se entiende el problema. Un registro que requiera entradas manuales o falle en los picos de carga no sirve para aplicaciones industriales.

Orgalim también exige que el registro esté protegido frente a interrupciones operativas: la alta disponibilidad no es una opción, sino un requisito. Porque si un funcionario de aduanas o una empresa de reciclaje no puede consultar un DPP porque el registro está fuera de servicio, toda la cadena de cumplimiento normativo se desmorona.

Hasta ahora, la Comisión no ha publicado un calendario vinculante para la puesta en marcha del registro. Esta es una de las mayores incertidumbres pendientes del ecosistema de DPP.

Qué deberían hacer ahora las empresas

La publicación de las normas EN 18216–18223 supone un punto de inflexión: los requisitos técnicos ya están definidos, aunque el registro todavía no exista. Las empresas sujetas al Reglamento sobre baterías o que se estén preparando para futuros actos delegados de ESPR deberían priorizar tres pasos:

  1. Adquirir y leer las normas. Las normas EN 18216–18223 están disponibles a través de los organismos nacionales de normalización (DIN en Alemania). La lectura de las especificaciones de API es obligatoria para todos aquellos que desarrollen o adquieran sistemas propios de DPP.

  2. Revisar la arquitectura de datos. ¿Pueden sus sistemas proporcionar puntos de datos dinámicos (SoH, SoC, historial de reparaciones) mediante una API? Si no es así, este es el momento adecuado para tomar una decisión arquitectónica, no seis meses antes de la fecha límite legal.

  3. Utilizar los entornos de pruebas. El entorno BatteryPass-Ready y DP-AWB están disponibles gratuitamente. Quienes prueben su implementación con antelación evitarán costosas mejoras posteriores bajo presión de tiempo.

Las normas ya están publicadas. El reloj sigue corriendo.

Fuentes