Direito ao apagamento, artigo 17.º do RGPD, no PrestaShop: eliminar a conta sem partir o rasto fiscal em 2026

O artigo 17.º do RGPD: uma obrigação simples de enunciar, complexa de executar

«O cliente pode pedir a eliminação dos seus dados.» A frase é lapidar no artigo 17.º do RGPD. A sua aplicação numa loja PrestaShop ou WooCommerce com 5 anos de existência é tudo menos simples. Porque uma «eliminação de conta» bem feita tem de navegar entre quatro exigências contraditórias:

• O direito ao apagamento do cliente (RGPD, artigo 17.º).
• A obrigação de conservação dos registos contabilísticos durante 10 anos (artigo 123.º do CIRC e artigo 52.º do CIVA).
• A rastreabilidade fiscal das vendas (faturação certificada, SAF-T (PT), comunicação à AT).
• O direito de resposta a um eventual litígio (garantia legal de conformidade de 3 anos em Portugal, Decreto-Lei n.º 84/2021).

A questão prática: um módulo que apaga tudo brutalmente coloca a empresa em infração contabilística. Um módulo que não apaga nada coloca a empresa em infração ao RGPD, com sanções até 4 % do volume de negócios mundial. A boa prática é a pseudonimização seletiva: apagar o que não é necessário a uma obrigação legal e conservar o resto numa forma não associável a uma pessoa identificada.

O que o artigo 17.º do RGPD diz exatamente

O artigo 17.º, n.º 1, enumera seis motivos que justificam o pedido de apagamento:

1. Os dados deixaram de ser necessários para a finalidade que motivou a recolha.
2. A pessoa retira o consentimento e não existe outro fundamento jurídico.
3. A pessoa opõe-se ao tratamento e não existe interesse legítimo prevalecente.
4. Os dados foram tratados ilicitamente.
5. Os dados têm de ser apagados para cumprir uma obrigação jurídica.
6. Os dados foram recolhidos no contexto da oferta de serviços a uma criança.

Mas o artigo 17.º, n.º 3, prevê cinco exceções que se aplicam com frequência ao comércio eletrónico:

1. Exercício da liberdade de expressão e de informação.
2. Cumprimento de uma obrigação jurídica (por exemplo: conservação contabilística).
3. Motivos de interesse público no domínio da saúde pública.
4. Fins de arquivo, investigação científica ou histórica, estatística.
5. Declaração, exercício ou defesa de um direito num processo judicial.

A exceção (b), obrigação jurídica, é a que se aplica aos dados contabilísticos. Mas não cobre todos os dados de uma conta de cliente: apenas os estritamente necessários à tenuta da contabilidade e ao cumprimento do prazo de conservação (10 anos).

Cartografar os dados de uma conta de cliente

Numa loja PrestaShop com 5 anos de histórico, uma conta de cliente contém tipicamente:

A regra de triagem: este dado é necessário ao rasto contabilístico ou a um eventual litígio? Se sim, conserva-se em forma pseudonimizada. Se não, apaga-se.

Pseudonimização: o mecanismo central

Pseudonimizar não é anonimizar. A diferença é jurídica e técnica:

• Anonimização: supressão irreversível da ligação entre o dado e a pessoa. O dado nunca mais pode ser associado. A anonimização retira o dado do perímetro do RGPD.
• Pseudonimização: substituição dos identificadores diretos por um pseudónimo, mas a ligação continua teoricamente reconstruível (por exemplo, através de uma tabela de correspondência cifrada). O dado continua no perímetro do RGPD, mas o tratamento é considerado menos arriscado.

No comércio eletrónico, procura-se geralmente uma pseudonimização forte que se aproxima de uma anonimização prática:

• customer.firstname → "Cliente"
• customer.lastname → "#" + id_customer (por exemplo "#42851")
• customer.email → "deleted-" + id_customer + "@invalid" (prefixo especial, domínio inválido)
• customer.phone → NULL
• customer.passwd → bytes aleatórios (conta efetivamente inutilizável)
• customer.note → NULL
• address.firstname, address.lastname nas moradas antigas → pseudónimo
• address.firstname, address.lastname na morada de faturação das encomendas existentes → conservar (necessários à fatura)

