7 Erros de Privacidade de Dados em Agentes de IA Que Vazam Silenciosamente os Dados da Sua Empresa (e Como Evitá-los)

A maioria dos vazamentos de dados em agentes de IA não vem do modelo a memorizar secretamente a sua empresa. Vem de erros de configuração e arquitetura que pode nomear e corrigir. Os principais: operar numa conta de nível de consumidor cujos padrões treinam com os seus inputs, deixar um agente herdar as permissões amplas de uma pessoa, ligar um agente voltado para o público a sistemas internos, e deixar a "tríade letal" intacta (dados privados, conteúdo não confiável e um caminho de envio externo) para que uma única injeção de prompt consiga ler os seus dados e enviá-los por correio para fora. Esse último padrão é exatamente como o EchoLeak (CVE-2025-32711) expôs dados sensíveis através do Microsoft 365 Copilot a partir de um email forjado, sem qualquer clique do utilizador. As correções não são exóticas, e quase todas são decisões tomadas antes do agente ser lançado, não uma checklist entregue a si depois de algo vazar.

Esta é a lista que percorremos antes de colocar um agente que construímos dentro da stack de outra empresa, escrita para que um proprietário não técnico consiga detetar os mesmos erros na sua própria configuração ou na de um fornecedor. Se preferir que sejamos nós a manter esta linha onde deve estar para si, veja como gerimos governança e risco de IA responsável. Tudo o que está abaixo é seu para usar de qualquer forma.

Primeiro, uma distinção que quase todos os artigos sobre este tema confundem, porque errá-la é o erro zero. Há duas formas completamente diferentes de os dados saírem através de um agente, e têm correções completamente diferentes:

• Tratamento de dados pelo fornecedor. O fornecedor do modelo armazena ou treina com os seus inputs? Isto é um contrato que assina e um nível de conta que escolhe. Resolve-se com termos e configuração.
• Exfiltração em tempo de execução. O agente pode ser enganado, no momento em que corre, para enviar os seus dados para algum lugar que não deveria? Isto resolve-se com arquitetura, não com um contrato.

Os números das sondagens dizem que os compradores sentem isto mesmo quando não conseguem nomeá-lo. Na investigação da Cloudera com quase 1.500 líderes seniores de TI em 14 países, 96% planeiam expandir o uso de agentes de IA no próximo ano, mas 53% (mais de metade) apontam a privacidade de dados como o seu principal obstáculo à adoção. Os sete erros abaixo são onde esse receio se torna um vazamento real, e onde vive a correção.

Erro 1: operar agentes de produção em contas de nível de consumidor

Este é o erro mais barato de cometer e o mais fácil de corrigir. Alguém liga um fluxo de trabalho a uma conta pessoal do ChatGPT ou a uma conta de consumidor do Gemini porque já está disponível, e agora os dados do seu negócio são regidos por termos de consumidor que nunca foram pensados para eles.

A diferença entre os níveis de consumidor e empresarial é nítida. No lado empresarial, o padrão é consistente entre fornecedores: sem treino com os seus dados por defeito, uma janela de retenção curta para monitorização de abuso, e opções mais fortes a pedido. A API da OpenAI retém dados durante 30 dias para monitorização de abuso e depois apaga-os, e não treina com eles por defeito. A partir de 14 de setembro de 2025, a Anthropic reduziu a retenção de registos da API de 30 dias para 7 dias, e os inputs e outputs da API nunca são usados para treino. O Vertex AI da Google (o nível empresarial) é configurável sem uso para treino. No lado do consumidor, os padrões invertem-se: o ChatGPT de consumidor armazena conversas indefinidamente a menos que as apague, e a retenção do Gemini de consumidor chega aos 36 meses e pode ser usada para melhorar produtos.

A correção: coloque cada agente de produção numa API empresarial ou conta de negócios, nunca num login pessoal. A tecnologia é idêntica. Os termos não são, e os termos são toda a diferença entre dados que permanecem regidos e dados que silenciosamente se tornam material de treino.

Erro 2: permissões demasiado amplas que o agente herda

O vazamento em tempo de execução mais comum não é engenhoso. A um agente é dado o acesso de um funcionário, ou pior, uma chave de administrador, para que tecnicamente possa ver tudo o que essa pessoa pode ver. Depois é-lhe feita uma pergunta, ou é enganado para uma, que vai muito além da sua função.

O Cloud Adoption Framework da Microsoft enuncia a regra com clareza: "Conceda aos agentes acesso apenas às fontes de dados específicas exigidas pela sua função. Não forneça acesso amplo a todos os dados da organização." Um agente de suporte não precisa do seu sistema de folha de pagamentos. Um agente de agendamento não precisa da base de dados de clientes. Quando um agente age em nome de uma pessoa, deve herdar as permissões dessa pessoa passando a sua identidade de forma segura, para que um agente de helpdesk mostre a um funcionário apenas o seu próprio registo de RH, não o de toda a gente.

