Privacidade de agentes de IA exige contexto, diz Google

O Google Research publicou em 5 de outubro de 2026 um relatório sobre privacidade e segurança de agentes de IA, assinado por Eugene Bagdasarian e Marco Gruteser. O documento consolida as discussões do CAPS Workshop (Contextual Agent Privacy and Security), realizado no fim de 2025 em Nova York, que reuniu mais de 50 pesquisadores da academia e da indústria.

A tese central é desconfortável para quem trata privacidade como sinônimo de sigilo: um agente só é útil se tiver acesso a dados pessoais e puder executar ações com consequência. Restringir o acesso resolve o risco eliminando a utilidade. O problema, então, não é se o agente acessa, e sim quando cada acesso é apropriado.

É uma mudança de enquadramento com implicações práticas para quem vai operar esses sistemas em ambiente corporativo — e vale dizer desde já o que o documento é: um relatório de posição, com proposta de arquitetura e agenda de pesquisa. Não há sistema implementado, medição ou produto por trás dele.

Três características que quebram o modelo tradicional

O relatório aponta por que ferramentas de segurança pensadas para software convencional não se aplicam bem a agentes:

• Interfaces não estruturadas. Quando a instrução chega em linguagem natural ou imagem, definir “comportamento esperado” fica difícil — e é essa ambiguidade que abre espaço para injeção de prompt, em que conteúdo processado pelo agente passa a funcionar como ordem.
• Fluxo de controle probabilístico. O agente planeja a execução de forma generativa, criando caminhos que não existiam no projeto. Teste tradicional, que percorre ramificações previstas, não cobre o que não foi previsto.
• Autonomia e delegação. Tarefas longas e repasse a subagentes afastam o usuário da supervisão. O relatório nomeia um efeito conhecido de quem opera sistemas com muitos alertas: a fadiga de confirmação — pedir aprovação a cada passo transforma a aprovação em reflexo, e a supervisão vira carimbo.

Integridade contextual: privacidade como fluxo apropriado

A base conceitual do relatório é a integridade contextual, estrutura segundo a qual privacidade não é segredo nem controle, mas fluxo apropriado de informação conforme normas sociais justificáveis. Uma norma tem três componentes:

• Atores — quem envia, quem recebe e sobre quem é a informação.
• Tipo de informação — registro médico, dado financeiro, localização.
• Princípio de transmissão — a regra que rege o fluxo, como confidencialidade ou reciprocidade.

O exemplo é simples e esclarece o conceito: contar ao médico sobre um sintoma é apropriado; o mesmo dado indo ao empregador, não. O dado é idêntico; o que muda é o contexto. É por isso que uma regra do tipo “nunca compartilhe dados de saúde” é ao mesmo tempo restritiva demais e permissiva demais.

A contribuição dos autores é estender esse raciocínio de informação para ação, no que chamam de segurança contextual: além de perguntar se um dado pode circular, perguntar se uma ação é apropriada naquele contexto. O exemplo do relatório: uma lista de presentes pode ser compartilhada com um assistente de compras, mas não com a família.

A proposta: um motor de políticas contextuais

Historicamente havia uma lacuna entre normas sociais, expressas de forma vaga, e permissões de sistema, expressas de forma binária. Os autores argumentam que modelos de linguagem podem fechar essa lacuna, por serem capazes de interpretar norma em linguagem natural e traduzi-la em decisão.

A arquitetura proposta é um motor de políticas contextuais dentro de uma camada supervisora, com geração dinâmica de política em tempo real — ajustada ao pedido do usuário e às ferramentas que o agente descobre durante a execução. A verificação ocorre antes que a informação deixe o espaço de trabalho do usuário.

O caso de uso descrito é organizar uma viagem para uma conferência: a tarefa exige decidir o que revelar ao comprar passagem, o que informar num pedido de visto e o que dizer aos organizadores. São três destinatários, três conjuntos de dados apropriados e nenhuma regra estática que resolva os três.

