Colocar IA no produto sem vazar dado do cliente

Quando uma equipe discute privacidade em integração com IA, a conversa costuma travar em "o modelo vai treinar com os nossos dados?". É uma pergunta legítima e, na prática, quase sempre a menos importante — porque a maior parte dos contratos corporativos já responde não, e porque os vazamentos reais acontecem em lugares bem mais prosaicos.

Este artigo é sobre os lugares prosaicos.

Onde o dado realmente escapa

Em ordem aproximada de frequência:

• Log da sua própria aplicação. O jeito natural de depurar uma integração de IA é registrar o prompt e a resposta. O prompt tem o texto do cliente dentro. Meses depois, existe um arquivo em /var/log com milhares de conversas, retido para sempre, legível por qualquer pessoa com acesso ao servidor e copiado junto em todo backup.
• Retenção do fornecedor. Mesmo sem treinar, provedores costumam guardar requisições por um período para investigar abuso. Isso é aceitável desde que seja uma decisão sua, com prazo conhecido, e não uma descoberta posterior.
• Prompt maior do que precisava ser. Passar o registro inteiro do cliente quando a tarefa precisava de três campos. É o erro mais comum e o mais fácil de corrigir.
• Uso informal. Alguém cola o retorno de um relatório em um chat público para "entender melhor". Nenhum controle técnico do backend cobre isso; só política e ferramenta aprovada.
• Ferramentas conectadas ao modelo. Um agente com acesso ao banco expande o alcance de qualquer instrução maliciosa que entre pelo texto do usuário. O problema deixa de ser privacidade e vira controle de acesso.
• Erro que sobe para o monitoramento. Uma exceção com o corpo da requisição anexado leva o prompt inteiro — com o dado pessoal — para dentro do sistema de observabilidade, que costuma ter retenção longa e acesso amplo.

Repare que quatro desses seis itens acontecem inteiramente dentro da sua infraestrutura, independentemente de qual modelo você use.

O que a LGPD exige, em termos operacionais

Sem transformar isto em texto jurídico, três princípios da lei se traduzem diretamente em decisões técnicas:

• Finalidade. O dado coletado para emitir uma nota não passa a estar disponível para qualquer experimento de IA. Cada novo uso precisa caber na finalidade informada.
• Necessidade (minimização). Trate apenas o mínimo necessário. Aplicado ao prompt, isso significa: não mande o registro inteiro.
• Transparência e responsabilidade. Se um fornecedor processa dados pessoais em seu nome, essa relação precisa estar documentada em contrato, com as garantias de segurança e a base legal registradas.

Na prática, três perguntas resolvem a maior parte da análise: qual dado pessoal entra no prompt, para onde ele vai, e por quanto tempo cada elo guarda. Se a equipe não sabe responder as três de cor, o controle ainda não existe.

Controle 1: mande menos

A defesa mais eficaz é a mais simples, e é técnica. Em vez de:

Analise este cliente e sugira uma ação:
{"nome":"Maria Silva","cpf":"123.456.789-00","email":"maria@exemplo.com",
 "telefone":"11 99999-0000","endereco":"Rua X, 100","plano":"Pro",
 "tickets_abertos":3,"dias_ate_renovacao":12,"uso_mensal_gb":840}

Mande:

Analise este cliente e sugira uma ação:
{"plano":"Pro","tickets_abertos":3,"dias_ate_renovacao":12,"uso_mensal_gb":840}

A resposta do modelo é igualmente boa e nenhum dado pessoal saiu. Nome e CPF não melhoravam a análise — estavam ali porque o objeto já existia no código e passá-lo inteiro dava menos trabalho.

Vale transformar isso em regra de arquitetura: a montagem do prompt seleciona campos, nunca serializa o objeto de domínio. Uma função toPromptPayload() explícita, com teste, é mais confiável do que a disciplina de quem escreve a próxima funcionalidade.

Controle 2: pseudonimize o que precisa ir

