em que formato devo fornecer os dados do passaporte de produto

Um formato de arquivo fixo ainda não está determinado, mas os requisitos que deve cumprir sim

Ainda não existe um formato de arquivo prescrito (como JSON, XML ou outro) para o passaporte de produto digital de equipamentos de eletrônica e TIC. O próprio ESPR não prescreve um formato específico, mas estabelece no artigo 10 e artigo 11 do Regulamento (UE) 2024/1781 os requisitos que a configuração técnica do passaporte deve cumprir: o passaporte deve ser baseado em normas abertas e interoperáveis, ser intercambiável entre sistemas e ser legível por máquina. Qual norma de arquivo concreto o cumpre será desenvolvido por categoria de produto em um ato delegado. Para eletrônica e TIC, esse ato ainda não existe.

Para eletrônica, isto ainda vale como marco, não como requisito estabelecido

Esta página trata do passaporte de produto digital para equipamentos de eletrônica e TIC sob o ESPR. Os artigos 10 e 11 aplicam-se a todas as categorias de produtos abrangidas pelo ESPR, mas a implementação técnica precisa — incluindo o formato de arquivo — é regulada separadamente por subcategoria. Isto significa que o que agora está estabelecido é um marco: requisitos de interoperabilidade, normas abertas e legibilidade por máquina. Não significa que já exista um formato de arquivo concreto no qual um fabricante ou importador de eletrônica deve fornecer os dados. Quem procura uma resposta como "forneça em JSON" ou "use o esquema XML X", não a encontrará em parte alguma da regulamentação neste momento para este grupo de produtos. Além disso, este tema é diferente da questão de se o passaporte de produto se aplica a um determinado produto de eletrônica — essa é uma questão separada com uma resposta diferente.

A publicação do ato delegado para eletrônica determina a data

Ainda não existe uma data fixa quando o formato de arquivo para eletrônica e TIC será conhecido. De acordo com o plano de trabalho ESPR 2025-2030, os atos delegados são desenvolvidos por subcategoria, com os primeiros atos esperados a partir de 2027. Assim que um ato delegado for publicado para eletrônica e TIC, espera-se que contenha também o formato técnico no qual os dados devem ser fornecidos. Até lá, apenas o marco geral do artigo 10 e artigo 11 aplica-se: normas abertas, interoperabilidade e legibilidade por máquina, sem que um único formato de arquivo concreto seja prescrito. Esta página será atualizada assim que o ato delegado para esta categoria fornecer uma resposta concreta.

O que um importador ou fabricante já pode preparar agora

Mesmo sem um formato de arquivo estabelecido, há muito a fazer na prática. Para começar, é útil determinar quais sistemas e dados formarão posteriormente a base do passaporte — a maioria das empresas já tem essas informações em algum lugar, por exemplo, em um sistema ERP ou de inventário, e é útil revisar previamente como tal sistema pode ser posteriormente conectado ao passaporte de produto. Além disso, é aconselhável pensar sobre identificação: cada produto deve ser rastreável até um passaporte, e isso requer uma abordagem consistente para atribuir um código de identificação único a cada produto. Também a questão de como o código QR será posteriormente colocado no produto e como isso se relaciona com códigos de barras existentes ou sistemas GS1 já pode ser investigada agora, independentemente de qual formato de arquivo será prescrito posteriormente. Assim que o ato delegado para eletrônica e TIC for publicado, provavelmente se alinhará com a infraestrutura já mencionada no artigo 13 (o registro de passaportes de produto digital) e artigo 14 (o portal web), de modo que uma preparação para essa estrutura já é útil agora, independentemente do formato técnico exato.

A base legal: artigo 10 e artigo 11 do ESPR

