Machine Unlearning: um fluxo prático para remoção de dados de AI

Se alguém pedir que você exclua os dados dessa pessoa de um sistema de AI, remover uma linha de um banco de dados não é todo o trabalho. Machine unlearning pode reduzir ou redirecionar a resposta de um modelo a exemplos específicos de treinamento, mas não limpa automaticamente o restante da stack: índices vetoriais, adapters ajustados, prompts em cache, checkpoints, réplicas, backups e exports. A NIST define machine unlearning como a remoção seletiva da influência de pontos específicos de treinamento de um modelo treinado e observa explicitamente que técnicas aproximadas eficientes podem evitar um novo treinamento completo do zero. Isso é mais restrito do que dizer que “todo o sistema esqueceu os dados”. NIST

Para a maioria das equipes, a resposta prática é em camadas. Primeiro, rastreie para onde os dados foram. Depois, interrompa a reutilização. Em seguida, exclua ou restrinja os artefatos derivados. Só então decida se os pesos do modelo precisam de retraining ou de unlearning aproximado. O Machine Unlearning Challenge de 2023 do Google usou exatamente essa abordagem centrada no modelo: um modelo submetido a unlearning deve se tornar difícil de distinguir de um modelo retreinado sem o forget set, preservando ao mesmo tempo o desempenho no retain set. Google Research

Sumário

O que machine unlearning realmente significa

Machine unlearning é uma operação no nível do modelo. Trata-se de reduzir a influência de dados selecionados sobre o comportamento de um modelo treinado. Isso pode significar retraining exato usando o conjunto retido ou um método aproximado que busca chegar perto o suficiente sem pagar o custo total de retraining. A NIST usa as duas ideias em sua entrada do glossário, e a página do desafio do Google define o padrão-ouro como a similaridade com um modelo retreinado do zero sem os exemplos esquecidos. NIST Google Research

Essa definição é importante porque os sistemas de AI raramente terminam nos pesos do modelo. Uma stack de produção normalmente inclui:

Excluir apenas uma dessas camadas ainda pode deixar os dados acessíveis em outro lugar. Na prática, “remover estes dados da AI” é um problema de lineage antes de se tornar um problema de edição de modelo.

Por que um fluxo normal de exclusão não é suficiente

Muitos produtos de AI nunca treinaram com os dados que lhes pedem para excluir. Eles apenas os recuperaram no momento da inferência. Nesse caso, o trabalho é remover registros de origem, embeddings derivados, caches e caminhos de acesso. Machine unlearning é irrelevante porque os pesos do modelo nunca foram alterados.

Os casos mais difíceis começam quando os dados afetaram pesos, adapters ou memórias persistentes. Então você precisa separar quatro situações, em vez de tratar toda solicitação de exclusão da mesma forma.

Essa tabela mostra por que “botão de excluir” é o modelo mental errado. O modelo correto é remoção com escopo definido e evidências.

Um fluxo prático em sete etapas

1. Defina o escopo da solicitação e congele a reutilização

Comece com os identificadores exatos: ID do usuário, hash do arquivo, IDs dos documentos, nomes das coleções vetoriais, IDs dos lotes de treinamento ou referências de tickets. Depois, interrompa novas reutilizações. Pause ingestão, retraining, jobs de export ou sincronizações que recriariam os mesmos dados enquanto você faz a limpeza.

Se a solicitação for motivada por privacidade, mantenha o enquadramento jurídico restrito. O Artigo 17 do GDPR cria um direito à exclusão em circunstâncias definidas, mas não informa qual camada técnica deve ser tocada primeiro. A opinião do European Data Protection Board de 18 de dezembro de 2024 sobre modelos de AI também afirma que modelos treinados com dados pessoais não podem, em todos os casos, ser tratados como anônimos. Preserve um fluxo explícito de exclusão, em vez de presumir que o modelo está fora do escopo. EUR-Lex EDPB

2. Rastreie o lineage antes de excluir qualquer coisa

Mapeie o caminho completo:

3. Exclua ou restrinja artefatos de origem e derivados

Agora limpe o que puder ser limpo de forma determinística:

Uma issue pública do AnythingLLM relatou que os embeddings de documentos excluídos supostamente continuaram recuperáveis em uma configuração baseada em Weaviate. Uma issue é evidência anedótica, não uma constatação sobre toda a plataforma. Ainda assim, ela mostra por que todo fluxo de exclusão precisa de um teste negativo de retrieval para IDs de documentos, frases distintivas e paráfrases.

4. Decida se os pesos do modelo foram alterados

Este é o ponto de ramificação que as equipes frequentemente ignoram.

O desafio de 2023 do Google define o objetivo no lado do modelo: o modelo submetido a unlearning deve se parecer com um modelo retreinado sem os exemplos esquecidos, preservando o comportamento útil aprendido com o restante dos dados. Google Research

5. Crie conjuntos de avaliação antes de alterar os pesos

Você precisa de pelo menos três recortes:

*Legenda: O trabalho de exclusão começa com o lineage dos dados e os artefatos derivados. Machine unlearning do modelo só começa depois que você prova se os pesos foram afetados.*

6. Teste o esquecimento e a utilidade retida em conjunto

Pesquisas recentes deixam claro o trade-off.

