Anexos modernos em eDiscovery

Não, não por padrão. Todos os tribunais federais dos EUA que decidiram diretamente a questão desde 2021 entenderam que um hiperlink para um arquivo na nuvem não é um anexo tradicional, e que arquivos vinculados não herdam a relação de família documental da mensagem que os contém. Esse padrão se mantém porque a resolução em massa de links foi considerada inviável ou desproporcional, não porque arquivos vinculados sejam irrelevantes. Eles continuam sujeitos a exibição mediante pedido direcionado, e o padrão se inverte por completo no momento em que você estipula o contrário em um protocolo ESI. Duas partes produtoras já aprenderam isso do jeito caro.

Um anexo moderno (também chamado de anexo na nuvem, anexo vinculado ou ponteiro) é uma URL dentro de um email, de uma postagem no Teams ou de uma mensagem no Slack que resolve para um arquivo hospedado em SharePoint, OneDrive, Google Drive ou Box. Os bytes nunca viajam com a mensagem. O que o destinatário recebeu foi um ponteiro e uma permissão e, como o arquivo de destino segue vivo e editável depois que o link é enviado, o documento que o remetente de fato compartilhou pode não existir mais quando alguém for coletar.

O que não é

Um anexo moderno não é um anexo tradicional. Um anexo tradicional é uma cópia: congelada no momento do envio, transportada dentro da mensagem e ligada a ela por uma relação pai-filho que toda plataforma de revisão entende. Um anexo moderno é uma referência sem cópia congelada e sem relação de família inerente, que é exatamente a lacuna sobre a qual a jurisprudência vem discutindo há cinco anos.

Também não é a mesma coisa que um link para uma página web pública. Um link para uma matéria de jornal ou para a página de preços de um fornecedor está fora da sua posse, custódia ou controle, então não gera obrigação de produção. O teste que transforma um link em anexo moderno é se o arquivo vinculado está em um sistema que a parte produtora controla. E não são dados de mensageria curta, embora os dois andem juntos, porque hoje os mesmos protocolos ESI regem ambos, e as mensagens de Slack e Teams são onde os anexos modernos são mais densos.

Por fim, não se resolve coletando o Drive inteiro. A coleta do repositório de arquivos do custodiante entrega os arquivos; ela não diz qual mensagem apontava para qual arquivo, que é justamente a associação que a parte solicitante está pedindo.

O que os tribunais decidiram

O fio condutor não é que arquivos vinculados não importem. É que os tribunais se recusaram de forma consistente a impor às partes produtoras a reconstrução em massa de famílias enquanto a tecnologia não consegue entregá-la, e empurraram as partes para uma troca direcionada. Meta Pixel é a formulação mais clara dessa divisão: o protocolo diz que não há famílias e, separadamente, as partes atendem a pedidos específicos razoáveis conforme eles surgem.

StubHub é o caso para ler antes de assinar qualquer coisa. A StubHub estipulou um protocolo que definia arquivos filhos incluindo hiperlinks para documentos internos, depois descobriu que não conseguia cumprir e violou a ordem desde a primeira produção em diante. O tribunal modificou o protocolo e negou as sanções, mas foi direto sobre a origem do dano: o prejuízo “foi causado pela decisão tola da StubHub de estipular o requisito de hiperlinks em primeiro lugar”. Uma estipulação transforma um limite técnico em uma ordem judicial que você já está descumprindo.

O modelo Cerebras

James v. Cerebras Systems (N.D. Cal., 7 de julho de 2026) é o primeiro protocolo ESI estipulado a tratar anexos modernos e governança de revisão com IA generativa em uma única ordem, e suas cláusulas sobre hiperlinks são o material mais copiável hoje disponível nos autos:

• Documentos hiperlinkados não são membros da família documental para fins de produção de anexos.
• A parte solicitante identifica documentos produzidos específicos que contêm links relevantes e pede esses arquivos, com teto de 100 hiperlinks pertinentes e não privilegiados para coleta direcionada.
• A parte produtora tem 14 dias para produzir a versão tal como existia no momento da coleta, ou a versão tal como existia quando o hiperlink foi enviado, quando isso for possível.

Essa alocação é o ponto central. Quem solicita arca com o custo de decidir o que importa; quem produz arca com o custo de recuperar. Nenhum dos dois lados é obrigado à coleta de tudo por padrão que tornou esse assunto intratável. A mesma ordem ainda fixa a validação da revisão com IA em nível de confiança de 95% para amostragem do conjunto nulo, com taxa de elusão que não ultrapasse 3%, e exige dados de mensageria curta em lotes de conversa de no mínimo 24 horas, algo coberto na entrada de eDiscovery.

O que as ferramentas realmente conseguem fazer

A resposta jurídica já está suficientemente assentada. Onde os times ainda se machucam é na resposta operacional, porque as duas principais suítes coletam anexos modernos e as duas fazem isso com limites fáceis de não perceber.

Microsoft Purview eDiscovery coleta anexos na nuvem no nível eDiscovery Premium, que exige Microsoft 365 E5 ou o add-on E5 Compliance e é licenciado por custodiante cujos dados você coleta. Ele consegue coletar a versão ao vivo, a versão existente no momento do compartilhamento ou todas as versões, e agrupa o arquivo vinculado com a mensagem pai por meio de um GroupID compartilhado mais uma propriedade Is modern attachment.

