Posso usar os dados do meu cliente para treinar IA?

A base de dados está ali, com anos de atendimento, documento e histórico. A tentação é evidente: usar isso para afinar um modelo e ter um sistema que entende o seu negócio como nenhum genérico entenderia.

A pergunta que precede a implementação não é técnica. É se você pode. E a resposta depende de uma distinção que costuma passar batida: processar dado é diferente de treinar com dado, e o que autoriza o primeiro nem sempre autoriza o segundo.

Por que treinar é diferente

Quando você envia o texto de um cliente para um modelo gerar um resumo, o dado é usado e descartado. A finalidade é evidente — prestar o serviço contratado — e o tratamento termina ali.

Treinar é outra coisa. O dado passa a integrar os pesos do modelo, de forma difusa e permanente. Três consequências decorrem disso:

• A finalidade mudou. O cliente forneceu o dado para receber um serviço, não para melhorar um produto que será vendido a terceiros. Finalidade é o eixo central da LGPD, e mudar de finalidade exige justificativa própria.
• A retenção virou indefinida. Você pode apagar a linha do banco; extrair aquela contribuição específica dos pesos do modelo não é uma operação que exista de forma prática.
• Pode haver memorização. Modelos ocasionalmente reproduzem trechos literais do material de treino, especialmente quando o exemplo aparece muitas vezes.

Essa terceira é a que transforma a discussão jurídica em risco técnico concreto: um modelo treinado com dado de um cliente pode, na resposta a outro, devolver algo que veio do primeiro.

A base legal precisa existir antes

A LGPD exige uma base legal para cada tratamento. Para treino, as candidatas usuais e o que cada uma implica:

• Consentimento. Específico e destacado para essa finalidade. Aceite genérico de termos de uso não cobre. Tem a fragilidade de poder ser revogado.
• Legítimo interesse. Possível, e exige o teste de balanceamento documentado — avaliar se a expectativa razoável do titular comporta esse uso. Não se aplica a dado sensível.
• Execução de contrato. Cobre prestar o serviço. Dificilmente cobre treinar um modelo que será usado com outros clientes.

Repare que dado sensível — saúde, biometria, convicção, origem racial — tem regime próprio e mais restrito. Base de atendimento médico, jurídico ou de recursos humanos cai aí com frequência, e o legítimo interesse deixa de ser opção.

Independentemente da base escolhida, três obrigações permanecem: informar o titular com transparência, registrar a decisão e a justificativa, e conseguir responder a um pedido de informação sobre o tratamento.

O contrato que você assinou

Antes mesmo da lei, olhe o que foi prometido. É o obstáculo mais frequente na prática, e o mais fácil de verificar.

Contratos B2B costumam trazer cláusulas que restringem uso de dado do cliente para qualquer finalidade além da prestação do serviço. Muitos vedam explicitamente o uso para desenvolvimento de produto ou treino de modelo.

Verifique, no seu contrato padrão e nos contratos negociados individualmente — que costumam ser mais restritivos:

• Cláusula de confidencialidade e o escopo de uso permitido.
• O acordo de tratamento de dados, quando existir, e o que ele diz sobre finalidade secundária.
• Se você é operador, e não controlador, daquele dado. Operador trata em nome do controlador e não pode dar destinação própria ao material. Se os dados são dos clientes do seu cliente, é bem provável que este seja o caso.

Um dado que você hospeda não é um dado que você pode usar. É a confusão mais cara dessa área.

Anonimizar é mais difícil do que parece

A saída natural é anonimizar. Dado anonimizado sai do escopo da LGPD — mas a lei exige que a anonimização seja irreversível considerando meios razoáveis, e é aí que a maioria das tentativas falha.

Trocar nome por [CLIENTE] não anonimiza. Um texto de atendimento com o número do pedido, a data, a cidade e o produto identifica a pessoa por combinação, mesmo sem nenhum nome.

O que costuma ser necessário:

• Remover identificadores diretos — nome, CPF, e-mail, telefone, endereço.
• Tratar quase-identificadores — data exata, CEP completo, valor específico, número de protocolo. Generalizar em faixas costuma bastar.
• Cuidar do texto livre, que é a parte difícil. Cliente escreve o próprio nome no meio da mensagem, cita o vizinho, informa o endereço de entrega.
• Avaliar o risco de reidentificação de forma explícita, com registro do raciocínio.

