La Comisión Europea puso en funcionamiento el 20 de julio de 2026 el registro de pasaportes digitales de producto junto con el entorno de pruebas. Así, una ESPR abstracta se ha convertido en un sistema que las empresas pueden probar realmente. Para los fabricantes, ahora es especialmente importante distinguir lo siguiente: el registro es el índice central; el pasaporte de producto sigue siendo descentralizado.
Qué entró en funcionamiento el 20 de julio
El registro admite identificadores de producto inequívocos, datos de registro y determinados metadatos. La información completa del producto sigue estando en manos del operador económico responsable o de un proveedor de servicios DPP contratado. Por eso, la Comisión describe expresamente el registro como un servicio de indexación y no como un sistema central de gestión de contenidos.
Está previsto realizar los registros mediante una interfaz de usuario segura y una API. Además, las empresas pueden generar un comprobante electrónico de registro. Esto es relevante para los procesos B2B, ya que permite a proveedores y clientes demostrar que un pasaporte se ha inscrito en el sistema de la UE sin duplicar todo el conjunto de datos.
El inicio no afecta únicamente a los grupos de productos ESPR. La Comisión también menciona baterías, productos de construcción, juguetes, detergentes y tensioactivos destinados al usuario final, siempre que el Derecho de la Unión aplicable exija un pasaporte digital de producto. El primer plazo vinculante sigue siendo el 18 de febrero de 2027 para determinadas baterías.
Registro, resolver y fuente de datos son tres capas diferentes
Un sistema DPP sólido debería separar claramente las funciones:
- El registro de la UE confirma que se han registrado un identificador y los metadatos prescritos.
- Un resolver dirige el identificador de producto persistente al recurso adecuado.
- La fuente de datos propiamente dicha proporciona contenidos actualizados para personas y máquinas.
Esta separación no es un detalle. Quien almacena todos los datos exclusivamente en su propia página de producto aún no cuenta con una integración del registro. Y quien, a la inversa, solo registra un identificador todavía no ofrece un pasaporte de producto utilizable. Ambos elementos deben estar conectados mediante identificadores estables.
Para la resolución resulta adecuado un enlace abierto y duradero. Un resolver de enlace digital puede permitir acceder a distintas representaciones desde el mismo identificador: una página web comprensible, JSON-LD legible por máquinas o documentación complementaria. El soporte de datos del producto o del envase permanece estable, aunque los sistemas de destino sigan evolucionando.
Qué deberían comprobar las empresas en el entorno de pruebas
El entorno de pruebas no está pensado únicamente para hacer clic manualmente. Debe tratarse como una fase previa a la integración en producción.
Organización y funciones
Primero hay que aclarar qué entidad jurídica realiza el registro, quién la representa en el sistema y qué equipos pueden crear o modificar registros. Esto afecta a los datos maestros, el cumplimiento normativo, TI y, en su caso, los proveedores de servicios externos. Un acceso personal de prueba no sustituye a un modelo de funciones para la explotación posterior.
Identificadores y granularidad
El equipo de producto debería comprobar si el futuro pasaporte se gestionará a nivel de modelo, lote o unidad. La respuesta depende de la normativa sectorial aplicable. La prueba del registro es el momento adecuado para establecer la correspondencia entre los identificadores internos de producto, los GTINs, los identificadores de lote y el identificador persistente utilizado externamente.
API y repetibilidad
Un proceso productivo necesita más que un POST correcto. El registro, la actualización y la gestión de errores deben poder repetirse y quedar registrados. Esto incluye solicitudes idempotentes, acuses de recibo técnicos y una asignación clara entre el registro del ERP, DPP y la entrada del registro. Un proceso de DPP basado en API reduce las divergencias manuales cuando se dan de alta productos en grandes cantidades.
Separación de metadatos y datos técnicos
Los datos del registro no deberían convertirse en un segundo inventario de datos de producto. Defina qué campos son obligatorios en el registro y cuáles permanecen en el pasaporte descentralizado. Cada información necesita una fuente principal, una entidad responsable y una regla de actualización.
Comprobante y supervisión
Los comprobantes de registro deberían almacenarse junto con la marca de tiempo, el identificador utilizado y la respuesta del sistema. Además, se necesita una comprobación cruzada: ¿existe el pasaporte, está disponible el resolver y siguen coincidiendo los metadatos del registro y el estado del producto?
Por qué las aduanas necesitan una cadena de comprobación propia
El registro ayuda a las autoridades aduaneras a comprobar automáticamente, antes del despacho a libre práctica, si existen un DPP registrado válido y el código de mercancía requerido. Esto crea una nueva dependencia para los importadores: el identificador de producto, la entrada del registro y la declaración aduanera deben ser coherentes.
Por tanto, un error no solo se hará visible en una página de producto. También puede afectar al proceso fronterizo. Ya durante las pruebas, las empresas deberían simular los flujos de datos desde el alta del producto hasta la documentación de importación y determinar quién puede corregir rápidamente un registro defectuoso.
Un plan de pruebas razonable de 30 días
- Seleccionar una entidad jurídica real y una gama de productos pequeña y representativa.
- Documentar para cada producto la granularidad prevista de DPP y los identificadores principales.
- Realizar un ciclo completo mediante la interfaz de usuario y, cuando sea relevante, la API.
- Archivar conjuntamente el comprobante de registro, la respuesta del resolver y los datos de producto legibles por máquinas.
- Probar casos de error: identificador duplicado, metadatos obsoletos, host de datos inaccesible y producto retirado.
- A partir de los resultados, establecer un modelo operativo con responsabilidades, supervisión y vías de escalado.
El inicio operativo del registro no significa que todos los requisitos de datos específicos de cada sector ya sean plenamente aplicables. Sin embargo, desplaza el debate de las presentaciones a los procesos verificables. Ahora las empresas pueden comprobar si sus identificadores, funciones y API encajan antes de que lleguen los primeros plazos obligatorios.