A correção: dê a cada agente a sua própria identidade, com escopo de privilégio mínimo, e faça-o herdar as permissões do utilizador que age em vez de carregar um superconjunto permanente. O teste é simples. Se o agente for enganado amanhã, o dano fica limitado pelo conjunto restrito que lhe foi concedido, não por tudo o que uma conta com permissões excessivas poderia alcançar.

Erro 3: agentes voltados para o público ligados a dados internos

Um chatbot no seu site e um agente que redige relatórios internos são dois mundos de segurança diferentes, e o vazamento acontece no momento em que alguém os deixa partilhar um backend. Um agente público recebe input de qualquer pessoa na internet. Se esse mesmo agente também conseguir consultar dados internos do negócio, construiu uma porta da web pública diretamente para os seus sistemas privados.

O framework da Microsoft traça aqui a linha mais dura: "Os agentes voltados para o público não devem aceder a dados internos do negócio." Mantenha o confidencial e o público separados por uma fronteira física ou lógica (o exemplo deles usa grupos de gestão "corp" e "online" separados). A questão é que a fronteira é estrutural, não uma esperança de que o prompt aguente.

A correção: coloque uma fronteira real entre agentes que recebem input público não confiável e agentes que tocam dados confidenciais. Se um único agente tiver genuinamente de fazer ambos, esse é o design de maior risco que pode escolher, e precisa dos controlos que quebram a tríade nos erros seguintes, não apenas de um prompt de sistema cuidadoso.

Erro 4: ignorar a tríade letal

Este é o erro que transforma os três primeiros numa exfiltração real. Simon Willison, o especialista independente que criou o termo "injeção de prompt", nomeou a "tríade letal" para agentes de IA: três condições que, quando combinadas, permitem que uma única instrução injetada roube os seus dados.

Quando as três estão presentes, um atacante esconde uma instrução dentro do conteúdo não confiável. O modelo, nas palavras de Willison, "seguirá alegremente quaisquer instruções que cheguem ao modelo, quer venham do seu operador ou de alguma outra fonte." Ele lê os seus dados privados e envia-os para fora, e nada no prompt lhe disse para não confiar no email.

A parte crua, e a razão por que isto é arquitetura e não um problema de engenharia de prompts: "ainda não sabemos como evitar isto a 100% de forma fiável." Exploits documentados atingiram o Microsoft 365 Copilot, o servidor MCP do GitHub e o GitLab Duo. Numa semana de janeiro de 2026, foram divulgadas vulnerabilidades de injeção indireta de prompt em quatro ferramentas de produtividade de IA, todas o mesmo padrão da tríade.

A correção: quebre uma perna. Negue o caminho de envio externo para que os dados roubados não tenham para onde ir, ou nunca deixe um agente que lê conteúdo não confiável ter também acesso a dados privados no mesmo contexto. Não precisa de vencer a luta impossível de apanhar todas as injeções. Precisa de garantir que mesmo uma injeção bem-sucedida não tem rota de saída.

Erro 5: tratar o EchoLeak como problema dos outros

Vale a pena nomear um incidente real, porque "a tríade letal" soa abstrato até a ver executada. O EchoLeak (CVE-2025-32711) foi um ataque zero-click ao Microsoft 365 Copilot. Um atacante enviou um email forjado. O Copilot, a fazer o seu trabalho normal, processou esse email (conteúdo não confiável), tinha acesso aos dados internos do utilizador (dados privados), e tinha forma de enviar informação para fora (comunicação externa). A instrução oculta completou a exposição de dados sensíveis sem qualquer interação do utilizador. Ninguém clicou em nada.

O erro aqui é assumir que um vazamento exige um funcionário descuidado. O EchoLeak não exigiu nenhum. A defesa que importava não era "formar os funcionários para detetar phishing", porque não havia nada para um humano detetar. A defesa era arquitetural: um agente que não consegue simultaneamente ler conteúdo controlado pelo atacante e exfiltrar não pode ser virado contra si desta forma.

A correção: assuma que o zero-click é o modelo de ameaça, não a exceção. Se o seu agente lê qualquer coisa que um agente externo possa influenciar (email, conteúdo web, ficheiros carregados, tickets) e também consegue enviar dados para fora, tem um buraco com a forma do EchoLeak até fechar uma dessas duas capacidades ou cercar rigidamente o caminho de envio.

Erro 6: nenhuma fronteira de residência ou retenção de dados