O Artigo 10 do Regulamento (UE) 2024/1781 (ESPR) descreve os requisitos gerais que um passaporte digital de produto deve cumprir, incluindo a acessibilidade e a confiabilidade dos dados. O Artigo 11 aborda especificamente o design técnico e o funcionamento do passaporte e menciona requisitos como interoperabilidade entre sistemas de diferentes operadores do mercado e o uso de normas abertas, sem prescrever obrigatoriamente um único formato de ficheiro. O desenvolvimento técnico adicional — incluindo presumivelmente também o formato de dados concreto — é realizado através de atos delegados por grupo de produtos, conforme anunciado no plano de trabalho ESPR 2025-2030. O Artigo 13 e o Artigo 14 do mesmo regulamento descrevem adicionalmente o registo e o portal web através do qual os dados do passaporte se tornam acessíveis, o que é relevante para a forma como um ficheiro entregue é finalmente apresentado e pesquisado. Para eletrónica e TIC, o ato delegado que o concretiza ainda não foi publicado neste momento.

Para quem pretenda fazer preparativos agora, o melhor é começar por colocar em ordem os seus próprios dados de produtos e sistemas de identificação, de modo que a transição para um formato de ficheiro concreto seja posteriormente uma questão de integração em vez de começar do zero. Também é aconselhável, neste meio tempo, analisar o que o registo de passaportes digitais de produtos contém e o que nele vai ficarpois esse registo provavelmente está directamente relacionado com o mecanismo de entrega final.

Em que se baseia isto

O regulamento em si está no EUR-Lex. Fazemos referência para cada afirmação; não tem de nos acreditar.

O que deve fazer concretamente

O que se espera de si

A questão de qual formato de ficheiro é obrigatório — JSON, XML, PDF, uma estrutura API específica — chega a cada importador e fabricante assim que o departamento de TI começa a desenvolver. A resposta com base no texto atual do ESPR é clara: um formato de ficheiro concreto não consta no regulamento. O Artigo 10 e o Artigo 11 do ESPR (Regulamento (UE) 2024/1781) estabelecem sim a que o passaporte digital de produto deve cumprir, mas isto acontece ao nível de requisitos funcionais e técnicos, não ao nível de "utilizar JSON-LD" ou "entregar um ficheiro XML de acordo com este esquema". O seu desenvolvimento é esperado através de atos delegados e de execução, por grupo de produtos.

A interoperabilidade é o centro, não um formato específico

O Artigo 10 do ESPR menciona a interoperabilidade como requisito essencial: o passaporte deve ser estruturado de tal forma que os sistemas de diferentes partes — autoridades de supervisão, operadores do mercado, consumidores — possam ler os dados. Para uma empresa com 10 a 100 funcionários, isto significa na prática que a escolha de um formato de armazenamento e intercâmbio apenas pode ser tomada com certeza após a chegada do ato delegado para a sua própria categoria de produtos. Até lá, é recomendável trabalhar com dados estruturados (pense em campos numa base de dados ou sistema ERP) em vez de manter dados apenas num documento solto ou PDF, para que uma divulgação posterior no formato final requeira menos retrabalho.

O passaporte deve ser legível através do suporte de dados QR

O Artigo 11 do ESPR descreve o funcionamento técnico do passaporte, incluindo a ligação com o suporte de dados no produto. Isto significa que os dados subjacentes, em qualquer formato, devem poder ser divulgados no momento em que alguém digitaliza o código. A forma como essa ligação funciona tecnicamente e que normas de identificação desempenham um papel são descritas na página sobre como é que o código QR do passaporte digital do produto chega à minha eletrônica. Para empresas que já trabalham com códigos de barras GS1, a questão de se uma estrutura de identificação existente pode ser reutilizada é relevante — esse tema é retomado na página sobre o que é GS1 Digital Link e se é necessário para o passaporte digital do produto.

Cada produto deve ser unicamente identificável, independentemente do formato do ficheiro

Independentemente do formato técnico que venha a ser prescrito, o requisito subjacente é que cada produto receba um código de identificação único. Esta é uma exigência separada que não se altera quando o formato de ficheiro for posteriormente estabelecido. As empresas que começarem agora a estruturar os seus dados de produto farão bem em incluir essa identificação como parte integrante. Como isto é construído na prática está explicado na página sobre como atribuir a cada produto um código de identificação único.

