Dados sensíveis em LLMs: o que avaliar antes da API

Dados sensíveis em LLMs viram um problema real assim que você manda uma linha de CPF, prontuário médico ou contrato de cliente para uma API externa sem antes classificar o que está saindo do seu ambiente. A resposta direta é: antes de qualquer integração, você precisa mapear a origem do dado, classificar o nível de sensibilidade e decidir se aquele processamento pode rodar fora da sua infraestrutura ou não. Se essa resposta não estiver clara antes do primeiro request, o risco já foi assumido, só ainda não apareceu.

Eu já vi esse erro de perto. Time empolgado com um protótipo, prompt bonito, resultado impressionante em duas semanas. Ninguém perguntou, antes de mandar o primeiro lote de dados de produção para a API, o que acontecia com aquele conteúdo do lado do provedor. Spoiler: o problema raramente aparece no modelo. Aparece três meses depois, numa auditoria, quando alguém pergunta onde os dados de clientes foram parar.

Isso não é sobre desconfiar de LLM. É sobre controle. Na minha experiência, controle sobre os dados importa mais do que controle sobre a ferramenta, principalmente quando o seu produto lida com informação regulada. E esse controle não se resolve com boa vontade, se resolve com processo.

O que conta como dado sensível quando você usa uma API de LLM

Dado sensível não é só CPF e senha. A LGPD define uma categoria específica (origem racial ou étnica, convicção religiosa, opinião política, dado de saúde, orientação sexual, dado genético ou biométrico) que exige tratamento mais rígido que dado pessoal comum.

No contexto de LLM, o problema é sutil: esse tipo de dado costuma entrar no prompt sem ninguém perceber. Um chatbot de suporte que recebe a descrição de um sintoma. Um agente que processa currículo e menciona licença maternidade. Um resumo de atendimento que cita religião do cliente porque ele mencionou de passagem.

O prompt inteiro, com todo esse contexto, sai da sua infraestrutura e vai para o provedor da API. A partir daí, o que acontece com aquele texto depende dos termos de uso, da política de retenção e de saber se o provedor usa esse conteúdo para treinar modelo.

Quando parar e avaliar antes de mandar dados para uma API externa

Alguns sinais deixam claro que você precisa parar e avaliar antes de integrar qualquer LLM externo:

• O produto lida com dado de saúde, financeiro ou de menores de idade.
• O cliente é do setor público, bancário ou de saúde e tem regulação setorial própria além da LGPD.
• O contrato com o cliente final tem cláusula de confidencialidade ou de localização de dados.
• A funcionalidade envolve decisão automatizada que afeta o cliente (aprovação de crédito, triagem de currículo, priorização de atendimento).

Se nenhum desses sinais estiver presente, o risco é menor e você pode seguir com integração padrão de API gerenciada, com atenção normal de segurança. Se algum estiver, o processo de avaliação vira pré-requisito, não etapa opcional.

Como mapear e classificar dados antes de qualquer integração

Mapeamento de origem

Antes de escrever qualquer prompt, alguém do time precisa listar de onde vem cada campo que entra naquele contexto. Não é exercício acadêmico. É a única forma de saber se um dado sensível está escondido dentro de um campo de texto livre, como uma observação de atendimento ou um comentário de formulário.

Classificação por sensibilidade

Depois do mapeamento, classifique cada campo em níveis simples: público, interno, pessoal e sensível. Você pode pedir para uma IA ajudar nessa triagem, descrevendo cada campo e perguntando em qual categoria da LGPD ele se encaixa. O trabalho da IA aqui é sugerir a classificação, não decidir sozinha. Alguém do time de dados ou jurídico precisa validar a lista final antes de qualquer prompt ir para produção.

Anonimização e mascaramento

Para campos classificados como sensíveis, a pergunta certa para a IA não é "resuma esse atendimento", é "resuma esse atendimento removendo nome, CPF, dado de saúde e substituindo por identificadores genéricos". Depois, valide manualmente uma amostra das saídas para confirmar que a mascaração realmente aconteceu antes de liberar em escala. Esse é o tipo de detalhe que a documentação da ferramenta nunca vai te lembrar de checar.