Alguns vazamentos não são exfiltrações dramáticas, são deriva lenta. Os dados acabam armazenados numa região que nunca aceitou, ou em registos por mais tempo do que a sua política permite, simplesmente porque ninguém definiu a fronteira. O framework da Microsoft lista isto como governança central: identificar a localização de cada fonte de dados, runtime de agente e armazenamento de output, manter os dados em regiões ou on-prem que correspondam à sua política de residência, e mantê-los encriptados em repouso.

A notícia tranquilizadora, que quase nenhum artigo declara com clareza, é o quanto pode fixar. O padrão empresarial entre fornecedores é sem treino por defeito, mais uma janela de retenção curta, mais garantias mais fortes a pedido. A Anthropic oferece a empresas qualificadas um acordo de Retenção Zero de Dados (ZDR), sob o qual os inputs e outputs não são armazenados além do necessário para rastrear abuso. A OpenAI oferece ZDR através de um acordo negociado e residência de dados. Ambos permitem escolher onde os dados ficam. Auto-hospedar um modelo aberto (por exemplo com Ollama) mantém os dados totalmente locais com retenção zero por terceiros.

A correção: decida e documente a fronteira antes do lançamento. Que região guarda os dados, quanto tempo vivem os registos, se precisa de ZDR, e se a recuperação sensível deve correr na sua própria VPC ou on-prem. O ZDR é normalmente apenas para API e negociado, e não cobre automaticamente todos os produtos a menos que o adicione, por isso o detalhe importa.

Erro 7: tratar a privacidade como uma checklist que se entrega

O último erro é estrutural. A maioria das orientações, incluindo o excelente framework da Microsoft, assume que vai construir e governar o agente sozinho, por isso entrega-lhe uma pilha de 3.000 palavras de identidades Entra, etiquetas Purview e grupos de gestão. Essa é a resposta certa para uma grande equipa de TI. Para a maioria dos negócios é uma checklist que ninguém tem o tempo ou a competência especializada para implementar na totalidade, por isso fica entregue a meio, e as lacunas são exatamente onde os dados vazam.

O erro é tratar os controlos como documentação em vez de como uma arquitetura que alguém possui de ponta a ponta. Uma checklist que lista "isolar dados confidenciais" e "restringir integrações externas a servidores MCP confiáveis" só é tão boa quanto a pessoa que a liga, valida cada comunicação externa, e monta o plano de incidentes para desativar um agente rapidamente quando algo corre mal.

A correção: garanta que uma parte possui de facto a fronteira, não apenas o documento. Ou constrói a capacidade interna para implementar e manter a stack completa, ou tem um operador a desenhar a arquitetura destes modos de falha e a operá-los, com uma fronteira publicada para a qual possa apontar. O meio-termo errado é uma lista de controlos e ninguém responsável por que eles aguentem.

Como os sete erros e correções se alinham

Aqui estão os sete num só lugar, ordenados por se a correção é um contrato que assina ou uma arquitetura que constrói. Essa divisão é a forma mais rápida de saber qual equipa possui cada um.

Repare que apenas dois dos sete são resolvidos por um contrato. Os outros cinco são arquitetura e propriedade, que é a parte que um PDF de melhores práticas não pode fazer por si. É também a razão honesta por que as fontes autoritativas deixam uma lacuna: dizem-lhe o que construir, não quem o vai construir corretamente dentro dos seus sistemas específicos.

O que de facto nunca sai, quando a fronteira é bem construída

É fácil ler sete erros e concluir que os agentes de IA são um campo minado de privacidade. Não são, quando a linha é traçada deliberadamente. Com termos empresariais, os seus inputs não são dados de treino, e a retenção é de dias, não para sempre (7 para a API da Anthropic, 30 para a OpenAI, apagados depois). Com ZDR, não são armazenados além do rastreio de abuso. Com a residência de dados fixada, ficam na sua região. Com recuperação em VPC ou on-prem, os dados sensíveis nunca saem do seu perímetro. Com ocultação na fronteira, os campos que nunca deveriam viajar são removidos antes de qualquer coisa ser enviada. Com escopo de privilégio mínimo que herda as permissões do utilizador, o agente só consegue alcançar aquilo que a pessoa que age já podia alcançar.

Essa é uma fronteira específica e defensável, e ser capaz de a enunciar com clareza é a questão toda. O perigo nunca foi o modelo a absorver silenciosamente a sua empresa. São os sete erros de configuração e arquitetura acima, cada um deles evitável antes do primeiro agente entrar em funcionamento.

Este é o trabalho que fazemos dentro das stacks de outras empresas: escolher os termos, definir o escopo das identidades, isolar o público do confidencial, quebrar a tríade, e possuir a fronteira para que aguente. Se quer estes erros eliminados pela arquitetura dos seus agentes antes de tocarem em algo real, marque uma consulta gratuita abaixo e mapearemos a sua fronteira em conjunto.