De la EN 18216 a la 18223: las seis normas CEN que definen un pasaporte digital del producto conforme
Durante tres años, todas las conversaciones sobre el pasaporte digital del producto (DPP) han chocado con la misma pregunta: ¿cómo es realmente un sistema DPP conforme? El ESPR (UE 2024/1781) es la autoridad jurídica. CIRPASS-2 esbozó la arquitectura. GS1 Digital Link nos dio la sintaxis de las URL. Pero faltaban las normas técnicas normativas propiamente dichas, aquellas a las que una marca puede remitirse y decir «construya conforme a esto».
Esa laguna ya se ha cerrado. El Comité Técnico Conjunto 24 (JTC 24) del CEN/CENELEC ha publicado seis normas europeas normativas que cubren la arquitectura técnica de un pasaporte digital del producto. En conjunto definen cómo funcionan los identificadores, cómo se transportan los datos, cómo se comporta la API, cómo se intercambian y archivan los datos y cómo interoperan los sistemas.
Las seis normas publicadas son:
- EN 18216: protocolos de intercambio de datos
- EN 18219: identificadores únicos
- EN 18220: soportes de datos
- EN 18221: almacenamiento y persistencia de datos
- EN 18222: API para el ciclo de vida y la búsqueda de pasaportes de productos
- EN 18223: interoperabilidad de sistemas
Otras dos, la EN 18239 (derechos de acceso y seguridad) y la EN 18246 (autenticación e integridad de los datos), siguen en preparación como proyectos prEN y las citan con carácter normativo la 18221, la 18222 y la 18223. Se esperan a continuación. Actualización, octubre de 2026: ambas fueron aprobadas por el CEN el 17 de agosto de 2026 y ya están publicadas; véase las ocho normas DPP están publicadas, solo seis están citadas.
Este artículo repasa lo que exige realmente cada una de las seis normas publicadas, por qué las marcas deberían ajustar ya sus sistemas DPP a ellas y cómo se relacionan las normas con el calendario de actos delegados del ESPR para los textiles.
Por qué estas normas importan para el cumplimiento del ESPR
El artículo 9 del ESPR exige pasaportes digitales de productos para los productos introducidos en el mercado de la UE en los grupos de productos regulados por actos delegados. Los artículos 10 y 11 enumeran los requisitos esenciales: los pasaportes deben estar vinculados a un identificador único persistente y ser legibles por máquina, accesibles, seguros e interoperables.
Sin embargo, esos artículos no especifican cómo cumplir los requisitos a nivel técnico. Eso es lo que hacen estas normas CEN. El anexo ZA de cada norma relaciona sus apartados con los requisitos del ESPR que cubre y, una vez que la Comisión cita una norma en el Diario Oficial, seguirla confiere presunción de conformidad (artículo 41 del ESPR): un sistema ajustado a la EN 18216 se presume conforme con el requisito de intercambio de datos del ESPR, un sistema que usa identificadores EN 18219 se presume conforme con el requisito de unicidad, y así sucesivamente. Actualización, octubre de 2026: las seis se citaron el 15 de julio de 2026 mediante la Decisión de Ejecución (UE) 2026/1736.
En términos prácticos: si no puede demostrar que se ajusta a estas normas, su evaluación de la conformidad con arreglo al ESPR se convierte en una argumentación a medida, caso por caso. Si puede, se convierte en una casilla que marcar.
EN 18216: protocolos de intercambio de datos
Es la norma de la capa de transporte. Define cómo se solicita, transmite y presenta un recurso DPP.
Sección 4, transporte: el intercambio de datos DPP debe usar HTTPS con TLS 1.2 como mínimo (se recomienda encarecidamente TLS 1.3) y HTTP/2 como mínimo, con HTTP/3 recomendado. Las API deberían seguir el estilo RESTful. Los protocolos más antiguos (TLS 1.1, SSL) están prohibidos.
Sección 5, formatos y negociación de contenido: debe admitirse JSON (según la ISO/IEC 21778) como base de interoperabilidad sintáctica. Pueden ofrecerse además XML, JSON-LD y HTML, y el formato servido se selecciona mediante negociación de contenido HTTP (según el RFC 9110, el patrón estándar de la cabecera Accept).
Este último requisito es el que no cumplen la mayoría de las implementaciones DPP actuales. La misma URL debe devolver HTML presentado (para un consumidor que escanea un código QR) o JSON / JSON-LD legible por máquina (para la herramienta de un reciclador, la integración de un mercado en línea o un verificador), según la cabecera Accept que envíe el cliente. Un recurso, varias representaciones.
Cuando se devuelve HTML, este debe cumplir la EN 301549 (la norma de accesibilidad de la UE). Una página DPP solo en HTML no es conforme con la EN 18216, aunque todo lo demás en ella sea correcto.
EN 18219: identificadores únicos
Es la norma sobre el esquema de identificadores y la más prescriptiva de las seis.
Sección 4.1, unicidad global: sin reasignación, distinto de cualquier otro identificador, sin coexistencia con otro ID para la misma instancia de producto.
Sección 4.2, persistencia: el identificador debe sobrevivir a la insolvencia o la liquidación del operador. Una nota añade que el registro DPP de la UE garantiza un nivel mínimo de conservación de los identificadores; mantener disponible el propio pasaporte es una obligación distinta del ESPR, que se cumple mediante una copia de seguridad en un prestador de servicios de pasaporte digital de productos (artículo 10, apartado 4, del ESPR).
Sección 4.3, sintaxis: juego de caracteres según la ISO/IEC 646; la forma URI debe seguir el RFC 3986; el identificador debe ser una URL o poder convertirse en una URL.
Sección 4.4, granularidad: cada identificador debe ser único en la granularidad más fina a la que sirve (modelo, lote o número de serie a nivel de artículo). La granularidad debe mantenerse coherente una vez el producto está en el mercado. Si la granularidad cambia (por ejemplo, una marca que pasa de DPP a nivel de lote a DPP a nivel de artículo), debe emitirse un nuevo identificador y vincularse al anterior a efectos de trazabilidad.
Sección 4.6, apertura: la información pública del DPP debe poder consultarse sin registro, sin descargar una aplicación y sin credenciales. No se permite la dependencia de un proveedor.
Esquema de ID 1, ID de ruta estructurada habilitado para la web (la vía GS1): la vía dominante en la práctica. Exige que el identificador cumpla la GS1 Digital Link URI Syntax v1.6.0:2022, aplique los identificadores de aplicación GS1 según la ISO/IEC 15418, siga la resolución de ruta estructurada de la ISO/IEC 18975 y use un código de agencia emisora registrado conforme a la ISO/IEC 15459-2 (un GS1 Global Company Prefix real, no un marcador de posición).
Una URL GS1 Digital Link conforme tiene este aspecto: /01/{GTIN}/22/{CPV}/10/{batch}/21/{serial}. Los segmentos de la ruta codifican automáticamente la granularidad: /01/{GTIN} solo es nivel de modelo, añadir /10/{batch} lo convierte en nivel de lote y añadir /21/{serial} lo convierte en nivel de artículo.
Sección 6, identificadores de operador económico y de instalación: deben usar uno de los esquemas ISO/IEC 6523 (LEI, GS1 GCP, PEPPOL), ISO/IEC 15418/15459, DID o DOI. Los nombres de fabricante en texto libre en la cabecera de un DPP no son conformes.
EN 18220: soportes de datos
Esta norma define el medio físico o visual por el que el identificador del DPP llega a un escáner o lector. En la práctica: códigos QR, códigos Data Matrix, etiquetas RFID, etiquetas NFC.
La EN 18220 exige que el soporte codifique el identificador único de producto (según la EN 18219) que da acceso al DPP, que pueda leerse con las cámaras de smartphone ampliamente disponibles y con lectores industriales estándar, y que cumpla requisitos de durabilidad adecuados al ciclo de vida del producto.
Para la mayoría de las categorías orientadas al consumidor (textiles, calzado, muebles), un código QR que codifica la URL GS1 Digital Link es el soporte de facto. La EN 18220 confirma que es aceptable, pero fija requisitos de durabilidad y contraste. Las marcas que usan etiquetas colgantes de papel deben asegurarse de que el soporte sobrevive al menos hasta que se vende el producto; las que usan etiquetas cosidas deben garantizar que pueda escanearse durante toda la vida útil prevista del producto.
EN 18221: almacenamiento, archivo y persistencia de datos
Aquí es donde la mayoría de las implementaciones DPP existentes tienen su mayor carencia.
Sección 4.2, archivo desde el primer cambio: todo cambio en un DPP debe archivarse desde el momento en que se produce, y el historial de versiones debe conservarse durante toda la vida útil del DPP. El DPP no es un único registro modificable; es un objeto versionado con historial completo.
Secciones 4.3 y 4.5, prestador de servicios DPP de copia de seguridad: cuando un producto se introduce en el mercado, puede exigirse que se ponga a disposición una copia de seguridad a través de un prestador de servicios; la redacción de la norma es condicional, y si se aplica o no lo determinan las normas propias del producto. Cuando se aplica, la copia de seguridad contiene la versión actual y todas las versiones históricas exigidas, y el acceso general al pasaporte en la copia de seguridad se abre una vez que el operador económico deja de estar activo en el mercado. Eso es lo que da al identificador la persistencia exigida (EN 18219 §4.2.2, que exige que el identificador sobreviva a la insolvencia, la liquidación o el cese de actividad).
La duración no es una cifra en esta norma. La EN 18221 define la vida útil del pasaporte digital del producto como el periodo durante el cual la normativa exige que el pasaporte esté disponible, y todos los requisitos de duración remiten a ella, así que los años proceden del acto delegado del ESPR para la categoría, no de la norma. Sí fija un requisito sobre el patrón de acceso: la versión tal como estaba en un momento dado debe poder recuperarse por agentes autenticados y autorizados, de modo que el archivo pueda consultarse y no sea un registro de solo escritura.
Un sistema DPP que solo almacena el último estado de cada pasaporte no es conforme. Las marcas tienen que diseñar para el almacenamiento versionado desde el primer día: añadir tablas de historial de versiones y puntos de lectura que tengan en cuenta las versiones es mucho más fácil en un sistema nuevo que adaptar uno que lleva dos años en producción.
EN 18222: API para el ciclo de vida y la búsqueda de pasaportes de productos
Es la norma de la API. Define la interfaz mínima que todo sistema DPP debe exponer.
La EN 18222 impone tres métodos de lectura que todo sistema DPP conforme debe exponer como puntos de acceso normalizados:
- ReadDPPById: obtiene un DPP por su identificador único (la URI Digital Link completa o el ID canónico).
- ReadDPPByProductId: obtiene el DPP vigente de un identificador de producto (normalmente el GTIN) y devuelve el pasaporte más reciente.
- ReadDPPIdsByProductIds: consulta masiva; a partir de una lista de identificadores de producto, devuelve los ID de DPP correspondientes. Así es como los mercados en línea, las autoridades aduaneras y los recicladores procesan catálogos de forma eficiente.
La norma también define métodos de ciclo de vida para crear, actualizar, archivar e inscribir DPP en el registro de la UE. Estos deben estar autenticados y sujetos a control de acceso (con la EN 18239 una vez publicada).
La mayoría de los sistemas DPP actuales solo exponen una interfaz CRUD genérica sobre su propio modelo de datos. La EN 18222 exige que los tres métodos de lectura existan como puntos de acceso normalizados: una herramienta construida para un sistema DPP conforme con la EN 18222 puede consultar otro sin cambiar el código. Esa es la base técnica de la integración de mercados en línea y recicladores a escala de la UE.
EN 18223: interoperabilidad de sistemas
Es la norma del esquema. Define la estructura canónica de la cabecera de un DPP, los metadatos que envuelven el contenido específico del producto, para que distintos sistemas DPP puedan intercambiar e interpretar los pasaportes de los demás.
Según la sección 4.1.2.1, la cabecera del DPP debe incluir:
- granularity: modelo, lote o artículo, declarado expresamente
- dppSchemaVersion: versión del esquema utilizado
- dppStatus: activo, retirado, sustituido, archivado
- lastUpdated: marca de tiempo del último cambio
- economicOperatorId: con el formato correcto según la ISO/IEC 6523 (LEI o GS1 GCP), no texto libre
- facilityId: el mismo requisito de formato
- dictionaryReference: para cada elemento de datos, una referencia al vocabulario controlado que define ese elemento
- contentSpecificationIds: referencias a las especificaciones de contenido de la categoría de producto (el esquema del acto delegado del ESPR, en los DPP textiles)
La EN 18223 es lo que hace real la interoperabilidad. Dos sistemas DPP ajustados a la misma especificación de contenido y que generan cabeceras conformes con la EN 18223 pueden intercambiar datos sin trabajo de integración a medida. Un reciclador puede construir una única herramienta que procese DPP textiles de cualquier marca.
Lo que aún falta: EN 18239 y EN 18246
Otras dos normas de la familia aún se están finalizando (actualización, octubre de 2026: ambas están ya publicadas, pero aún no citadas en el Diario Oficial):
- EN 18239: derechos de acceso y seguridad. Define cómo funcionan la autenticación, la autorización y el acceso basado en funciones para los datos del DPP. Las distintas partes interesadas (consumidor, taller de reparación, reciclador, autoridad aduanera, autoridad de vigilancia) necesitan distintos niveles de acceso al mismo DPP.
- EN 18246: autenticación e integridad de los datos. Define cómo puede verificarse criptográficamente que un DPP es auténtico y no se ha modificado. Probablemente use credenciales verificables o trabajos similares del W3C.
La EN 18221, la EN 18222 y la EN 18223 citan ambas con carácter normativo, así que las seis normas existentes tienen dependencias que aún no están totalmente publicadas. Las marcas que construyen hoy infraestructura DPP deberían diseñarla con capas de autenticación e integridad intercambiables, listas para incorporar la EN 18239 y la EN 18246 una vez finalizadas.
Cómo encaja esto con el calendario de actos delegados del ESPR
El reglamento marco ESPR (UE 2024/1781) entró en vigor el 18 de julio de 2024. El plan de trabajo de la Comisión para el ESPR (publicado en abril de 2025) confirma los actos delegados sucesivos que definen los requisitos específicos de cada grupo de productos. Para los textiles, el acto delegado se espera de forma indicativa en 2027, con requisitos aplicables al menos 18 meses después de su entrada en vigor, es decir, no antes de mediados de 2028.
Las normas CEN descritas aquí son horizontales: definen el sistema, no los campos de datos específicos de los textiles. El esquema de datos textiles procederá del acto delegado del ESPR y del trabajo sectorial de CIRPASS-2, y se conectará a la cabecera EN 18223 como referencia contentSpecificationIds.
Esta separación importa para la planificación. Una marca puede construir hoy conforme a las EN 18216 / 18219 / 18220 / 18221 / 18222 / 18223: la capa de sistema ya está totalmente especificada para las seis publicadas. La capa de campos textiles se añadirá encima cuando se publique el acto delegado, sin rediseñar el sistema.
Qué deberían hacer ya las marcas
Para las marcas que ya tienen DPP piloto en funcionamiento (con códigos QR y URL Digital Link), los pasos prácticos a corto plazo son:
- Audite su resolver conforme al §5 de la EN 18216. ¿Devuelve la misma URL JSON o JSON-LD cuando se llama con
Accept: application/json? Si no, añada la negociación de contenido. Suele ser la corrección más pequeña de la lista. - Suba granularity, dppSchemaVersion, dppStatus y lastUpdated a la cabecera del DPP. Según el §4.1.2.1 de la EN 18223, son obligatorios.
- Sustituya cualquier campo de fabricante en texto libre por un economicOperatorId con el formato correcto. Según el §6 de la EN 18219, debe ser un LEI, un GS1 GCP o equivalente. El texto libre no supera la evaluación de la conformidad.
- Planifique el diseño del archivo para la EN 18221. Si su tabla de DPP solo almacena el último estado, añada una tabla de versiones y puntos de lectura que tengan en cuenta las versiones. Es mucho más fácil añadirlo antes de tener cientos de miles de DPP en producción.
- Planifique los tres métodos de lectura obligatorios de la EN 18222. Si su API actual es un CRUD genérico sobre un modelo de fuente de datos, póngale delante alias REST ligeros que expongan
ReadDPPById,ReadDPPByProductIdyReadDPPIdsByProductIdscomo puntos de acceso normalizados.
Dónde obtener las normas
El CEN no vende normas directamente. Se distribuyen a través de los organismos nacionales de normalización. Vías de compra habituales para la serie EN 18216–18223:
- SIS (sis.se): el organismo nacional sueco. Compra por norma o suscripción a SIS. Útil si quiere la serie completa en sueco (SS EN) y en inglés.
- en-standard.eu: tienda privada, descarga inmediata en PDF.
- DIN (Alemania) / BSI (Reino Unido): las mismas normas EN, a veces con versiones en inglés más rápidas.
El coste habitual es de 50-200 € por norma. El conjunto completo de seis normas cuesta entre 300 y 1.000 €, según la vía. El estado de la serie completa puede seguirse en standards.cencenelec.eu.
Conclusión
La publicación de las EN 18216, 18219, 18220, 18221, 18222 y 18223 cierra la mayor ambigüedad técnica que ha pesado sobre el trabajo con el DPP en los últimos tres años. Las marcas ya no tienen que adivinar cómo es un sistema DPP conforme: las especificaciones son ahora normativas, pueden comprarse y, una vez citadas en el Diario Oficial, confieren presunción de conformidad con arreglo al artículo 41 del ESPR.
El periodo entre ahora y la exigencia del ESPR para los textiles (no antes de mediados de 2028) es el momento adecuado para auditar los pilotos existentes con las normas, cerrar las carencias en negociación de contenido, atributos de cabecera, diseño del archivo y métodos de lectura normalizados, y diseñar con puntos de conexión intercambiables para la EN 18239 y la EN 18246 cuando se finalicen.
Las marcas que construyan conforme a estas normas ahora tendrán presunción de conformidad cuando empiece la exigencia. Las que no, tendrán que presentar una argumentación a medida en cada evaluación de la conformidad.