As decisões de LGPD que precisam entrar no schema do banco de dados

Um pedido de exclusão chega e o dado está em cinco lugares

Um titular exerce o direito de eliminação previsto no artigo 18 da LGPD, e a empresa descobre, ao tentar atender, que o dado dele não mora num lugar só. Está na tabela de cadastro, está copiado dentro de um log de auditoria, está num backup de três meses atrás e está, com alguma frequência, numa tabela de eventos que ninguém classificou como dado pessoal porque a coluna se chama apenas "user_id", enquanto o nome associado a esse identificador vive em outra tabela do mesmo banco. Atender ao pedido dentro do prazo exige localizar e tratar todas essas cópias, e a velocidade com que isso acontece foi determinada meses ou anos antes, quando alguém desenhou o schema sem imaginar que o pedido chegaria.

A política de privacidade publicada no rodapé do site cumpre a obrigação de informar, e ela é necessária. O que ela não alcança é a obrigação de agir sobre o dado quando alguém pede, porque agir depende de saber onde o dado está e de existir uma rotina capaz de alcançá-lo. Essa parte é modelagem de banco, o mesmo tipo de decisão que tratamos como arquitetura na frente de LGPD & Privacidade. Quem redige o texto jurídico não tem como implementá-la, e quem desenha as tabelas decide, quase sempre sem perceber, se ela custará uma consulta ou um projeto.

Onde o dado pessoal aparece além da tabela de cadastro

Uma modelagem descuidada trata dado pessoal como se ele vivesse exclusivamente na tabela de usuários, quando ele se espalha para toda tabela em que um identificador de pessoa é gravado junto com um evento ou uma transação. Um sistema de agendamento médico registra, no histórico de consulta, sintoma relatado, hora de chegada e profissional que atendeu. Um CRM de cobrança guarda o CPF associado a cada contrato dentro do histórico financeiro. Uma tabela de log de aplicação armazena o corpo inteiro de uma requisição porque isso facilitava a depuração no mês em que o sistema foi escrito, e ninguém revisitou a decisão depois.

Classificar essas tabelas antes da primeira migration tem custo de trabalho e produz um artefato que precisa sobreviver à saída de quem projetou o sistema: um comentário estruturado no próprio schema, um documento de classificação versionado junto ao repositório, ou os dois. O artigo 37 da LGPD já exige do controlador e do operador o registro das operações de tratamento que realizam, de modo que esse inventário atende a uma obrigação legal e resolve um problema operacional no mesmo movimento.

O que distingue dado anonimizado de dado pseudonimizado

A lei trata os dois regimes de forma diferente, e a diferença muda o que o schema precisa garantir. Dado anonimizado, definido no artigo 5º como aquele relativo a titular que não possa ser identificado considerando meios técnicos razoáveis e disponíveis na ocasião do tratamento, deixa de ser dado pessoal por força do artigo 12, com a ressalva expressa de que o processo de anonimização não pode ser revertido. Dado pseudonimizado, descrito no artigo 13, perde a possibilidade de associação direta ou indireta a um indivíduo exceto pelo uso de informação adicional mantida separadamente. Enquanto essa informação adicional existir em algum lugar, todas as obrigações da lei continuam valendo sobre aquele registro.

A confusão entre os dois aparece com regularidade em revisão de código. Um sistema substitui o CPF por um hash e passa a tratar o resultado como dado anônimo. Como o CPF tem onze dígitos e um espaço de valores pequeno para os padrões de computação atuais, o hash calculado sem sal adequado é reversível por força bruta em tempo curto, o que mantém o dado dentro do regime de dado pessoal com todas as consequências. Ilegibilidade a olho nu não é critério técnico de anonimização, ainda que funcione bem como argumento numa reunião em que ninguém vai conferir.

Retenção precisa existir como campo e como rotina

Prazo de retenção definido apenas em documento jurídico não impede que a tabela cresça indefinidamente, porque nenhuma rotina automatizada lê aquele documento antes de decidir o que apagar. O artigo 16 determina a eliminação do dado após o término do tratamento, ressalvadas hipóteses como o cumprimento de obrigação legal ou regulatória, e transformar esse comando em comportamento do sistema exige duas coisas concretas: um campo de data associado ao evento e um processo periódico que aplique exclusão ou anonimização sobre os registros que passaram do prazo previsto para aquele tipo de dado.

O prazo varia por tipo, e é aí que a modelagem prova o próprio valor. A Resolução CFM nº 1.821/2007 fixa em vinte anos, contados a partir do último registro, o prazo mínimo de guarda do prontuário médico, muito acima do que qualquer empresa aplicaria a um log de acesso ou a um evento de navegação, a mesma exigência que tratamos na frente de Tecnologia para Saúde. Um schema que trata todos os registros como categoria única não consegue aplicar prazos distintos sem reescrita, e a alternativa costuma ser guardar tudo pelo prazo mais longo, o que aumenta custo de armazenamento e superfície de exposição ao mesmo tempo, sem benefício para ninguém.

Registro de acesso com granularidade suficiente para investigar

O artigo 46 exige do controlador e do operador medidas de segurança capazes de proteger o dado pessoal de acessos não autorizados. Traduzido para o desenho de um sistema, isso vira um conjunto de decisões verificáveis: quem, dentro da empresa contratante, tem permissão de leitura sobre dado sensível; se cada leitura fica registrada com identificação de quem consultou o quê e quando; e se um relatório agregado entregue a uma área de recursos humanos ou a um contratante de serviço de saúde ocupacional sai anonimizado por padrão, com piso mínimo de respondentes antes de qualquer número aparecer na tela, prática que aplicamos no case de telepsicologia corporativa.

A granularidade do registro determina se uma investigação de incidente é possível. Um log que informa apenas que um usuário autenticou na aplicação não sustenta apuração nenhuma. O log que sustenta é aquele capaz de dizer que um usuário específico abriu o registro de um paciente específico num horário específico. Essa granularidade tem custo de armazenamento, que precisa ser dimensionado quando o sistema é desenhado, junto com o prazo de retenção do próprio log, que também é dado pessoal e também prescreve.

O custo de adiar essas decisões

Incluir tudo isso num sistema que já está em produção é possível e mais caro do que teria sido defini-lo no desenho inicial, porque envolve migrar dado existente, ajustar relatórios e integrações que dependem do formato antigo e retreinar quem usa o sistema sobre um comportamento que mudou sem que a mudança tenha origem visível para quem opera.

A resistência a tratar disso no início raramente é técnica. Ela nasce do prazo do projeto e do argumento de que essa camada entra depois, quando a primeira versão já estiver no ar e a operação tiver se estabilizado. O que se observa na prática é outra coisa: o schema nascido sem essas decisões só volta à mesa quando um incidente ou uma auditoria externa força a revisão, e nesse ponto o custo da correção já vem somado ao dano que a correção deveria ter evitado.