O novo gargalo prático: quem pode registrar um passaporte?
O Registro de DPP da UE está operacional desde 20 de julho de 2026. Inicialmente, para muitas equipes, a questão técnica esteve em primeiro plano: é possível registrar um identificador de produto e o suporte de dados resolve corretamente? Isso é necessário, mas incompleto. Com o Regulamento de Execução (UE) 2026/1778, de 16 de julho de 2026, a identidade que precede o processo adquire relevância regulatória própria: os registros devem ser feitos por agentes econômicos verificados, e o acesso às funções do Registro não é o mesmo que o acesso público às informações do produto.
Isso não é motivo para tornar os códigos QR mais complicados. É motivo para modelar corretamente responsabilidades, comprovantes e autorizações antes do primeiro processo de registro produtivo. O guia a seguir separa esses níveis e mostra o que os fabricantes podem preparar agora na prática.
Três identidades que não podem ser misturadas
Em um projeto de DPP, aparecem pelo menos três identidades diferentes.
Primeiro, há o agente econômico: a empresa ou o empresário individual que coloca um produto no mercado ou atua no Registro. O artigo 4.º do Regulamento 2026/1778 vincula a classificação como “operador econômico verificado” à comprovação de identidade. Para empresários individuais estabelecidos na UE, o ato jurídico menciona, por exemplo, uma assinatura eletrônica qualificada ou um meio de identificação eletrônica compatível com o eIDAS e com alto nível de garantia. As pessoas jurídicas também devem ser verificadas por meio de comprovantes definidos.
Em segundo lugar, há o usuário humano. Compras, manutenção de dados mestres, compliance, prestadores de serviços externos e um DPP não atuam automaticamente com a mesma autorização. Por isso, uma conta de usuário não substitui o contexto empresarial verificado. É necessária uma associação rastreável: quem atua em nome de qual agente econômico, com qual função e até quando?
Em terceiro lugar, há a identidade do produto. Um GTIN, um número de série ou outro identificador descreve o produto ou a granularidade exigida; ele não comprova que a pessoa diante da tela tem autorização para fazer o registro. O ESPR separa expressamente essas esferas: o suporte de dados conecta o produto ao passaporte, enquanto o Registro mantém os identificadores exclusivos e os dados de registro. A visão geral da Comissão sobre o DPP descreve o processo de forma correspondente: as informações do produto são criadas e registradas; em seguida, o Registro gera um ID de registro exclusivo.
Quem reunir essas três identidades em uma tabela, um token de API ou uma caixa de e-mail compartilhada criará posteriormente um risco operacional e de auditoria. A pergunta correta não é “quem conhece o link?”, mas “quem pode iniciar uma operação no Registro em nome deste agente econômico?”.
O acesso público por QR não é uma autorização no Registro
Um código QR no produto continua sendo uma porta de acesso ao passaporte. Ele não é um mecanismo de login no Registro e também não deve se tornar um. Consumidores, empresas de reparo, recicladores e autoridades precisam de informações diferentes. O guia atual da Comissão sobre o DPP descreve expressamente que as informações são acessíveis de acordo com as funções dos usuários.
Na prática, recomenda-se, portanto, uma separação clara de camadas:
- A leitura pública fornece uma visualização estável e de acesso gratuito do passaporte, com as informações exigidas para o respectivo grupo de produtos.
- Uma interface com acesso restrito por função gerencia comprovantes, dados de fornecedores, históricos de alterações e aprovações internas.
- O conector do Registro só pode transmitir os dados de registro necessários e associar uma resposta do Registro a um registro de produto específico.
Isso evita duas suposições comuns. Primeiro: um link QR “secreto” não substitui o controle de acesso; ele pode ser compartilhado e não é uma comprovação confiável de autorização. Segundo: o Registro não é o local de armazenamento de toda a documentação do produto. A Comissão explica que as informações completas do produto podem ficar com o agente econômico ou com um DPP; os metadados e identificadores necessários é que são registrados.
O que o regulamento sugere tecnicamente
O Regulamento 2026/1778 não descreve o Registro como um simples banco de dados de consulta. Ele menciona, entre outros elementos, uma API para registro e recebimento de dados, uma plataforma para confirmar existência e completude, um esquema para IDs de registro exclusivos, um diretório de DPP, um sistema de logs e esquemas de identificação e autorização. Os modelos de dados também precisam ser versionados.
Essas disposições não resultam em uma arquitetura de produto pronta. Mas oferecem diretrizes sólidas:
Perfil empresarial antes da importação de produtos
Antes de uma importação em massa, crie um registro empresarial controlado. Ele deve incluir a entidade jurídica, seu status como agente econômico, o comprovante de identidade escolhido, o momento da verificação e a área responsável. O comprovante em si deve ser armazenado por um sistema DPP apenas na medida necessária e permitida; muitas vezes, basta um status de verificação com referência e lógica de validade ou reavaliação.
A delegação é um registro próprio
Quando um prestador de serviços ou uma agência atua, a delegação precisa ter um escopo. No mínimo, é recomendável especificar o agente econômico, as ações permitidas, os grupos de produtos ou marcas, o início, o fim e a revogação. Uma chave de API geral sem limite de mandato é ampla demais para uma ação relevante para o registro.
O registro como processo comprovável
Para cada registro, as equipes devem guardar pelo menos a versão local do produto, o identificador transmitido, a resposta, incluindo o ID de registro, o carimbo de data e hora, a função atuante e a classe de erro. Assim, será possível distinguir posteriormente se um passaporte estava incompleto do ponto de vista técnico, se houve colisão de identificadores ou se faltou autorização. O registro de logs não deve se transformar na coleta de dados pessoais desnecessários; deve criar uma cadeia de ações responsável e verificável.
Testar autorizações como regras de negócio
Os casos de teste não devem terminar em “a API respondeu 200”. Verifique pelo menos se: um usuário sem autorização não consegue iniciar um registro; um prestador delegado só consegue processar o mandato acordado; uma delegação expirada é rejeitada; a visualização pública do passaporte não revela dados internos do Registro nem dos comprovantes; e um processo reenviado é tratado de forma rastreável como repetição.
Um plano de início enxuto para as próximas semanas
Não comece com uma migração completa. Escolha uma pequena quantidade representativa de produtos e uma cadeia real de responsabilidades.
- Atribua, para cada produto-piloto, o fabricante, o responsável por colocá-lo no mercado, os responsáveis pelos dados e, quando aplicável, o prestador de serviços.
- Documente por qual procedimento o agente econômico é verificado e quem aprova a verificação.
- Defina funções para elaboração, aprovação técnica, registro e acesso somente para leitura.
- Registre um conjunto de dados de teste com dados de produto versionados e documente o registro, a resposta e o caminho de correção.
- Teste o acesso público por QR separadamente das funções internas e do conector do Registro.
- Pratique a revogação e a alteração: o que acontece quando há troca de prestador, mudança da denominação empresarial ou um identificador incorreto?
Esse processo também está alinhado à recomendação já publicada de testar separadamente o Registro, o resolvedor e a fonte de dados. A novidade é o foco: antes de uma integração robusta com a API, é preciso estar claro qual organização verificada e qual função são responsáveis pela ação.
O que ainda não se deve afirmar
O regulamento do Registro cria o quadro técnico e organizacional. Ele não torna imediatamente cada grupo de produtos obrigado ao DPP nem substitui atos delegados específicos de cada setor. A Comissão continua organizando a introdução por grupos de produtos; de acordo com os ESPR, está previsto, em princípio, um período de transição de pelo menos 18 meses. Da mesma forma, o status empresarial verificado não é uma autorização para fornecer dados de produto incompletos ou incorretos.
Ainda assim, a consequência para as equipes é concreta: identidade, mandato, funções e logs devem entrar no backlog de DPP antes que os registros sejam ampliados. Assim, o código QR continua sendo a porta de entrada pública simples — e a operação no Registro se torna aquilo que é do ponto de vista regulatório: uma ação responsável e rastreável de um agente econômico verificado.