Cabe uma observação crítica. A proposta usa um modelo de linguagem para julgar a adequação dos fluxos — isto é, coloca um componente probabilístico como árbitro de uma decisão de segurança. O relatório não detalha o que acontece quando esse juiz erra, nem como ele próprio resiste a conteúdo malicioso, que é exatamente o problema que se pretende conter. É a questão em aberto mais relevante do documento.

Seis frentes propostas

O relatório não aposta em uma solução única e organiza a agenda em camadas:

1. Isolamento no sistema — limitar capacidades dinamicamente, estabelecer identidade do agente e conceder ou revogar acesso conforme o contexto muda, em vez de permissões estáticas no estilo de sistema operacional.
2. Raciocínio no modelo — o modelo deve resolver pedidos subespecificados e avaliar adequação quando as normas mudam, em vez de simplesmente obedecer.
3. Controles centrados no usuário — superar o modelo de “aviso e consentimento”, que pressupõe decisões previsíveis e granulares, em favor de controles dinâmicos compatíveis com o modelo mental de quem usa.
4. Interação entre agentes — criar salvaguardas contra agentes que, interagindo, acabem por violar normas em conjunto.
5. Governança de ecossistema — normas compartilhadas entre agentes, com mecanismos de resolução de conflito, negociação e verificação de conformidade.
6. Avaliação dinâmica — parâmetros padronizados para cenários multiagente, com ambientes de simulação abertos, para estabelecer uma linha de base comum de segurança.

A quarta frente conversa diretamente com pesquisa que já acompanhamos: um estudo mostrou que agentes de IA podem coordenar decisões por estados internos que não aparecem no registro público da conversa — ou seja, a verificação de conformidade não pode se apoiar apenas na transcrição. E a terceira frente encontra eco em outro achado: modelos abertos desrespeitam com frequência as políticas de divulgação declaradas pelo próprio usuário, o que mostra que delegar a decisão ao modelo ainda não é garantia.

Impactos, limitações e o que considerar

Para quem avalia adoção corporativa de agentes, o valor imediato do relatório é servir de lista de perguntas ao fornecedor: como a ferramenta estabelece identidade do agente; o que acontece quando ele descobre uma ferramenta nova em tempo de execução; como se evita que a aprovação do usuário vire automatismo; o que é registrado quando subagentes conversam entre si.

As limitações são relevantes e devem ser ditas com clareza. Não há implementação, medição de desempenho, taxa de erro ou custo associado à camada supervisora proposta — e uma verificação a cada fluxo tem custo de latência que o documento não dimensiona. A integridade contextual, por sua vez, depende de normas socialmente compartilhadas, que variam entre culturas e setores; quem define a norma quando ela é ambígua é uma questão política, não técnica, e o relatório a deixa em aberto.

Vale notar ainda que se trata de uma empresa que desenvolve agentes propondo o arcabouço de governança para agentes. Isso não invalida o conteúdo — a estrutura conceitual é anterior ao Google e bem estabelecida na literatura de privacidade —, mas convém ler a agenda sabendo quem a escreve.

Conclusão

O relatório acerta ao recusar o falso dilema entre agente útil e agente seguro, e ao propor que a pergunta certa não é o que o agente pode acessar, mas se determinado fluxo é apropriado naquele contexto. Para equipes de segurança, é uma mudança de método: sai a lista estática de permissões, entra a avaliação situacional.

O que falta é a parte difícil — transformar isso em sistema que funcione com latência aceitável e que resista a quem tentar manipular o próprio árbitro. O que vale observar é se os ambientes de simulação multiagente propostos saem do papel, porque sem avaliação padronizada não há como comparar implementações nem saber se alguma delas de fato funciona.

Fontes e referências

• Google Research — Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle, por Eugene Bagdasarian e Marco Gruteser
• Google Research — Relatório técnico completo do CAPS Workshop
• Google Research — Blog de pesquisa do Google