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

La pregunta parece banal, pero no lo es: ¿con qué frecuencia debe actualizarse un pasaporte digital de producto? Quien busque una cifra concreta en el Reglamento de ESPR (UE) 2024/1781 se llevará una decepción. El texto solo establece que el DPP debe contener «información actualizada y precisa», sin frecuencia, sin SLA y sin especificación técnica. Lo que esto significa en la práctica depende en gran medida del tipo de producto, la cadena de suministro y los actos delegados que aún deben aprobarse para cada categoría de producto.

Este artículo explica qué categorías de datos pueden cambiar, qué patrones de actualización están demostrando su eficacia en las primeras implementaciones y dónde se encuentran los escollos regulatorios.

Qué puede cambiar realmente en un DPP

Un pasaporte de producto no es un PDF estático. Está compuesto por puntos de datos con ciclos de vida muy diferentes.

Datos estáticos frente a datos dinámicos

A grandes rasgos, los campos de DPP pueden dividirse en tres clases:

Categoría de datos	Frecuencia de cambio habitual	Ejemplos
Datos maestros	Una vez (al introducir el producto)	GTIN, composición de materiales, fabricante
Datos de lote/partida	Por ciclo de producción	Valor de PCF, origen de las materias primas, certificados
Datos del ciclo de vida	Activados por eventos	Historial de reparaciones, retirada, vía de eliminación

El borrador de datos del JRC para productos de acero deja especialmente clara esta diferencia: allí, la huella de carbono específica del producto (PCF) se registra explícitamente a nivel de lote y debe calcularse con métodos compatibles con ISO 14067. Esto significa que cada nuevo lote de producción puede tener un valor de PCF diferente; el pasaporte debe referenciar correctamente ese valor, no el promedio del año anterior.

El ejemplo de las baterías como modelo

El pasaporte digital de baterías, que será obligatorio a partir del 18 de febrero de 2027, muestra hasta qué punto pueden ser dinámicos los datos de DPP. Los informes del sector sobre la implementación del pasaporte digital de baterías identifican la fragmentación de datos y las actualizaciones de datos dinámicos como los dos problemas prácticos principales. Las baterías acumulan datos a lo largo de su vida útil: estado de salud (SoH), ciclos de carga y reparaciones. Utilizar aquí un conjunto de datos estático no cumple la normativa.

Patrones de actualización: cómo funcionan hoy las implementaciones

Actualizaciones activadas por eventos mediante webhook

El patrón más sólido en los primeros sistemas de DPP es la actualización activada por eventos: un sistema backend envía un webhook en cuanto cambia un punto de datos relevante, por ejemplo, cuando se emite un nuevo certificado de inspección o se completa una reparación.

// Beispiel: Webhook-Handler für DPP-Update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Importante: la ESPR exige implícitamente capacidad de mantener un registro de auditoría. Los cambios deben seguir siendo trazables; sobrescribir datos sin versionado supone un riesgo regulatorio.

Actualizaciones por lotes para la información de partidas

Cuando los valores de PCF o los certificados de lotes completos de producción se actualizan de una sola vez, resulta adecuado utilizar un procedimiento de importación masiva. En él se transmite una lista de números de pasaporte junto con el nuevo valor del campo:

# Beispiel: Bulk-PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Plataformas como qr3.app con importación masiva admiten este patrón, de modo que no es necesario actualizar cada lote manualmente.

GS1 Digital Link como capa de resolución

Un aspecto que suele subestimarse: el código QR del producto no puede cambiar; está impreso físicamente. Lo que debe cambiar es el contenido al que apunta. Precisamente ahí GS1 Digital Link proporciona la capa de abstracción decisiva. El código QR codifica una URI estable (p. ej., https://id.example.com/01/04012345678901/21/SN-00042), y el resolvedor redirige a la fuente de datos actualizada.

Driscoll's demostró en GS1 Connect 2026 cómo funciona este principio a gran escala: más de mil millones de envases tipo clamshell de berries recibieron identidades únicas y están migrando actualmente a códigos QR totalmente conformes con GS1 Digital Link. El código del envase permanece sin cambios; lo que cambia es el conjunto de datos situado detrás del resolvedor.

Las nuevas tecnologías, como la colaboración entre Polytag y DataLase, demuestran que los códigos QR conformes con GS1 ya pueden aplicarse incluso sobre sustratos de envase difíciles y a la velocidad de las líneas de producción; la barrera física disminuye, pero la lógica del resolvedor sigue siendo la misma.

Escollos regulatorios

La Directiva EmpCo como presión adicional

Quien crea que solo debe vigilar la ESPR subestima el panorama general. En junio de 2026, la Comisión Europea inició procedimientos de infracción contra 20 Estados miembros por la transposición deficiente de la Directiva EmpCo (UE) 2024/825. Esta directiva prohíbe el greenwashing y exige información clara sobre la durabilidad y la reparabilidad; información que debe incorporarse directamente al DPP. Por tanto, unos índices de reparabilidad obsoletos o unas etiquetas de sostenibilidad no válidas en el pasaporte pueden constituir no solo una infracción de ESPR, sino también una infracción de EmpCo.

No hay un plazo de actualización explícito, pero sí obligaciones implícitas

La ausencia de una frecuencia indicada en la ESPR no es carta blanca. Del texto «información actualizada y precisa» pueden derivarse varias obligaciones implícitas:

Actualización vinculada a eventos: en cuanto se produzca una retirada, una reparación o un cambio en un certificado, el pasaporte debe actualizarse, sin demora.
Actualización vinculada al lote: los valores de PCF y las pruebas del origen de las materias primas no deben transferirse de un lote antiguo a uno nuevo si los valores difieren.
Conformidad con la vigilancia del mercado: las autoridades deben poder consultar el pasaporte durante todo el ciclo de vida del producto. Un pasaporte que nunca vuelve a actualizarse después de la venta carece de valor para la información sobre reparaciones y eliminación.

Ecommerce Europe recomienda expresamente en su documento de posición una introducción por fases y una granularidad de datos flexible; esto implica indirectamente que los procesos de actualización pueden desarrollarse de forma iterativa, siempre que se cumplan los requisitos fundamentales.

Recomendaciones prácticas

Planificar el registro de auditoría desde el principio

Cada cambio en un conjunto de datos de DPP debería registrarse con fecha y hora, autor y motivo del cambio. Hoy esto no es una obligación explícita de ESPR, pero se espera en los actos delegados y resulta de facto necesario para la vigilancia del mercado.

Arquitectura del resolvedor antes que arquitectura de datos

Quien define primero la estructura de datos y después piensa cómo apuntará el código QR a ella está construyendo en el orden equivocado. El orden correcto es: definir la URI del resolvedor (GS1 Digital Link), después el esquema de datos y, por último, los procesos de actualización. El pasaporte digital de producto de qr3.app sigue este principio: el código QR es estable y el conjunto de datos que hay detrás está versionado y puede modificarse mediante parches.

Utilizar sistemáticamente los ID de lote

Quien gestione los valores de PCF o los certificados a nivel de producto en lugar de a nivel de lote se enfrentará a problemas como muy tarde en la primera inspección de vigilancia del mercado. El ID de lote debería estar establecido como campo obligatorio en cada conjunto de datos de DPP, no como un campo de metadatos opcional.

La situación regulatoria es compleja, pero los patrones técnicos son manejables. Lo decisivo es no tratar la capacidad de actualización como una función añadida posteriormente, sino como un principio arquitectónico desde el primer día.