IA generativa com LGPD: mascarar antes do LLM

Para usar IA generativa com dados da empresa sem expor dados pessoais, o caminho mais seguro é tratar esses dados antes que eles cheguem ao modelo: identificar onde estão os dados pessoais, aplicar uma regra de mascaramento no catálogo de dados e só então montar o contexto enviado ao LLM. Com uma trilha de auditoria por consulta, a LGPD deixa de ser um freio e passa a ser um requisito de arquitetura.

Este artigo explica por que o mascaramento precisa vir antes do modelo, quais técnicas usar em cada tipo de dado e onde essa regra deve ficar para valer em qualquer uso dos dados. Não se trata de um parecer jurídico: as decisões sobre base legal e risco continuam com o seu jurídico e o seu encarregado de dados.

Por que o problema aparece com a IA generativa

Em um painel de BI, quem consulta vê apenas as colunas que alguém escolheu mostrar. Na IA generativa, o caminho é outro: um sistema de RAG (retrieval-augmented generation) busca trechos de documentos, tabelas ou tickets que parecem relevantes para a pergunta e os coloca no contexto do modelo. O que entra nesse contexto pode:

ser enviado à API de um provedor de modelos, muitas vezes fora do Brasil;
aparecer na resposta para alguém que não deveria ver aquele dado;
ficar registrado em logs de prompts e respostas, que costumam ter controle de acesso mais frouxo do que o do banco de origem.

Dados pessoais escondidos em texto livre — um CPF no corpo de um e-mail, um endereço em um ticket de suporte, um nome em uma ata — são o caso mais comum. Eles escapam de qualquer filtro que olhe apenas para o nome das colunas.

O que a LGPD exige, em termos de engenharia

A LGPD (Lei 13.709/2018) se aplica ao tratamento de dado pessoal: informação relacionada a pessoa natural identificada ou identificável. Alguns conceitos da lei se traduzem diretamente em decisões técnicas:

Dado pessoal sensível (origem racial ou étnica, saúde, vida sexual, opinião política, biometria, entre outros) está sujeito a regras mais restritivas e merece uma classificação própria no catálogo.
Dado anonimizado não é considerado dado pessoal, desde que a anonimização não possa ser revertida com esforço razoável. Na prática, isso é difícil de garantir quando o dado ainda precisa ser útil.
Pseudonimização — substituir o identificador por outro, mantendo a possibilidade de reidentificação por meio de uma informação guardada separadamente — reduz o risco, mas o dado continua sendo pessoal.
Transferência internacional: enviar dados pessoais a um provedor de modelos no exterior configura transferência internacional, que a lei só admite em hipóteses específicas.
Necessidade: tratar apenas o mínimo necessário para a finalidade. Para um assistente que responde dúvidas sobre contratos, o CPF do cliente raramente é necessário.

O ponto em comum: a forma mais simples de cumprir boa parte dessas exigências é garantir que o dado pessoal não chegue ao modelo quando ele não for necessário para a resposta.

Técnicas de mascaramento, campo a campo

Não existe uma técnica única. A regra adequada depende do uso que o campo precisa continuar permitindo depois de mascarado.

Técnica	O que faz	Quando usar
Hash com segredo	Substitui o valor por um código fixo, que não pode ser revertido sem o segredo	Relacionar registros da mesma pessoa sem expor quem ela é (ex.: CPF como chave)
Tokenização	Substitui o valor por um token e guarda o original em um cofre	Quando um processo autorizado precisa recuperar o valor real (ex.: cartão)
Mascaramento parcial	Oculta parte do valor	Exibição para o atendimento (ex.: e-mail com o domínio oculto)
Generalização	Reduz a precisão	Análises que só precisam de faixa ou região (ex.: CEP por região, idade por faixa)
Supressão	Remove o valor	Campos sem uso para a finalidade

Duas observações práticas:

