Por onde começar a adequação à LGPD num sistema pequeno

O cliente pergunta se o seu sistema "está adequado à LGPD" e você, que mantém um sistema de agendamento para salões com três mil cadastros, não sabe por onde começar. A tentação é baixar um modelo de política de privacidade, publicar no rodapé e considerar resolvido. A resposta curta: a adequação de um sistema pequeno começa por um inventário, não por um documento. Liste quais dados pessoais o sistema guarda, para que serve cada um, com qual base legal, por quanto tempo fica guardado e quem consegue ver. Com esse inventário pronto, a política de privacidade, o atendimento aos titulares e as decisões de segurança passam a ter base real.

Este guia é técnico e informativo. Ele não é consultoria jurídica e não substitui a orientação de um advogado ou profissional especializado em proteção de dados, nem os guias oficiais da ANPD e do governo.

O que a lei pede, em termos práticos

A Lei Geral de Proteção de Dados Pessoais, a Lei 13.709 de 2018, vale para qualquer tratamento de dados pessoais feito no Brasil ou de pessoas no Brasil, independentemente do tamanho da empresa. "Tratamento" é praticamente qualquer operação: coletar, guardar, consultar, compartilhar, apagar. A fiscalização é da Autoridade Nacional de Proteção de Dados, a ANPD.

Alguns conceitos aparecem em todo o roteiro:

• Dado pessoal: informação relacionada a pessoa natural identificada ou identificável. Nome, e-mail, CPF, telefone, endereço, e também IP, identificador de dispositivo e cookie de sessão, quando permitem chegar a alguém.
• Dado pessoal sensível: categoria com proteção reforçada, que inclui, entre outros, dados de saúde, biométricos, de origem racial ou étnica, de convicção religiosa e de vida sexual. Se o seu sistema guarda algo assim, o cuidado sobe de nível.
• Controlador: quem decide por que e como os dados são tratados. Em geral, a empresa dona do serviço.
• Operador: quem trata os dados em nome do controlador. Se você desenvolve e hospeda o sistema para o salão, provavelmente é operador dos dados dos clientes do salão.
• Base legal: a hipótese prevista na lei que autoriza o tratamento. Consentimento é uma delas, mas não a única. Execução de contrato, cumprimento de obrigação legal e legítimo interesse são outras.
• Titular: a pessoa a quem os dados se referem.

A ANPD publicou regras com obrigações simplificadas para agentes de tratamento de pequeno porte. Vale verificar, com quem entende do assunto, se a sua empresa se enquadra e o que muda no seu caso.

Como fazer o inventário de dados

1. Liste onde o sistema guarda dados. Banco principal, backups, logs, ferramenta de e-mail, planilhas exportadas, serviço de analytics, gateway de pagamento.
2. Para cada tabela ou serviço, liste os campos pessoais. Comece pelo banco, que é o mais fácil de varrer.
3. Escreva a finalidade de cada grupo de dados em uma frase. "Criar a conta", "confirmar o agendamento por WhatsApp", "emitir a nota fiscal".
4. Indique a base legal provável de cada finalidade. Essa é a etapa em que a orientação jurídica mais ajuda.
5. Defina o prazo de guarda. Por quanto tempo o dado fica depois que a conta é encerrada ou o serviço termina, e como ele é apagado ou anonimizado de verdade.
6. Registre quem acessa. Perfis de usuário, equipe interna, fornecedores.
7. Anote com quem os dados são compartilhados. Provedor de nuvem, serviço de envio de e-mail, contabilidade.

Varrendo o banco atrás de campos pessoais

Uma consulta no catálogo do banco dá o ponto de partida. Exemplo para PostgreSQL:

SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND column_name ~* '(nome|email|cpf|rg|telefone|celular|nasc|endereco|cep|ip|token)'
ORDER BY table_name, column_name;

Ela não encontra tudo: campos de texto livre, como "observações", costumam esconder dados pessoais e até sensíveis, do tipo "cliente alérgica a tal produto". Revise essas colunas manualmente.

Exemplo trabalhado: o sistema de agendamento

O inventário do sistema de agendamento, escrito em lista, ficaria parecido com isto:

