Tenho de registar quanto tempo um aparelho recebe actualizações de software?

O apoio ao software ainda não é uma obrigação firme

Um período obrigatório para atualizações de software ainda não está definido. O Regulamento-quadro ESPR (Regulamento (UE) 2024/1781) fornece a base legal para tornar isso obrigatório por categoria de produto, mas o requisito real — por quanto tempo um fabricante deve continuar fornecendo atualizações e se esse período deve constar no passaporte do produto digital — será estabelecido apenas através de um ato delegado para o grupo de produtos específico. Para equipamentos de eletrônica e TIC, esse ato ainda não existe. Até que exista, não há obrigação geral e executável de estabelecer um período de atualização no passaporte, mesmo que a obsolescência de software seja precisamente o tipo de tema de sustentabilidade que o ESPR visa.

Relevante para produtos com software, não para todos

Este tópico aplica-se a dispositivos cuja funcionalidade depende de software: eletrodomésticos com funções inteligentes, equipamentos de TIC e eletrônica mais ampla com firmware ou software de sistema operacional. Para produtos puramente mecânicos sem software, a questão simplesmente não se coloca. Também dentro do setor eletrónico: o ESPR funciona com atos delegados por subcategoria, portanto um requisito que se aplica aos smartphones não se aplica automaticamente a uma máquina de lavar ou a um router. O próprio Regulamento-quadro (artigos 5.º a 7.º) lista o tipo de requisitos que podem ser estabelecidos — incluindo durabilidade, fiabilidade e adequação para reparação e atualização — mas ainda não os traduz num número concreto de anos para um produto concreto. Quem agora procura um período firme para um dispositivo específico não o encontrará em parte alguma do texto atual do ESPR.

Ainda sem data: atos delegados por categoria

Não há data fixa para quando isto se aplicará à eletrônica e TIC. De acordo com o Plano de trabalho ESPR 2025-2030, os atos delegados por subcategoria serão elaborados, com a expectativa de que os primeiros apareçam a partir de 2027. Esta é uma indicação do plano de trabalho, não um compromisso nem uma lei. Até que um ato delegado para um grupo de produtos específico seja publicado, aplicam-se a esse grupo as disposições gerais do ESPR (artigos 5.º a 7.º para os requisitos substantivos, artigo 10.º para o que deve constar no passaporte do produto digital) sem que deles resulte já um período de atualização concreto. Assim que um ato delegado para eletrônica ou TIC for publicado, a data e o conteúdo desse requisito constarão aqui.

O que isto significa: ordem de ação

Quem se quiser preparar para isto, começa por consultar a sua própria categoria de produto no Plano de trabalho ESPR e acompanha a partir daí a publicação do ato delegado correspondente — este é o momento em que fica claro se, e por quanto tempo, um período de atualização se torna obrigatório e se deve constar no passaporte do produto digital. Até à publicação desse ato, não existe obrigação legal de incluir esta informação num passaporte, mas nada impede um fabricante de registar internamente agora há quanto tempo o apoio ao software é prometido por linha de produto — isto é então um compromisso próprio e voluntário, não uma obrigação do ESPR. Para quem está a fazer elaborar um passaporte do produto digital, isto significa concretamente: a estrutura atual do passaporte ainda não precisa de conter este campo, mas assim que o ato delegado para a subcategoria relevante o exigir, esse campo será adicionado ao passaporte e preenchido com os dados fornecidos pelo fabricante ou importador nessa altura. Quem regista agora dados sobre apoio ao software — que modelos, que períodos, que políticas de atualização — tem assim uma vantagem no momento em que o requisito se concretiza, porque esses dados já estarão disponíveis para serem incorporados no passaporte.

A base: artigos 5.º a 7.º e artigo 10.º

A possibilidade de estabelecer requisitos para o suporte de software decorre dos artigos 5 a 7 da ESPR (Regulamento (UE) 2024/1781), que estabelecem o quadro para o design ecológico: requisitos de desempenho como durabilidade, fiabilidade e aptidão para atualização, e requisitos de informação sobre estes. Estes artigos identificam as categorias de requisitos que podem ser desenvolvidos através de actos delegados por grupo de produtos, mas não estabelecem por si próprios um prazo concreto de atualização. O artigo 10 do mesmo regulamento estabelece o que deve ser incluído no passaporte digital do produto; aqui também se aplica que os campos de dados precisos são determinados por categoria de produto, com base nos requisitos estabelecidos para essa categoria. Enquanto não for publicado um acto delegado para eletrónica e TIC que especificamente mencione o suporte de software, este tema permanece dentro do regulamento-quadro como uma possibilidade, não uma obrigação concreta.

Quem já está a trabalhar nesta questão fará melhor em acompanhar a publicação do acto delegado para a sua própria categoria de produto e, entretanto, pôr em ordem os seus próprios dados sobre suporte de software, para que fiquem prontos assim que o passaporte o solicitar.

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

O suporte de software pode tornar-se um requisito de conceção ecológica

O ESPR permite incluir, nos actos delegados, requisitos relativos à sustentabilidade de um produto, incluindo também a software: o tempo durante o qual um aparelho recebe atualizações funcionais e de segurança, e o que acontece à funcionalidade do aparelho quando esse suporte termina. Os artigos 5.º a 7.º do ESPR (Regulamento (UE) 2024/1781) mencionam isto como parte dos requisitos de desempenho e de informação que podem ser estabelecidos por grupo de produtos. Para equipamentos eletrónicos e TIC, trata-se de um dos tópicos considerados relevantes, tendo em conta o papel da software na vida útil de um aparelho — uma máquina de lavar ou um portátil que funcionam tecnicamente mas deixam de receber atualizações são frequentemente substituídos na prática. Para uma empresa com 10 a 100 colaboradores, isto significa que o departamento responsável pela informação do produto (geralmente o mesmo que já prepara os períodos de garantia e manuais de utilizador) terá de manter um novo dado: o período durante o qual as atualizações são entregues, por modelo de produto ou por versão de software.

