Antes do modelo de IA: anonimização como controle de governança
Por Jhonathan Campos, Fundador
Diretrizes 02/2026 do EDPB na prática: a avaliação que decide o que entra no pipeline de IA
Seções: Teste jurídico · Isolamento, vinculação e inferência · Web scraping · Registro da decisão · Consulta e próximos passos
Anonimização é trabalho de engenharia desde que equipes começaram a preparar conjuntos reais de dados para análise e aprendizado de máquina. Excluir nomes e números de conta é a parte fácil. A substância está nos quase identificadores, no risco de vinculação e na probabilidade de alguém ainda conseguir distinguir uma pessoa pelo que restou. Bons profissionais de engenharia de privacidade trabalham assim há anos. O que mudou foi a visibilidade jurídica dessa prática. Em 7 de julho de 2026, o Comitê Europeu para a Proteção de Dados adotou as Diretrizes 02/2026 sobre anonimização, acompanhadas de diretrizes sobre web scraping no contexto de IA generativa. Os dois textos estão em consulta pública até 30 de outubro de 2026.
É a primeira manifestação completa do Comitê sobre o tema desde o Parecer 05/2014 do Grupo de Trabalho do Artigo 29. O texto incorpora o julgamento do Tribunal de Justiça de 4 de setembro de 2025 no processo C-413/23 P, EDPS v SRB, em uma análise mais ampla relativa à entidade. Os mesmos dados podem ser anônimos para uma entidade e pessoais para outra, conforme os meios disponíveis a cada uma. O núcleo operacional tem três partes. Os dados podem ser considerados anônimos com segurança quando nenhum registro pode ser isolado, nenhuma vinculação a outros dados da mesma pessoa é possível e nenhuma inferência específica sobre uma pessoa identificada ou identificável pode ser produzida. Se um critério falhar, as circunstâncias ainda precisam ser analisadas.
Para equipes que criam sistemas de IA, a consequência aparece na preparação dos dados. A anonimização é uma avaliação com critérios definidos, método documentado, dever de teste e reavaliação. Tudo isso precisa terminar antes do primeiro treinamento. Um modelo moldado por exemplos identificáveis não se torna anônimo por causa de documentação produzida depois.
Um caso acompanhará a análise. Uma seguradora de médio porte quer ajustar um modelo de linguagem para fazer triagem de chamados de sinistro. Os chamados misturam metadados estruturados, como CEP, tipo de sinistro e data, com descrições livres escritas por clientes. Um fornecedor externo executará o ajuste. A pergunta é se o conjunto preparado deixa o escopo do GDPR antes de sair da empresa.
O teste jurídico e a perspectiva relativa à entidade
O ponto de partida é o Artigo 4(1) do GDPR junto com o Considerando 26. Informação é dado pessoal quando se relaciona a uma pessoa natural identificada ou identificável, considerando os meios razoavelmente prováveis de serem usados na identificação. As diretrizes seguem C-434/16 Nowak sobre quando a informação se relaciona a uma pessoa e C-582/14 Breyer sobre meios disponíveis por canais lícitos. O julgamento SRB integra a perspectiva relativa à entidade. O mesmo conjunto pode ser pessoal nas mãos de uma entidade e anônimo nas de outra. A avaliação precisa dizer qual perspectiva examinou.
O Comitê oferece dois caminhos. Na abordagem simplificada, o controlador trata os dados como pessoais onde houver incerteza relevante. Isso pode ir além do mínimo jurídico, porque dados anônimos para algumas entidades ainda serão tratados como pessoais. A empresa compra confiança ao preço de um escopo maior. Na abordagem contextual, a identificabilidade é avaliada para um destinatário e ambiente específicos, exigindo evidência sobre direitos de acesso, dados auxiliares e capacidades realistas. A abordagem simplificada provavelmente dominará a prática, pois muitos controladores não conseguem produzir evidência suficiente sobre o ambiente do destinatário. O Comitê também alerta contra depender da suposta falta de motivação para reidentificar.
No caso da seguradora, o fornecedor de ajuste não acessa o sistema de apólices. A seguradora ainda o mantém, inclusive a tabela entre IDs dos chamados e segurados. Como o fornecedor trata dados em nome da seguradora, a avaliação passa pela perspectiva dela. Enquanto a seguradora preservar as chaves de junção, os chamados continuam sendo dados pessoais no pipeline. Se a empresa quisesse enviar um extrato transformado a um parceiro de pesquisa independente, a abordagem contextual poderia permitir outra conclusão, desde que o arquivo comprovasse o ambiente real do parceiro e a transformação resistisse aos três critérios abaixo.
Isolamento, vinculação e inferência no conjunto de chamados
Isolamento de registros. Metadados estruturados são o terreno clássico da engenharia de privacidade. CEP, tipo de sinistro e data parecem inofensivos isoladamente, mas podem distinguir um único segurado numa área rural. Técnicas como k-anonimato ajudam porque obrigam a equipe a perguntar se cada combinação de quase identificadores inclui pessoas suficientes. Ainda assim, são apenas o começo. O teste do EDPB também cobre vinculação e inferência. Por isso, texto narrativo, embeddings, saídas sintéticas e modelos treinados exigem avaliações diferentes. Cinco registros com o valor comum “investigação de incêndio criminoso pendente” satisfazem k=5 e ainda revelam algo sensível sobre cada membro. O texto livre é mais difícil. Uma frase que descreve incêndio em uma casa de determinado vilarejo numa semana específica isola o autor melhor do que o ID apagado. A supressão automática encontra nomes e contas, mas cronologia e contexto escapam. Essa camada exige amostragem com revisão humana e critérios documentados.
Vinculação. Conjuntos de IA são montados, e a montagem concentra o risco. O extrato de chamados parece autônomo até ser unido ao CRM criado seis meses antes para um modelo de churn. Embeddings merecem atenção específica. Um índice vetorial mantém proximidade semântica com o texto de origem. A busca por similaridade pode reconectar fragmentos que a supressão separou. O repositório de embeddings deve fazer parte do conjunto avaliado, com os mesmos controles de acesso e o mesmo plano de teste.
Inferência. Este é o critério com maior peso para IA. O Comitê já indicou no Parecer 28/2024 sobre modelos de IA que não se presume anônimo um modelo treinado com dados pessoais. As Diretrizes 02/2026 generalizam a conclusão. Inferências proibidas podem surgir de registros, agregados, modelos treinados e saídas sintéticas, inclusive por prompting. Para a seguradora, a pergunta operacional é se o modelo ajustado memorizou chamados raros. As diretrizes reconhecem a superfície de ataque, mas não prescrevem testes. Escolher o protocolo é uma decisão que o registro precisa justificar.
Um protocolo defensável pode inserir registros canário no treino e tentar extraí-los por prompts, executar testes de membership inference contra uma amostra real mantida fora do treinamento e procurar quase duplicatas entre saídas geradas e corpus. As configurações de amostragem devem corresponder ao produto. Cada teste entrega um resultado mensurável para o arquivo.
Dados sintéticos passam pelo mesmo portão. Se a seguradora gerar chamados artificiais a partir do corpus real para o fornecedor, o gerador ainda foi treinado no sinistro raro. Geradores podem reproduzir exceções. O conjunto sintético só ganha condição anônima depois de passar pelos mesmos três critérios.
Aqui aparece a lacuna profissional. Um advogado que não lê um relatório de membership inference não consegue encerrar a avaliação. Um engenheiro que nunca trabalhou o Considerando 26 não pode dizer o que o relatório deve demonstrar. A conclusão pertence a quem combina os dois campos. Essa ponte entre engenharia de software e direito de compliance é o núcleo da minha prática.
Web scraping na entrada do pipeline
As diretrizes complementares importam quando a seguradora decide que seus chamados são poucos e acrescenta reclamações extraídas de fóruns. Web scraping é tratamento sujeito ao GDPR sempre que envolve coleta, armazenamento ou recuperação de dados pessoais. A disponibilidade pública não muda a pergunta inicial. As diretrizes enfatizam limitação de finalidade e transparência e são operacionais quanto à exatidão: fontes confiáveis, datas registradas e validação antes do treinamento.
Muitos controladores privados avaliarão o Artigo 6(1)(f) como base legal. Para eles, anonimização trabalha duas vezes. Filtrar e transformar na entrada reduz o volume que precisa ser justificado no teste de balanceamento. Um passo documentado e testado também pode contar como salvaguarda. A sequência determina o valor. O filtro precisa atuar antes de o material chegar ao corpus. Um desenho que ingere tudo e limpa depois será analisado como tal.
O registro da decisão e a conexão com o AI Act
As diretrizes exigem que o processo de anonimização e os testes das saídas supostamente anônimas sejam documentados e preservados. Um incidente de segurança pode exigir reavaliação. Se as tabelas de associação vazarem, o extrato enviado ao parceiro pode mudar de condição jurídica de um dia para o outro. O arquivo precisa dizer quem reavalia e quando.
Na minha prática, a entrega é um único registro assinado antes do treinamento. Ele identifica dados de origem e finalidade, descreve método e resultados e registra risco residual, responsável e gatilhos de reavaliação. Um registro curto apoiado por testes pesa mais do que uma política extensa. A política expressa intenção. O registro mostra o que ocorreu.
O mesmo registro apoia o arquivo do AI Act. O Artigo 10 exige governança de dados documentada para sistemas de alto risco. O registro de anonimização contribui com procedência, preparação e risco residual de privacidade. Ele não substitui a avaliação completa do Artigo 10, que inclui representatividade, possíveis vieses e adequação à finalidade. Criada no momento certo, uma evidência serve aos dois regimes. Criada tarde, precisa ser reconstruída sob prazo a partir do histórico do repositório.
O que a consulta pode mudar e o que fazer enquanto isso
O texto está aberto a comentários até 30 de outubro de 2026. O critério de inferência aplicado a modelos generativos ainda pode mudar. Uma leitura estrita coloca quase todo modelo grande treinado em texto humano do lado dos dados pessoais. Desenvolvedores que discordarem devem apresentar evidência técnica na consulta. O Comitê mostrou que exemplos trabalhados produzem mais efeito do que posições abstratas.
A recomendação útil não é esperar. Escolha um pipeline ativo, execute agora a avaliação dos três critérios e escreva o registro como se o texto fosse final. As lacunas descobertas são, ao mesmo tempo, backlog de compliance e possível contribuição para a consulta. Se o modelo será treinado antes de 30 de outubro, a avaliação precisa acontecer primeiro.