Por que o inventário declarativo não resiste a um ambiente multi-cloud
Nós observamos, em programas de privacidade de grande porte, uma divergência silenciosa: o CISO trabalha com o mapa de ativos da infraestrutura e o DPO trabalha com a planilha de atividades de tratamento. Os dois documentos descrevem a mesma empresa, mas raramente coincidem. Quando um auditor pede o inventário, a pergunta implícita é qual dos dois mapas reflete a realidade. Quando ocorre um incidente, a pergunta passa a ser quais dados e quantos titulares foram afetados, e a resposta depende de um inventário que ninguém tem certeza de que está atualizado.
O inventário declarativo, montado por entrevistas e planilhas, parte de uma premissa que deixou de valer: a de que as áreas sabem onde estão os seus dados. Em ambientes híbridos, os dados circulam entre data centers próprios, mais de uma nuvem, aplicações contratadas diretamente por áreas de negócio, data lakes, backups e ambientes de teste. Cada migração, integração ou projeto de analytics cria cópias que não passam pelo crivo do time de privacidade.
Considere uma seguradora cujo time de analytics, para treinar um modelo de precificação, replica parte da base de apólices em um ambiente de teste hospedado em uma segunda nuvem. A cópia contém dados pessoais, financeiros e de saúde, existe há oito meses, tem acesso amplo e não consta de nenhum registro. Ninguém agiu de má-fé: o projeto nasceu na área de dados, o inventário vive no jurídico e o caminho entre os dois nunca foi desenhado.
O problema não é de diligência individual, mas de arquitetura. Um método que depende de lembrança não acompanha um ambiente que muda todos os dias.
O que a LGPD exige do registro e o que deixa em aberto
O art. 37 da LGPD determina que controlador e operador mantenham registro das operações de tratamento de dados pessoais que realizarem. A lei, porém, não especifica campos, formato nem periodicidade de atualização. Essa abertura é conveniente e, ao mesmo tempo, traiçoeira: quase qualquer documento atende à letra do artigo, mas apenas um registro que reflete a realidade sustenta o programa diante de um auditor ou da ANPD.
Por isso, nós tratamos o registro como o resultado de um processo, e não como um documento. O auditor quer reconstituir, para uma atividade de tratamento, onde estão os dados, quem é responsável, qual é a finalidade e quando a informação foi verificada pela última vez. O Board, por sua vez, precisa saber qual parcela do ambiente está efetivamente coberta. Como o art. 37 se aplica também ao operador, os provedores de nuvem mantêm o próprio registro, e o registro do cliente não pode presumir que o do fornecedor o substitui.
Duas camadas, uma única verdade
O que a descoberta técnica entrega e onde falha
A descoberta técnica varre repositórios, bancos de dados, armazenamentos de objetos e aplicações em busca de padrões de dados pessoais. Ela responde com precisão a duas perguntas: onde há dados e de que tipo. Contudo, não sabe por que aquele dado existe, qual base legal o sustenta ou por quanto tempo deve ser mantido. Além disso, enfrenta limites reais: dados não estruturados, campos livres e conteúdo cifrado geram falsos positivos e pontos cegos.
O que o contexto de negócio entrega e onde falha
O contexto de negócio, obtido junto às áreas, responde ao que a tecnologia não alcança: finalidade, base legal, compartilhamento e retenção. Todavia, ele só conhece o que as áreas enxergam. Sistemas paralelos, cópias para teste e integrações informais ficam fora do relato.
Um inventário confiável de dados pessoais é aquele em que a descoberta técnica (onde estão os dados, em quais sistemas e nuvens) é reconciliada continuamente com o contexto de negócio e jurídico (finalidade, base legal, retenção, compartilhamento), sob responsável nomeado.
Cada camada, isolada, cria um risco específico. A tabela abaixo organiza o papel de cada uma.
| Camada | Pergunta que responde | Fonte | Responsável | Risco se usada isoladamente |
|---|---|---|---|---|
| Descoberta técnica | Onde estão os dados pessoais e de que tipo? | Varredura de repositórios, bancos, armazenamentos e aplicações | CISO e infraestrutura | Dados encontrados sem finalidade, base legal ou dono definidos |
| Contexto de negócio | Por que o dado é tratado, com que base legal e por quanto tempo? | Entrevistas e levantamentos com as áreas | DPO e donos dos processos | Registro que ignora sistemas paralelos e cópias não declaradas |
| Reconciliação | O que foi encontrado coincide com o que foi declarado? | Cruzamento das duas camadas, com lista de divergências | DPO e CISO em conjunto | Divergências sem prazo nem responsável para tratamento |
| Registro das operações de tratamento | Qual é a versão oficial e verificada? | Resultado da reconciliação, com data e responsável | DPO | Documento formalmente completo, mas defasado em relação ao ambiente |
Reconciliação: o que transforma mapa em inventário
A reconciliação gera dois tipos de divergência. O primeiro é o dado encontrado sem registro: a cópia de teste da seguradora, a base importada para uma campanha, o repositório esquecido depois de um projeto. O segundo é o registro sem dado: uma atividade que consta do inventário, mas cujo sistema foi desativado, o que sugere documentação obsoleta ou retenção indevida. Os dois tipos exigem dono, prazo e decisão registrada, senão a lista de divergências vira apenas mais um documento sem consequência.
O ciclo também precisa de gatilhos além do calendário. Nós recomendamos que a contratação de um novo sistema, a abertura de uma nova nuvem, uma migração relevante e o início de um projeto de dados disparem a atualização do inventário no mesmo fluxo em que a área de segurança aprova a mudança. Um inventário que depende de lembrança é revisado quando alguém lembra; um inventário integrado ao fluxo de mudanças é revisado quando o ambiente muda.
Imagine uma operadora de saúde que conectou o inventário ao processo de aprovação de novos fornecedores e sistemas. Quando o time de TI solicita uma ferramenta de atendimento, o pedido só avança se o responsável registrar quais dados serão tratados e onde ficarão armazenados. O ganho não está na tecnologia, e sim no caminho obrigatório.
Medir a confiabilidade: cobertura, frescor e rastreabilidade
Três indicadores mostram se o inventário merece confiança. A cobertura mede a proporção de sistemas, nuvens e repositórios efetivamente varridos e reconciliados. O frescor mede o tempo transcorrido desde a última verificação de cada atividade. A rastreabilidade mede se cada registro aponta para um responsável, uma fonte técnica e uma data. Apesar disso, indicador sem método de apuração não convence o auditor: cada percentual precisa poder ser reconstruído a partir de registros.
Para o Board, a leitura é direta. Um inventário com cobertura declarada de 100% e frescor desconhecido é uma afirmação, e não uma evidência. Ainda assim, ninguém espera perfeição de um ambiente que muda diariamente. O que se espera é uma lacuna conhecida, quantificada e com plano de tratamento.
O que o inventário sustenta nos demais processos
O inventário é a base de processos que a empresa executa sob pressão. O relatório de impacto, previsto no art. 38, parte do conhecimento das atividades de tratamento. O atendimento a titulares, que inclui confirmar a existência de tratamento e dar acesso aos dados (art. 18), depende de saber em quais sistemas procurar. A resposta a incidentes depende de estimar rapidamente quais dados e quantos titulares foram afetados, dentro dos três dias úteis exigidos para a comunicação à ANPD. Entretanto, nenhum desses processos corrige um inventário ruim: todos apenas herdam a sua falha, no pior momento possível.
Conclusão
Mapear dados em ambientes híbridos e multi-cloud deixa de ser um projeto com data de término quando a empresa admite que o ambiente nunca para de mudar. O inventário confiável combina o que a tecnologia encontra com o que o negócio explica, reconcilia as duas visões em ciclo, atribui dono a cada divergência e mede a si mesmo por cobertura, frescor e rastreabilidade. O que o auditor, a ANPD e o Board avaliam, ao fim, é essa capacidade de mostrar onde estão os dados, por que existem e quando foram verificados pela última vez.
Leia também:
- Questionário anual não é gestão de terceiros: como monitorar operadores de forma contínua e comprovar a verificação que a LGPD exige do controlador?
- Dosimetria de sanções da ANPD: o que o programa de governança precisa provar para pesar a favor da empresa?
Para times de privacidade em operação de grande porte
Se a sua operação precisa verificar se o inventário atual reflete o ambiente real e sustenta as respostas à auditoria e à ANPD, o Executive Briefing reúne uma análise direcionada a CISOs, DPOs e áreas de compliance. Acesse: Executive Briefing.
Perguntas frequentes (FAQ)
Dúvidas comuns sobre inventário de dados e registro das operações de tratamento em ambientes multi-cloud
1. O que a LGPD exige em relação ao inventário de dados pessoais?
O art. 37 exige que controlador e operador mantenham registro das operações de tratamento de dados pessoais que realizarem. A lei não define campos, formato nem periodicidade de atualização, de modo que a empresa deve garantir que o registro reflita a realidade e possa ser comprovado.
2. Qual é a diferença entre data discovery e o registro das operações de tratamento?
O data discovery localiza dados pessoais nos sistemas e nas nuvens, indicando onde estão e de que tipo são. O registro das operações de tratamento documenta as atividades, com finalidade, base legal, compartilhamento e retenção. O primeiro alimenta o segundo, mas não o substitui.
3. Ferramentas de descoberta automática dispensam as entrevistas com as áreas?
Não. A descoberta técnica não sabe a finalidade, a base legal nem o prazo de retenção de cada dado, e tem limites com dados não estruturados e conteúdo cifrado. As entrevistas completam o que a tecnologia não alcança, e a reconciliação das duas visões é o que produz um inventário confiável.
4. Com que frequência o inventário deve ser atualizado?
A LGPD não fixa periodicidade. Em ambientes multi-cloud, a prática recomendada combina ciclos regulares de reconciliação com gatilhos de mudança, como novo sistema, nova nuvem, migração ou início de projeto de dados, para que o inventário acompanhe o ambiente e não apenas o calendário.
