ISO/IEC JTC 5: preparar a arquitetura para a interoperabilidade de DPP

Por que uma questão de arquitetura entra agora na agenda

O Passaporte Digital de Produto está sendo introduzido gradualmente na Europa por meio de atos legislativos setoriais. Para as empresas, isso pode facilmente criar a impressão de que cada grupo de produtos precisa de seu próprio modelo de dados, seu próprio suporte de dados e sua própria lógica de integração. É justamente nessa interface que começa o trabalho da ISO/IEC JTC 5: o comitê técnico conjunto foi criado em 2026 e deve desenvolver as bases para a interoperabilidade entre setores e sistemas de DPP. Sua primeira reunião anunciada ocorrerá de 7 a 9 de setembro de 2026, em Berlim. A ISO/IEC JTC 5 descreve expressamente seu mandato como uma estrutura para o sistema DPP e o ecossistema DPP; as normas específicas de cada setor continuam sob responsabilidade dos comitês técnicos competentes.

Isso não constitui uma nova obrigação legal nem uma norma ISO publicada. Ainda assim, é um motivo sólido para separar a própria arquitetura dos campos de dados de curto prazo. O primeiro item de trabalho, ISO/AWI 25534-1, ainda está na fase de projeto 10.99; o projeto foi aprovado em 12 de fevereiro de 2026. Segundo a ISO, o trabalho trata de termos, princípios básicos, categorias de dados e mecanismos de governança e confiança. A entrada pública do projeto menciona expressamente “under development”. Quem concluir hoje que existe uma obrigação de certificação ou um formato de intercâmbio concluído está se antecipando.

O que separa a estrutura internacional das exigências da UE

A UE já estabelece parâmetros concretos. A Comissão explica que o DPP disponibiliza informações relacionadas ao produto em um modelo descentralizado: os dados completos permanecem com o agente econômico ou com o provedor de serviços DPP; o registro mantém identificadores exclusivos e dados de registro obrigatórios. Um suporte de dados, como um código QR, conecta o produto físico ao seu passaporte. A página da Comissão sobre DPP também menciona diferentes níveis de acesso para funções e cronogramas setoriais.

A isso somam-se as normas europeias harmonizadas. A Decisão de Execução (UE) 2026/1736, de 14 de julho de 2026 faz referência a seis normas DPP, entre outros temas, sobre identificadores, interoperabilidade, suportes de dados, APIs, intercâmbio de dados e armazenamento de dados. Sua função é concreta: para os requisitos abrangidos por elas, o cumprimento pode fundamentar a presunção de conformidade nos termos dos artigos 10 e 11 do ESPR.

A JTC 5 não substitui esses níveis. Ela atua acima deles: uma estrutura neutra em relação aos setores deve ajudar a explicar como termos, categorias de dados, confiança e governança se relacionam entre sistemas. A consequência prática é importante. Um fabricante não deve esperar por uma futura edição da ISO para disponibilizar suas informações sobre baterias, têxteis ou aço. Mas deve evitar fixar os campos atuais do setor como núcleo imutável de um modelo DPP empresarial abrangente.

Três decisões de arquitetura que fazem sentido hoje

1. Separar a identidade estável dos perfis funcionais

Um passaporte precisa de uma identidade técnica duradoura: produto, variante, lote ou unidade individual; agente econômico responsável; resolução por meio do suporte de dados. A base jurídica determina, em seguida, quais informações funcionais são necessárias para isso. Essas informações devem ser organizadas em perfis versionados. Um módulo de bateria para dados de CO₂ ou de estado de saúde, portanto, não é um esquema básico geral. Da mesma forma, dados de materiais, reparo ou reciclagem não devem ser inseridos apenas como texto livre não estruturado em um passaporte geral.

Na prática, isso significa que um ID central estável, um identificador de perfil documentado e uma versão do perfil devem estar associados. Cada visualização do passaporte disponibilizada deve indicar qual perfil e qual versão determinaram o conteúdo. Assim, as equipes podem incorporar um ato legislativo, uma regra setorial ou, posteriormente, uma norma, sem reescrever dados históricos ou URLs.

2. Modelar separadamente a origem dos dados e o acesso

Interoperabilidade não é apenas um formato JSON. Ela depende de o destinatário conseguir avaliar a origem, a validade e a função de uma informação. Portanto, armazene para cada elemento ou pacote de dados, no mínimo, a fonte, o escopo de validade, o momento da coleta, a parte responsável e a versão funcional. Um indicador interno de qualidade é diferente de uma declaração de conformidade juridicamente vinculante; uma informação fornecida por um fornecedor é diferente de um valor medido.

A segunda parte é o acesso. A Comissão descreve diferentes acessos a informações para consumidores, empresas de reparo, recicladores e autoridades. Isso exige uma separação consciente entre a visualização pública do passaporte, o acesso profissional autorizado e a área de trabalho interna. Uma URL não deve se tornar uma autorização. Funções, mandatos, categorias de dados e decisões auditáveis precisam ser verificados no servidor.

3. Testar os limites de intercâmbio como contratos

Um sistema DPP tem várias transições: ERP ou PLM fornecem dados mestres, fornecedores fornecem comprovantes, um provedor de serviços hospeda os dados, um registro recebe metadados e usuários externos leem uma visualização pública ou protegida. Cada transição precisa de um contrato legível por máquina: campos permitidos, identificadores, semântica, casos de erro, versionamento e compatibilidade retroativa.

Isso já pode ser testado. Casos de teste úteis incluem versões de perfil desconhecidas, comprovantes expirados, ausência de origem dos dados, funções não autorizadas, registros duplicados e um suporte de dados que aponta para um passaporte que já não está disponível. O teste ainda não comprova a conformidade com uma futura norma ISO. Mas cria a capacidade de comprovação que faltará mais tarde, quando o modelo de dados e os direitos já estiverem indissociavelmente misturados.

Um plano de trabalho de 90 dias sem especulação

Nos próximos 30 dias, vale a pena fazer um levantamento: quais identificadores de produtos existem, quais perfis de dados são realmente utilizados e quais dados estão apenas em documentos? Em seguida, vem uma decisão de arquitetura: modelo central, registro de perfis, modelo de origem e matriz de acesso. Em uma terceira etapa, um produto real deve percorrer todas as transições — do sistema de origem, passando pelo passaporte, até a função da empresa de reparo ou da autoridade.

Os limites permanecem claros. A ISO/AWI 25534-1 não é uma norma concluída; não há cláusulas publicadas que as equipes possam implementar. Além disso, o cronograma da Comissão é indicativo e não substitui a análise do ato legislativo aplicável ao respectivo grupo de produtos. O benefício do acompanhamento, portanto, não está em marcar antecipadamente uma caixa em uma lista de conformidade, mas em uma arquitetura capaz de incorporar adequadamente novos perfis, funções e regras de intercâmbio.