Pedidos de direito ao esquecimento colidem com a forma como os LLMs realmente armazenam dados

O artigo 17 do RGPD e disposições de exclusão semelhantes em outras leis de privacidade foram escritos em torno de um modelo mental simples: dados pessoais vivem em um registro, dentro de um banco de dados, e uma empresa pode encontrar esse registro e excluí-lo. Esse modelo funciona bem para o endereço de um cliente em um CRM. Ele se desfaz completamente quando os mesmos dados desse cliente foram usados para treinar ou ajustar um modelo de linguagem grande, porque um modelo treinado não armazena dados pessoais como um registro recuperável. Ele os armazena como um padrão difuso de ajustes de peso distribuídos por bilhões de parâmetros, e não existe uma consulta que selecione apenas a contribuição de uma pessoa e a remova.

A suposição que a lei de exclusão faz

Os reguladores de privacidade construíram suas estruturas de exclusão em torno de bancos de dados, e a lógica é sólida para esse caso de uso: localizar a linha, excluir a linha, confirmar a exclusão. As empresas passaram duas décadas construindo as ferramentas para fazer isso de forma confiável em escala. Nenhuma dessas ferramentas se transfere para os parâmetros de um modelo. Depois que os dados de treinamento são absorvidos nos pesos via descida de gradiente, a contribuição específica de um documento ou dos dados de uma pessoa não é isolável posteriormente. O modelo não “contém” o exemplo de treinamento em nenhuma forma que você possa localizar e remover.

Por que os LLMs quebram essa suposição

As opções honestas para realmente satisfazer um pedido de exclusão contra um modelo treinado são todas caras, e a maioria incompleta. O retreinamento completo a partir de um conjunto de dados do qual os dados da pessoa foram removidos é a única abordagem que satisfaz claramente a letra da lei, e custa milhões de dólares e semanas de computação para qualquer modelo de tamanho significativo — um custo que escala com o tamanho do modelo e a frequência de retreinamento, não com quantos pedidos de exclusão chegam. A pesquisa em desaprendizado de máquina (machine unlearning) produziu técnicas que ajustam os pesos de um modelo para reduzir a influência de exemplos de treinamento específicos sem retreinamento completo, mas os resultados publicados mostram consistentemente que esses métodos são aproximados: eles reduzem de forma mensurável a capacidade de um modelo de reproduzir conteúdo memorizado específico, mas não garantem que a remoção seja completa, e verificar essa completude é, em si, um problema de pesquisa aberto. Uma empresa que lança um patch de desaprendizado atualmente não consegue provar, à satisfação de um regulador, que os dados realmente desapareceram.

A maioria das empresas atualmente evita a versão mais difícil desse problema mantendo dados pessoais fora do conjunto de treinamento desde o início e confiando na geração aumentada por recuperação (RAG) em vez disso — buscando os dados do usuário em um banco de dados convencional e apagável no momento da inferência, em vez de incorporá-los aos pesos do modelo. Essa abordagem resolve genuinamente o problema de exclusão para novos sistemas projetados com isso em mente. Ela não faz nada pela geração de modelos já treinados em conjuntos de dados coletados antes que essa distinção se tornasse prática padrão, que é a maior parte da frota de modelos de fronteira atualmente em produção.

Onde a disputa está realmente acontecendo

Os reguladores começaram a tratar isso como uma questão real, não hipotética. Autoridades europeias de proteção de dados abriram investigações sobre se os pipelines de treinamento de modelos fundacionais cumprem as obrigações de exclusão, e as respostas que as empresas deram — apontando para filtragem, bloqueio de conteúdo no nível de saída, ou ciclos de retreinamento programados — ainda não satisfizeram reguladores que pedem prova de que a influência dos dados de um indivíduo específico foi removida, não apenas suprimida na etapa de saída. A distinção importa: impedir que um modelo repita o nome de uma pessoa em sua saída não é o mesmo que remover os dados dessa pessoa dos pesos que produziram essa saída, e vários casos em andamento giram exatamente em torno dessa diferença.

O que as empresas estão realmente fazendo sobre isso

Na prática, a maioria das empresas de IA que atualmente lidam com esse risco fazem três coisas simultaneamente: deslocar novos sistemas para arquiteturas RAG que mantêm os dados pessoais apagáveis por design, programar retreinamentos completos periódicos em conjuntos de dados limpos como a aproximação mais próxima da conformidade para modelos já implantados, e fazer lobby junto aos reguladores para aceitar a filtragem no nível de saída como conformidade suficiente em vez de exigir remoção no nível dos pesos. Essa terceira estratégia é a que está sendo realmente contestada nos processos regulatórios atuais.

Conclusões práticas

Se você está implantando um produto baseado em LLM que toca dados pessoais, prefira designs aumentados por recuperação que mantêm esses dados em um armazenamento apagável, não incorporados em pesos ajustados.
Não trate a filtragem de conteúdo no nível de saída como equivalente à exclusão. Os reguladores, cada vez mais, não fazem isso, e a lacuna entre os dois é onde está a exposição legal atual.
Orce retreinamentos completos periódicos em conjuntos de dados limpos como um custo de conformidade real para qualquer modelo ajustado que lide com dados pessoais.
Observe as investigações europeias sobre conformidade no treinamento de modelos fundacionais — seu resultado provavelmente definirá a definição prática de “exclusão” para modelos treinados em todas as jurisdições.
Se sua equipe jurídica está confiando em técnicas de desaprendizado de máquina para satisfazer um pedido de exclusão, obtenha por escrito qual padrão de completude o regulador realmente aceitará.