Por qué "registrar una vez" no es suficiente
Muchas empresas tratan el Pasaporte Digital de Producto (DPP) como un ejercicio de cumplimiento puntual: recopilan los datos, crean una entrada en el registro y listo. El Reglamento ESPR (UE) 2024/1781 cuenta una historia diferente. Exige que las entradas del registro permanezcan disponibles y actualizadas durante al menos 10 años después de la última vez que un producto se introduce en el mercado. Si descatalogas un modelo hoy, debes mantener su entrada hasta al menos 2036 — incluidos los endpoints del resolver válidos y los identificadores únicos correctos.
Este artículo explica qué implica realmente actualizar una entrada del registro, qué campos se ven afectados y cómo asegurar el proceso desde el punto de vista técnico.
Qué almacena el registro — y qué no
El 29 de abril de 2026, la Comisión Europea publicó el borrador del reglamento de ejecución para el registro central de DPP. El documento deja claro lo ligero que está diseñado para ser el registro central: almacena únicamente tres elementos de datos por entrada:
| Campo | Descripción | Obligación de actualización |
|---|---|---|
| Identificador único (UID) | Identificador único del producto/modelo | Inmutable una vez asignado |
| Endpoint del resolver | URL donde se puede recuperar el DPP completo | Actualizable; obligatorio en caso de migración |
| Código de mercancía | Código de categoría de producto (p. ej., código HS o CN) | Corregible en caso de entrada errónea |
Los datos reales del producto — composición de materiales, índice de reparabilidad, huella de carbono — no se almacenan en el registro central. Los proporciona el fabricante o un fiduciario de datos autorizado en el endpoint del resolver. El registro es simplemente la libreta de direcciones. Esta separación importa desde el punto de vista arquitectónico: una actualización de la entrada central solo es necesaria cuando cambian el UID, el resolver o el código de mercancía. El mantenimiento de los datos a nivel de contenido ocurre exclusivamente del lado del proveedor de datos.
Los requisitos de datos específicos del producto — qué debe aparecer exactamente en el DPP — siguen siendo competencia de la normativa sectorial, como los reglamentos delegados en virtud de la ESPR o, para las baterías, el Reglamento sobre baterías (UE) 2023/1542.
Cuándo es obligatoria una actualización del registro
El endpoint del resolver ha cambiado
Este es el escenario más común en la práctica. Las empresas cambian de proveedor de nube, migran a nuevas plataformas de DPP o consolidan dominios. En cuanto el endpoint del resolver anterior deja de ser accesible, ningún escáner — ya sea una autoridad aduanera, un organismo de vigilancia del mercado o un consumidor final — puede recuperar el DPP. El reglamento no especifica explícitamente un plazo de respuesta, pero la obligación de disponibilidad de 10 años crea, en la práctica, tolerancia cero ante enlaces rotos de forma permanente.
Recomendación: Utiliza un resolver en un subdominio estable y propiedad de la empresa (p. ej., dpp.tuempresa.com) como capa de indirección. De este modo, cuando cambies de plataforma, solo necesitas reconfigurar internamente — sin tocar la entrada del registro. Esto sigue el principio del GS1 Digital Link, donde el código QR apunta a un resolver estable que, a su vez, redirige a sistemas backend cambiantes.
Se introdujo un código de mercancía incorrecto
Los códigos de mercancía (códigos CN o HS) determinan qué reglamentos delegados se aplican a un producto. Un código incorrecto puede provocar que el producto se clasifique en la categoría equivocada, o que se clasifique erróneamente durante los controles fronterizos automatizados — que la UE planea introducir a partir de 2028 con la propuesta de Ley de Economía Circular. Las correcciones están permitidas según el borrador del reglamento de ejecución, pero requieren una justificación documentada.
Adquisición corporativa o transferencia de licencia
Cuando un producto cambia de propiedad económica, debes evaluar si también se está transfiriendo la responsabilidad del resolver. La cuenta del registro está vinculada al registrante original; una transferencia requiere un proceso formal a través de la autoridad nacional competente.
Proceso técnico: actualizar una entrada
El reglamento de ejecución prevé una interfaz basada en API para el registro. El endpoint exacto solo se publicará una vez que el reglamento entre en vigor, pero el flujo de trabajo previsto puede deducirse del borrador:
# Authentication via OAuth 2.0 Client Credentials
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X POST https://registry.dpp.ec.europa.eu/oauth/token \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_SECRET" \
-d "scope=registry:write"
# PATCH request to update the resolver endpoint
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X PATCH https://registry.dpp.ec.europa.eu/v1/entries/{uid} \
-H "Authorization: Bearer {ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/{uid}",
"updateReason": "platform_migration"
}'
El campo updateReason está designado como obligatorio en el borrador para todos los cambios distintos de la entrada inicial. Los valores permitidos incluyen platform_migration, domain_change, commodity_code_correction y ownership_transfer. El historial de auditoría de todas las actualizaciones lo conserva el registro durante todo el período de 10 años.
Actualizaciones masivas para grandes carteras de productos
Las empresas con miles de SKU no pueden gestionar solicitudes individuales manualmente. El borrador del reglamento prevé un endpoint por lotes:
{
"batchUpdate": [
{
"uid": "urn:epc:id:sgtin:0614141.107346.2017",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2017",
"updateReason": "platform_migration"
},
{
"uid": "urn:epc:id:sgtin:0614141.107346.2018",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2018",
"updateReason": "platform_migration"
}
]
}
Construir y mantener estos procesos masivos requiere una gestión de datos estructurada, como la que exige un flujo de trabajo de importación masiva para entradas de DPP.
La estandarización internacional como ancla de estabilidad
Un proceso de actualización es tan robusto como los estándares sobre los que se construye. Aquí es donde entra en juego la creación de ISO/IEC JTC 5: el nuevo Comité Técnico Conjunto, cuya secretaría ostenta el Instituto Alemán de Normalización (DIN), tiene la tarea de desarrollar estándares internacionales para la interoperabilidad global de los sistemas de DPP.
En términos prácticos para los procesos de actualización: una vez que ISO/IEC JTC 5 adopte estándares para formatos de datos, esquemas de API y estructuras de identificadores, se espera que estos se incorporen a futuras revisiones de los reglamentos de ejecución de la ESPR. Las empresas que ya se apoyan en identificadores conformes con GS1 (GTIN, SGTIN) y en resolvers de GS1 Digital Link están bien posicionadas: estos estándares se consideran la implementación de referencia para el JTC 5.
La notificación a la OMC del reglamento del registro de la UE (G/TBT/N/EU/1211) del 21 de mayo de 2026 también indica que el sistema se clasifica como un reglamento técnico de comercio — con implicaciones para los fabricantes de terceros países que exportan productos a la UE. Ellos también deben mantener y conservar actualizadas las entradas del registro.
El mantenimiento de datos como proceso continuo: implicaciones organizativas
La obligación de 10 años no es únicamente una tarea de TI. Requiere medidas organizativas:
- Documentar las responsabilidades: ¿Quién en tu organización es responsable de las entradas del registro? Este rol debe permanecer cubierto incluso a través de la rotación de personal y de las reestructuraciones corporativas.
- Configurar la monitorización del resolver: Las comprobaciones automatizadas de disponibilidad (comprobaciones de estado HTTP) de todos los endpoints de resolver activos no son un extra deseable — son un mínimo operativo.
- Mantener un registro de cambios: El historial de auditoría del registro es accesible para las autoridades. Complétalo con un registro de cambios interno que incluya justificaciones y aprobaciones.
- Revisar los contratos con los proveedores de plataformas: Si utilizas un proveedor de servicios de DPP externo, el contrato debe cubrir explícitamente el requisito de disponibilidad de 10 años — incluidas las disposiciones para casos de insolvencia o cierre del negocio del proveedor.
El 27 de mayo de 2026, la Comisión Europea celebró un seminario web sobre la implementación del DPP de baterías que abordó explícitamente los retos de mantenimiento de datos a los que se enfrentan las pymes. El mensaje fue claro: la disponibilidad de datos a largo plazo no es un detalle técnico — es una obligación fundamental.
Conclusión
Una entrada del registro de DPP no es un documento estático. El reglamento de ejecución de abril de 2026 establece un marco jurídico que exige a los fabricantes mantener sus datos de forma activa y documentada a lo largo de una década. La buena noticia: el registro central se mantiene deliberadamente ligero. Si diseñas los endpoints de resolver pensando en la estabilidad, utilizas identificadores conformes con GS1 e integras los procesos de cambio en tu organización, la carga técnica de las actualizaciones sigue siendo manejable — y estarás bien preparado para los próximos estándares de ISO/IEC JTC 5.