API externa gerenciada vs modelo self-hosted: quando escolher cada um

Quando o dado é público ou interno, API gerenciada resolve com menos esforço operacional e você fica livre de manter infraestrutura de modelo.

Quando o dado é pessoal sensível e o volume justifica o investimento, rodar LLMs localmente com Ollama tira o dado da sua rede zero vezes, porque ele nunca sai dela. Isso custa mais em manutenção e em infraestrutura, mas elimina a dependência de contrato de terceiro para garantir que o dado não vira material de treino de outro modelo.

Não existe resposta universal aqui. Existe estimar o custo de LLMs em produção somado ao custo de exposição regulatória, e comparar contra o custo de manter um modelo próprio rodando. Na maioria dos casos que vi, a decisão vira clara assim que você coloca as duas contas lado a lado.

O que a LGPD realmente exige de quem processa dados com IA

A lei não proíbe uso de IA. Exige base legal para o tratamento, transparência sobre como o dado é usado e, em decisões automatizadas que afetam a pessoa, direito de solicitar revisão humana. Para tratamento de dado sensível em escala, a recomendação prática é montar um relatório de impacto à proteção de dados antes do deploy, documentando por que aquele dado precisa passar por IA e quais controles existem.

Vale a leitura oficial da Autoridade Nacional de Proteção de Dados (ANPD) para entender as diretrizes atualizadas sobre tratamento automatizado, porque a interpretação da lei evolui e vale acompanhar direto da fonte.

O custo de ignorar isso

Multa é a parte visível. A parte que dói mais, na minha experiência, é ter que trocar de provedor às pressas depois que um cliente descobre que dado sensível estava indo para uma API sem controle. Isso significa reescrever prompt, reavaliar guardrails para validar entrada e saída de LLMs e, quase sempre, migrar histórico de dados que já foi processado.

Também vale rastrear chamadas de LLM com Langfuse self-hosted, porque sem log detalhado de o que foi enviado para cada provedor, você não tem como responder com precisão quando alguém perguntar quais dados saíram e para onde.

Perguntas frequentes

Posso usar API de LLM externa com dados sensíveis?

Pode, desde que exista base legal, contrato que garanta que o dado não vira material de treino e mascaramento de campos sensíveis antes do envio. Sem esses três pontos, o risco fica alto demais para justificar a conveniência.

O que é dado sensível segundo a LGPD?

É a categoria de dado pessoal que revela origem racial, religião, opinião política, saúde, orientação sexual, dado genético ou biométrico. Esses dados exigem tratamento mais rígido que dado pessoal comum, incluindo base legal específica.

Vale a pena rodar modelo próprio só por privacidade?

Vale quando o volume de dado sensível é alto e recorrente, porque o custo de infraestrutura se paga com a redução de risco regulatório. Para volume baixo ou esporádico, mascaramento de dado antes de enviar para API gerenciada costuma resolver com menos esforço.

Como saber se meu prompt está vazando dado sensível?

Faça auditoria de amostra revisando manualmente prompts reais enviados em produção, procurando campos de texto livre onde informação sensível pode ter entrado sem intenção. Automatize essa checagem com um segundo modelo perguntando se o texto contém dado sensível, mas valide o resultado com revisão humana periódica.

Conclusão

Dados sensíveis em LLMs não são um detalhe de compliance para resolver depois do deploy. São critério de decisão desde o desenho do prompt. O time que mapeia, classifica e mascara antes de integrar gasta mais tempo no início e bem menos tempo apagando incêndio depois.

Comece mapeando os campos que hoje entram nos seus prompts de produção e classificando cada um por sensibilidade. Se identificar volume relevante de dado sensível, avalie o custo real de manter processamento local antes de assinar mais um contrato de API externa.