Durante décadas, pensar num “produto defeituoso” significava imaginar um objeto físico: um eletrodoméstico que provoca um incêndio, uma peça automóvel que falha ou um equipamento que causa uma lesão.
Esse conceito está prestes a tornar-se muito mais digital.
A Diretiva (UE) 2024/2853 reformula o regime europeu da responsabilidade por produtos defeituosos e adapta-o a uma realidade em que um produto pode continuar a mudar depois de sair da fábrica.
O software passa a estar expressamente incluído no conceito de produto. Isso abrange aplicações e sistemas de inteligência artificial. Serviços digitais necessários ao funcionamento de determinados produtos podem igualmente ficar abrangidos quando estejam integrados ou interligados com o produto sob controlo do fabricante.
A consequência é relevante para empresas tecnológicas e não tecnológicas:
um defeito já não tem necessariamente de estar num parafuso, numa bateria ou numa peça física. Pode estar no código.
O regime atual português ainda é anterior à economia digital
Em Portugal, o regime específico da responsabilidade objetiva por produtos defeituosos encontra-se atualmente no Decreto-Lei n.º 383/89, de 6 de novembro.
O diploma estabelece que o produtor responde, independentemente de culpa, pelos danos provocados por defeitos dos produtos que coloca em circulação. O conceito tradicional de produto assenta, porém, essencialmente numa “coisa móvel”, refletindo a realidade tecnológica da Diretiva europeia de 1985 que o diploma transpôs.
Quase quarenta anos depois, um automóvel pode receber novas funcionalidades remotamente, um dispositivo médico pode depender de software, um equipamento doméstico pode estar permanentemente ligado à cloud e um sistema de IA pode continuar a aprender depois de ter sido disponibilizado.
Foi precisamente para responder a esta transformação que a União Europeia aprovou a Diretiva (UE) 2024/2853.
O prazo para os Estados-Membros a transporem termina em 9 de dezembro de 2026. O novo regime europeu destina-se aos produtos colocados no mercado ou que entrem em serviço após essa data, mantendo-se o regime anterior para os produtos abrangidos pelas regras transitórias.
Para as empresas, isto significa que o momento para preparar contratos, documentação técnica, seguros e processos internos é agora — não depois de surgir o primeiro incidente.
Software passa a ser expressamente um produto
Esta é uma das alterações mais importantes.
A nova Diretiva clarifica que software pode constituir um produto para efeitos de responsabilidade por defeitos.
Estão incluídos diferentes tipos de software, incluindo aplicações e sistemas de inteligência artificial. A exceção mais relevante respeita ao software livre e de código aberto desenvolvido ou fornecido fora do âmbito de uma atividade comercial.
Imagine uma aplicação incorporada num equipamento que, devido a um erro, envia instruções incorretas.
Ou um software utilizado para controlar um dispositivo que provoca uma operação insegura.
Ou um sistema de IA integrado num produto que desenvolve posteriormente um comportamento perigoso.
A discussão já não terá necessariamente de começar pela pergunta:
“Qual foi a peça física que falhou?”
Poderá começar por:
“O software fazia parte do produto e apresentava um defeito de segurança?”
E se o problema surgir depois da venda?
Aqui a mudança é ainda mais significativa.
No mundo tradicional, o fabricante colocava um produto no mercado e, em princípio, perdia grande parte do controlo sobre ele.
Um produto digital pode funcionar de forma muito diferente.
Pode receber:
- atualizações;
- upgrades;
- novas funcionalidades;
- alterações remotas;
- componentes de software adicionais;
- modelos de IA atualizados;
- aprendizagem contínua.
A Diretiva tem esta realidade expressamente em conta.
Quando o fabricante continue a exercer controlo sobre software ou serviços relacionados, poderá existir responsabilidade por defeitos que surjam posteriormente através de atualizações, upgrades ou outros elementos digitais sob o seu controlo.
Isto altera a ideia de que a responsabilidade termina simplesmente porque o produto estava seguro no dia em que saiu da fábrica.
No ambiente digital, o produto pode continuar a evoluir.
E a responsabilidade pode acompanhar essa evolução.
Até um sistema de IA que continua a aprender pode criar responsabilidade
A Diretiva refere expressamente a capacidade de um produto continuar a aprender ou adquirir novas funcionalidades depois de colocado no mercado como um dos fatores relevantes para determinar se é defeituoso.
Esta questão é particularmente importante em sistemas de inteligência artificial.
Imagine-se um sistema que é seguro quando é disponibilizado, mas que continua a modificar o respetivo comportamento através de aprendizagem posterior.
Se essa evolução ocorrer dentro da esfera de controlo do fabricante e originar uma situação insegura, não será necessariamente suficiente alegar que o comportamento perigoso não existia na versão inicial.
A análise terá de considerar também a arquitetura do sistema, a utilização previsível, as atualizações e o controlo mantido pelo fabricante.
É uma lógica diferente da do software tradicional “entregue e terminado”.
Uma vulnerabilidade de cibersegurança também pode tornar um produto defeituoso
Este é talvez um dos desenvolvimentos mais relevantes para as empresas.
A nova Diretiva determina que, ao avaliar se um produto apresenta um defeito, devem ser considerados os requisitos de segurança aplicáveis — incluindo requisitos de cibersegurança relevantes para a segurança do produto.
Por outras palavras, um produto pode tornar-se perigoso não porque uma peça se partiu, mas porque possui uma vulnerabilidade explorável.
Imagine uma fechadura inteligente com uma falha de segurança.
Um automóvel conectado cujo software pode ser manipulado.
Um dispositivo médico vulnerável a acesso indevido.
Ou um equipamento doméstico conectado que deixa de receber atualizações essenciais.
A cibersegurança deixa, assim, de ser apenas uma questão de proteção de dados ou segurança informática.
Pode transformar-se numa questão de responsabilidade civil pelo próprio produto.
E se o fabricante não fornecer uma atualização de segurança?
Também aqui a Diretiva é particularmente relevante.
Quando o defeito resultar da falta de uma atualização ou upgrade de software necessário para manter a segurança, e essa atualização esteja sob controlo do fabricante, o operador económico não poderá simplesmente invocar o facto de o defeito ter surgido depois de o produto ter sido colocado no mercado para afastar a responsabilidade.
Isto não significa que a Diretiva crie, por si só, uma obrigação universal de atualizar indefinidamente todos os produtos.
Significa algo diferente:
quando existe uma atualização necessária à segurança e a situação se encontra dentro do controlo do fabricante, a falta dessa atualização pode ser relevante para a responsabilidade por danos.
A documentação sobre o período de suporte de um produto, atualizações previstas e fim de vida tecnológico passa, por isso, a assumir ainda maior importância.
Quem pode responder?
Outro erro seria pensar que esta responsabilidade diz respeito apenas à fábrica que produziu o objeto.
A nova Diretiva procura garantir que, numa cadeia de fornecimento moderna, exista um operador económico dentro da União Europeia contra o qual o lesado possa exercer os seus direitos.
Dependendo do caso, poderão estar em causa:
- o fabricante do produto;
- o fabricante de um componente;
- o fornecedor de software;
- quem modifique substancialmente um produto;
- o importador;
- o mandatário do fabricante;
- determinados prestadores de serviços de execução;
- distribuidores em certas circunstâncias;
- determinadas plataformas em linha.
Uma empresa que importa produtos tecnológicos para a União Europeia não deve, portanto, assumir que toda a responsabilidade permanece automaticamente do outro lado do mundo.
Modificar um produto também pode transformar uma empresa em “fabricante”
A economia circular introduz outro cenário interessante.
Produtos são reparados, atualizados, reconstruídos, modificados e colocados novamente no mercado.
A nova Diretiva prevê que uma pessoa ou empresa que efetue uma modificação substancial de um produto fora do controlo do fabricante original possa ser tratada como fabricante do produto modificado para efeitos de responsabilidade.
Isso pode tornar-se relevante para empresas que:
adaptam equipamentos;
instalam novos sistemas;
alteram significativamente funcionalidades;
recondicionam determinados produtos;
ou integram componentes digitais que transformam o funcionamento original.
A questão jurídica passa a ser não apenas “quem produziu isto inicialmente?”, mas também:
“quem transformou o produto que efetivamente chegou às mãos do utilizador?”
O marketplace também deve prestar atenção
A cadeia de responsabilidade pode ainda alcançar determinadas plataformas em linha.
Quando uma plataforma desempenha o papel de fabricante, importador, mandatário, prestador de serviços de execução ou distribuidor, pode responder nos mesmos termos do operador económico correspondente.
Mesmo uma plataforma que atue como intermediária pode, em determinadas condições previstas no regime europeu, vir a ser responsabilizada.
Para marketplaces, isto torna particularmente importante saber:
quem é o fabricante;
quem introduziu o produto na União;
quem é o operador económico responsável;
que informação é disponibilizada ao consumidor;
e como são tratados produtos potencialmente inseguros.
Que danos passam a estar abrangidos?
A Diretiva abrange danos resultantes de morte e lesões pessoais, incluindo determinados danos à saúde psicológica clinicamente reconhecidos.
Abrange igualmente danos patrimoniais nos termos nela previstos.
E introduz uma novidade particularmente adaptada à economia digital: a destruição ou corrupção de dados que não sejam utilizados para fins profissionais pode constituir dano indemnizável.
Isto mostra até que ponto o conceito de dano associado a um produto se afastou da imagem tradicional de um objeto fisicamente destruído.
O dano também pode ser digital.
A vítima continua a ter de provar tudo?
Em princípio, quem pede indemnização deve demonstrar o dano, o defeito do produto e a relação causal entre ambos.
Mas provar tecnicamente que um algoritmo, firmware ou sistema complexo provocou determinado dano pode ser extremamente difícil para um consumidor.
A Diretiva procura reduzir essa assimetria.
Prevê mecanismos de acesso a elementos de prova e estabelece presunções em determinadas situações destinadas a facilitar a prova do defeito ou do nexo causal, especialmente quando a complexidade técnica torne excessivamente difícil ao lesado demonstrar todos os elementos através dos meios habituais.
Para as empresas, esta mudança tem outra consequência:
a capacidade de documentar como o produto foi concebido, atualizado, testado e mantido passa a ter ainda maior importância em caso de litígio.
O contrato com o developer torna-se ainda mais importante
Imagine uma empresa que fabrica um equipamento, mas subcontrata todo o software a uma empresa externa.
O consumidor não conhece essa divisão contratual.
Vê um único produto.
Se o software provocar um dano, podem surgir posteriormente questões de responsabilidade e regresso entre os vários intervenientes na cadeia.
Por isso, contratos tecnológicos deverão definir claramente matérias como:
- especificações e requisitos de segurança;
- obrigações de atualização;
- correção de vulnerabilidades;
- duração do suporte;
- testes e validação;
- documentação técnica;
- comunicação de incidentes;
- cooperação em investigações e reclamações;
- responsabilidade entre os intervenientes;
- seguros;
- conservação de evidência técnica.
Um contrato que diga apenas “o fornecedor desenvolverá a aplicação” poderá revelar-se insuficiente para um produto destinado a permanecer operacional durante vários anos.
Um exemplo simples: a máquina continua igual, mas o software muda
Uma empresa vende uma máquina conectada em janeiro de 2027.
Fisicamente, o equipamento não sofre qualquer alteração.
Seis meses depois recebe uma atualização remota.
Essa atualização introduz um erro.
A máquina passa a executar determinada operação de forma insegura e provoca uma lesão.
No modelo clássico, poderia existir a tentação de perguntar apenas se a máquina estava defeituosa quando foi vendida.
No novo regime, a análise é mais ampla.
Será necessário perceber quem controlava a atualização, quem a desenvolveu, quem a autorizou, se a utilização era previsível, se existiam requisitos de segurança aplicáveis e se o produto continuava sob controlo relevante do fabricante.
É precisamente por isto que a responsabilidade por produtos deixa de ser apenas uma questão do departamento de qualidade.
Passa a envolver também IT, cibersegurança, contratos, desenvolvimento de produto e gestão jurídica.
O que devem as empresas fazer antes de dezembro de 2026?
Não é necessário esperar pela primeira reclamação.
Uma empresa que fabrica, importa, distribui ou integra tecnologia pode começar por mapear os produtos relativamente aos quais poderá assumir responsabilidade.
Depois deve identificar que componentes físicos, software, sistemas de IA e serviços digitais fazem parte de cada produto.
Convém igualmente saber quem controla atualizações e upgrades, durante quanto tempo existirá suporte, como são identificadas vulnerabilidades e que documentação demonstra as decisões tomadas ao longo do ciclo de vida.
Os contratos com fornecedores e developers devem ser revistos à luz dessa realidade.
E também vale a pena verificar se os seguros de responsabilidade contratados correspondem efetivamente ao risco criado por produtos cada vez mais digitais.
Quando faz sentido procurar a OpenLexis?
Uma empresa pode cumprir tecnicamente os requisitos de desenvolvimento e, ainda assim, ter uma cadeia contratual mal estruturada.
Ou pode ter excelentes contratos, mas não saber que determinado software a aproxima juridicamente da posição de fabricante.
Ou importar um produto acreditando que a responsabilidade pertence exclusivamente ao fabricante estrangeiro.
É precisamente neste cruzamento que uma análise inicial pode evitar problemas posteriores.
Na OpenLexis podemos ajudar a identificar:
- que posição a empresa ocupa na cadeia de fornecimento;
- quais os riscos jurídicos associados aos produtos que comercializa;
- que contratos devem ser revistos;
- como estruturar responsabilidades com developers e fornecedores;
- que documentação deve ser preservada;
- que impacto a nova Diretiva poderá ter no modelo de negócio;
- quando é necessário recorrer a advogado, especialista técnico, seguradora ou outro profissional.
A avaliação técnica da segurança de um produto ou software pertence naturalmente aos profissionais especializados nessa matéria.
Mas saber quem pode responder juridicamente quando alguma coisa falha deve ser pensado antes do incidente.
A pergunta já não é apenas:
“quem fabricou o produto?”
Nos produtos digitais, a pergunta passa também a ser:
“quem controlava o software, as atualizações e a segurança quando o dano aconteceu?”