Neste artigo
- Retenção e uso para treinamento são coisas diferentes
- O que você não deveria mandar sem pensar duas vezes
- LGPD não é opcional, mesmo que pareça
- As perguntas que eu faço antes de qualquer integração
- Quando considerar modelos locais ou on-premise
- Como classificar antes de construir
- A pergunta que fecha o raciocínio
Para a maioria das equipes que estão integrando LLMs em produtos, a conversa sobre dados acontece depois que o produto já está funcionando. Eu sei porque já participei dessas conversas e, spoiler, elas são bem mais difíceis quando você está desfazendo uma integração do que planejando uma.
O problema não é técnico. É de ordem. A pergunta “o que acontece com esse dado quando eu mando para a API?” deveria vir antes da pergunta “como eu conecto isso ao meu CRM?”. Na prática, ela vem depois, quando alguém do jurídico ou de segurança pede um relatório de fluxo de dados e você não tem resposta clara.
Então vou começar pelo que a maioria das documentações não explica com clareza suficiente.
Retenção e uso para treinamento são coisas diferentes
Quando você manda um texto para uma API de LLM, esse texto vai para um servidor externo. A partir daí, o que acontece depende de duas variáveis: política de retenção e política de treinamento. São perguntas diferentes e as pessoas costumam confundir as duas.
Retenção diz respeito a quanto tempo o provedor guarda os dados enviados. Pode ser zero, processamento em memória e descarte imediato. Pode ser 30 dias para fins de debugging. Pode ser mais. A maioria das APIs empresariais, quando você usa a versão paga com contrato, oferece retenção zero ou períodos curtos com opção de opt-out explícito.
Treinamento é se os dados enviados são usados para melhorar os modelos futuros. Esse é o ponto que mais gera confusão. No plano gratuito ou consumer de muitos provedores, a resposta padrão costuma ser que podem ser usados, sim. Nas versões de API com contrato empresarial, geralmente existe opt-out, às vezes ativado por padrão, mas só se você estiver sob o plano certo.
O erro mais comum é assumir que “API” significa automaticamente que os dados não são usados para treinamento. Não significa. O que significa é que você tem mais controle disponível, mas só se ler os termos e configurar os ajustes certos. Omissão aqui não é inocente.
O que você não deveria mandar sem pensar duas vezes
Não é questão de paranoia. É questão de classificação. Toda empresa que trabalha com dados deveria ter, mesmo que de forma simples, uma ideia do que é dado sensível e o que não é.
Na prática, alguns tipos de dado pedem mais atenção antes de ir para qualquer API externa:
- Dados pessoais identificáveis de usuários, como nome, CPF, e-mail, histórico de compras vinculado a pessoa física.
- Dados financeiros, especialmente se incluem informações de pagamento, saldo ou crédito.
- Dados de saúde, mesmo que anonimizados de forma incompleta.
- Informações confidenciais de clientes B2B, como dados de contratos, negociações ou estratégias.
- Propriedade intelectual interna, como dados proprietários de pesquisa ou lógica de negócio exclusiva.
O ponto não é nunca mandar nada para fora. É saber exatamente o que você está mandando e ter uma decisão consciente sobre isso, não uma omissão que ninguém percebeu na hora.
LGPD não é opcional, mesmo que pareça
A Lei Geral de Proteção de Dados obriga empresas que tratam dados pessoais de brasileiros a ter base legal para cada operação de tratamento. Quando você manda um dado pessoal para uma API de LLM, você está compartilhando esse dado com um terceiro. Isso é tratamento. Precisa de base legal. Precisa de, dependendo do contexto, consentimento ou legítimo interesse documentado e justificado.
O que pouca gente discute: o provedor da API também passa a ser um operador de dados na estrutura da LGPD. Isso significa que deveria haver um contrato de processamento de dados entre você e o provedor. Provedores grandes como OpenAI, Anthropic e Google têm esse tipo de documento disponível, geralmente chamado de Data Processing Agreement (DPA). Mas você precisa assinar, ativar ou pelo menos estar sob um plano que o inclua automaticamente.
Se você está usando a versão gratuita de qualquer produto de IA para processar dados de clientes, é muito provável que você não tenha esse contrato. E aí a conversa com o jurídico vai ser desconfortável. Pois é.
As perguntas que eu faço antes de qualquer integração
Esse checklist foi construído por tentativa e erro. Não é exaustivo, mas é o mínimo que eu precisaria ter respondido antes de aprovar qualquer integração de LLM em produção:
- Qual é a política de retenção de dados da API? Está documentada? Onde?
- Existe opt-out de uso para treinamento? Está ativado na nossa conta?
- O provedor oferece DPA para o plano que usamos? Está assinado ou ativado?
- Que tipo de dado vai passar por essa integração? Está classificado como sensível?
- Se o provedor tiver uma violação de segurança, qual é o protocolo de notificação deles e ele cabe dentro dos prazos da LGPD?
- Existe alguma forma de anonimizar ou pseudonimizar os dados antes de enviar, sem perder utilidade para o caso de uso?
Esse conjunto de perguntas não resolve tudo, mas filtra os casos onde a integração não deveria acontecer ainda, ou pelo menos não daquele jeito.
Quando considerar modelos locais ou on-premise
Não estou aqui para defender que todo mundo deveria rodar modelo local. Não é isso. Mas existe um conjunto de situações onde faz mais sentido do que parece à primeira vista, e ignorar essa alternativa por preguiça de avaliar é uma decisão ruim disfarçada de agilidade.
Se você está em setor regulado, como saúde, crédito ou jurídico, o custo de compliance com API externa pode superar o custo operacional de rodar um modelo menor internamente. Especialmente se os dados são altamente sensíveis e o caso de uso é bem definido e estável.
Detalhe importante: se a tarefa é suficientemente específica, um modelo menor ajustado para aquele contexto frequentemente entrega qualidade comparável a um modelo grande genérico, com a vantagem de que o dado nunca sai da sua infraestrutura. Na minha experiência, a maioria das equipes não considera essa opção porque o caminho de menor atrito é a API externa. Caminho de menor atrito e decisão mais inteligente raramente são a mesma coisa.
Como classificar antes de construir
O que funciona melhor, e o que eu recomendo a qualquer equipe antes de começar qualquer integração de LLM, é definir a política de dados antes de qualquer decisão de ferramenta. Significa sentar com as áreas relevantes, normalmente produto, jurídico e segurança, e responder três perguntas concretas:
Que dados esse sistema vai processar? Liste com exemplos concretos, não categorias vagas. “Dados do usuário” não é uma resposta útil. “Nome, e-mail e histórico de pedidos dos últimos 12 meses” é.
Algum desses dados tem restrição regulatória ou contratual que impede compartilhamento com terceiros? Inclui contratos com clientes B2B que tenham cláusulas de confidencialidade sobre os dados que você processa para eles.
Se algum dado sensível precisar passar pelo sistema, qual é o processo de aprovação e documentação necessário? Não precisa ser burocrático, mas precisa existir e precisar ser seguido.
Com essas respostas, a conversa sobre qual API usar, com qual plano e com quais configurações fica muito mais direta. Sem elas, você está construindo sobre suposições que vão aparecer na forma de problema mais tarde.
A pergunta que fecha o raciocínio
No final das contas, a métrica que importa aqui não é técnica. É: se alguém auditar o fluxo de dados desse sistema amanhã, você consegue explicar onde cada tipo de dado vai, quanto tempo fica lá e com qual base legal o compartilhamento acontece?
Se a resposta for “não sei”, o problema não é a ferramenta escolhida. É que a decisão foi tomada sem as informações mínimas. E isso é um problema que aparece cedo ou tarde, geralmente nas piores circunstâncias possíveis.
Não precisa ser burocrático para ser sério. Um documento simples, uma conversa documentada, um DPA assinado. O esforço é pequeno comparado ao custo de desfazer uma integração que deveria ter sido avaliada antes de subir.