A chave está na nuance: guarda-se a fatura tal como foi emitida (obrigação contabilística), mas apaga-se tudo o que já não serve.

Arquitetura de um módulo de eliminação conforme

Um módulo sério para PrestaShop, como o DfAccountDelete, implementa cinco camadas:

Camada 1: identificação do pedido

Três canais possíveis:

• Botão na área de cliente: «Eliminar a minha conta», acessível a partir de «Os meus dados». UX de autosserviço.
• Formulário de pedido: para os antigos clientes que já não conseguem iniciar sessão. Verificação de identidade por e-mail com ligação de confirmação.
• Pedido ao encarregado de proteção de dados: por e-mail ou carta, tratado manualmente e registado no sistema.

Camada 2: verificação de identidade

Antes de apagar, confirma-se que a pessoa é mesmo a titular da conta. Para os clientes autenticados: a sessão iniciada mais a introdução da palavra-passe ou validação por e-mail. Para os não autenticados: envio de um e-mail de confirmação com ligação de uso único e duração limitada (tipicamente 1 hora). Para os pedidos por carta: cópia de documento de identificação conservada 1 ano e depois destruída.

Camada 3: prazo de reflexão

Opcional mas recomendado: um prazo de 7 a 30 dias entre o pedido e a execução efetiva. O utilizador recebe um e-mail «o seu pedido será tratado em [data], clique aqui para cancelar». Evita as eliminações acidentais e os arrependimentos.

Camada 4: execução da pseudonimização

O módulo executa numa transação MySQL atómica:

1. Pseudonimiza ps_customer (nome, e-mail, telefone, entre outros).
2. Pseudonimiza as ps_address não associadas a encomendas finalizadas.
3. Apaga os ps_cart abandonados, ps_compare, ps_wishlist.
4. Apaga as entradas de programa de fidelização, alertas de preço, alertas de stock.
5. Anonimiza as avaliações públicas («Cliente anónimo») ou apaga-as consoante a política.
6. Apaga os registos de sessão, tokens de magic link, carrinhos guardados.
7. Apaga as subscrições de newsletter (e propaga ao Mailchimp e ao Brevo por API, se ligados).
8. Marca a conta como eliminada (active=0, deleted=1, deleted_at = agora).
9. Conserva intactas as encomendas, faturas e notas de crédito (ps_orders, ps_order_invoice, ps_order_slip).

Camada 5: registo de auditoria e notificação

Uma entrada num registo de auditoria RGPD:

• Data do pedido, data da execução.
• E-mail de origem (antes da pseudonimização).
• ID do cliente.
• Método de verificação de identidade.
• Lista das tabelas afetadas e número de linhas alteradas.

Este registo é conservado 3 anos, prazo razoável para demonstrar a conformidade. Serve em caso de inspeção da CNPD ou de pedido da pessoa («apagaram mesmo os meus dados?»).

É enviado um e-mail de confirmação para o endereço de origem, com menção de que os dados foram apagados exceto os necessários à contabilidade (transparência, artigo 12.º do RGPD).

A ponte com a faturação: o que é preciso preservar sem falta

Certos dados são necessários à faturação certificada e ao SAF-T (PT) que a AT pode exigir:

• Identificação do cliente na fatura emitida (nome, NIF se o cliente o indicou, morada de faturação no momento da emissão). Mas não é preciso que esse nome continue localizável a partir da base de clientes viva: está na fatura arquivada e em ps_orders.
• Montantes sem IVA, IVA, portes, total com IVA: dados contabilísticos puros, a conservar intactos.
• Data da encomenda, da fatura, do pagamento: idem.
• Método de pagamento (Stripe, PayPal, Multibanco, transferência): útil para a reconciliação bancária.

O padrão prático: pseudonimiza-se ps_customer, mas deixam-se ps_orders.firstname, ps_orders.lastname e ps_orders.email tal como estavam no momento da encomenda. É o que aparece na fatura emitida. A fatura é o registo contabilístico, imutável. A conta de cliente é um agregado vivo, que se pode anonimizar.

