Manter os dados do DPP atualizados: o que o ESPR realmente exige

Desde a adoção do Regulamento ESPR (UE) 2024/1781, o Digital Product Passport (DPP) é direito vinculativo da UE. O que muitas empresas subestimam: o DPP não é um documento estático, criado uma única vez no lançamento no mercado. Deve ser mantido atualizado durante todo o ciclo de vida do produto — e os requisitos para isso estão a tornar-se cada vez mais específicos.

Este artigo explica quais dados devem ser atualizados, quando isso deve ocorrer, como a arquitetura do Registry influencia o modelo de atualização e quais padrões técnicos se revelam eficazes na prática.

O que o regulamento diz sobre o ciclo de atualização

Campos de dados estáticos vs. dinâmicos

O próprio ESPR não especifica uma frequência explícita de atualização, mas estabelece que o DPP deve conter «informações atuais e exatas». A especificação ocorre a nível setorial — e, neste ponto, o projeto do JRC para produtos semiacabados de ferro e aço fornece o panorama mais claro até agora.

O projeto distingue sistematicamente entre duas granularidades de dados:

Nível	Identificador	Dados de exemplo	Motivo da atualização
Nível de lote (Lot)	Número do lote	Teor de material reciclado, composição da liga, PCF segundo a ISO 14067	Em caso de alteração na produção, novo lote
Nível de produto (Item)	Número de série	Dimensões, certificações, declarações de conformidade	Em caso de recertificação, recolha, reparação

Esta distinção é decisiva para a arquitetura da base de dados: os dados de lote são normalmente registados uma vez por ciclo de produção e, depois, permanecem estáveis — salvo se um recálculo da pegada de CO₂ resultar num valor corrigido. Já os dados a nível de produto podem mudar durante toda a vida útil, por exemplo, quando um equipamento é reparado ou uma certificação é renovada.

O Regulamento relativo às baterias (UE) 2023/1542 já contempla implicitamente esta distinção: os dados de capacidade, que se alteram devido à degradação, devem ser mantidos atualizados — um requisito que dificilmente é viável sem uma arquitetura clara.

O Registry como diretório, não como armazenamento de dados

Um equívoco frequente diz respeito ao papel do Registry central do DPP. O projeto de regulamento de execução para o Registry do DPP deixa claro: o Registry armazena exclusivamente o identificador único, o endpoint do resolver e o código aduaneiro — não os dados efetivos do passaporte.

Isto significa para a gestão de atualizações: o conteúdo do passaporte e o Registry são sistemas separados. Quem atualiza dados de produto, em regra, não precisa de intervir no Registry — exceto se o endpoint do resolver mudar (por exemplo, numa mudança de sistema). O consórcio CIRPASS-2 referiu explicitamente este padrão de arquitetura no seu parecer sobre o projeto do Registry e recomenda incluir a norma EN 18219 como referência vinculativa no regulamento de execução — entre outros motivos, para assegurar a interoperabilidade com o GS1 Digital Link.

Cenários de atualização na prática

Cenário 1: Nova pegada de CO₂ devido à mudança de fornecedor

A pegada de carbono específica do produto (PCF) é gerida a nível de lote segundo o projeto do JRC para o aço e deve ser calculada com métodos compatíveis com a ISO 14067. Se um produtor de aço mudar a sua fonte de energia ou fornecedor de sucata, o PCF do novo lote muda — mas não o dos lotes já entregues.

Em termos técnicos, isto significa: o registo DPP do lote antigo permanece inalterado. Para o novo lote, é criado um novo registo, que pode usar o mesmo endpoint do resolver, mas contém um novo número de lote 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}
  }'

Cenário 2: Certificação prestes a expirar a nível de produto

As declarações de conformidade e as certificações têm datas de validade. Assim que é emitida uma nova certificação, o DPP a nível de produto deve ser atualizado. Como o endpoint do resolver permanece inalterado, não é necessária qualquer atualização do Registry — apenas o registo por trás do endpoint é alterado.

// 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,
  });
}

Cenário 3: Migração do resolver numa mudança de sistema

Se uma empresa mudar de prestador de serviços do DPP, o endpoint do resolver muda. Neste caso, o Registry deve ser atualizado — para cada identificador afetado. Este é o tipo de atualização mais trabalhoso, pois exige uma escrita no Registry.

Recomendação: utilize um resolver próprio e estável (por exemplo, dpp.ihrunternehmen.de) como camada intermédia, que redireciona internamente para o prestador de serviços em questão. Desta forma, o endpoint registado no Registry mantém-se permanentemente estável.

Requisitos técnicos para o sistema de atualização

Versionamento e trilho de auditoria

O ESPR não exige um versionamento explícito, mas a combinação de responsabilidade pelo produto e controlo aduaneiro torna um trilho de auditoria praticamente inevitável. Se um agente aduaneiro, em 2030, verificar o DPP de uma viga de aço produzida em 2027, deve ser possível determinar quais dados eram aplicáveis no momento da importação.

Esquema mínimo para uma tabela DPP versionada:

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 âncora estável de identificador

O GS1 Digital Link separa claramente o identificador do resolver: o código QR no produto codifica um URL como https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, que aponta, através do resolver GS1 ou de um resolver próprio, para o registo atual do DPP. As atualizações do registo não exigem uma nova rotulagem — o suporte físico de dados permanece inalterado.

A TEKLYNX atualizou o seu software CODESOFT e passa agora a suportar esquemas de codificação GS1 «++», com os quais URLs web podem ser gravados diretamente na memória de tags RAIN-RFID — um requisito resultante da combinação entre a EN 18220 e a norma GS1 Digital Link.

Governação: quem pode atualizar o quê?

Além da questão técnica, surge a questão da governação: quais intervenientes da cadeia de abastecimento podem escrever quais campos do DPP? O consórcio CIRPASS-2 identificou pontos críticos relativos à soberania dos dados em cadeias de abastecimento transfronteiriças.

Um modelo prático distingue três funções:

Fabricante (Creator): Preenche todos os campos na criação; pode atualizar todos os campos.
Interveniente autorizado (Editor): Pode atualizar campos definidos (por exemplo, histórico de reparações, novas certificações) — documentado com identificador próprio.
Leitor (Reader): Pode ler todos os campos públicos, sem permissões de escrita.

A Ecommerce Europe exigiu, no seu documento de posição sobre a implementação do DPP, que também sejam possíveis «DPPs parciais» para produtos usados — ou seja, registos que atualizam apenas parte dos campos originais. Isto já é tecnicamente possível hoje, mas ainda falta como categoria formal nos regulamentos de execução.

Conclusão

Manter os dados do DPP atualizados não é um esforço pontual, mas sim um processo operacional. As principais conclusões do atual enquadramento regulamentar:

Separe lote e produto — a estratégia de identificadores determina quais dados devem ser atualizados e quando.
O Registry não é um armazenamento de dados — atualizações do conteúdo do passaporte normalmente não exigem uma escrita no Registry.
O versionamento é, na prática, obrigatório — mesmo que o regulamento não o prescreva explicitamente.
O GS1 Digital Link desacopla o suporte físico de dados e o registo — isto reduz significativamente o esforço nas atualizações de dados.
As funções de governação devem ser definidas antecipadamente — quem pode escrever o quê e como isso é registado?

As normas estão a tornar-se mais específicas, os primeiros projetos-piloto estão em curso — quem estruturar corretamente a arquitetura agora evitará correções dispendiosas quando os regulamentos de execução setoriais entrarem em vigor.