• Tabela clientes: nome, celular, e-mail. Finalidade: identificar o cliente e confirmar o horário. Acesso: atendentes do salão. Compartilhamento: serviço de envio de mensagens.
• Tabela clientes: data de nascimento. Finalidade declarada: mensagem de aniversário. Ninguém usa a função há dois anos. Candidata a sair.
• Tabela agendamentos: campo observações. Contém, em alguns registros, informações de saúde digitadas pela equipe. Dado sensível sem necessidade clara. Orientar a equipe e revisar o campo.
• Logs do servidor: IP e URL acessada. Finalidade: segurança e diagnóstico. Prazo definido: rotação automática.
• Backups diários do banco. Contêm tudo o que está acima e precisam seguir o mesmo prazo de guarda.

Esse exercício já produz decisões concretas: um campo a remover, um campo de texto livre a revisar, um prazo de log a configurar. Campo que existe "porque um dia pode servir" é o primeiro candidato a sair. Dado que você não guarda não vaza.

Prazo de guarda e exclusão que acontece de verdade

Definir um prazo só vale se alguma coisa apaga os dados quando ele chega. Uma rotina agendada resolve a parte do banco principal:

-- Anonimiza clientes com conta encerrada há mais tempo que o prazo definido pela empresa
UPDATE clientes
SET nome = 'Cliente removido',
    celular = NULL,
    email = NULL,
    data_nascimento = NULL,
    anonimizado = true
WHERE conta_encerrada_em < now() - interval '2 years'
  AND anonimizado = false;

O intervalo de dois anos é só exemplo. O prazo certo depende das finalidades e de obrigações legais, como as fiscais, e deve ser definido com orientação adequada. O ponto técnico é outro: backups também precisam respeitar o prazo, com uma política de retenção que descarte cópias antigas. Senão, apagar na base principal não apaga nada. O mesmo vale para logs: veja como manter senhas e dados sensíveis fora do log.

Quem acessa e como você sabe

Separe quem opera o sistema de quem só usa. Um perfil administrativo que enxerga todos os cadastros precisa de motivo, de autenticação forte e de registro de acesso. Senhas armazenadas com hash adequado, como em login com senha protegida. Acesso ao banco de produção restrito a poucas pessoas, com credenciais individuais. Se houver um incidente de segurança que possa trazer risco aos titulares, a lei prevê comunicação à ANPD e aos titulares. Ter registro de acesso é o que permite responder o que foi exposto.

O que o titular pode pedir

A lei garante ao titular, entre outros, o direito de confirmar se você trata dados dele, acessar esses dados, corrigir dados incompletos ou errados, e pedir a eliminação de dados tratados com base no consentimento, além de informações sobre com quem eles foram compartilhados. Preveja um caminho simples para isso. Não precisa ser um portal no primeiro dia. Pode ser um e-mail publicado na política de privacidade, desde que alguém responda e o sistema consiga localizar todos os registros daquela pessoa, inclusive nas tabelas secundárias.

Erros comuns

• Começar pela política de privacidade. O texto promete coisas que ninguém verificou no sistema, e a primeira solicitação de titular expõe a diferença.
• Tratar consentimento como a única base legal. Pedir consentimento para o que é necessário ao contrato cria um problema quando a pessoa revoga.
• Ignorar backups e logs no inventário. Os dados apagados continuam existindo em cópias que ninguém controla.
• Manter campos "para o futuro". Cada campo sem finalidade é risco sem benefício.
• Exclusão só na interface. O registro some da tela, mas continua no banco com uma marca de "inativo".
• Acesso administrativo amplo e sem registro. Se algo vazar, não há como saber quem viu o quê.

Checklist

• Existe uma lista dos locais onde o sistema guarda dados pessoais, incluindo backups, logs e fornecedores.
• Cada grupo de dados tem uma finalidade escrita em uma frase.
• Campos sem finalidade foram removidos ou têm data para sair.
• Dados sensíveis foram identificados, inclusive em campos de texto livre.
• Há prazo de guarda definido e uma rotina que apaga ou anonimiza quando ele vence.
• Backups seguem uma política de retenção coerente com o prazo.
• Acesso administrativo é individual, restrito e registrado.
• Há um canal publicado para titulares e alguém responsável por responder.

Abra o esquema do seu banco agora e escolha uma tabela com dados de pessoas. Você consegue dizer, para cada coluna, por que ela existe e quando ela será apagada?