No PrestaShop, esta lógica é facilitada pelo facto de a fatura ser gerida por ps_order_invoice com os seus próprios campos (o nome não é só referenciado por id_customer, fica também congelado na encomenda). No WooCommerce é mais delicado: as encomendas guardam o ID do cliente e reconstroem a informação na exibição. É preciso congelar o nome e a morada de faturação na encomenda no momento da pseudonimização, senão a fatura regenerada mostra «Cliente anónimo». E, em qualquer plataforma, a fatura fiscalmente válida está no software certificado, que tem as suas próprias obrigações de conservação.

As avaliações e os comentários: um caso à parte

Uma avaliação de produto exibida publicamente com o nome do cliente é um dado pessoal (artigo 4.º do RGPD). O seu apagamento a pedido coloca dois problemas:

• O conteúdo da avaliação tem valor para os outros clientes (informação ao consumidor).
• O histórico das avaliações serve à média de classificação.

A resolução jurídica normal: anonimizar o nome («Cliente anónimo» ou «C.A.»), conservar o conteúdo da avaliação e a nota. É um tratamento estatístico no sentido do artigo 17.º, n.º 3, alínea d). Se o cliente pedir explicitamente o apagamento completo da avaliação («não quero que este texto continue a existir»), apaga-se por inteiro, e recalcula-se a média sem o dado perdido.

Esta nuance deve ser apresentada ao utilizador no formulário: «Quer apagar as suas avaliações ou torná-las anónimas?».

Casos particulares difíceis

Conta de cliente com litígio em curso

Se uma encomenda está em litígio (devolução bloqueada, contestação, acionamento da garantia), o apagamento dos dados do cliente compromete a defesa da empresa. O artigo 17.º, n.º 3, alínea e), cobre este caso: pode recusar o apagamento até à resolução do litígio, informando o cliente da razão. A conservação faz-se com estatuto «em litígio» e acesso restrito.

Conta B2B com vários utilizadores

Numa conta B2B com vários utilizadores, o apagamento da conta de um utilizador não deve apagar a empresa. Apaga-se o utilizador (que tem um direito individual) e conservam-se as encomendas em nome da empresa (que, sendo pessoa coletiva, não tem direito ao apagamento).

Newsletter sem conta (anónima)

Um e-mail inscrito na newsletter sem conta de cliente: o apagamento é imediato, sem pseudonimização. Não há obrigação contabilística associada. Uma exceção: se o consentimento de marketing for registado para prova, pode conservar-se o histórico do consentimento (data, IP, opt-in) durante 3 anos depois da anulação da subscrição. Depois disso, apagamento completo.

Subscritores de um serviço recorrente

Nas lojas com subscrições, o apagamento da conta exige primeiro a paragem da subscrição (é impossível cobrar um cartão de uma conta que já não existe). O módulo tem de sequenciar: cancelamento das subscrições, espera de um ciclo para confirmação, pseudonimização. Saltar a sequência causa cobranças órfãs e contencioso com os clientes.

O prazo de resposta imposto pelo RGPD

Artigo 12.º, n.º 3, do RGPD: a resposta a um pedido deve ocorrer no prazo de 1 mês, prorrogável por mais 2 meses nos pedidos complexos, com notificação da prorrogação ao requerente. Na prática, no comércio eletrónico:

• Pedido simples pelo botão «eliminar a minha conta»: execução imediata (com o prazo de reflexão opcional), muito abaixo do prazo legal.
• Pedido por e-mail ou carta que exige verificação de identidade: 1 a 2 semanas de tratamento, abaixo do mês.
• Pedido em contexto complexo (litígio, subscrição ativa, várias contas): 1 mês com informação ao requerente sobre o estado.

O incumprimento do prazo expõe a sanções da CNPD. Um módulo automatizado que responde em 24 a 48 h cobre largamente o risco.

Custo e retorno

O retorno de um módulo de eliminação de conta conforme mede-se de forma diferente de um módulo de conversão:

• Custo do módulo: 39 € de licença para PrestaShop.
• Custo evitado de uma sanção: variável, mas as sanções aplicadas a lojas online na Europa entre 2023 e 2025 vão de alguns milhares de euros para PME a vários milhões para as grandes insígnias. A relação custo/risco é extremamente favorável.
• Custo evitado de tratamento manual: numa loja com 50 000 clientes, tratar 5 a 10 pedidos por mês à mão representa 2 a 4 horas mensais de trabalho interno, cerca de 1200 € por ano.
• Benefício de confiança: mostrar um botão «eliminar a minha conta» bem visível tornou-se um sinal de confiança forte em 2026, mensurável na taxa de criação de contas (3 % a 6 % a mais observados).

FAQ

É mesmo preciso guardar as encomendas 10 anos depois de eliminar a conta?

Sim, é a obrigação contabilística e fiscal (artigo 123.º do CIRC, artigo 52.º do CIVA). O RGPD não dispensa do direito fiscal. A resolução: as encomendas ficam na base em forma pseudonimizada (o nome do cliente já não está ligado a uma conta viva, mas continua na fatura emitida, como é necessário). Findos os 10 anos, o apagamento completo é possível.

O que fazer se o Mailchimp ou o Brevo continuar a enviar a newsletter?

O artigo 19.º do RGPD impõe a propagação do apagamento aos destinatários dos dados. Se sincronizou a base com o Mailchimp, o Brevo ou o Klaviyo, o módulo tem de chamar a respetiva API para apagar o contacto, e não apenas anular a subscrição. É um ponto a validar na instalação: todos os conectores de marketing têm de receber o sinal de apagamento.

Como gerir o apagamento nos subcontratantes (Stripe, PayPal)?

O Stripe e o PayPal conservam os tokens de pagamento e o histórico das transações segundo a sua política, em geral 10 anos por conformidade fiscal e combate ao branqueamento de capitais. Não pode forçar o apagamento: é a obrigação legal deles, distinta da sua. A menção na política de privacidade deve indicar que os subcontratantes de pagamento conservam os dados segundo o seu próprio prazo legal.

Pode-se eliminar uma conta sem informar o cliente?

Se foi o cliente a pedir a eliminação: informa-se da execução. Se é a empresa que elimina por iniciativa própria (inatividade prolongada, por exemplo): tem de ter previsto essa política nas condições gerais e na política de privacidade, e idealmente notificar 30 dias antes para permitir a oposição. A eliminação sem notificação é arriscada.

Quanto tempo depois de um pedido de apagamento pode um cliente voltar?

O direito ao apagamento não é um direito à reversão. Depois de os dados serem apagados (ou pseudonimizados), o cliente que volta cria uma conta nova do zero. O histórico fica no registo de auditoria RGPD (que serve para provar que o pedido foi executado), mas não pode ser reutilizado para reconstituir a conta inicial.

Em síntese

A eliminação de conta conforme ao artigo 17.º do RGPD é um exercício de equilíbrio entre quatro obrigações legais contraditórias. A resolução passa pela pseudonimização seletiva: apaga-se ou anonimiza-se tudo o que não está coberto por uma obrigação de conservação, e conserva-se intacto o rasto contabilístico necessário à faturação certificada e ao controlo fiscal.

O módulo DfAccountDelete para PrestaShop implementa esta lógica com as cinco camadas de um fluxo conforme: identificação, verificação de identidade, prazo de reflexão opcional, pseudonimização atómica, registo de auditoria. Preserva a cadeia contabilística e integra-se com as principais ferramentas de marketing (Mailchimp, Brevo, Klaviyo) para propagar o apagamento.

O bom reflexo em 2026: mostrar um botão «eliminar a minha conta» bem visível na área de cliente (sinal de confiança, conformidade explícita), documentar o fluxo na política de privacidade (transparência, artigo 12.º), conservar o registo de auditoria 3 anos para demonstrar a conformidade em caso de inspeção da CNPD.

Para as lojas que querem uma auditoria completa da sua conformidade com o RGPD, a nossa auditoria PrestaShop cobre os seis pontos críticos: cookies e consentimento, fundamento do tratamento dos dados de clientes, prazos de conservação parametrizados, direito de acesso e portabilidade, direito ao apagamento, registo das atividades de tratamento (artigo 30.º).