Hash sem segredo não protege o CPF. A quantidade possível de CPFs é pequena o bastante para ser testada por força bruta; use um segredo (HMAC) guardado separadamente dos dados.
Texto livre exige detecção. Em documentos, e-mails e tickets, a regra por coluna não basta: é preciso detectar entidades (nomes, documentos, contatos) no texto antes da indexação, combinando um detector de entidades com expressões regulares para os formatos brasileiros, e mascarar o que for encontrado.

Onde a regra deve ficar: no catálogo, não em cada aplicação

O erro mais caro é espalhar o mascaramento pelas aplicações: um filtro no chatbot, outro no painel, um terceiro na API. Cada nova aplicação precisa reimplementar a regra, e basta uma delas esquecer.

A alternativa é tratar a privacidade como uma propriedade do dado:

O catálogo registra quais colunas e quais campos de texto contêm dado pessoal, e de que tipo.
A regra de mascaramento fica associada a essa classificação: quem não tem permissão para ver o valor real recebe o valor mascarado, de onde quer que venha a consulta.
Os principais motores e catálogos de dados já oferecem esse mecanismo, com políticas de mascaramento por coluna e filtros por linha associados a etiquetas de classificação.

Assim, um campo novo marcado como pessoal já nasce protegido, e o pipeline de IA não precisa de lógica própria: ele lê os dados pelo catálogo e os recebe já tratados.

Como fica um RAG sobre dados tratados

Uma arquitetura que atende à maioria dos casos:

Ingestão com classificação. Ao entrar na plataforma, cada fonte é catalogada, e os campos com dado pessoal são marcados.
Tratamento antes da indexação. O texto que será transformado em vetores passa pela detecção e pelo mascaramento. O índice vetorial nunca recebe dados pessoais em claro.
Recuperação com permissão. A busca respeita as permissões de quem pergunta: o assistente não traz trechos de documentos que a pessoa não poderia abrir.
Contexto mínimo. Apenas os trechos necessários vão para o modelo, já mascarados.
Auditoria. Cada consulta registra quem perguntou, quais trechos foram recuperados, qual modelo respondeu e quando.

Repare que o modelo pode ser trocado sem refazer a camada de privacidade, porque ela fica antes dele.

Trilha de auditoria: o que registrar

Quando o jurídico ou a área de segurança perguntar "quais dados pessoais chegaram a qual modelo?", a resposta precisa vir de um registro, não de uma estimativa. Uma trilha útil guarda, por consulta:

quem consultou e com qual permissão;
quais fontes e trechos foram recuperados;
se algum campo pessoal foi entregue em claro e por qual regra;
qual modelo, e em qual versão, respondeu;
data e hora.

A própria trilha contém informações sensíveis e deve ter acesso restrito e prazo de retenção definido.

Modelos de terceiros

Usar modelos de provedores externos é comum e, muitas vezes, a escolha mais sensata. Com o mascaramento aplicado antes da montagem do contexto, o provedor recebe apenas dados já tratados. Ainda assim, vale verificar com o jurídico:

onde o provedor processa e armazena as requisições;
se as requisições são usadas para treinar modelos e como desativar esse uso;
o prazo de retenção dos logs do provedor;
a hipótese de transferência internacional aplicável.

Checklist para começar

Inventariar as fontes que vão alimentar a IA e onde há dado pessoal, inclusive em texto livre.
Classificar esses campos no catálogo, com um nível próprio para dados sensíveis.
Definir a regra de mascaramento por tipo de dado, de acordo com o uso que o campo precisa continuar permitindo.
Tratar o texto antes da indexação vetorial.
Garantir que a recuperação respeite as permissões de quem pergunta.
Registrar a trilha de auditoria por consulta e por modelo.
Revisar com o jurídico a base legal, a transferência internacional e os contratos com os provedores.

Como a Coding4u trabalha isso

Na Coding4u, a LGPD vem antes da IA: dados pessoais são mascarados no catálogo antes de chegarem a qualquer modelo, e cada consulta deixa trilha de auditoria. Os detalhes estão em LGPD e IA. Se você está avaliando um assistente ou um RAG sobre os dados da sua empresa, a conversa de 30 minutos e o diagnóstico inicial não têm custo, e você sai deles com uma proposta.