Categories: INTELIGENCIA ARTIFICIAL

Privacidade personalizada: LLMs ignoram regras do usuário

Um artigo submetido ao arXiv em 21 de agosto de 2026 e aceito para a conferência EMNLP 2026 aponta uma lacuna concreta na forma como modelos de linguagem lidam com dados pessoais: quando o usuário define explicitamente o que pode e o que não pode ser compartilhado, os modelos frequentemente ignoram a instrução. Em um dos cenários testados, o Gemma3-4B desconsiderou a política definida pelo usuário em 74,28% dos casos em que deveria ter recusado; o Qwen2.5-7B, em 51,25%.

O trabalho é assinado por Junseok Kim, Nakyeong Yang e Kyomin Jung, do IPAI da Universidade Nacional de Seul — Yang também é afiliado ao Instituto Max Planck de Sistemas de Software, na Alemanha. Os autores propõem o conceito de privacidade personalizada, um benchmark para medi-la e um método de intervenção que reduz as violações sem exigir novo treinamento do modelo.

O contexto que dá relevância ao problema é a IA agêntica. Assistentes que executam tarefas em nome do usuário — agendar, comprar, preencher formulários, negociar com terceiros — precisam de acesso a dados pessoais para funcionar. A pergunta deixa de ser se o modelo tem os dados e passa a ser quando ele decide revelá-los.

De privacidade contextual para privacidade personalizada

A pesquisa anterior nessa área trabalha com o conceito de privacidade contextual: a ideia, herdada da teoria da integridade contextual, de que a adequação de revelar uma informação depende da situação. Compartilhar o histórico de alergias com um restaurante ao fazer uma reserva é apropriado; compartilhar o mesmo dado com uma loja de eletrônicos não é.

Os autores apontam o limite dessa formulação: mesmo dentro de um contexto idêntico, pessoas diferentes têm tolerâncias diferentes. Duas pessoas fazendo a mesma reserva no mesmo restaurante podem discordar sobre revelar a alergia — uma considera necessário, outra considera invasivo. Uma norma contextual única não acomoda essa variação, e é exatamente essa variação que uma política de privacidade definida pelo usuário deveria capturar.

Formalmente, o trabalho define um conjunto de campos de informação do usuário, um subconjunto contextualmente relevante para cada tarefa e uma política individual que determina, dentro desse subconjunto, o que o usuário autoriza revelar. Tudo o que fica de fora é informação restrita.

P3Bench: como a falha foi medida

Para avaliar o problema, os pesquisadores construíram o P3Bench (Personalized Privacy Preservation Benchmark), que estende o conjunto de dados AirGapAgent-R, apresentado por Green e colaboradores em 2025. O benchmark usa 3.536 instâncias de teste, cobrindo 17 perfis distintos de usuário, organizadas em quatro configurações de política:

Privacy-Max — política maximamente restritiva: só o nome pode ser revelado.
Contact-Open — permite campos básicos de contato, como nome, telefone e e-mail.
Health-Open — permite campos ligados à saúde, como alergias e medicamentos.
Preference-Open — permite dados de estilo de vida e preferências, como hobbies, comida favorita e preferências de viagem.

A avaliação usa três métricas. A taxa de recusa excessiva (over-refusal, OR) mede quando o modelo se nega a revelar algo que o usuário autorizou. A taxa de compartilhamento excessivo (over-sharing, OS) mede o oposto: quando revela algo que o usuário restringiu. E a distância de erro de política (Policy Error Distance, PED) combina as duas como a distância euclidiana até o ponto ideal em que ambas são zero, evitando que um método pareça bom apenas por trocar um tipo de erro pelo outro.

Há ainda uma quarta métrica, mais reveladora: a razão de ignorância de política (Policy Ignorance Ratio, PIR). Ela mede, especificamente nos casos em que a política do usuário exige suprimir uma resposta que o modelo daria normalmente, com que frequência o modelo simplesmente mantém a resposta que teria dado sem política nenhuma. São dessa métrica os números de 51,25% e 74,28% citados no início.

O que a PIR captura é mais preocupante do que erro aleatório: indica que a política declarada pelo usuário no prompt não altera o comportamento do modelo. Os autores atribuem isso ao fato de que modelos já carregam políticas implícitas de privacidade, formadas durante o pré-treinamento e o ajuste por instruções, e que essas políticas internas prevalecem sobre a instrução explícita.

Repair: intervenção em cabeças de atenção

A proposta dos autores para corrigir isso se chama Repair e opera em tempo de inferência, sem alterar os pesos do modelo. Funciona em três etapas.

Primeiro, a seleção de cabeças relevantes à política. Em um transformer, cada camada de atenção é composta por várias cabeças cujas saídas são concatenadas antes da projeção final — o que significa que cada cabeça pode ser sondada e manipulada de forma independente. Os pesquisadores treinam sondas sobre as ativações de cada cabeça para identificar quais delas carregam informação sobre o estado de divulgação (revelar ou recusar) condicionado à política. As mais informativas, medidas por AUROC, são selecionadas — nos experimentos reportados, as 30 melhores.

