Minimização de dados em agentes de IA: compartilhe menos, controle mais

A minimização de dados em agentes de IA consiste em entregar ao agente apenas os campos que a tarefa exige, substituir ou remover o restante antes que chegue ao modelo e manter esses campos fora da memória e dos logs. Isso reduz a exposição sem prejudicar os resultados, porque a maioria das tarefas depende de poucos fatos, não do registro inteiro. O método é simples de enunciar: defina a tarefa, crie uma lista de campos permitidos, aplique a lista na camada de ferramentas e teste a saída contra a versão com todos os dados.

Principais pontos

• Minimize por tarefa, não por agente. O mesmo agente pode precisar de campos diferentes para responder a um pedido de reembolso e para atualizar uma entrega.
• Aplique a lista de campos nas ferramentas e integrações, não apenas nas instruções escritas, porque instruções podem ser ignoradas ou sobrescritas.
• Substitua em vez de apenas apagar. Marcadores consistentes e valores generalizados preservam o raciocínio do modelo.
• Texto livre, anexos, memória e logs são onde a minimização mais vaza, então projete esses pontos de propósito.
• Comprove que funciona rodando os mesmos casos com e sem os campos retidos, e revise a lista sempre que a tarefa mudar.

O que significa minimização de dados quando quem lê é um agente de IA?

Minimização de dados é um princípio antigo de privacidade: usar apenas as informações pessoais e sensíveis que uma finalidade declarada exige. Para uma pessoa, isso costuma significar não coletar campos extras em um formulário. Para um agente, a pergunta se desloca para três lugares: o que entra no contexto do modelo, o que as ferramentas devolvem a ele e o que fica guardado depois em memória, transcrições e logs.

O risco é prático, não abstrato. Um funcionário que cola o cadastro inteiro de um cliente em um chat expõe mais do que o necessário. Um agente conectado a um CRM, a uma caixa de e-mail ou a uma pasta compartilhada pode fazer o mesmo muitas vezes por dia, em silêncio, porque ninguém escolheu o que deixar de fora. Cada campo extra é mais um dado que o provedor do modelo processa, mais um dado armazenado em um rastro de execução e mais um dado que uma instrução maliciosa pode tentar extrair.

A lógica é a mesma do menor privilégio no controle de acesso, que o OWASP Authorization Cheat Sheet descreve bem: conceder o mínimo necessário e negar por padrão. A minimização aplica essa ideia aos campos de dados, e não apenas aos sistemas. Para empresas que tratam dados pessoais de pessoas no Brasil, o princípio da necessidade da LGPD aponta na mesma direção, e o artigo LGPD e agentes de IA nas empresas: o que verificar antes de usar cobre a lista de verificação mais ampla.

O agente piora se enxergar menos?

Geralmente não, desde que os campos sejam escolhidos de acordo com a tarefa. Um modelo que redige a resposta sobre uma encomenda atrasada não precisa de CPF, de endereço completo nem de uma anotação sobre uma disputa antiga. Contexto em excesso pode até reduzir a qualidade, porque o modelo passa a ter mais material irrelevante para ponderar. A orientação da Anthropic sobre engenharia de contexto descreve o objetivo como o menor conjunto possível de informações de alto sinal que torne provável o comportamento desejado. Engenharia de contexto para agentes de negócio é justamente aplicar essa ideia ao conhecimento da empresa.

Há uma exceção real. Às vezes o campo que você gostaria de remover é o próprio sinal. O país do cliente pode definir qual texto de reembolso se aplica. A data de renovação de um contrato pode definir se uma mensagem é urgente. Por isso a minimização é uma decisão testada, não uma regra geral: remova, compare os resultados e restaure apenas o que mudou o desfecho.

Como decidir quais campos uma tarefa precisa?

Trabalhe a partir da tarefa, uma de cada vez. Este plano cabe em uma página e pode ser executado em uma sessão curta de trabalho com a pessoa responsável pelo processo.

