Falar de LGPD costuma soar como assunto de advogado, não de programador. Mas, para quem constrói um sistema que guarda dados de saúde, LGPD na prática é trabalho de engenharia todo santo dia. Não é uma checklist que se resolve uma vez e se esquece. É uma camada que atravessa cada decisão técnica, desde o modelo do banco de dados até o log mais bobo que você deixa rodando em produção.
Neste post reúno os cuidados reais que aplico no dia a dia, sem citar clientes ou dados específicos — só engenharia.
Por que dados de saúde pedem cuidado redobrado
A LGPD já trata dado pessoal com seriedade. Dado de saúde, porém, entra numa categoria à parte: a lei chama isso de “dado pessoal sensível”. Ou seja, o tratamento exige base legal mais restrita e cuidado redobrado em cada etapa. Além disso, um vazamento nessa categoria carrega peso maior — tanto legal quanto reputacional. Por isso, LGPD na prática, nesse contexto, não é um “nice to have”. É pré-requisito para o produto sequer existir.
Os pilares de LGPD na prática que uso no dia a dia
Ao longo do tempo, converti a teoria da lei em hábitos técnicos concretos. Alguns deles:
Minimização de dados. Antes de guardar qualquer campo novo, pergunto se ele é realmente necessário. Menos dado guardado é, automaticamente, menos risco.
Criptografia em repouso e em trânsito. Dado sensível nunca fica em texto puro no banco. Da mesma forma, toda comunicação entre frontend e backend passa por HTTPS, sem exceção.
Controle de acesso granular. Nem todo usuário do sistema precisa ver tudo. Por isso, defino papéis claros e limito o que cada papel enxerga, mesmo dentro da própria organização do cliente.
Log de auditoria. Quem acessou o quê, e quando, fica registrado. Isso ajuda tanto a investigar incidentes quanto a provar conformidade, se um dia for preciso.
Anonimização em ambientes de teste. Nunca uso dado real em homologação ou desenvolvimento. Em vez disso, gero dados fictícios que imitam o formato real, sem carregar nenhuma informação verdadeira.
Política de retenção e exclusão. Dado não fica guardado para sempre só porque “pode ser útil depois”. Defino prazos e, ao final deles, o dado é de fato apagado, não só marcado como inativo.
LGPD na prática: erros comuns que já evitei (ou corrigi)
Um erro clássico é tratar consentimento como um checkbox genérico no cadastro, sem clareza sobre para que o dado será usado. Outro é deixar logs de aplicação registrando informação sensível sem perceber — um print de debug esquecido pode virar um vazamento silencioso. Também é comum subestimar terceiros: se você usa um serviço externo de e-mail, storage ou analytics, o dado que passa por ele também é sua responsabilidade.
Vale complementar essa leitura com o post sobre FastAPI e Angular, que fala de outra decisão de arquitetura por trás do mesmo produto.
LGPD na prática não é checklist, é cultura de produto
No fim, o maior aprendizado é que LGPD na prática funciona melhor como cultura do que como checklist. Checklist se cumpre uma vez e se esquece. Cultura se aplica toda vez que uma decisão técnica nova aparece — um campo novo no formulário, uma integração nova, um relatório novo para o cliente. Para quem constrói software de saúde sozinho, sem um time de compliance dedicado, essa mentalidade é o que garante que o produto continue seguro conforme cresce. A referência oficial mais confiável para dúvidas específicas continua sendo a própria Autoridade Nacional de Proteção de Dados (ANPD), que publica orientações atualizadas sobre a aplicação da lei.
0 Comentários