LGPD em produtos com IA: checklist técnico para coletar menos e proteger mais

Introdução

Construir um produto com IA no Brasil implica, necessariamente, lidar com a LGPD. Isso não é novidade — a lei está em vigor desde 2020, com sanções aplicáveis desde 2021. O que ainda surpreende em muitos produtos é a distância entre "ter uma política de privacidade" e "ter um produto que respeita a privacidade por design". Produtos com IA têm características específicas que tornam a adequação mais complexa: coletam dados textuais ricos (que podem conter informações sensíveis sem que o usuário perceba), processam esses dados por terceiros (os provedores de modelo), e frequentemente armazenam logs de operação que não foram pensados como dados pessoais, mas o são. Este artigo não é consultoria jurídica. É um checklist técnico baseado em decisões reais de arquitetura para produtos que querem coletar menos, proteger mais e conseguir demonstrar isso quando necessário.

O problema específico de IA e dados pessoais

Em um produto SaaS convencional, o fluxo de dado pessoal é relativamente claro: usuário cria conta, fornece dados, esses dados ficam no banco. O mapeamento é direto. Em um produto com IA, surgem camadas adicionais:

1. O input do usuário contém dados pessoais implícitos

Quando um usuário pede para gerar seu currículo, o texto que ele fornece contém nome, histórico profissional, formação, localização, às vezes dados de saúde ou situação familiar. Esses dados transitam pelo produto, são enviados ao provedor do modelo e podem ser retidos em logs.

2. O processamento acontece fora da sua infraestrutura

A chamada à API de um modelo de linguagem envia dados do seu usuário para servidores de terceiros. As condições de tratamento, retenção e uso desse dado dependem do contrato com o provedor — e da política de dados deles, não da sua.

3. Logs de operação são dados pessoais

Logs que registram o input e output de cada operação para fins de depuração ou melhoria de produto contêm, na prática, dados pessoais do usuário. Eles precisam ser tratados como tais.

Checklist técnico de adequação

Coleta e minimização de dados

Coletar apenas o que é necessário para a operação. Se a geração do documento não requer o CPF do usuário, não coletar o CPF. Princípio da minimização (Art. 6º, III da LGPD). Remover campos opcionais que acumulam dados sem uso claro. Campos "pode preencher se quiser" frequentemente ficam cheios em banco, nunca são usados e aumentam o escopo de exposição em caso de incidente. Documentar, para cada dado coletado: qual a finalidade, qual a base legal, por quanto tempo será retido. Esse mapeamento (registro de atividades de tratamento) é exigido pelo Art. 37 para empresas obrigadas e é boa prática para todas. [INSERIR TABELA DE MAPEAMENTO DE DADOS: campo, finalidade, base legal, retenção, quem acessa]

Dados em trânsito para o provedor de modelo

Verificar a política de uso de dados do provedor (OpenAI, Anthropic, Google, etc.) em relação ao uso dos inputs para treinamento. A maioria oferece opções de opt-out que precisam ser ativadas explicitamente via configuração de conta ou parâmetro na chamada de API. Documentar no Aviso de Privacidade que dados são processados por terceiros, com identificação dos provedores e link para as políticas deles. Transferência para terceiros exige base legal e transparência. Avaliar se o contrato com o provedor cobre os requisitos de suboperador para fins de LGPD. Para dados de usuários brasileiros, o provedor age como operador (Art. 39). Considerar opções de processamento local ou regional para dados sensíveis, onde a latência adicional seja aceitável.

Logs e armazenamento de operações

Definir política de retenção de logs de input/output. Logs de depuração não precisam ficar permanentes. Defina um período (ex: 30 dias) e implemente deleção automática. Anonimizar ou pseudonimizar logs sempre que possível. Para fins de análise de qualidade de prompt, você não precisa do nome real do usuário no log — apenas do padrão de input. Separar logs de aplicação de dados de operação de IA. Logs de sistema (erros, latência, chamadas) não precisam conter o conteúdo das operações. Armazene-os em camadas separadas com controles de acesso distintos. Garantir que backups de banco incluam na política de retenção os dados de operação. Dados deletados do banco principal que persistem em backup por anos são um problema real de adequação. [INSERIR DIAGRAMA DE FLUXO DE DADO: onde o dado do usuário passa, quem tem acesso, quando é deletado] Direitos do titular Implementar mecanismo de exclusão de dados por solicitação do usuário (Art. 18, VI). Isso inclui dados de conta, histórico de documentos gerados e, onde aplicável, logs de operação. Implementar mecanismo de portabilidade — o usuário deve conseguir exportar seus dados em formato estruturado. Garantir que a deleção de conta propague para todos os sistemas onde os dados existem: banco principal, cache, backups em rotação, logs retidos, dados enviados a suboperadores. Documentar o prazo de atendimento para solicitações de titulares (ANPD orienta 15 dias; defina o fluxo antes de receber a primeira solicitação). Ter ponto de contato claro para solicitações de titulares — um e-mail funciona; o que não funciona é não ter nenhum canal.

