LGPD no desenvolvimento de software: o que decidir antes da primeira tela

LGPD no desenho do sistema, não no fim do projeto

Antes de qualquer tela, quatro decisões precisam entrar na especificação de um sistema que trata dados pessoais conforme a Lei Geral de Proteção de Dados (LGPD): que dados ele coleta e por quê, quem acessa cada um, por quanto tempo ficam guardados e como cada acesso é registrado. Decidir isso no desenho costuma custar menos do que remendar depois, quando as telas, o banco de dados e os relatórios já foram construídos em torno de outras premissas.

Este texto é um roteiro de decisões de projeto, não um parecer jurídico. Interpretar a LGPD para o seu caso é trabalho do jurídico do órgão ou da empresa. O que cabe à equipe de tecnologia é transformar essas interpretações em requisitos que o sistema consiga cumprir.

A ideia tem nome: privacidade desde a concepção. O art. 46, §2º manda observar as medidas de segurança desde a fase de concepção do produto ou do serviço. Em vez de tratar a proteção de dados como uma revisão no fim do projeto, ela entra como requisito, no mesmo nível de cadastro, relatório ou integração. Quando o assunto chega só na homologação, sobram duas saídas ruins: aceitar o que já foi construído ou refazer partes do sistema.

Na prática, isso significa chamar o encarregado de dados para o levantamento. É a pessoa indicada pelo órgão como canal de comunicação com os titulares dos dados e com a Autoridade Nacional de Proteção de Dados (art. 5º, VIII). Ele conhece as bases legais que o órgão usa, os compromissos já assumidos com os titulares e o que o jurídico exige. Essas respostas viram requisitos escritos, e não suposições da equipe técnica. O levantamento de requisitos é o momento certo para essa conversa.

Se o seu projeto é um sistema feito sob medida, a vantagem é que nada está pronto de antemão: as quatro decisões podem moldar o sistema desde a primeira versão.

Checklist de dados pessoais para quem especifica o sistema

Cada item abaixo vira uma pergunta que a equipe responde por escrito, com o responsável pela área e o encarregado. Respostas incompletas servem de começo, desde que a lacuna fique registrada.

Que dado coletar, e por quê

Liste cada campo pessoal que o sistema vai pedir ou receber: nome, documento, endereço, contato, dado de saúde, dado de terceiros. Ao lado de cada um, escreva a finalidade. Se ninguém consegue explicar para que o campo existe, ele é candidato a sair do formulário. É a lógica da minimização de dados, que a LGPD trata como princípio da necessidade (art. 6º, III): limitar o tratamento ao mínimo necessário para a finalidade. Confirme com o jurídico como a LGPD trata o tema no seu caso.

Perguntas para a equipe:

• Para que serve este campo no processo?
• O processo funcionaria sem ele?
• Existe uma base legal que sustente a coleta, definida pelo jurídico?
• O dado vem do próprio titular ou de outra base?

Formulário que pede tudo "por garantia" cria um passivo: cada dado a mais precisa ser protegido, controlado e, em algum momento, descartado.

Quem acessa o quê

Nem todo perfil precisa ver todo dado. Um exemplo hipotético: num sistema de protocolo, o atendente precisa do nome e do contato do requerente. O analista da área técnica talvez só precise do conteúdo do pedido. O gestor, de relatórios agregados, sem identificação.

Defina o acesso por perfil e, quando o dado for mais sensível, por campo. Registre também quem concede e quem revoga permissão, e o que acontece quando alguém muda de área ou deixa o órgão.

Perguntas para a equipe:

• Quais perfis existem e o que cada um enxerga?
• Quem pode exportar dados em massa?
• Como o acesso é retirado quando a pessoa sai?

Por quanto tempo guardar

Todo dado pessoal precisa de um destino final: ser apagado, anonimizado ou arquivado conforme alguma regra. O prazo não é decisão da equipe técnica. Ele vem da norma que se aplica ao processo e da orientação do jurídico, e muda de um tipo de dado para outro.

O que a equipe técnica decide é como o sistema cumpre o prazo. Rotina automática de descarte, marcação para revisão ou arquivamento em área separada são desenhos diferentes, e escolher entre eles depois da entrega costuma exigir mudar o banco de dados.

Perguntas para a equipe:

• Qual é a regra de guarda de cada tipo de dado, e quem a definiu?
• O sistema aplica essa regra sozinho ou depende de alguém lembrar?
• Cópias de segurança e arquivos exportados também seguem a regra?

O que fica de fora do sistema