Uma detecção automática de dado pessoal ajuda no volume, mas erra — e a taxa de erro importa quando o resultado alimenta um modelo permanente. Vale amostrar manualmente uma parte do conjunto anonimizado antes de treinar: é o único jeito de saber a taxa real de escape.

Se o dado não pode sair da sua infraestrutura durante esse processamento, essa é uma das situações em que processar localmente deixa de ser preferência e vira requisito.

O direito de eliminação e o modelo

Aqui está o problema sem solução limpa. Se um titular pedir a exclusão dos dados e eles já estiverem em um modelo treinado, o que acontece?

Apagar do banco é trivial. Remover a influência daquele registro dos pesos não é uma operação disponível na prática. As saídas reais, em ordem de preferência:

• Treinar apenas com dado anonimizado, para que a questão não se coloque.
• Manter procedência. Saber quais registros compuseram cada versão do conjunto de treino permite excluí-los do próximo ciclo — o que exige versionar conjunto e modelo juntos.
• Retreinar periodicamente a partir do conjunto atualizado, com uma cadência declarada.

A terceira é a que sustenta uma resposta honesta ao titular: informar que o dado foi removido da base e do próximo ciclo de treino, e em quanto tempo o modelo atual será substituído.

Um caminho que costuma resolver

Antes de assumir todo esse custo, vale confirmar se treinar é mesmo necessário. Como o comparativo entre RAG, fine-tuning e prompt mostra, boa parte do que se quer obter com treino é, na verdade, problema de conhecimento — e conhecimento se resolve com recuperação.

A diferença em conformidade é enorme. Em RAG, o documento continua no seu banco, com controle de acesso, retenção e exclusão funcionando normalmente. Ele é consultado no momento da pergunta e não integra permanentemente nada. Um pedido de eliminação é executado apagando o registro e reindexando.

Some a isso os controles que valem em qualquer arranjo, e que o artigo sobre IA sem vazar dado do cliente detalha: o vazamento costuma acontecer pelo log e pela retenção do fornecedor, não pelo treino.

O caso do fornecedor que treina com o seu dado

A mesma pergunta se inverte, e vale fazê-la sobre quem você contrata. Se você envia dado de cliente para uma API de IA, o que aquele fornecedor faz com o conteúdo?

Os termos variam bastante, e mudam com o tempo. O que verificar, nos termos de uso e não no material de marketing:

• Se o conteúdo enviado é usado para treinar. Muitos serviços distinguem o plano gratuito do corporativo justamente nesse ponto.
• Por quanto tempo fica retido. Retenção para moderação de abuso é comum, e costuma ser de dias a semanas mesmo quando não há treino.
• Se há opção de recusar, e se ela precisa ser solicitada ativamente.
• Onde o processamento ocorre, o que se conecta à discussão de jurisdição.

Esse item costuma ser o mais relevante na prática, porque afeta o uso diário e não apenas um projeto de treino eventual. E como você é controlador do dado dos seus clientes, a escolha do fornecedor e a documentação dessa escolha são responsabilidade sua — inclusive perante um cliente que pergunte.

O checklist mínimo

• Leia o contrato antes de olhar a lei. Ele costuma decidir sozinho.
• Defina e registre a base legal, com o teste de balanceamento se for legítimo interesse.
• Verifique se há dado sensível no conjunto — se houver, o regime é outro.
• Anonimize de verdade, e valide por amostragem manual.
• Versione o conjunto de treino com procedência, para conseguir excluir depois.
• Pergunte se RAG resolve. Na maioria das vezes resolve, com uma fração da exposição.

Vale registrar o que costuma destravar essa conversa dentro das empresas. O time técnico tende a tratar o assunto como obstáculo e o jurídico como risco a evitar, e a discussão trava. O que resolve é mudar a pergunta: em vez de "podemos usar os dados?", perguntar "qual é o menor conjunto de dados que resolve o nosso problema?". Quase sempre a resposta é bem menor do que a base inteira — e um recorte pequeno, anonimizado e com finalidade clara é uma conversa muito mais simples de aprovar do que um pedido amplo.

Este texto é uma leitura técnica e não substitui parecer jurídico. As referências legais podem ter mudado, e decisão sobre base legal e uso de dado pessoal deve passar por quem responde formalmente por ela na sua empresa.