• Passo 1: Escreva a tarefa em uma frase, com o resultado esperado. Por exemplo: redigir uma resposta de status para um cliente que pergunta onde está o pedido.
• Passo 2: Liste todos os campos que o sistema de origem guarda para aquele registro, incluindo anotações e anexos, e não só os que o agente vê hoje.
• Passo 3: Classifique cada campo em quatro grupos: necessário para decidir, necessário para personalizar, necessário para agir e desnecessário.
• Passo 4: Para campos necessários apenas para agir, como um endereço de e-mail, verifique se a ferramenta consegue usá-los sem que o modelo os leia. O agente passa uma referência e o sistema a resolve.
• Passo 5: Escreva uma lista de permissão para a tarefa. Tudo o que não estiver na lista fica retido por padrão. Uma lista de bloqueio falha no dia em que um campo novo é adicionado ao sistema de origem.
• Passo 6: Escolha um tratamento para cada campo permitido: passar como está, mascarar, generalizar ou trocar por um marcador.
• Passo 7: Aplique a lista na camada de ferramenta ou integração, de modo que o modelo nunca receba os campos retidos.
• Passo 8: Teste com uma amostra de casos reais do passado, compare as saídas com a versão com todos os dados e anote qualquer campo cuja remoção tenha alterado o resultado.
• Passo 9: Defina um responsável e um gatilho de revisão, como um campo novo, uma ferramenta nova ou uma mudança na tarefa.

Mantenha a lista de permissão em uma configuração que o responsável pelo processo consiga ler, não escondida no texto do prompt. A mesma disciplina vale para os escopos de acesso: dar ao agente só o necessário no Google Workspace ou no Microsoft 365 limita quais sistemas ele alcança, enquanto a lista de campos limita o que ele lê dentro deles. Você precisa dos dois.

Quais técnicas de ocultação funcionam, e quando?

Escolha a técnica de acordo com o que o modelo precisa fazer com o campo.

• Remover: o campo não é necessário. É o padrão e a opção mais simples.
• Mascarar: mostrar só um trecho quando uma pessoa precisa reconhecer o valor, como os últimos caracteres de um número de pedido.
• Generalizar: reduzir a precisão. Uma data de nascimento exata vira uma faixa etária, um endereço vira uma cidade, um horário vira uma data.
• Pseudonimizar: trocar nomes e identificadores por marcadores consistentes, como Cliente A e Fornecedor B. A tabela de correspondência fica fora do modelo, de modo que o rascunho pode ser restaurado antes de uma pessoa revisar ou enviar.
• Referenciar: deixar o agente agir sobre um identificador, por exemplo responder ao contato cadastrado, enquanto o sistema busca o e-mail ou o telefone.
• Resumir antes: uma etapa determinística extrai os poucos fatos relevantes de um documento longo, e o agente vê apenas esse extrato.

A consistência importa mais do que se imagina. Se o marcador da mesma pessoa muda entre mensagens, o agente perde o fio e pode confundir duas partes. Seja realista também quanto à detecção automática. A busca por padrões encontra valores formatados, como números de cartão ou de documentos, mas deixa passar nomes e contexto dentro de texto livre. Prefira campos estruturados com lista de permissão e trate a detecção automática em texto livre como segunda camada, não como a primeira.

Dados pseudonimizados continuam sendo dados pessoais enquanto existir uma tabela de correspondência. Proteja essa tabela com o mesmo cuidado do registro original e mantenha-a fora do alcance do agente.

Um cenário ilustrativo: resposta sobre o status de uma entrega

Cenário ilustrativo: uma distribuidora quer que um agente redija respostas a clientes que perguntam onde está o pedido. O cadastro do cliente tem nome completo, telefone, endereço de entrega, dados de cobrança, itens do pedido, eventos da transportadora e um campo de anotações em texto livre em que a equipe registrou reclamações anteriores.

Aplicando o plano, a tarefa precisa do primeiro nome, do status do pedido, do último evento da transportadora, da janela prevista de entrega e da categoria do item. Não precisa dos dados de cobrança, do endereço completo nem das anotações. A etapa de envio precisa do endereço, mas só a ferramenta de envio precisa, então o agente passa a referência do pedido e a ferramenta resolve o contato. Uma regra sinaliza os pedidos cujas anotações mencionam uma reclamação em aberto, e esses vão para uma pessoa, que vê o registro completo por definição.