Decidir o que não entra é tão importante quanto decidir o que entra. Anexos livres, campos de observação e planilhas importadas são portas por onde dado pessoal entra sem que ninguém tenha planejado.

Um campo de texto aberto, por exemplo, convida o usuário a escrever o que não deveria: documento de terceiros, informação de saúde, dado que o processo nunca precisou. Se o campo é necessário, oriente na própria tela sobre o que não preencher.

Perguntas para a equipe:

• Há campo livre ou upload sem controle de tipo?
• Dados de outros sistemas serão copiados para o novo, ou apenas consultados quando necessário?
• Existe dado que o sistema novo poderia deixar de pedir?

Consultar o dado na origem, em vez de copiá-lo, reduz o número de lugares onde ele precisa ser protegido.

LGPD em sistema público: o que muda quando o órgão trata o dado

Em sistema público, o tratamento de dados pessoais costuma existir para cumprir uma finalidade pública: executar uma política, prestar um serviço, atender uma obrigação legal. Isso orienta o projeto de três maneiras.

Finalidade pública e transparência. O sistema precisa deixar claro, para quem usa e para quem é atendido, que dados trata e para que, em linguagem que o cidadão entenda. Para o poder público, a LGPD pede informações claras e atualizadas sobre a finalidade e as práticas do tratamento, de preferência no site do órgão (art. 23, I). A transparência passa a ser requisito de tela e de documentação, e não apenas de um texto institucional. Convém verificar com o jurídico como ela se combina com as regras de acesso à informação que o órgão já cumpre.

Papéis. A LGPD distingue o controlador, a quem cabem as decisões sobre o tratamento, do operador, que trata o dado em nome do controlador (art. 5º, VI e VII). Isso aparece no projeto quando há um fornecedor envolvido: quem decide, quem opera e quem responde por quê deve estar claro no contrato e refletido nas permissões do sistema. Quem define esses papéis para o seu caso é o jurídico.

Compartilhamento entre órgãos e integrações. Sistema público raramente trabalha sozinho. Cada integração por API com outro órgão é um compartilhamento de dados pessoais e pede perguntas próprias: que campos trafegam, com qual finalidade, com qual autorização, e quem registra cada troca. Integração que envia o cadastro inteiro "porque era mais fácil" costuma ser o ponto mais difícil de justificar depois.

Nenhuma dessas decisões se resolve no código. Mas todas acabam nele, e é por isso que precisam chegar à equipe técnica como requisito claro.

Registro de acesso e trilha de auditoria

A trilha de auditoria responde, depois que algo aconteceu, a quatro perguntas: quem viu, quem alterou, quem exportou e quando. Sem ela, atender um pedido de um titular ou apurar um acesso indevido vira investigação manual, com pouca chance de conclusão.

Decida cedo o que o sistema registra. Um ponto de partida:

• consulta a registro com dado pessoal;
• criação, alteração e exclusão;
• exportação e impressão em massa;
• mudança de permissão e de perfil;
• tentativas de acesso que falharam.

Há um cuidado que costuma ser esquecido: o log não deve virar uma segunda base de dados pessoais em texto aberto. Registre o identificador do registro e a ação, não o conteúdo completo. Um log com CPF e endereço em cada linha cria o mesmo problema que ele deveria ajudar a resolver.

Defina também quem lê a trilha. Uma trilha que ninguém consulta não protege nada. Estabeleça quem a revisa, com que frequência, e o que acontece quando algo suspeito aparece.

A trilha ajuda ainda a atender o titular. Quando uma pessoa pergunta que dados o órgão tem sobre ela ou pede a correção de uma informação, o sistema precisa conseguir localizar o que é dela e mostrar o que foi feito. Isso se projeta no desenho dos dados, e não se improvisa no dia do pedido.

Por onde começar o escopo de um sistema com dado pessoal

As quatro decisões deste texto já são o começo do escopo: que dado entra, quem acessa, por quanto tempo fica e como cada uso é registrado. Leve essas perguntas para a primeira conversa com o jurídico e com o encarregado, e registre o que ainda estiver em aberto.

A Evo Tech cria sistemas sob demanda com foco em órgãos públicos. Se você está especificando um sistema assim e quer conversar sobre o escopo, veja a página de sistemas sob medida e fale com o nosso time. Se a necessidade for uma equipe dedicada para construir o sistema, o Squad de TI é a modalidade a considerar. E, se ainda está decidindo entre produto pronto e sistema próprio, comece por o que é um sistema sob demanda.