LGPD em aplicações LLM: minimização e mascaramento
A maioria das empresas que usa IA generativa está em risco de violação da LGPD sem saber. Não por negligência — mas porque os guias de adequação à lei foram escritos antes de LLMs existirem no contexto corporativo. Este artigo preenche essa lacuna: bases legais, minimização de dados, mascaramento antes do prompt e o que a ANPD espera de você.
O problema: a LGPD não menciona LLM, mas se aplica completamente
A Lei Geral de Proteção de Dados (Lei 13.709/2018) não usa as palavras "LLM", "ChatGPT" ou "IA generativa" em nenhum artigo. Mas isso não significa que ela não se aplica — significa que ela se aplica de forma ampla, porque foi escrita com base em princípios, não em tecnologias específicas.
Toda vez que você envia dados pessoais para um LLM — seja via API externa ou via modelo rodando internamente — você está realizando tratamento de dados pessoais conforme definido no artigo 5° da LGPD. "Tratamento" inclui: coleta, produção, recepção, classificação, utilização, acesso, reprodução, transmissão, distribuição, processamento, arquivamento, armazenamento, eliminação, avaliação, controle, modificação, comunicação, transferência, difusão ou extração.
Enviar um e-mail de cliente para análise de sentimento via API da OpenAI? Tratamento + transferência a terceiro. Usar histórico de compras de usuários para personalizar recomendações via LLM? Tratamento para finalidade de marketing. Processar currículos via IA para triagem de RH? Tratamento de dados sensíveis (saúde, etnia podem constar) com implicações ainda mais graves.
Bases legais para processar dados com LLM
O artigo 7° da LGPD lista as hipóteses que autorizam o tratamento de dados pessoais. Para sistemas com LLM, as mais relevantes são:
- Consentimento (art. 7°, I): o titular autorizou explicitamente. Problemático como base única para funcionalidades essenciais — se o usuário não consentir, perde o serviço, o que compromete a liberdade do consentimento.
- Execução de contrato (art. 7°, V): o processamento é necessário para executar o contrato com o titular. Se você oferece um serviço de análise financeira com IA, processar os dados financeiros do cliente é parte da execução do serviço contratado.
- Legítimo interesse (art. 7°, IX): a base mais flexível, mas exige que o interesse do controlador não prevaleça sobre os direitos do titular. Requer teste de proporcionalidade e pode ser contestada.
- Cumprimento de obrigação legal (art. 7°, II): aplicável quando a lei exige o processamento — ex.: análise de transações para prevenção à lavagem de dinheiro.
Para dados sensíveis (saúde, biometria, raça, religião, opinião política, orientação sexual — art. 11), as hipóteses são mais restritas: basicamente consentimento específico e destacado, ou execução de contrato de saúde.
Tabela de adequação LGPD para sistemas LLM
A seguir, exemplos concretos de tipos de dados pessoais frequentes em sistemas com LLM, com a base legal recomendada, técnica de proteção, responsável e prazo de retenção sugerido:
| Dado pessoal | Base legal recomendada | Técnica de proteção antes do prompt | Responsável | Prazo de retenção sugerido | Risco se descumprido |
|---|---|---|---|---|---|
| CPF / CNPJ | Execução de contrato ou obrigação legal | Mascaramento (ex.: ***.456.789-**) ou substituição por ID interno | Equipe de engenharia + DPO | Duração do contrato + 5 anos (prescrição civil) | Alto — dado identificador direto; violação gera multa e risco de fraude |
| Consentimento ou execução de contrato | Substituir por hash ou ID de usuário; enviar domínio apenas quando irrelevante o usuário específico | Equipe de engenharia + DPO | Duração do consentimento ou contrato | Médio — possibilita contato não autorizado; violação de finalidade | |
| Nome completo | Execução de contrato ou legítimo interesse | Usar primeiro nome ou pseudônimo quando contexto não exige nome completo | Equipe de produto + DPO | Duração do contrato + 2 anos | Baixo a médio — risco aumenta quando combinado com outros dados |
| Conteúdo de contrato / proposta | Execução de contrato | Redação automática dos dados pessoais das partes; enviar apenas cláusulas relevantes para a análise | Jurídico + engenharia + DPO | Duração do contrato + 5 anos | Alto — pode conter dados sensíveis; sigilo profissional; segredo de negócio |
| Histórico de mensagens / atendimento | Execução de contrato ou consentimento | Anonimizar ou pseudonimizar antes de usar em fine-tuning; mascarar PII antes de enviar ao modelo | Engenharia + DPO | Máximo 2 anos para finalidade de melhoria; duração do contrato para fins operacionais | Alto — histórico rico em dados que permitem re-identificação |
| Dados de saúde | Consentimento específico e destacado (art. 11, I) | Minimização máxima: enviar apenas o dado estritamente necessário para a análise clínica | DPO + direção | Conforme regulação setorial (CFM: mínimo 20 anos para prontuário) | Crítico — dado sensível; risco de discriminação; multa máxima ANPD |
| Dados financeiros (renda, transações) | Execução de contrato ou obrigação legal | Agregar ou anonimizar; nunca enviar transações individuais sem necessidade comprovada | Engenharia + Compliance + DPO | 5 anos (Lei 9.613/98 para prevenção a fraudes) | Alto — risco financeiro direto ao titular; BACEN também pode fiscalizar |
| Localização / endereço | Consentimento ou execução de contrato | Usar apenas cidade/estado quando precisão não é necessária; nunca coordenadas em tempo real | Engenharia + DPO | Necessidade operacional + 1 ano | Médio — combinado com outros dados, permite rastreamento; risco de segurança física |
Minimização de dados: o princípio mais ignorado
O artigo 6°, III da LGPD estabelece o princípio da necessidade: "limitação do tratamento ao mínimo necessário para a realização de suas finalidades". Em português claro: se você não precisa de um dado para cumprir a finalidade declarada, não deve coletá-lo — e muito menos enviá-lo ao LLM.
O problema é que desenvolvedores tendem a enviar o máximo de contexto possível ao modelo, na crença de que mais informação gera respostas melhores. Isso geralmente é verdade do ponto de vista de qualidade — mas cria um problema sério de conformidade.
A abordagem correta é o design por minimização: para cada campo que vai ao prompt, questione se ele é estritamente necessário para a tarefa. Se um chatbot de suporte técnico precisa analisar um ticket, ele precisa do nome completo e CPF do cliente — ou apenas do número do ticket e histórico de interações técnicas? Na maioria dos casos, o nome completo e o CPF são desnecessários para resolver o problema técnico.
Mascaramento e anonimização antes do prompt
Quando a minimização não é possível — porque o dado é genuinamente necessário para a tarefa — a próxima camada de proteção é o mascaramento ou anonimização antes de enviar ao modelo.
Existem dois conceitos distintos aqui:
- Pseudonimização: substituição de identificadores diretos (CPF, e-mail) por identificadores artificiais (ID interno, token). O dado original ainda existe no seu sistema — você pode re-identificar. Para a LGPD, dados pseudonimizados ainda são pessoais, mas com proteção adicional.
- Anonimização: processo pelo qual a re-identificação se torna impossível ou desproporcional. Dados genuinamente anonimizados saem do escopo da LGPD. O problema: anonimização verdadeira é difícil, e a ANPD adota critério técnico rigoroso para aceitar a afirmação de anonimização.
Para a maioria dos casos práticos, a abordagem recomendada é:
- Criar uma camada de pré-processamento que roda antes de qualquer chamada ao LLM.
- Usar ferramentas como Microsoft Presidio, spaCy + NER ou AWS Comprehend para detectar automaticamente PII no texto.
- Substituir por placeholders:
[CPF],[EMAIL],[NOME]. - Manter um mapa de reversão seguro (se necessário para a funcionalidade) que nunca vai ao modelo.
Consentimento em chatbots com IA: como implementar corretamente
Se você usa consentimento como base legal, a coleta deve ser feita de forma que atenda os requisitos da LGPD. Para chatbots, o problema é que o usuário pode fornecer dados pessoais livremente no chat sem ter sido informado sobre o processamento via LLM.
As boas práticas são:
- Aviso na abertura do chat: informar claramente que o chat é assistido por IA, quais dados são processados e para qual finalidade — antes de qualquer interação.
- Link para política de privacidade que descreve especificamente o uso de IA generativa.
- Opção de atendimento humano: o usuário deve poder optar por não usar IA. Se isso não for possível operacionalmente, consentimento não é a base adequada.
- Registro do consentimento: timestamp, versão da política aceita, canal e mecanismo de coleta.
DPO e Relatório de Impacto (RIPD): quando são obrigatórios para IA
O DPO (Data Protection Officer, ou Encarregado de Dados na LGPD) não é obrigatório para todas as empresas — mas para aquelas que processam dados pessoais em larga escala, especialmente dados sensíveis, a ANPD recomenda fortemente a designação. Para um SaaS com IA processando dados de milhares de usuários, é essencial.
O RIPD (Relatório de Impacto à Proteção de Dados Pessoais) é exigido pelo artigo 38 da LGPD para tratamentos que, "por sua natureza, âmbito, contexto e finalidades, possam gerar riscos às liberdades civis e aos direitos fundamentais". Sistemas de IA que tomam decisões com impacto significativo nos titulares se enquadram nessa categoria.
Para um RIPD de sistema LLM, você deve documentar:
- Quais dados pessoais são processados e por qual finalidade.
- Como os dados fluem entre os componentes (incluindo APIs de terceiros).
- Riscos identificados para os titulares.
- Medidas de mitigação implementadas.
- Avaliação de proporcionalidade e necessidade.
Para o registro das decisões tomadas com IA — parte central do RIPD —, leia: Auditoria de decisões assistidas por IA: como fazer.
Multas ANPD e risco regulatório: o que esperar
A ANPD tem acelerado seu ritmo de fiscalização. Em 2025, publicou guia específico sobre inteligência artificial e tratamento automatizado, sinalizando que sistemas de IA são prioridade de fiscalização para 2026.
O regime de sanções previsto no artigo 52 da LGPD inclui:
- Advertência com prazo para adoção de medidas corretivas.
- Multa simples de até 2% do faturamento bruto, limitada a R$ 50 milhões por infração.
- Multa diária para infrações continuadas.
- Publicização da infração — o "naming and shaming" que pode ser mais impactante que a multa.
- Bloqueio ou eliminação dos dados pessoais envolvidos.
- Suspensão parcial ou total do funcionamento do banco de dados.
Para PMEs, a multa financeira pode parecer gerenciável — mas a publicização e o bloqueio de dados em um sistema de IA operacional são devastadores. Um SaaS que tem seu banco de dados bloqueado pela ANPD perde a capacidade de operar o serviço para todos os clientes.
Transferência internacional: o ponto mais crítico para APIs de LLM
Quando você usa a API da OpenAI (EUA), Anthropic (EUA) ou Google (global), está realizando transferência internacional de dados pessoais — regulada pelos artigos 33 a 36 da LGPD.
As condições para transferência internacional incluem:
- O país destino oferece nível de proteção adequado (a ANPD ainda não publicou lista definitiva).
- O controlador oferece garantias adequadas via cláusulas contratuais específicas ou normas corporativas globais.
- Consentimento específico do titular para a transferência.
Na prática, os grandes provedores de LLM (OpenAI, Anthropic, Google, Microsoft) oferecem cláusulas de processamento de dados (DPA — Data Processing Agreement) que podem ser invocadas como base para transferência. Verifique se você assinou e configurou o DPA com seu provedor — muitas empresas usam APIs sem nunca ter formalizado essa cláusula.
Para a camada técnica de proteção, sempre aplique mascaramento de PII antes de enviar para APIs externas. Assim, mesmo que haja uma discussão legal sobre a transferência, os dados transferidos não contêm identificadores diretos. Para proteção contra prompt injection em dados mascarados, veja: Prompt injection: ataques indiretos e como defender. Para a política completa de uso aceitável, leia: Política de uso aceitável e guardrails para IA corporativa.
Conclusão: LGPD e IA não são inimigos — exigem design consciente
Adequar um sistema com LLM à LGPD não significa abrir mão das capacidades de IA. Significa projetar o fluxo de dados com o mesmo rigor que você projeta a arquitetura técnica. Minimização de dados, mascaramento antes do prompt e bases legais claras são decisões de arquitetura — não obstáculos legais.
As empresas que tratam LGPD como restrição tendem a fazer remendos de última hora. As que tratam como requisito de design constroem sistemas mais seguros, mais confiáveis e — ironicamente — com melhor qualidade de dado, porque são forçadas a pensar no que realmente precisam processar.