Aviso de Privacidade e consentimento

Aviso de Privacidade em linguagem acessível, com identificação do controlador, finalidades de tratamento, compartilhamento com terceiros, direitos do titular e como exercê-los. Não enterrar o Aviso de Privacidade em rodapé de página. Para produtos que coletam dados no momento do cadastro, o link deve estar visível no fluxo. Consentimento não é a única base legal e frequentemente não é a mais adequada. Para muitos produtos B2C, "execução de contrato" (Art. 7º, V) ou "legítimo interesse" (Art. 7º, IX) são bases mais adequadas e mais fáceis de sustentar do que consentimento — que exige opt-in específico e pode ser revogado a qualquer momento. Não usar linguagem de "ao usar o produto você concorda com..." como substituto de consentimento real. Não funciona como base legal.

Segurança técnica mínima

Dados em repouso criptografados, especialmente campos com informações pessoais sensíveis. Dados em trânsito via HTTPS/TLS em todas as chamadas, incluindo chamadas internas entre serviços. Controle de acesso por papel — quem tem acesso a quais dados na equipe? Acesso irrestrito ao banco de produção para toda a equipe de desenvolvimento é um problema de adequação. Plano de resposta a incidente documentado. Em caso de vazamento, a LGPD exige notificação à ANPD e aos titulares afetados em prazo razoável. Sem plano documentado, o tempo de resposta ao incidente se torna o tempo de descobrir o que fazer. [INSERIR PRINT DE CONFIGURAÇÃO DE CONTROLE DE ACESSO EM BANCO OU DASHBOARD DE ADMINISTRAÇÃO]

Decisões de arquitetura que impactam adequação

Não armazenar o documento final se não for necessário Se o produto gera o documento e o usuário faz o download, por que armazenar o documento no servidor? Se não há funcionalidade que dependa do histórico de documentos gerados, não armazenar é a decisão que elimina um vetor de exposição inteiro. Separar dados de conta de dados de operação Dados de conta (email, nome, plano) e dados de operação (inputs de documentos gerados) têm finalidades diferentes, ciclos de vida diferentes e requisitos de acesso diferentes. Armazená-los separados — com controles de acesso distintos — simplifica tanto a adequação quanto a eventual portabilidade ou exclusão. Pseudonimização como padrão em logs Substituir identificadores pessoais por hashes em logs de operação permite manter a utilidade do log para depuração sem expor os dados do usuário diretamente. Um log com user_id: a3f9c2... é menos arriscado que um log com email: joao.silva@empresa.com.br.

Erros comuns encontrados em produtos com IA

Acreditar que "a API não armazena" dispensa o tratamento. Mesmo que o provedor não use os dados para treinamento, o dado trafegou para sistemas de terceiros. Isso precisa estar no aviso de privacidade. Confundir política de privacidade com adequação à LGPD. Ter um documento publicado não é o mesmo que ter processos implementados. A ANPD pode solicitar demonstração dos processos, não apenas do documento. Deixar dados de usuários desativados indefinidamente em banco. Usuários que cancelaram a conta ou ficaram inativos por longos períodos têm direito à exclusão — e manter esses dados sem base legal é violação. Não ter logs de acesso aos dados pessoais. Em caso de incidente, saber quem acessou quais dados e quando é informação crítica. Sem isso, a resposta ao incidente fica comprometida.

Aprendizados práticos

Privacidade por design é mais barata que adequação retroativa. Corrigir a arquitetura de dados depois que o produto está em produção, com usuários reais, é muito mais caro do que pensar nesses requisitos durante o design. Coletar menos dado é também uma decisão de engenharia, não apenas legal. Menos dado significa menos superfície de ataque, menos custo de armazenamento e menos complexidade de gerenciamento. O registro de atividades de tratamento precisa ser mantido atualizado. Um documento criado no lançamento e nunca atualizado não reflete o produto real. Conformidade com LGPD é um processo contínuo, não um projeto com data de conclusão.

Conclusão

Produtos com IA têm uma superfície de exposição de dados maior do que produtos convencionais, porque o input do usuário é rico em informação pessoal e o processamento envolve terceiros. Isso não inviabiliza o produto — exige atenção estruturada.

O checklist acima não é exaustivo e não substitui assessoria jurídica especializada em proteção de dados. É um ponto de partida técnico para equipes que querem sair do "temos uma política de privacidade" para o "nosso produto trata dados pessoais com responsabilidade demonstrável".

O próximo passo é revisar o mapeamento de dados do produto com esse checklist em mãos e identificar as lacunas prioritárias. Especialmente: onde estão os logs de operação de IA, quem tem acesso a eles e por quanto tempo ficam.