Linhagem de dados vira exigência para empresas que usam agentes de IA

Quando um agente confia no outro sem checagem

Um vendedor pede a um agente de IA os preços negociados com um cliente. O agente busca a informação em vários lugares: sistema de preços restrito, comunicações internas e orçamentos arquivados. Ele organiza tudo e entrega uma resposta que parece correta. Um segundo agente usa esse resultado para redigir a proposta comercial, e nenhum humano revisa nenhuma das duas etapas.

Essa é a cena que a MIT Technology Review descreve em um relatório publicado em 4 de novembro de 2026, produzido em parceria com a empresa de segurança de dados Cyberhaven. Quando alguém percebe que a proposta final contém informação confidencial e não aprovada, já é tarde: ninguém consegue apontar em qual dos dois agentes o dado sensível entrou no fluxo, nem para quantos outros sistemas ele se espalhou depois.

O texto é um conteúdo patrocinado, produzido pelo braço de conteúdo de marca da publicação (chamado Insights), não pela redação editorial do MIT Technology Review. Isso não muda o problema técnico que ele descreve: é um risco concreto para quem está construindo sistemas com múltiplos agentes de IA em produção.

O motivo: segurança de IA virou um problema de visibilidade de dados

Segundo o relatório, à medida que empresas colocam agentes de IA em fluxos de trabalho do dia a dia, elas descobrem que não basta mais proteger arquivos parados num servidor. O dado que entra num agente é ingerido, copiado, resumido, transformado e redistribuído em novos formatos, muitas vezes em segundos e sem rastro visível.

A conclusão do texto é direta: segurança de IA não é um problema de ferramenta, é um problema de visibilidade de dados. Abordagens tradicionais, pensadas para proteger aplicações, redes ou endpoints isolados, não dão conta de rastrear algo que se move entre dezenas de agentes, cada um com acesso a um conjunto diferente de fontes.

O que é linhagem de dados, e por que ela virou pré-requisito

O termo que o relatório usa em inglês é data lineage, que pode ser traduzido como linhagem de dados: o histórico completo de onde um dado nasceu, por quais sistemas e transformações ele passou, e onde terminou sendo usado. Numa arquitetura de agentes, isso significa saber não só qual documento um agente consultou, mas também se esse documento já era, ele mesmo, resultado de um resumo feito por outro agente a partir de uma fonte restrita.

Sem esse rastro, um erro de acesso vira um vazamento silencioso: o dado sensível já saiu do sistema de origem, foi reescrito por um modelo de linguagem e chegou a um documento final sem nenhuma marca que indique sua origem. É exatamente isso que acontece no cenário descrito pelo relatório: a proposta comercial final não carrega metadado nenhum que aponte de onde veio o trecho problemático.

O que muda para quem constrói agentes

Para times de TI e desenvolvimento que já colocam múltiplos agentes para conversar entre si (um agente de busca, um agente de síntese, um agente que redige o documento final), o recado prático é que controle de acesso no nível da aplicação não basta. É preciso rastrear o dado, não só o agente.

Na prática, isso aparece em decisões concretas de arquitetura:

• Marcar cada trecho recuperado por uma busca em um RAG (sigla para retrieval augmented generation, a técnica de buscar documentos relevantes antes de gerar a resposta) com metadado de origem, incluindo o nível de restrição do documento fonte.
• Propagar esse metadado quando um agente repassa o resultado para outro, em vez de deixar que a saída de um agente vire uma string de texto comum sem contexto.
• Registrar em log, com um identificador único por chamada, toda vez que um agente lê um dado restrito, para permitir reconstruir depois o caminho completo de uma informação até o documento final.
• Aplicar controle de acesso no nível do dado, não só do sistema: um agente com permissão para ler uma tabela de preços não deveria automaticamente poder incluir esse dado num documento destinado a alguém sem a mesma permissão.
• Tratar cada handoff entre agentes como ponto de risco, do mesmo jeito que uma API externa é tratada hoje: validar o que entra e o que sai, sem assumir que o resultado de um agente já está limpo.

Um metadado simples de linhagem, anexado a cada trecho que circula entre agentes, pode ser tão direto quanto isto:

{
  "source": "pricing_system",
  "classification": "restricted",
  "retrieved_by": "agent_search_01",
  "trace_id": "8f2e9c"
}

O agente seguinte na cadeia decide o que fazer com o trecho não só pelo conteúdo, mas também pela classificação que veio junto. Essa é uma leitura própria de como o problema descrito no relatório poderia ser atacado na prática, não uma recomendação detalhada no material original.

O que fica em aberto

O material fonte não indica ferramenta específica, framework ou padrão de mercado para implementar linhagem de dados em sistemas de agentes de IA. Também não há número de incidentes reais nem estudo de caso nomeado, apenas o cenário hipotético do vendedor e da proposta comercial. O relatório existe para promover um estudo mais extenso, disponível para download, em parceria com a Cyberhaven, empresa que vende produtos de segurança de dados.

O ponto que fica claro, independentemente do fornecedor por trás do relatório, é que a arquitetura de múltiplos agentes sem revisão humana em cada handoff cria uma superfície de risco nova. O dado erra de forma silenciosa e sem assinatura, porque passou por pelo menos um agente a mais do que em um pipeline tradicional com um único modelo respondendo direto ao usuário.

Fonte: MIT Technology Review — IA