Antes de Guardar Mais Um Campo, Pergunte Se Precisa Dele

Introdução: A Pergunta Que Quase Ninguém Faz

Tem uma pergunta que quase nenhum sistema foi feito para responder: por que você guarda esse dado?

O caminho natural é guardar tudo. Por precaução. Porque um dia pode ser útil. Porque ninguém teve coragem de apagar.

Nada disso parece problema até o dia em que é.

O Que Costuma Acabar No Banco

Olhando para sistemas reais, o padrão se repete:

• CPF no cadastro porque, um dia, pode ser necessário. Não foi.
• Endereço completo de quem só compra produto digital.
• Data de nascimento que nunca foi usada para nada.
• Cópia de documento que alguém mandou pelo WhatsApp e acabou numa pasta compartilhada.
• Log com dados do cliente dentro, guardado para sempre.

Cada um desses campos foi uma decisão pequena e razoável. Juntos, formam um passivo grande.

Dado Guardado Não Fica Neutro

Dado guardado tem custos que aparecem depois:

1. Precisa ser protegido. Criptografia, controle de acesso, backup, auditoria.
2. Precisa ser localizado quando alguém pedir informações sobre si.
3. Precisa ser apagado quando alguém exigir a exclusão.
4. Vira sua responsabilidade se vazar, mesmo que você nunca tenha usado o campo.

Você assumiu todo esse custo por um campo que nunca foi usado uma vez sequer.

No Brasil, isso também tem nome na lei. A LGPD (Lei 13.709/2018) traz o princípio da necessidade: a coleta deve se limitar ao mínimo necessário para a finalidade. Não é só boa prática de engenharia. Para a empresa, é obrigação. Se quiser entender o texto exato, vale ler o artigo 6º diretamente, ou consultar um advogado para o seu caso.

A Inversão Que Resolve Grande Parte Disso

Em vez de perguntar o que guardar, pergunte o que dá para não ter.

Na prática, são quatro perguntas por campo do cadastro:

1. Esse dado é usado por alguma funcionalidade hoje?
2. Se não é, por quanto tempo ainda faz sentido mantê-lo?
3. Quem dentro da empresa precisa enxergar isso?
4. O que acontece se ele vazar amanhã?

Campo que não passa na primeira pergunta não deveria estar sendo coletado.

Campo que passa, mas tem prazo de validade, deveria ter descarte automático. Não pode depender de alguém lembrar de limpar.

Como Isso Vira Código

Uma forma simples de tornar a retenção explícita:

// Cada campo sensível declara por que existe e até quando
export const customerFieldPolicy = {
  cpf: {
    purpose: 'emissão de nota fiscal',
    retentionDays: 365 * 5,
    accessRoles: ['finance'],
    collectedWhen: 'nota fiscal solicitada',
  },
  birthDate: {
    purpose: null, // nenhuma funcionalidade usa
    retentionDays: 0,
    accessRoles: [],
    collectedWhen: null,
  },
} as const;

// Job que roda diariamente e aplica a política
export async function purgeExpiredFields() {
  for (const [field, policy] of Object.entries(customerFieldPolicy)) {
    if (policy.retentionDays === 0) {
      await db.customers.updateMany({}, { [field]: null });
    }
  }
}

O ponto não é o código exato. É que a finalidade, o prazo e o acesso ficam escritos em algum lugar, e alguém consegue responder sobre eles sem investigar.

Um campo com purpose: null é um sinal de alerta. Quase sempre é um campo que deveria nem existir.

Trade-offs: Quando Guardar Faz Sentido

Nem todo dado deve sumir. Alguns exigem guarda por motivo legal, fiscal ou contratual. Por exemplo, dados de nota fiscal costumam ter prazo definido pela legislação tributária.

A diferença é que cada retenção tem um motivo escrito. Guardar por obrigação é diferente de guardar por hábito.

E cuidado com o caminho oposto: apagar dado que ainda é necessário para um processo em andamento, como uma disputa ou uma cobrança aberta. Minimização não é apagar tudo. É guardar com critério.

Checklist de Minimização

• Cada campo do cadastro tem uma finalidade escrita?
• Existe algum campo coletado que nenhuma funcionalidade usa?
• Cópias de documentos ficam fora de pastas, chats e planilhas?
• Logs evitam dados pessoais ou têm prazo de retenção?
• Existe um processo para atender pedidos de exclusão ou acesso?
• Alguém sabe quais campos são sensíveis?

Se a maioria dos itens estiver sem resposta, o sistema está guardando mais do que precisa.

Conclusão: Menos Dado, Menos Problema

Quando um cliente pedir a exclusão dos próprios dados, a diferença entre um sistema minimalista e um acumulador é enorme.

No primeiro, a tarefa é pequena e previsível. No segundo, é uma caça ao tesouro por tabelas, logs, backups e pastas esquecidas.

Abra o cadastro de cliente do seu sistema e conte quantos campos são de fato usados. Quase sempre é menos da metade.

Quer Revisar Seus Dados?

Se seu sistema coleta mais do que precisa e você quer entender o que pode ser removido, posso ajudar com:

• Mapeamento de dados pessoais: quais campos existem, onde estão e para que servem
• Política de retenção: prazos, descarte automático e acesso por função
• Fluxo de exclusão e acesso: como atender pedidos do titular sem caça ao tesouro

Vamos revisar seus dados →