Porque é que "registar uma vez" não é suficiente
Muitas empresas tratam o Passaporte Digital de Produto (DPP) como um exercício de conformidade único: recolher os dados, criar uma entrada no registo e está feito. O Regulamento ESPR (UE) 2024/1781 conta uma história diferente. Exige que as entradas no registo permaneçam disponíveis e atualizadas durante pelo menos 10 anos após a última vez que um produto é colocado no mercado. Se descontinuar um modelo hoje, terá de manter a sua entrada até pelo menos 2036 — incluindo endpoints de resolução válidos e identificadores únicos corretos.
Este artigo explica o que envolve, na prática, atualizar uma entrada no registo, que campos são afetados e como assegurar o processo do ponto de vista técnico.
O que o registo armazena — e o que não armazena
A 29 de abril de 2026, a Comissão Europeia publicou o projeto de regulamentação de execução para o registo central de DPP. O documento deixa claro quão enxuto o registo central foi concebido para ser: armazena apenas três elementos de dados por entrada:
| Campo | Descrição | Obrigação de atualização |
|---|---|---|
| Identificador único (UID) | Identificador único do produto/modelo | Imutável depois de atribuído |
| Endpoint de resolução | URL onde o DPP completo pode ser obtido | Atualizável; obrigatório aquando da migração |
| Código de mercadoria | Código de categoria do produto (por exemplo, código SH ou NC) | Corrigível em caso de entrada errada |
Os dados reais do produto — composição de materiais, índice de reparabilidade, pegada de carbono — não são armazenados no registo central. São fornecidos pelo fabricante ou por um administrador de dados autorizado no endpoint de resolução. O registo é simplesmente a agenda de endereços. Esta separação é importante do ponto de vista arquitetural: uma atualização da entrada central só é necessária quando o UID, o resolver ou o código de mercadoria mudam. A manutenção dos dados ao nível do conteúdo acontece exclusivamente do lado do fornecedor de dados.
Os requisitos de dados específicos do produto — o que exatamente tem de constar no DPP — continuam a ser do domínio da regulamentação setorial específica, como os regulamentos delegados ao abrigo do ESPR ou, no caso das baterias, o Regulamento Baterias (UE) 2023/1542.
Quando uma atualização do registo é obrigatória
O endpoint de resolução mudou
Este é o cenário mais comum no mundo real. As empresas mudam de fornecedor de cloud, migram para novas plataformas de DPP ou consolidam domínios. Assim que o endpoint de resolução anterior fica inacessível, nenhum scanner — seja uma autoridade aduaneira, um organismo de fiscalização do mercado ou um consumidor final — consegue obter o DPP. O regulamento não especifica explicitamente um prazo de resposta, mas a obrigação de disponibilidade durante 10 anos cria, na prática, tolerância zero para ligações permanentemente quebradas.
Recomendação: Utilize um resolver de subdomínio estável e detido pela própria empresa (por exemplo, dpp.suaempresa.com) como camada de indireção. Assim, quando mudar de plataforma, só precisa de reconfigurar internamente — sem tocar na entrada do registo. Isto segue o princípio do GS1 Digital Link, em que o código QR aponta para um resolver estável que, por sua vez, redireciona para sistemas de backend variáveis.
Foi introduzido um código de mercadoria incorreto
Os códigos de mercadoria (códigos NC ou SH) determinam quais os regulamentos delegados que se aplicam a um produto. Um código incorreto pode resultar na classificação do produto na categoria errada, ou na sua classificação incorreta durante verificações fronteiriças automatizadas — que a UE planeia introduzir a partir de 2028 ao abrigo do proposto Circular Economy Act. As correções são permitidas ao abrigo do projeto de regulamentação de execução, mas exigem uma justificação documentada.
Aquisição empresarial ou transferência de licença
Quando um produto muda de propriedade económica, é necessário avaliar se a responsabilidade pelo resolver também está a ser transferida. A conta de registo está associada ao registante original; uma transferência exige um processo formal junto da autoridade nacional competente.
Processo técnico: atualizar uma entrada
A regulamentação de execução prevê uma interface baseada em API para o registo. O endpoint exato só será publicado quando o regulamento entrar em vigor, mas o fluxo de trabalho esperado pode ser deduzido a partir do projeto:
# 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"
}'
O campo updateReason está designado como obrigatório no projeto para todas as alterações que não sejam a entrada inicial. Os valores permitidos incluem platform_migration, domain_change, commodity_code_correction e ownership_transfer. O histórico de auditoria de todas as atualizações é conservado pelo registo durante todo o período de 10 anos.
Atualizações em massa para grandes portefólios de produtos
As empresas com milhares de SKUs não conseguem gerir pedidos individuais manualmente. O projeto de regulamento prevê um endpoint de lote (batch):
{
"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 e manter estes processos em massa exige uma gestão de dados estruturada, tal como requerido por um fluxo de trabalho de importação em massa para entradas de DPP.
A normalização internacional como âncora de estabilidade
Um processo de atualização é tão robusto quanto as normas em que assenta. É aqui que entra a criação do ISO/IEC JTC 5: o novo Comité Técnico Conjunto, cujo secretariado é assegurado pelo Instituto Alemão de Normalização (DIN), tem a missão de desenvolver normas internacionais para a interoperabilidade global dos sistemas de DPP.
Em termos práticos para os processos de atualização: assim que o ISO/IEC JTC 5 adotar normas para formatos de dados, esquemas de API e estruturas de identificadores, espera-se que estas alimentem futuras revisões dos regulamentos de execução do ESPR. As empresas que já dependem de identificadores conformes com a GS1 (GTIN, SGTIN) e de resolvers GS1 Digital Link estão bem posicionadas: estas normas são consideradas a implementação de referência para o JTC 5.
A notificação à OMC do regulamento do registo da UE (G/TBT/N/EU/1211), a 21 de maio de 2026, também sinaliza que o sistema é classificado como um regulamento técnico de comércio — com implicações para os fabricantes de países terceiros que exportam produtos para a UE. Também eles têm de manter e conservar as entradas no registo atualizadas.
A manutenção dos dados como processo contínuo: implicações organizacionais
A obrigação de 10 anos não é apenas uma tarefa de TI. Exige medidas organizacionais:
- Documentar a responsabilidade: Quem, na sua organização, é responsável pelas entradas no registo? Este papel tem de permanecer preenchido mesmo através de rotatividade de pessoal e reestruturações empresariais.
- Configurar a monitorização do resolver: Verificações automatizadas de disponibilidade (verificações de estado HTTP) para todos os endpoints de resolução ativos não são um luxo — são um mínimo operacional.
- Manter um registo de alterações: O histórico de auditoria no registo é acessível às autoridades. Complemente-o com um registo de alterações interno que inclua justificações e aprovações.
- Rever os contratos com os fornecedores de plataforma: Se utilizar um prestador de serviços de DPP externo, o contrato tem de cobrir explicitamente o requisito de disponibilidade de 10 anos — incluindo disposições para a insolvência ou o encerramento da atividade do fornecedor.
A 27 de maio de 2026, a Comissão Europeia realizou um webinar sobre a implementação do DPP de baterias que abordou explicitamente os desafios de manutenção de dados que as PME enfrentam. A mensagem foi clara: a disponibilidade dos dados a longo prazo não é um detalhe técnico — é uma obrigação central.
Conclusão
Uma entrada no registo DPP não é um documento estático. A regulamentação de execução de abril de 2026 estabelece um quadro jurídico que exige que os fabricantes mantenham os seus dados de forma ativa e documentável ao longo de uma década. A boa notícia: o registo central é deliberadamente mantido enxuto. Se conceber os endpoints de resolução para serem estáveis, utilizar identificadores conformes com a GS1 e incorporar os processos de alteração na sua organização, a sobrecarga técnica das atualizações mantém-se gerível — e estará bem preparado para as futuras normas ISO/IEC JTC 5.