A apresentação ao registo requer um formato próprio

O artigo 13.º do ESPR introduz o registo de passaportes digitais de produtos, no qual certas informações sobre o passaporte são registadas. Também aqui ainda não foi estabelecido em que formato de ficheiro exato deve ocorrer essa apresentação — isso será especificado posteriormente. No entanto, é claro que este registo é um fluxo de apresentação separado além do passaporte que é acessível através do código QR. Mais informações sobre o que deve incluir estão na página sobre o que é o registo de passaportes digitais de produtos e o que deve incluir.

Onde as coisas correm mal na prática

Estabelecer demasiado cedo num formato rígido. Algumas empresas estão agora a ter passaportes em PDF construídos porque é rápido e reconhecível, enquanto o requisito final provavelmente exigirá dados estruturados e legíveis por máquinas. Um PDF é legível para as pessoas, mas não é automaticamente adequado para a interoperabilidade que o artigo 10.º do ESPR pretende.

Dados dispersos por múltiplos sistemas sem ligação. As informações de produtos encontram-se frequentemente parcialmente no sistema ERP, parcialmente em documentos de marketing, parcialmente junto de um fornecedor externo. Sem um plano para reunir tudo isto, será difícil depois mudar rapidamente assim que o formato obrigatório for conhecido. As empresas que consideram ter o seu próprio sistema a funcionar encontram mais informações sobre as possibilidades na página sobre a integração do passaporte de produto num sistema ERP ou de inventário próprio.

Confusão entre o próprio passaporte e o registo. O passaporte consultável através do código QR e os dados que constam do registo não são automaticamente idênticos em forma ou formato. Presumir que um único ficheiro é suficiente para ambos os fins é um risco que só se torna visível quando os actos de execução se tornam concretos.

Não ter em conta múltiplos níveis de produto. Para produtos vendidos em embalagens compostas, ou onde um aparelho consiste em múltiplas partes com o seu próprio passaporte, a questão de como os formatos de dados se articulam é ainda mais complexa. Isto aplica-se por exemplo a uma caixa com múltiplos aparelhos dentro e a produtos que requerem múltiplos passaportes de produto.

Atenção insuficiente à legibilidade a longo prazo. Um formato de ficheiro que é actualmente comum pode não permanecer assim durante um período mais longo. Como o passaporte deve manter-se acessível durante um determinado período, a escolha do formato é também uma questão sobre durabilidade — ver a explicação sobre quanto tempo um passaporte de produto deve permanecer disponível.

O que pode registar

Um levantamento de onde os dados de produtos são atualmente registados (ERP, PIM, folhas de cálculo, documentos de fornecedores) e em que formato.
Uma lista de fontes de dados obrigatórias por categoria de produto, assim que o acto delegado para essa categoria for publicado.
Acordos com fornecedores e subfornecedores sobre o formato em que fornecem os seus dados de produto, para que a articulação seja mais fácil posteriormente.
Uma pessoa responsável interna ou equipa que acompanhe o desenvolvimento das normas técnicas, uma vez que o artigo 11.º do ESPR receberá especificações adicionais sobre este assunto.
Documentação sobre o método de identificação escolhido por produto, independentemente do formato de ficheiro final.
Um levantamento dos requisitos de alojamento e disponibilidade, que juntamente com o formato determinam como o passaporte é configurado tecnicamente — ver a página sobre que requisitos de alojamento se aplicam.

Esta não é aconselhamento jurídico. Esta página fornece informações gerais sobre a regulação sobre a qual esta plataforma versa. Não conhecemos a sua situação. Se tiver dúvidas sobre o seu caso específico, consulte um jurista ou a autoridade competente de supervisão.

Escrito com IA com base nas fontes acima, verificado por um ser humano a 2026-09-05. Há algo que não esteja correto? Avise-nos — as correções têm prioridade.