DPP: Mantener los datos actualizados: lo que realmente exige la ESPR

Desde la aprobación de la ESPR-Reglamento (UE) 2024/1781, el Pasaporte Digital de Producto (DPP) forma parte del Derecho vinculante de la UE. Lo que muchas empresas subestiman: el DPP no es un documento estático que se genera una sola vez al introducir el producto en el mercado. Debe mantenerse actualizado durante todo el ciclo de vida del producto, y los requisitos al respecto son cada vez más precisos.

Este artículo explica qué datos deben actualizarse y cuándo, cómo la arquitectura del registro influye en el modelo de actualización y qué patrones técnicos han demostrado su eficacia en la práctica.

Qué dice el Reglamento sobre el ciclo de actualización

Campos de datos estáticos frente a dinámicos

La propia ESPR no establece una frecuencia de actualización explícita, pero dispone que el DPP debe contener «información actualizada y exacta». La concreción se realiza a nivel sectorial, y aquí el proyecto del JRC para productos semiacabados de hierro y acero ofrece hasta ahora la imagen más clara.

El proyecto distingue sistemáticamente entre dos granularidades de datos:

Nivel	Identificador	Datos de ejemplo	Motivo de actualización
Nivel de lote (Lot)	Número de lote	Contenido reciclado, composición de la aleación, PCF según ISO 14067	Cambio en la producción, nuevo lote
Nivel de producto (Item)	Número de serie	Dimensiones, certificaciones, declaraciones de conformidad	Recertificación, retirada, reparación

Esta distinción es decisiva para la arquitectura de la base de datos: los datos de lote suelen escribirse una vez por ciclo de producción y permanecen estables después, salvo que un nuevo cálculo de la huella de CO₂ dé como resultado un valor corregido. En cambio, los datos del nivel de producto pueden cambiar durante toda la vida útil, por ejemplo, cuando se repara un dispositivo o se renueva una certificación.

El Reglamento sobre baterías (UE) 2023/1542 ya contempla implícitamente esta distinción: los datos de capacidad, que cambian debido a la degradación, deben mantenerse actualizados, un requisito difícil de cumplir sin una arquitectura clara.

El registro como directorio, no como almacén de datos

Un malentendido frecuente se refiere al papel del DPP-registro central. El proyecto de Reglamento de Ejecución relativo al registro DPP deja claro que el registro almacena exclusivamente el identificador único, el punto final del resolvedor y el código de mercancía, no los datos propiamente dichos del pasaporte.

Esto implica para la gestión de actualizaciones lo siguiente: el contenido del pasaporte y el registro son sistemas separados. Quien actualiza los datos del producto normalmente no tiene que modificar el registro, salvo que cambie el punto final del resolvedor, por ejemplo, al cambiar de sistema. El consorcio CIRPASS-2 señaló explícitamente este patrón arquitectónico en su declaración sobre el proyecto de registro y recomienda incluir la norma EN 18219 como referencia vinculante en el Reglamento de Ejecución, entre otras razones, para garantizar la interoperabilidad con GS1 Digital Link.

Escenarios de actualización en la práctica

Escenario 1: Nueva huella de CO₂ por cambio de proveedor

La huella de carbono específica del producto (PCF) se gestiona a nivel de lote según el proyecto del JRC sobre el acero y debe calcularse con métodos compatibles con ISO 14067. Si un productor de acero cambia su fuente de energía o su proveedor de chatarra, cambia el PCF del nuevo lote, pero no el de los lotes ya entregados.

Técnicamente, esto significa que el registro de DPP del lote antiguo permanece sin cambios. Para el nuevo lote se crea un registro nuevo que puede utilizar el mismo punto final del resolvedor, pero lleva un número de lote nuevo como identificador.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Escenario 2: Certificación caducada a nivel de producto

Las declaraciones de conformidad y las certificaciones tienen fechas de caducidad. En cuanto se emite una nueva certificación, debe actualizarse el DPP a nivel de producto. Como el punto final del resolvedor permanece sin cambios, no es necesario actualizar el registro; solo cambia el registro situado detrás del punto final.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Escenario 3: Migración del resolvedor al cambiar de sistema

Si una empresa cambia de proveedor de su servicio DPP, cambia el punto final del resolvedor. En este caso, debe actualizarse el registro para cada identificador afectado. Es el tipo de actualización más laborioso, porque requiere una escritura en el registro.

Recomendación: utilice un resolvedor propio y estable (p. ej., dpp.ihrunternehmen.de) como capa intermedia que redirija internamente al proveedor correspondiente. Así, el punto final registrado permanece estable de forma permanente.

Requisitos técnicos del sistema de actualización

Control de versiones y registro de auditoría

La ESPR no exige un control de versiones explícito, pero la combinación de responsabilidad por productos y controles aduaneros hace que un registro de auditoría sea, de hecho, imprescindible. Si en 2030 un agente de aduanas comprueba el DPP de una viga de acero producida en 2027, debe poder determinarse qué datos eran válidos en el momento de la importación.

Esquema mínimo para una tabla DPP con control de versiones:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link como ancla estable del identificador

El GS1 Digital Link separa claramente el identificador del resolvedor: el código QR del producto codifica una URL como https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, que, a través del resolvedor GS1 o de un resolvedor propio, apunta al registro actual de DPP. Las actualizaciones del registro no requieren un nuevo etiquetado: el soporte físico permanece sin cambios.

TEKLYNX ha actualizado su software CODESOFT y ahora admite esquemas de codificación GS1 «++», con los que se pueden escribir URL web directamente en la memoria de etiquetas RAIN-RFID, un requisito derivado de la combinación de EN 18220 y el estándar GS1 Digital Link.

Gobernanza: ¿quién puede actualizar qué?

Además de la cuestión técnica, se plantea la cuestión de la gobernanza: ¿qué actores de la cadena de suministro pueden escribir qué campos del DPP? El consorcio CIRPASS-2 ha identificado aquí puntos críticos relacionados con la soberanía de los datos en las cadenas de suministro transfronterizas.

Un modelo práctico distingue tres roles:

Fabricante (Creator): Escribe todos los campos al crearlos y puede actualizar todos los campos.
Actor autorizado (Editor): Puede actualizar determinados campos (p. ej., historial de reparaciones, nuevas certificaciones), documentándolo con su propio identificador.
Lector (Reader): Puede leer todos los campos públicos, pero no tiene permisos de escritura.

Ecommerce Europe exigió en su documento de posición sobre la implementación de DPP que también fueran posibles «DPPs parciales» para los productos de segunda mano, es decir, registros que actualizan solo una parte de los campos originales. Esto ya puede implementarse técnicamente, pero todavía falta como categoría formal en los Reglamentos de Ejecución.

Conclusión

Mantener actualizados los datos de DPP no es una tarea puntual, sino un proceso operativo. Estas son las principales conclusiones del estado actual de la regulación:

Separe el lote y el producto: la estrategia de identificadores determina qué datos deben actualizarse y cuándo.
El registro no es un almacén de datos: las actualizaciones del contenido del pasaporte normalmente no requieren una escritura en el registro.
El control de versiones es, de hecho, obligatorio: aunque el Reglamento no lo exija explícitamente.
GS1 Digital Link desacopla el soporte físico del registro: esto reduce considerablemente el esfuerzo necesario para actualizar los datos.
Los roles de gobernanza deben definirse de antemano: ¿quién puede escribir qué y cómo se registra?

Las normas son cada vez más precisas y los primeros proyectos piloto ya están en marcha. Quien establezca ahora la arquitectura correctamente evitará costosas correcciones cuando entren en vigor los Reglamentos de Ejecución específicos de cada sector.