Como desenhar fluxos de dados alinhados à LGPD

Introdução: por que fluxos de dados são o coração da LGPD

Quando falamos de LGPD, é comum focar em políticas, bases legais e contratos. Tudo isso é importante, mas, na prática, a pergunta que mais importa é simples:

Por onde os dados pessoais entram, por onde circulam e para onde vão?

É isso que um bom fluxo de dados responde. Ele mostra a jornada dos dados pessoais, da coleta ao descarte, passando por armazenamento, integrações, compartilhamentos e tratamentos internos.

Sem essa visão, fica difícil:

• Definir bases legais com segurança.
• Estabelecer prazos de retenção coerentes com a realidade.
• Identificar riscos de vazamento ou acesso indevido.
• Atender direitos de titulares de forma eficiente.

Este guia é um passo a passo para desenhar fluxos de dados alinhados à LGPD, pensando tanto em quem cuida da arquitetura quanto em jurídico, negócio e privacidade.

---

Identificando pontos de entrada de dados pessoais

O primeiro passo é entender onde os dados pessoais entram na organização. Em geral, os pontos de entrada se dividem em alguns grupos:

• Formulários digitais
  Sites, aplicativos, portais internos, sistemas de terceiro com embeds ou iframes.

• Canais de atendimento
  E-mail, chat, WhatsApp, telefone, URA, chatbot, central de suporte.

• Integrações de sistemas
  APIs entre sistemas internos, integrações com parceiros, webhooks, importação de arquivos.

• Canais administrativos
  Processos internos que recebem dados por planilhas, documentos digitalizados, contratos, currículos.

Para cada ponto de entrada, vale registrar pelo menos:

• Que dados pessoais são coletados (campos específicos).
• A finalidade declarada para essa coleta.
• A base legal pretendida (consentimento, contrato, obrigação legal, legítimo interesse etc.).
• Quem é o titular (cliente, colaborador, fornecedor, visitante, lead).

Isso evita cenários em que o fluxo é desenhado de forma genérica, do tipo "dados do cliente vão para o sistema X", sem clareza sobre quais dados, por qual motivo e com qual respaldo jurídico.

---

Mapeando processamento, compartilhamentos e integrações

Depois de saber onde os dados entram, o próximo passo é entender o que acontece com eles por dentro.

Perguntas úteis:

• Em quais sistemas esses dados são registrados logo após a entrada?
• Há tratamentos adicionais, como enriquecimento, segmentação, análise ou cruzamento com outras bases?
• Existem integrações com outros sistemas internos ou externos?
• Há exportações regulares para planilhas ou relatórios manuais?
• Esses dados são compartilhados com operadores ou parceiros (gateways, CRMs, empresas de logística, contabilidade, folha de pagamento etc.)?

Para cada etapa do fluxo, é importante registrar:

• Tipo de tratamento
  Exemplo: armazenamento, consulta, atualização, exclusão, anonimização, pseudonimização, transferência.

• Responsável pela etapa
  Time, área ou fornecedor que controla aquele trecho do fluxo.

• Categoria de destinatário
  Operador, controlador conjunto, suboperador, parceiro comercial.

Aqui, um diagrama simples já ajuda muito. Não precisa ser perfeito, mas deve mostrar claramente de onde os dados vêm, por onde passam e com quem são compartilhados.

---

Definindo onde e como os dados são armazenados

Com o fluxo de processamento e integrações mapeado, o próximo ponto é responder:

Onde, exatamente, esses dados ficam guardados?

Algumas dimensões importantes:

• Tipo de repositório
  Banco de dados relacional, banco NoSQL, data lake, ferramenta SaaS, pastas em nuvem, servidor de arquivos, sistemas legados.

• Localização
  País ou região em que os dados são armazenados ou processados (importante para transferência internacional).

• Formato
  Dados estruturados (tabelas, campos) ou não estruturados (PDF, imagens, gravações, anexos).

• Nível de proteção
  Criptografia em repouso, controles de acesso, logs de acesso, backups, segregação por cliente ou por ambiente.

É neste momento que muitas empresas descobrem dados pessoais esquecidos em:

• Pastas compartilhadas pouco controladas.
• Planilhas antigas, ainda ativas, usadas como "quebra-galho".
• Sistemas de terceiro sem revisão recente de contrato e de medidas de segurança.

Criar um quadro que relacione sistema, tipo de dado, finalidade, base legal, localização e retenção é um passo fundamental para sair do abstrato e entrar no concreto.

---

Retenção, descarte e anonimização no desenho do fluxo

Um fluxo de dados alinhado à LGPD não termina quando os dados são armazenados. É preciso desenhar também como e quando eles deixam de ser dados pessoais utilizáveis.

Alguns elementos a considerar:

• Prazo de retenção
  Por quanto tempo aquele dado precisa ser mantido para cumprir a finalidade e obrigações legais ou regulatórias? Há diferença entre dados de leads, clientes ativos, ex-clientes, colaboradores, ex-colaboradores?