O artigo *Behavioral Audit of Machine Unlearning Has a Privacy Cost* argumenta que, para modelos convexos, uma auditoria comportamental black-box não pode simultaneamente detectar unlearning insuficiente e evitar o vazamento de informações sobre a participação no retain set para um auditor honesto, mas curioso. Os autores também apresentam evidências empíricas de que essa tensão persiste em configurações não convexas. Isso significa que uma única pontuação de auditoria limpa não equivale a uma prova universal de esquecimento seguro. arXiv

O framework de auditoria do Google Research, de 10 de junho de 2026, aborda o problema de outra direção. Ele propõe Regularized f-Divergence Kernel Tests para tornar a auditoria mais sensível e controlar falsos positivos de forma mais confiável em diferentes tamanhos de amostra. O resultado é um teste estatístico, não uma prova de exclusão completa. Google Research

PrivUn separa três níveis de recuperação: retrieval direto, recuperação in-context e restauração por meio de fine-tuning. Use os níveis que correspondem ao seu acesso ao modelo. Uma recusa ao prompt original pode passar na primeira verificação enquanto um caminho de recuperação mais forte ainda expõe o alvo.

7. Desative artefatos obsoletos e mantenha as evidências

Depois do trabalho no lado do modelo, remova ou coloque em quarentena réplicas, checkpoints, adapters e caches obsoletos. Em seguida, mantenha um pacote de evidências:

Essa evidência é o que transforma um fluxo de exclusão em algo que suporte, segurança, jurídico e engenharia podem verificar em conjunto.

O que as pesquisas mais recentes sobre unlearning realmente sustentam

Três artigos recentes são úteis aqui, mas sustentam alegações diferentes.

Auditorias comportamentais não são gratuitas

O artigo de junho de 2026 sobre auditoria comportamental é o alerta mais forte contra alegações exageradas. Seu resultado central não é que “unlearning é impossível”. O resultado é mais restrito e mais útil: sob um proprietário desonesto e um auditor honesto, mas curioso, uma auditoria comportamental pode criar um trade-off de privacidade e auditoria. Se sua narrativa de compliance depende apenas de sondagens black-box, você pode vazar informações sobre os dados retidos ao tentar verificar o esquecimento. arXiv

Edição direcionada pode funcionar em benchmarks selecionados

*ZeroUnlearn* apresenta um resultado mais otimista. Ele reformula machine unlearning como um problema de edição de modelo, relata resultados fortes de benchmark em Llama-3.2, Llama-3.1 e Qwen-3 e afirma que sua atualização few-shot em forma fechada mantém a etapa de SVD abaixo de 0,3 segundo em MCF e ZsRE, enquanto a edição end-to-end cresce de cerca de 0,04 hora com 10 amostras para 3,35 a 3,82 horas com 1000 amostras, com memória total de aproximadamente 14,9 a 17,4 GB. Esses números importam porque mostram que unlearning aproximado não é automaticamente caro demais para ser testado. arXiv

Mas as limitações importam mais do que o destaque principal. O artigo avalia modelos abertos selecionados e datasets de benchmark como MCF, ZsRE e uma versão single-hop adaptada do MQUAKE. Ele também usa seleção direcionada de camadas para evitar danos à capacidade geral. Isso é evidência de remoção promissora de fatos em escala de benchmark, não uma prova de que um sistema de produção apagou completamente todas as cópias de informações sensíveis. arXiv

A exclusão contínua ainda é fraca em sistemas multimodais

*ICU-Bench* é o contraponto preocupante. O benchmark contém 1.000 perfis sensíveis à privacidade provenientes de relatórios médicos e contratos de trabalho, 9.500 imagens, 16.000 pares de perguntas e respostas e 100 tarefas sequenciais de forget. A conclusão é simples: os métodos atuais de unlearning multimodal têm dificuldades em cenários contínuos e não preservam simultaneamente a qualidade do esquecimento, a utilidade retida e a estabilidade em sequências longas. Se seu produto recebe solicitações repetidas de exclusão ao longo do tempo, este é o artigo que você deve ler antes de prometer automação limpa. arXiv

Em conjunto, os artigos sustentam uma posição prática:

O que prometer a usuários e stakeholders

Prometa menos. Verifique mais.

Uma boa linguagem é:

Uma linguagem ruim é:

Se precisar de uma regra curta, use esta: machine unlearning é uma camada dentro de um fluxo mais amplo de remoção de dados de AI.

FAQ

Excluir uma linha do vector database faz o LLM esquecer?

Não. Isso pode impedir que um caminho de retrieval reintroduza os dados, o que frequentemente é a correção inicial certa para sistemas RAG. Mas, se o mesmo conteúdo foi usado em fine-tuning, continual training ou memória persistente do modelo, excluir apenas a linha vetorial não altera os pesos.

Machine unlearning pode provar que meus dados desapareceram de todas as cópias de modelos?

Não por si só. Pesquisas recentes sobre auditoria mostram que auditorias black-box têm limitações, e sistemas de produção frequentemente incluem caches, adapters, checkpoints, réplicas e backups fora da superfície do modelo auditado. Você precisa de evidências no nível do sistema, não apenas de uma pontuação no nível do modelo. arXiv Google Research

Verificações de alegações

Fontes