A Comissão Europeia colocou em funcionamento, em 20 de julho de 2026, o registo de passaportes digitais de produtos, juntamente com o ambiente de teste. Assim, uma componente abstrata de ESPR tornou-se um sistema que as empresas podem efetivamente experimentar. Para os fabricantes, é agora sobretudo importante distinguir: o registo é o índice central, enquanto o passaporte do produto continua descentralizado.
O que entrou em funcionamento em 20 de julho
O registo recebe identificadores únicos de produtos, dados de registo e metadados selecionados. As informações completas sobre o produto continuam a estar com o operador económico responsável ou com um prestador de serviços de DPP contratado. Por isso, a Comissão descreve expressamente o registo como um serviço de índice, e não como um sistema central de gestão de conteúdos.
Estão previstos registos através de uma interface de utilizador segura e de uma API. As empresas podem também gerar um comprovativo eletrónico de registo. Isto é relevante para processos B2B, porque fornecedores e clientes podem assim comprovar que um passaporte foi inscrito no sistema da UE, sem duplicar todo o conjunto de dados.
O lançamento não abrange apenas grupos de produtos de ESPR. A Comissão menciona também baterias, produtos de construção, brinquedos, detergentes e tensioativos destinados ao utilizador final, desde que a respetiva legislação da União exija um passaporte digital de produto. O primeiro prazo obrigatório mantém-se em 18 de fevereiro de 2027 para determinadas baterias.
Registo, resolvedor e fonte de dados são três camadas distintas
Um sistema robusto de DPP deve separar claramente as funções:
- O Registo da UE confirma que um identificador e os metadados obrigatórios estão registados.
- Um resolvedor encaminha o identificador persistente do produto para o recurso adequado.
- A fonte de dados propriamente dita fornece conteúdos atualizados para pessoas e máquinas.
Esta separação não é um pormenor. Quem armazena todos os dados exclusivamente numa página de produto própria ainda não tem uma integração com o registo. Inversamente, quem apenas regista um identificador ainda não disponibiliza um passaporte de produto utilizável. Ambos têm de estar ligados através de identificadores estáveis.
Para a resolução, é adequado um link aberto e permanente. Um resolvedor de ligação digital da GS1 pode tornar acessíveis diferentes representações a partir do mesmo identificador: uma página web compreensível, JSON-LD legível por máquina ou documentação complementar. O suporte de dados no produto ou na embalagem mantém-se estável, mesmo que os sistemas de destino evoluam.
O que as empresas devem verificar no ambiente de teste
O ambiente de teste não se destina apenas a um teste manual de cliques. Deve ser tratado como uma etapa preliminar da integração em produção.
Organização e funções
Primeiro, é necessário esclarecer qual a entidade jurídica que se regista, quem a representa no sistema e quais as equipas autorizadas a criar ou alterar registos. Isto envolve dados mestres, conformidade, TI e, se aplicável, prestadores de serviços externos. Um acesso pessoal de teste não substitui um modelo de funções para a futura operação.
Identificadores e granularidade
A equipa de produto deve verificar se o futuro passaporte será gerido ao nível do modelo, do lote ou da unidade individual. A resposta depende da legislação setorial aplicável. O teste do registo é o momento certo para mapear entre si IDs internos de produto, GTINs, identificadores de lote e o identificador persistente utilizado externamente.
API e repetibilidade
Um processo de produção exige mais do que um POST bem-sucedido. O registo, a atualização e o tratamento de erros devem ser repetíveis e registados. Isto inclui pedidos idempotentes, confirmações técnicas e uma associação clara entre o registo ERP, DPP e a entrada no registo. Um processo de DPP baseado em API reduz divergências manuais quando os produtos são criados em maiores quantidades.
Separação entre metadados e dados especializados
Os dados do registo não devem tornar-se um segundo repositório de dados de produto. Defina quais os campos obrigatórios no registo e quais permanecem no passaporte descentralizado. Para cada informação, é necessária uma fonte principal, uma entidade responsável e uma regra de atualização.
Comprovativos e monitorização
Os comprovativos de registo devem ser guardados juntamente com a marca temporal, o identificador utilizado e a resposta do sistema. Além disso, é necessária uma verificação: o passaporte existe, o resolvedor está acessível e os metadados do registo e o estado do produto continuam a coincidir?
Porque é que a alfândega precisa de uma cadeia de verificação própria
O registo ajuda as autoridades aduaneiras a verificar automaticamente, antes da introdução em livre prática, se existe um DPP registado válido e o código aduaneiro exigido. Para os importadores, isto cria uma nova dependência: o identificador do produto, a entrada no registo e a declaração aduaneira têm de ser consistentes.
Por isso, um erro não se torna visível apenas numa página de produto. Pode afetar o processo na fronteira. As empresas devem já no teste simular fluxos de dados desde a criação do produto até à documentação de importação e definir quem pode corrigir rapidamente um registo incorreto.
Um plano de testes sensato para 30 dias
- Selecionar uma entidade jurídica real e um pequeno sortido de produtos representativo.
- Documentar, para cada produto, a granularidade planeada de DPP e os identificadores principais.
- Executar um ciclo completo através da interface de utilizador e, se relevante, da API.
- Arquivar em conjunto o comprovativo de registo, a resposta do resolvedor e os dados de produto legíveis por máquina.
- Testar casos de erro: identificador duplicado, metadados desatualizados, anfitrião de dados inacessível e produto retirado.
- Derivar dos resultados um modelo operacional com responsabilidades, monitorização e via de escalonamento.
O início operacional do registo ainda não significa que todos os requisitos de dados específicos de cada setor já se apliquem integralmente. No entanto, desloca a discussão das apresentações para processos verificáveis. As empresas podem agora perceber se os seus identificadores, funções e APIs são compatíveis, antes de se aplicarem os primeiros prazos obrigatórios.