A informação tem de estar disponível no passaporte do produto

O artigo 10.º do ESPR (Regulamento (UE) 2024/1781) descreve que informações devem ser incluídas no passaporte digital do produto assim que um acto delegado o estabeleça para um grupo de produtos. Quando a duração do suporte de software for um requisito para equipamentos eletrónicos, essa informação não apenas chegará a um manual ou website, mas também ao próprio passaporte — estruturada e ligada ao suporte de dados QR no produto. Para uma empresa de médio porte, isto significa que o período de atualização não pode ser determinado isoladamente pelo departamento de software e comunicado isoladamente pelo departamento de marketing: essa informação tem de estar no mesmo conjunto de dados que, por exemplo, o consumo de energia e a pontuação de capacidade de reparação. O que deve estar exatamente no passaporte varia por grupo de produtos; em que dados constam do passaporte de produto da eletrónica? está um resumo das categorias de dados que nele aparecem.

O período especificado deve corresponder à realidade

Estabelecer uma duração de suporte é um passo; honrá-la é outro. Se um fabricante se compromete com um período de atualizações no passaporte, a expectativa é que esse período seja realmente cumprido — e que as alterações (um ciclo de atualização encerrado mais cedo, uma aquisição que leve a um enfraquecimento da equipa de software) sejam processadas. Isto levanta a questão com que frequência os dados do passaporte devem manter-se atuais; ver com que frequência os dados devem manter-se atuais? para o que se sabe sobre o assunto. Para uma empresa desta dimensão, isto frequentemente significa que o compromisso sobre a duração das atualizações não é apenas feito pelo gestor de produto, mas é coordenado com a parte que efetivamente mantém a software — equipa interna ou fornecedor externo.

Onde as coisas correm mal na prática

Uma primeira situação: um fabricante menciona um período de atualização em material de marketing ("cinco anos de atualizações de segurança"), mas este compromisso não está registado em nenhum documento interno com uma data de início e fim. Assim que essa informação tiver de constar no passaporte, não há uma fonte única de onde extrair.

Uma segunda situação: a software de um aparelho é fornecida por um subcontratante (um fabricante de chips, um fornecedor de plataforma), e o importador que redige o passaporte do produto não sabe quanto tempo esse subcontratante garante suporte. A responsabilidade pela exatidão dos dados do passaporte repousa na parte que o faz preparar, mesmo que a informação subjacente venha de um terceiro.

Uma terceira situação: um aparelho é vendido em várias configurações (diferentes conjuntos de chips, diferentes versões de software por região de mercado), mas o período de atualização é especificado como um único número para todo o número de modelo. Numa inspecção posterior, verifica-se que algumas configurações têm um período de suporte mais curto do que outras.

Uma quarta situação: um dispositivo já vendido deixa de receber atualizações mais cedo do que o previsto devido a uma mudança estratégica, sem que esta mudança seja comunicada a quem gere o pasaporte. Os dados do pasaporte continuam a mostrar o período original, demasiado otimista.

Uma quinta situação: uma empresa assume que "suporte de software" diz respeito apenas a atualizações de segurança, enquanto as atualizações funcionais (novas funcionalidades, compatibilidade com novos acessórios) são tratadas separadamente — e a comunicação sobre isto para o cliente é inconsistente, sem clareza sobre qual das duas deve constar no pasaporte.

O que pode registar

Um documento interno por modelo de produto com o período de suporte de atualizações funcionais e de atualizações de segurança, cada um com uma data de início clara (por exemplo, introdução no mercado) e, se conhecida, data de fim.
Acordos com fornecedores de software ou subcontratados sobre a duração mínima de suporte que garantem, incluindo o que acontece em caso de aquisição, insolvência ou descontinuação de uma plataforma.
Um panorama de qual funcionalidade do dispositivo depende de atualizações de software, e o que acontece a essa funcionalidade assim que o suporte termina (por exemplo: o dispositivo continua a executar funções básicas, mas perde a ligação a uma aplicação).
Um processo para comunicar alterações no planeamento de atualizações (cessação antecipada, prorrogação) ao departamento que gere o pasaporte do produto, de modo que os dados não fiquem desatualizados em relação à realidade.
Distinção por versão ou variante de um modelo de produto, quando o suporte de software varia conforme o chipset ou a região de mercado.
Documentação da fonte da informação: o período indicado é um compromisso próprio ou uma garantia transmitida por um subcontratado? Isto é relevante assim que alguém perguntar em que se baseia um dado no pasaporte — ver também Descobri um erro no pasaporte do produto, e agora? sobre como lidar com dados incorretos ou desatualizados.

Assim que a ação delegada para eletrónica e TIC for publicada, ficar-se-á a saber concretamente quais dados são exatamente obrigatórios e em que forma. Até lá, construir um dossiê próprio e verificável sobre períodos de atualização é uma forma de não ter de reconstruir posteriormente o que foi uma vez prometido.

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 uma pessoa em 2026-08-22. Há algo que não esteja correto? Avise-nos — as correções têm prioridade.