O detalhe é que a versão compartilhada só existe se você tiver configurado isso antes. Por padrão, o fluxo coleta a versão ao vivo atual. Recuperar a versão que foi de fato enviada exige um rótulo de retenção configurado para se aplicar automaticamente a anexos na nuvem, que tira um snapshot da cópia no momento do compartilhamento. Se esse rótulo não estava ativo antes de o compartilhamento acontecer, a versão enviada nunca foi preservada e nenhuma configuração de coleta vai trazê-la de volta.

Limites documentados do Purview, vigentes na revisão de 11 de junho de 2026:

A atribuição de custodiante também funciona ao contrário: o arquivo vinculado é atribuído ao custodiante da mensagem, não a quem é dono do arquivo. Se o usuário A compartilha um arquivo do OneDrive do usuário C com o usuário B, e você coleta da caixa postal do usuário B, o arquivo fica sob o usuário B.

Google Vault exporta arquivos vinculados do Drive pela opção Export linked Drive files nas exportações do Gmail. Ele devolve apenas a versão atual: o Vault não tem equivalente de versão no momento do envio como o snapshot por rótulo de retenção do Purview. Hiperlinks públicos, como páginas publicadas do Google Sites e links de formulários do Google que aceitam envio, não podem ser exportados, assim como alguns formatos legados de link do Drive e links dentro de mensagens criptografadas. Os arquivos exportados chegam separados das mensagens pai, então a associação precisa ser reconstruída depois a partir do mapeamento de drive-links exportado, antes da revisão.

Como negociar isso antes da coleta

Faça isso no protocolo ESI, antes de coletar um único custodiante:

1. Declare a regra de família de forma explícita. Escreva que arquivos hiperlinkados não são membros da família documental, na formulação de Meta Pixel / Cerebras. O silêncio é pior do que qualquer uma das duas respostas, porque deixa a briga para um momento em que você já produziu.
2. Fixe o mecanismo de pedido direcionado com um número e um prazo. Cerebras te dá 100 hiperlinks e 14 dias. Escolha números adequados ao caso, mas escolha números: “pedidos razoáveis” sem teto reproduz o problema da coleta em massa com outro nome.
3. Diga qual versão é devida. A da data de coleta ou a da data de envio. Não prometa a de envio a menos que a rotulagem de retenção de anexos na nuvem já estivesse rodando nos sites em escopo quando as mensagens foram enviadas. Confira a data de configuração, não o documento de política.
4. Recorte as exclusões que você realmente tem. Copie para o protocolo os limites reais da sua plataforma: o teto de 50 links, mensagens criptografadas, partes citadas de encaminhamentos, canais compartilhados do Teams. “Na medida do tecnicamente viável” é uma frase que você vai ter que litigar; uma lista enumerada é uma para a qual você pode apontar.
5. Torne o teto recíproco. Em um caso com dois lados pesados em documentos, a parte solicitante vira parte produtora na reconvenção.
6. Faça o teste de viabilidade antes de assinar. Pegue uma amostra de algumas centenas de mensagens em escopo, passe por elas na plataforma que você vai usar de verdade e conte quantos links resolvem para um arquivo que você consegue produzir. Esse número, e não o datasheet do fornecedor, é contra o que você negocia.

Erros comuns

• Estipular hiperlink-como-anexo sem testar. É exatamente a falha da StubHub, e a compreensão do tribunal não se estendeu à estipulação em si. Guarda: trate qualquer cláusula sobre hiperlinks como um compromisso técnico que exige uma coleta de amostra antes da assinatura, no mesmo patamar de aceitar um formato de produção.
• Supor que a versão enviada é recuperável. Tanto o Purview quanto o Vault devolvem por padrão a versão ao vivo atual, e o snapshot no momento do envio do Purview só existe onde um rótulo de retenção foi aplicado de forma prospectiva. Guarda: ligue a rotulagem de retenção de anexos na nuvem como controle permanente de prontidão para retenção, não como passo do momento da coleta: nessa altura a questão já está decidida.
• Ler um relatório de coleta limpo como se fosse completo. O teto de 50 links, o corte de 2.048 caracteres de URL e a exclusão das partes citadas descartam links sem gerar erro. Guarda: sinalize no processamento as mensagens com mais de 50 links e mande para revisão manual; concilie a contagem de links no corpo das mensagens com os links de fato resolvidos.
• Reter a caixa postal, mas não o arquivo. Uma retenção sobre a caixa postal de um custodiante não congela um arquivo vinculado que está no OneDrive de outra pessoa, e a atribuição de custodiante do Purview não vai dizer de quem ele era de verdade. Guarda: defina o escopo da retenção legal sobre locais de arquivos além de custodiantes, e preserve as coleções de sites a partir das quais os times em escopo realmente compartilham.
• Produzir arquivos vinculados que nunca passaram pelo filtro de privilégio. Um arquivo vinculado entra porque o pai dele bateu com um termo de busca, inclusive, conforme a documentação do Purview, quando o próprio arquivo não teria batido e mesmo que ele esteja fora do limite de conformidade. Guarda: passe o corpus de arquivos vinculados pela revisão de privilégio como população própria e com termos de busca próprios, antes de ele entrar no conjunto de produção.

Relacionado

• eDiscovery — o processo ao redor, as etapas do EDRM e o restante do protocolo Cerebras
• Processo de retenção legal — onde a preservação de anexos na nuvem precisa ser decidida
• Revisão de privilégio — o filtro que os arquivos vinculados driblam por padrão
• Microsoft Purview eDiscovery — o lado da coleta para tenants do Microsoft 365
• Relativity — onde as famílias reconstruídas aterrissam para revisão