Erros comuns de retencao e eliminacao que equipas SaaS ainda cometem

Erros de retencao e eliminacao surgem quando uma empresa SaaS trata o tema como uma politica e nao como uma operacao. No GDPR, dados pessoais nao devem ser guardados por mais tempo do que o necessario, devem existir prazos de eliminacao ou review, e o direito ao apagamento pode exigir acao concreta. A dificuldade esta em provar isso em sistemas, tickets, vendors, backups e evidencia de auditoria.

Os erros mais comuns sao triggers pouco claros, regras sem mapa de sistemas, excecoes informais, promessas irrealistas sobre backups e evidencia fraca.

Porque ainda falha

Em papel parece simples: dados de clientes por um periodo, tickets de suporte por outro, dados de candidatos apos o processo e backups por rotacao. Na pratica, os mesmos dados podem estar na app, warehouse, CRM, helpdesk, logs, analytics, billing, exports, drives e ambientes de fornecedores. Sem mapa, a eliminacao e parcial.

Erro 1: politica sem mapa de sistemas

Uma retention schedule deve ligar regras a sistemas reais. Para cada workflow, documente onde os dados vivem, quem e owner, que acao e possivel e que evidencia fica. Comece por account closure, pedidos de apagamento, tickets de suporte, employee records, vendor offboarding, analytics e logs.

Erro 2: duracao sem trigger

"Guardar tres anos" nao explica quando o relogio comeca. Pode ser churn, fatura final, desativacao de conta, fecho de ticket ou fim de obrigacoes contratuais. O trigger deve ser um evento operacional verificavel.

Erro 3: entregar tudo a engineering

Engineering executa muita coisa, mas legal, privacy, security, support, finance, product e procurement tambem decidem ou controlam partes do fluxo. Defina quem decide a regra, deteta o trigger, aprova excecoes, executa e guarda evidencia.

Erro 4: minimizacao tarde demais

Eliminar e mais dificil quando se recolheu demasiada informacao. Forms, analytics, anexos de suporte, integracoes e campos livres espalham dados pessoais. Cada feature deve perguntar se o dado e necessario, se dados anonimos ou agregados chegam, onde ha copias e que regra de retencao se aplica.

Erro 5: esquecer backups

Sistemas live podem apagar rapidamente, enquanto backups expiram por rotacao. Alguns sao imutaveis ou nao permitem remocao por registo. Separe live deletion, anonimizacao, backup expiry, restore controls e legal holds. O EDPB destacou em 2026 backups e periodos de retencao como desafios praticos.

Erro 6: tratar todos os pedidos igual

O direito ao apagamento nao e absoluto. Obrigacoes legais, interesse publico ou defesa de direitos podem justificar retencao limitada. Use uma decision tree: identidade e scope, sistemas e vendors, fundamento para apagamento, excecoes, acao e documentacao.

Erro 7: perder evidencia

Um script, um email do fornecedor e um ticket fechado nao bastam se nao conectarem regra, trigger, decisao, owner, acao e data. A evidencia deve ser simples, mas consistente.

Erro 8: nao rever apos mudancas de produto

Novas integracoes, tabelas analytics, logs de AI, screenshots de suporte ou migracoes billing mudam o scope. Launches de maior risco devem responder: que dados pessoais, que copias, que owner, que eliminacao, que evidencia?

Checklist pratica

• Cada regra esta ligada a sistemas e vendors.
• O trigger e um evento claro.
• Owners de decisao, execucao e evidencia estao definidos.
• Backups, arquivos e exports sao tratados separadamente.
• Excecoes e legal holds estao documentados.
• Promessas a clientes correspondem a realidade tecnica.

Comece com um workflow concreto, como encerramento de conta ou pedido de apagamento. Um processo pequeno e executavel vale mais do que uma politica ampla sem prova.