A equipe roda uma amostra de casos passados nas duas versões. Se as respostas coincidem em conteúdo e tom, a versão mais enxuta entra em uso. Se um caso diverge, digamos porque uma anotação sobre instruções de acesso ao prédio se mostrou relevante, adiciona-se um único campo extraído com as instruções de entrega, em vez de expor a anotação inteira. O resultado é uma superfície menor com a mesma utilidade.

Onde a minimização falha sem ninguém perceber?

A maioria dos vazamentos vem de pontos que as equipes esquecem de projetar.

• Texto livre: anotações, corpos de e-mail e comentários de chamados contêm exatamente o que os campos estruturados já tinham limpado.
• Anexos: um PDF enviado ao agente leva todas as páginas, não só o parágrafo de que a tarefa precisa.
• Respostas amplas das ferramentas: uma ferramenta de consulta que devolve o cadastro inteiro desfaz a lista de permissão. Projete ferramentas que devolvam resultados estreitos, no formato da tarefa.
• Memória e resumos: tudo o que o agente viu pode ser armazenado e reaparecer em uma conversa sem relação.
• Logs e rastros: dados de depuração costumam guardar prompts completos. Registre nomes de campos, referências e decisões, e mantenha os valores de fora.
• Instruções injetadas: o texto de um e-mail ou de uma página web pode mandar o agente revelar o que ele possui. A orientação do OWASP sobre prompt injection enfatiza limitar o que o modelo pode acessar e fazer. Um agente que nunca recebeu um campo não consegue vazá-lo.

Trate a lista de permissão como um controle vivo, não como um projeto pontual. O NIST AI Risk Management Framework descreve isso como trabalho contínuo: mapear por onde os dados passam, medir se os controles se sustentam e gerenciar as mudanças. Na prática, isso significa um responsável, uma amostra de evidências e uma revisão agendada.

Como a Be Human trabalha isso

A Be Human trata a lista de campos como parte do desenho da função do agente. Em um primeiro projeto, definimos uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável, e a lista de permissão de cada tarefa é registrada nesse momento. Os limites de campos e a ocultação são aplicados nas integrações, e não no texto do prompt, o agente trabalha com identidade própria e permissões restritas, e os logs registram referências em vez de valores brutos. Na operação gerenciada, avaliações recorrentes rodam os casos de novo com as entradas minimizadas, revisões de permissão identificam campos que voltaram a aparecer e as mudanças na lista passam pelo responsável do lado da empresa.

Perguntas frequentes

Minimização de dados é o mesmo que anonimização? Não. A minimização decide o que o agente recebe para uma tarefa, enquanto a anonimização tenta tornar impossível ligar os dados de volta a uma pessoa. Dados pseudonimizados continuam sendo dados pessoais enquanto existir uma tabela de correspondência, então use a minimização primeiro e trate os marcadores como uma camada adicional.

A minimização substitui a avaliação de segurança do provedor de IA? Não. Ela reduz o que fica exposto se algo der errado, mas você ainda precisa saber onde os dados são processados, por quanto tempo são retidos e quem pode acessá-los. Os dois controles funcionam juntos, e nenhum dispensa o outro.

Como saber se um campo retido prejudicou os resultados? Rode o mesmo conjunto de casos reais do passado com e sem o campo e peça ao responsável pelo fluxo que compare as saídas quanto a conteúdo, tom e erros. Se aparecer diferença, restaure apenas a versão mais estreita do campo que resolve o problema, como um fato extraído em vez de uma anotação inteira.

Quem deve ser o responsável pela lista de campos? Quem é dono do fluxo de trabalho deve ser dono da lista, com revisão de privacidade ou de segurança nos campos sensíveis. Essa pessoa sabe o que a tarefa exige e consegue avaliar o equilíbrio entre proteção e utilidade. Revise a lista sempre que a tarefa, uma ferramenta ou o sistema de origem mudar.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.