Segundo, a construção de vetores de intervenção específicos por estado. Para o estado de recusa, os vetores são as ativações médias correspondentes. Para o estado de divulgação, os autores optaram por um desenho assimétrico: em vez de sobrescrever a ativação pela média — o que apagaria a informação específica da entrada necessária para produzir o valor correto do campo —, constroem uma direção que suprime os componentes ligados à recusa preservando o conteúdo da entrada.

Terceiro, a intervenção adaptativa. Em uma primeira passagem, as sondas das cabeças selecionadas preveem o estado de divulgação apropriado para aquela entrada e aquela política, com decisão por voto majoritário. A intervenção correspondente é então aplicada.

Resultados e o que eles não dizem

Os experimentos usaram três modelos de código aberto ajustados para instrução: Qwen2.5 nas versões de 3 e 7 bilhões de parâmetros, e Gemma3 de 4 bilhões. As comparações incluíram prompt direto, cadeia de raciocínio sem exemplos e dois métodos recentes de direcionamento de ativações, CAST e AdaSteer.

Cenário	PED com prompt direto	PED com Repair	Redução
Privacy-Max — Qwen2.5-3B	71,11	6,78	90,5%
Privacy-Max — Gemma3-4B	35,38	11,40	67,8%

Os autores destacam que o Repair reduz simultaneamente a recusa excessiva e o compartilhamento excessivo, em vez de apenas empurrar o modelo para um dos extremos — uma distinção relevante, já que um sistema que recusa tudo teria compartilhamento excessivo zero e seria inútil. Registram também que a cadeia de raciocínio induz uma troca assimétrica entre os dois tipos de erro, o que sugere que pedir ao modelo para “pensar passo a passo” não resolve, sozinho, decisões de divulgação personalizadas.

Três limites merecem registro, dois deles declarados pelos próprios autores. A cobertura de campos de dados pessoais e de cenários do benchmark é limitada. E o P3Bench trabalha apenas com campos estruturados — nome, telefone, medicamento — enquanto revelações reais de privacidade costumam ser não estruturadas: uma experiência pessoal sensível, uma situação familiar, algo que não cabe em um campo predefinido. Estender o controle personalizado a esses casos permanece em aberto.

O terceiro limite é de escala: os experimentos cobrem modelos de 3 a 7 bilhões de parâmetros. Não há, no que foi publicado, evidência sobre como o problema se comporta em modelos de fronteira, muito maiores e com ajuste de alinhamento mais elaborado. É plausível que modelos maiores sigam políticas explícitas com mais fidelidade, mas isso é hipótese, não resultado — e a arquitetura do Repair, que depende de acesso às ativações internas, só se aplica a modelos de pesos abertos.

Por que isso importa fora do laboratório

Do ponto de vista de produto, o achado tem consequência direta para qualquer sistema que ofereça ao usuário controles de privacidade implementados como instrução no prompt. Se metade das restrições declaradas é ignorada, o controle existe na interface e não no comportamento — uma diferença que importa tanto para a confiança do usuário quanto para quem precisa demonstrar conformidade.

No Brasil, a Lei Geral de Proteção de Dados estrutura boa parte do tratamento em torno de finalidade e consentimento, com o titular podendo determinar o alcance do uso de seus dados. Um assistente que aceita a restrição e não a cumpre cria um descompasso entre o registro do consentimento e o que o sistema efetivamente faz. Vale a ressalva de que o artigo não trata de conformidade regulatória — a conexão com a LGPD é uma leitura possível do resultado técnico, não uma afirmação dos autores.

Há também um aspecto positivo relevante: o método proposto não exige retreinamento nem ajuste fino. Intervenções em tempo de inferência são baratas e reversíveis, o que as torna viáveis para quem opera modelos abertos em infraestrutura própria. A contrapartida é a dependência de um conjunto de calibração e de acesso às ativações internas, o que exclui serviços consumidos apenas por API.

Conclusão

O trabalho não afirma que modelos de linguagem vazam dados de forma deliberada nem que existe falha de segurança explorável. O que ele documenta, com um benchmark público e métricas explícitas, é algo mais mundano e mais estrutural: instruções de privacidade escritas no prompt competem com preferências já embutidas no modelo, e frequentemente perdem.

O que vale acompanhar a seguir é se o P3Bench será adotado por outros grupos, se os resultados se sustentam em modelos maiores e se abordagens de controle em tempo de inferência como o Repair encontram caminho para sistemas em produção. Enquanto isso, a recomendação prática para quem constrói assistentes com acesso a dados pessoais é tratar política declarada em prompt como preferência, não como garantia — e validar empiricamente se ela está sendo cumprida.