• Critérios de descarte
  O que dispara a exclusão ou anonimização? Fim do contrato, pedido do titular, fim de um prazo legal, inatividade por determinado período.

• Forma de descarte
  Exclusão lógica, exclusão física, anonimização ou pseudonimização. Como isso é feito tecnicamente em cada sistema?

• Impactos em backup e logs
  Quando um dado é excluído do sistema principal, o que acontece com cópias em backup, logs e exportações antigas? Há política específica para esses casos?

No fluxo, vale representar não só a entrada e o processamento, mas também:

• Para onde vão os dados quando o relacionamento termina.
• Como a empresa garante que não mantém dados além do necessário.
• Que tipos de anonimização fazem sentido para fins estatísticos ou analíticos.

---

Documentando fluxos de forma simples para devs e jurídico

Um dos grandes desafios em LGPD é criar uma documentação que sirva tanto para quem escreve código quanto para quem lê contratos. Se o material for técnico demais, jurídico não acompanha. Se for genérico demais, TI não consegue implementar.

Algumas sugestões práticas:

• Usar diagramas simples com caixas e setas, indicando sistemas, bases de dados e integrações principais.
• Acompanhar cada diagrama de uma tabela resumida, com colunas como: etapa, sistema, categorias de dados pessoais, titulares, finalidade, base legal, operadores envolvidos, prazo de retenção.
• Evitar jargão excessivo. Quando usar termos técnicos, incluir uma breve explicação.

Uma boa meta é que qualquer pessoa da empresa, com um pouco de contexto, consiga apontar em qual parte do fluxo está o dado que o titular está perguntando.

---

Mantendo o mapa de dados vivo conforme o sistema evolui

Fluxos de dados não são algo que se desenha uma vez e guarda na gaveta. Sistemas mudam, integrações novas surgem, ferramentas antigas são aposentadas, estratégias de negócio mudam.

Para que o mapa de dados não fique desatualizado em poucos meses, vale adotar algumas rotinas:

• Vincular o mapa a processos de mudança
  Sempre que houver uma grande alteração de sistema, integração ou coleta de dados, o fluxo deve ser revisado.

• Revisões periódicas
  Ao menos uma vez por ano, revisar fluxos principais, principalmente daqueles sistemas que concentram mais dados pessoais.

• Responsáveis claros
  Definir quem é o "dono" de cada fluxo ou sistema e quem responde por manter a documentação atualizada.

• Integração com o dia a dia de desenvolvimento
  Em novos projetos, o desenho de fluxos de dados pessoais deve fazer parte da própria fase de arquitetura, não ser um documento paralelo feito depois.

Com isso, o mapa deixa de ser um artefato estático e passa a fazer parte da cultura de desenvolvimento e de gestão de riscos.

---

Exemplo prático de fluxo de dados comentado

Para concretizar, imagine um fluxo simplificado de um formulário de contato em um site institucional que coleta nome, e-mail e mensagem.

1. Coleta no site

   • Campos: nome, e-mail, conteúdo livre da mensagem.
   • Finalidade: atendimento de contato espontâneo do titular.
   • Base legal: execução de procedimentos preliminares a pedido do titular.

2. Envio para o backend

   • Dados são enviados via HTTPS para o servidor da aplicação.
   • A aplicação registra um log mínimo técnico (data, IP, status da requisição), sem armazenar o corpo completo da mensagem em log.

3. Armazenamento em sistema de atendimento

   • Os dados são inseridos em uma base de tickets ou CRM.
   • Permissões de acesso são limitadas ao time de atendimento e supervisão.
   • Há trilha de alterações no ticket.

4. Uso para resposta ao titular

   • O time responde a mensagem utilizando o próprio sistema ou e-mail corporativo.
   • As interações ficam registradas no histórico do ticket.

5. Retenção

   • Definido prazo de retenção, por exemplo, 2 anos após o encerramento do atendimento, salvo obrigações legais específicas.
   • Passado o prazo, os tickets são anonimizados ou removidos de forma segura.

6. Compartilhamentos

   • Caso um operador terceirizado forneça a solução de CRM, ele é identificado como operador, com contrato adequado e medidas de segurança revisadas.

Representar esse fluxo em um diagrama, com uma tabela que traga os dados principais, já é um enorme avanço em relação a ter apenas um texto genérico na política de privacidade.

---

Conclusão

Desenhar fluxos de dados alinhados à LGPD não é um exercício teórico, e sim uma forma prática de conectar:

• Arquitetura e código com
• Bases legais e políticas e com
• Riscos e decisões de negócio.

Quando a organização entende claramente como os dados pessoais circulam, decisões sobre coleta mínima, retenção, compartilhamento e atendimento a titulares se tornam mais simples e menos subjetivas.

O objetivo deste guia é ser um ponto de partida. A partir dele, cada empresa pode adaptar o nível de detalhe, as ferramentas e os formatos de documentação, mantendo sempre a ideia central: fluxos de dados bem desenhados são a base para uma LGPD aplicável, sustentável e integrada ao dia a dia dos times.