Aplicar a LGPD em um projeto de software exige transformar obrigações e decisões de privacidade em requisitos de produto. O trabalho começa antes da tela de consentimento: finalidade, dados necessários, acesso, retenção, compartilhamento e atendimento ao titular influenciam arquitetura e operação.
Este conteúdo apoia o planejamento técnico e não substitui avaliação jurídica do caso. A ANPD mantém materiais orientativos que ajudam a interpretar papéis e boas práticas.
Mapeie o tratamento por fluxo
Para cada jornada, registre quais dados entram, de quem são, por que são usados, onde ficam, com quem são compartilhados e quando devem ser eliminados. Faça isso pelo processo real, incluindo exportações, logs, backups, suporte e integrações.
Um formulário pode coletar poucos campos, mas a operação gerar histórico, anexos e eventos. O mapa precisa acompanhar todo o ciclo.
Colete o necessário para a finalidade
Cada campo deve ter justificativa. Diferencie o que é obrigatório para entregar o serviço do que é útil para análise futura. Campos opcionais precisam ser apresentados como tal.
Minimização reduz exposição, custo de proteção e complexidade no atendimento a solicitações. Também melhora a experiência ao evitar cadastros extensos sem benefício claro.
Modele acesso e segregação
Defina perfis e ações: quem consulta, cria, altera, exporta e exclui. Evite um único papel administrativo para todas as funções. Dados sensíveis, financeiros ou de saúde podem exigir controles mais restritos e registro de acesso.
No backend, a autorização deve ser verificada a cada operação. Esconder um botão na interface não impede acesso direto à API.
Planeje retenção e eliminação
Registre prazo ou critério por categoria de dado, considerando obrigações aplicáveis e a finalidade. A exclusão precisa alcançar bases operacionais, filas, arquivos temporários e cópias derivadas dentro do que for tecnicamente e legalmente adequado.
Backups exigem política própria. Eles podem permanecer protegidos até expirar, sem voltar ao uso cotidiano. Documente como uma restauração evita reativar dados que já deveriam estar eliminados.
Prepare direitos do titular
O sistema deve permitir localizar dados por identidade, verificar a pessoa solicitante, registrar a demanda e executar a resposta aprovada. Dependendo do contexto, isso pode envolver confirmação, acesso, correção, portabilidade, informação sobre compartilhamento ou eliminação.
Não crie uma função de exclusão automática sem considerar registros que precisam ser mantidos. O fluxo deve separar decisão, execução e evidência.
Avalie fornecedores e integrações
Liste serviços que recebem dados: nuvem, atendimento, pagamento, analytics, e-mail e IA. Verifique finalidade, retenção, segurança, suboperadores, localização e mecanismo de devolução ou exclusão ao fim do contrato.
Envie apenas os campos necessários e use credenciais com menor privilégio. A integração deve registrar falhas sem gravar conteúdo sensível indevidamente.
Construa segurança e evidência
Use criptografia em trânsito, proteção de segredos, autenticação forte, logs, atualizações e backups testados. Registre mudanças de permissão, exportações e ações administrativas relevantes.
Logs também contêm dados. Limite conteúdo e retenção, proteja o acesso e evite registrar tokens, senhas ou documentos completos.
Checklist para requisitos
| Tema | Pergunta para o projeto |
|---|---|
| Finalidade | Por que cada dado é necessário? |
| Transparência | A pessoa entende o uso no momento adequado? |
| Acesso | Quem pode fazer o quê? |
| Retenção | Quando o dado deixa de ser necessário? |
| Titulares | Como localizar, revisar e executar solicitações? |
| Incidentes | Como detectar, conter, avaliar e registrar? |
Valide antes do lançamento
Teste perfis sem permissão, exportações, correções, eliminação, falhas de integração e restauração de backup. Revise textos e configurações no ambiente final. Nomeie responsáveis para privacidade, segurança e operação após o deploy.
Privacidade desde o desenho evita remendos e ajuda a construir confiança. Para traduzir o mapa de dados em arquitetura, permissões e fluxos verificáveis, fale com a A2CR.
Como isso aparece na operação
Uma solicitação deixa de circular por mensagens e passa a ter responsável e prazo.
Cadastros duplicados são substituídos por uma fonte oficial.
Indicadores são calculados durante a operação, sem consolidação manual.
Comparação prática
| Alternativa | Quando faz sentido | Principal cuidado |
|---|---|---|
| Software pronto | Processo comum | Aderência e licenças |
| Integração | Ferramentas já funcionam | Falhas e dados |
| Sistema sob medida | Regra estratégica | Escopo e manutenção |
Fluxo recomendado
- Diagnosticar
- Priorizar
- Validar uma primeira versão
- Medir e evoluir
Perguntas frequentes
Qual é a diferença entre SaaS e software sob medida?
SaaS distribui o mesmo produto entre vários clientes. Software sob medida representa regras e integrações específicas. A decisão depende de aderência, custo total, dados e capacidade de evolução.
Como saber se a empresa precisa de um sistema personalizado?
Quando um processo relevante exige controles paralelos, retrabalho, regras específicas ou integrações que ferramentas prontas não atendem de maneira sustentável.
É possível começar com uma primeira versão menor?
Sim. A primeira versão deve resolver um fluxo completo para usuários reais, com critérios claros de sucesso, antes de ampliar funcionalidades.