Quando o texto livre é o dado — um ticket, uma reclamação, um e-mail — não dá para selecionar campos. Aí a técnica é substituir identificadores por marcadores antes de enviar e reverter na volta:

Original: "Sou a Maria Silva, CPF 123.456.789-00, e meu pedido 88213 não chegou"
Enviado:  "Sou a [PESSOA_1], CPF [CPF_1], e meu pedido [PEDIDO_1] não chegou"

O mapa [PESSOA_1] → Maria Silva fica na sua aplicação, em memória, pelo tempo da requisição. O modelo trabalha igual — a tarefa não dependia do nome real — e o que trafega não identifica ninguém.

Duas ressalvas honestas: reconhecimento de entidades erra, então isso reduz risco sem eliminá-lo; e há casos em que a combinação de dados restantes ainda identifica a pessoa. Trate como redução de superfície, não como anonimização no sentido legal.

Controle 3: pare de logar o prompt inteiro

Este é o item de maior retorno e o mais esquecido.

• Registre metadados, não conteúdo: identificador da requisição, modelo, contagem de tokens, latência, status, custo.
• Se precisar do conteúdo para depurar, registre atrás de uma flag desligada em produção, com retenção curta e explícita.
• Configure o rastreador de erros para não anexar o corpo da requisição. Praticamente todos anexam por padrão.
• Aplique retenção de verdade. Log sem rotação é dado pessoal acumulando em disco:

# /etc/logrotate.d/meuapp
/var/log/meuapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 meuapp adm
}

Note o 0640 e o grupo: log de aplicação não precisa ser legível por todo mundo no servidor — é o raciocínio de permissões aplicado a um arquivo que ninguém trata como sensível e quase sempre é.

E lembre que o backup copia o log junto. Um log com dado pessoal e retenção de 14 dias, cujo backup guarda 12 meses, tem retenção real de 12 meses.

Controle 4: cerque o segredo e o acesso

A chave de API do provedor de IA merece o mesmo tratamento de uma senha de banco:

• Fora do repositório e fora da imagem do container. Em variável de ambiente lida de arquivo com permissão 600, ou em um gerenciador de segredos.
• Chave por ambiente, para que a de desenvolvimento não alcance dados de produção.
• Rotacionável sem redeploy, porque um dia ela vai vazar.

E, quando o modelo tem ferramentas conectadas, o princípio muda de figura: o agente herda as permissões que você der a ele. Um agente que consulta o banco com usuário de leitura restrito a uma view é uma decisão de arquitetura; um agente com a mesma credencial da aplicação é uma superfície de ataque na qual o texto do usuário final influencia o que será executado.

Controle 5: escolha onde processar — com critério, não por reflexo

"Rodar local é mais seguro" é meia verdade. O que muda é quem assume o risco.

Autohospedar é a escolha certa quando o contrato ou a regulação proíbem a saída do dado, ou quando o volume justifica. Não é automaticamente mais seguro: um servidor de inferência esquecido, sem patch e com a porta aberta, é pior do que uma API bem contratada. Se for esse o caminho, os cuidados de infraestrutura estão em rodar um modelo de IA na sua própria VPS — e a primeira linha de defesa continua sendo fechar o que não precisa estar aberto.

Um checklist antes de subir a integração

1. Listar, campo a campo, o que entra no prompt. Cortar tudo que não muda a resposta.
2. Confirmar no contrato do fornecedor: treinamento, retenção, sub-processadores e região de processamento.
3. Desligar o log de conteúdo em produção e conferir o que o rastreador de erros anexa.
4. Definir retenção — e verificar que o backup respeita a mesma retenção.
5. Guardar a chave de API fora do código, com permissão restrita e rotação possível.
6. Registrar a decisão: qual dado, qual finalidade, qual base legal, quem aprovou.
7. Se houver ferramentas conectadas ao modelo, revisar as permissões dessas ferramentas como se fossem de um usuário externo. Porque, na prática, são.

Nenhum item dessa lista é sobre o modelo. Todos são sobre o encanamento em volta dele — que é onde o dado costuma escapar.