Dois pipelines de due diligence. Mesmo modelo, mesma data room, mesma grelha de respostas. Um identificou 5 de 5 problemas materiais inseridos. O outro identificou 3 de 5. Os dois que falhou são precisamente os dois pelos quais seria despedido.
O essencial
Os três problemas que ambos os pipelines identificaram eram os óbvios - do tipo que um associado competente assinala com um marcador amarelo. Os dois que o single-prompt não detetou exigiam ligar dois documentos entre si ou aplicar conhecimento jurídico externo a uma cláusula que, à primeira vista, parece inofensiva. São exatamente as categorias em que as ferramentas de due diligence com IA falham silenciosamente, e exatamente as categorias que todos os discursos de vendedores de IA para M&A evitam mencionar.
Factos-chave
- O single-prompt identificou 3/5 problemas materiais inseridos; o swarm de 3 agentes identificou 5/5 — ambos com precisão 1.0, mesmo modelo (Claude Opus 4.7, contexto de 1M), mesma data room de 30 documentos. O artigo declara que os números são calibrados de forma simulada para demonstrar o harness open-source.
- A data room de 30 documentos (~13.200 palavras / 24.000 tokens) cabe numa única chamada de contexto de 1M, com ~976K tokens de sobra — o tamanho do contexto não era a limitação.
- O swarm executou 32 chamadas a LLMs (30 de pesquisa + 1 de sinalização de risco + 1 de síntese), a um custo de aproximadamente 2-3x o do single-prompt.
Construímos os dois pipelines, corremo-los sobre os mesmos dados e tornámos pública a grelha de respostas.
Porque realizámos este teste
Todos os discursos de vendas de due diligence com IA a que assistimos evitam a mesma pergunta: qual é a arquitetura? Um único prompt gigante com todo o contexto? Um pipeline multiagente? RAG sobre documentos fragmentados? A maioria não responde. A demonstração é um memorando polido e um dashboard. A arquitetura é «proprietária».
Isso é um problema, porque a arquitetura é o produto. Um único prompt sobrecarregado de contexto e um swarm de 3 agentes a correr no mesmo modelo produzem memorandos drasticamente diferentes sobre a mesma data room. Quisemos medir até que ponto.
Por isso construímos ambos. Mesmo modelo - Claude Opus 4.7, contexto de 1M - mesmos documentos, mesmo harness de avaliação. As diferenças no resultado refletem a arquitetura do prompt, não a escolha do modelo. Um LLM-as-judge avaliou os resultados face a uma grelha de respostas com os problemas inseridos, à qual tinha acesso, mas que os pipelines em si não podiam ver.
Uma nota antes dos números: trata-se de uma experiência controlada sobre dados sintéticos. Os números do pipeline simulado foram calibrados para demonstrar o harness de ponta a ponta. Publicamo-lo mesmo assim porque acreditamos que o padrão de falha - o single-prompt perde a ligação entre documentos e os problemas de conhecimento externo - se replica com chamadas reais a LLMs, e o desenho da experiência é reutilizável. O código é open-source.
A data room
Trinta documentos em markdown, sete categorias, num total de ~13.200 palavras / 24.000 tokens. Construída para espelhar a densidade de sinal de uma data room de uma ronda Série D no setor terapêutico, com nomes de empresas claramente fictícios para que ninguém a confunda com uma fuga de dados (Acme Sprockets, NorthStar Therapeutics, Helix BioSystems, Meridian Bio).
Todo o corpus cabe numa única chamada do Claude Opus 4.7 com contexto de 1M, com ~976K tokens de sobra. Isto elimina a desculpa mais comum para o desempenho inferior do single-prompt. Não estamos a pedir ao modelo que recupere informação de um corpus demasiado grande para o seu contexto. Toda a data room está dentro da janela.
Os cinco problemas inseridos
Cinco problemas materiais foram inseridos em documentos de aparência comum - não em cabeçalhos, não anunciados. Deliberadamente variados quanto à dificuldade de deteção:
- Três problemas visíveis à primeira vista, num único documento - uma cláusula de mudança de controlo num contrato de fornecimento, um pedido reconvencional em litígio no valor de mais de 10% do preço de compra e uma reserva sobre a continuidade operacional no relatório do auditor. Itens de checklist. Falhar a checklist é falhar a due diligence.
- Um problema entre documentos - uma lacuna na cadeia de titularidade da propriedade intelectual, visível apenas ao ligar o registo de cessão de PI (que assinala um engenheiro sem PIIA em falta), uma licença principal (que nomeia esse mesmo engenheiro como inventor da plataforma licenciada) e a carta de oferta desse engenheiro (que diz «PIIA em anexo» sem qualquer anexo). Nenhum documento isolado contém o sinal completo.
- Um problema de conhecimento externo - uma cláusula de não-concorrência de 2 anos a nível nacional para a Chief Scientific Officer, regida pela lei da Califórnia. Para saber que não tem qualquer valor, é preciso saber que a California Bus. & Prof. § 16600 anula a maioria das cláusulas de não-concorrência para trabalhadores, e que a AB-1076 (em vigor desde janeiro de 2024) acrescentou ainda uma obrigação de notificação.
A grelha de respostas completa, com os critérios «tem de detetar» para o LLM-as-judge, está em `fixtures/known-issues.md`. Não a mostrámos aos pipelines.
Pipeline 1: single-prompt
Concatenar todos os documentos. Envolvê-los num system prompt de advogado sénior. Uma chamada ao LLM. Obter o memorando. É isto que a maioria dos discursos «usamos um modelo de fronteira com contexto de 1M» esconde por trás.
const SYSTEM = `You are a senior M&A diligence attorney reviewing a target
company data room on behalf of an acquirer paying $250M for the entire
company. Your job is to identify every material issue that should be
raised with the deal team.
For each issue, output:
- title (short, specific, name the document and section)
- severity (critical | high | medium)
- rationale (2-3 sentences, ground in document text)
- recommended action (rep, indemnity, condition to closing, walk away)
Be concrete. Cite section numbers and document IDs. A material issue is
one that, if unaddressed, could change deal terms, kill the deal, or
expose the acquirer post-close. Do not include ordinary-course items.`;Uma única chamada ao modelo. ~24K tokens de entrada, ~3K de saída, menos de 15 segundos de execução, poucos cêntimos por corrida. Barato, rápido, estruturalmente simples.
Resultado: 3/5 identificados. Precisão 1.0. Falhas: a lacuna na cadeia de titularidade da PI e a cláusula de não-concorrência da Califórnia.
Acertou na cláusula de mudança de controlo, na exposição ao litígio e na reserva sobre a continuidade operacional. Um memorando limpo e bem citado. Sem alucinações. Parecia, francamente, bastante bom - até se comparar com a grelha de respostas.
Pipeline 2: swarm de 3 agentes
Três agentes, cada um uma chamada ao modelo distinta, com o seu próprio system prompt:
- Investigador (30 chamadas em paralelo, uma por documento). Resumo estruturado por documento: contrapartes, prazo, termos económicos, linguagem de mudança de controlo, disposições invulgares, questões em aberto.
- Sinalizador de risco (uma chamada). Lê os 30 resumos do investigador. Devolve uma lista em JSON dos problemas materiais, com gravidade, fundamentação e citações das fontes.
- Sintetizador (uma chamada). Transforma a lista de sinalizações num memorando para a equipa da operação.
Total: 32 chamadas a LLMs. Custo mais elevado - o investigador paga tokens de entrada 30 vezes em vez de uma. O custo total é aproximadamente 2-3x o do single-prompt, consoante a verbosidade do resultado.
Repare no campo `sources` no schema do sinalizador de risco. O schema obriga o modelo a atribuir cada sinalização a um ou mais documentos. Essa única decisão de design é o que faz com que os problemas entre documentos sejam detetados - pede-se ao modelo que pense entre resumos, não apenas dentro de cada um.
Resultado: 5/5 identificados. Precisão 1.0.
O que o single-prompt não detetou, e porquê
Esta é a parte que importa. As duas falhas são estruturais à arquitetura do single-prompt, não falhas aleatórias.
Falha 1 - A lacuna na cadeia de titularidade da PI
O registo de cessão de PI assinala que o engenheiro Wei Lin tem «uma carta de oferta assinada em arquivo, mas sem PIIA contra-assinada registada - a acompanhar». A carta de oferta tem uma linha de marcador de posição que diz `[PIIA anexada como Anexo A]`, sem qualquer anexo. A licença principal, numa pasta separada, nomeia Wei Lin como inventor da plataforma central licenciada. Ligando os três, obtém-se um problema crítico: o adquirente pode, na realidade, não ser o titular da PI pela qual está a pagar 250 milhões de dólares.
O modelo em single-prompt consegue ver os três documentos. Simplesmente não os liga sob uma instrução genérica de «encontrar todos os problemas materiais». Contextos longos esbatem a ligação entre documentos - o modelo produz uma excelente análise por documento, mas raramente dá o passo extra de perguntar «será que o engenheiro do documento X é a mesma pessoa do documento Y, e isso muda o quadro?». Não há incentivo no prompt para o fazer.
O swarm detetou-o porque a entrada do sinalizador de risco são resumos estruturados por documento, com entidades nomeadas em evidência. Quando o prompt no estilo de um sócio vê «engenheiro com PIIA em falta» num resumo e «engenheiro nomeado como inventor» noutro, a ligação está a um único passo de inferência de distância, e não enterrada em 24K tokens de texto contratual.
Experimente HAQQ AI grátis
Experimente a redação e pesquisa jurídica com IA
Falha 2 - A cláusula de não-concorrência inexequível da Califórnia
A Chief Scientific Officer tem, no seu contrato de trabalho, uma cláusula de não-concorrência de 2 anos a nível nacional. Lei aplicável: Califórnia. Vive em Palo Alto.
Para quem tenha lido a California Bus. & Prof. § 16600, a cláusula é, na prática, nula. A AB-1076, em vigor desde janeiro de 2024, reforçou ainda mais essa regra: os empregadores têm de notificar ativamente os antigos trabalhadores com este tipo de cláusulas de que estas são inexequíveis, sob pena de responsabilidade adicional.
O modelo em single-prompt sabe isto. Pergunte-lhe diretamente - «esta cláusula de não-concorrência é exequível na Califórnia?» - e ele responde. Simplesmente não traz esse conhecimento à superfície por iniciativa própria, sob uma instrução genérica de «encontrar todos os problemas materiais». A cláusula parece inofensiva à primeira vista. Nada no próprio documento grita «pergunta se sou exequível».
O swarm detetou-o porque o system prompt do sinalizador de risco delimita o modelo a um papel de sócio, aplicando um limiar de materialidade entre resumos - e, nesse papel, coloca questões jurisdicionais sobre cláusulas restritivas. Com um agente mais especializado (um revisor dedicado a direito laboral, ou uma chamada a uma base de dados de legislação), isto torna-se determinístico. Com um único prompt genérico, é uma questão de sorte.
Estes não são modos de falha exóticos. A ligação entre documentos e o conhecimento legislativo externo são as duas categorias em que a due diligence acrescenta mais valor. São também as duas categorias em que sobrecarregar de contexto um modelo de fronteira dá a pior falsa sensação de segurança, porque o resultado parece exaustivo.
O compromisso entre custo e qualidade
O single-prompt é mais barato, mais rápido e produz um memorando mais coerente. Numa data room de 30 documentos, é aproximadamente 3x mais barato e 3x mais rápido do que o swarm.
O swarm identifica mais, deixa um rasto de auditoria por documento e permite substituir agentes por especialistas (regulação da FDA, ERISA, fiscalidade, direito laboral específico de cada jurisdição) sem reescrever o pipeline.
Quando é que o ganho justifica o custo?
- Menos de 10 documentos, valor da operação abaixo de 25 milhões de dólares, primeira leitura com tempo limitado - o single-prompt é suficiente. A superfície de ligação entre documentos é pequena.
- 30+ documentos, valor da operação acima de 100 milhões de dólares, qualquer coisa antes da assinatura - swarm. A diferença de custo numa operação de 100 milhões de dólares é irrelevante face a um único problema material não detetado.
- Setores regulados (ciências da vida, serviços financeiros, defesa) - swarm, com pelo menos um agente especializado para o regulador relevante.
- Qualquer coisa por cuja omissão perderia o emprego - swarm.
Para as dimensões de operação a que isto se destina, mais alguns dólares por corrida são um erro de arredondamento face ao custo de não detetar um destes problemas na assinatura. A opção por defeito é o swarm. O single-prompt é uma ferramenta de triagem, não uma ferramenta de due diligence.
O que isto significa se estiver a comprar IA para M&A neste momento
Quatro coisas. Nenhuma delas é lisonjeira para os fornecedores.
Um. Não confie num «assistente de due diligence com IA» que não lhe diga qual é a sua arquitetura. Se a resposta a «single prompt ou multiagente?» for «proprietário», vá embora. A arquitetura decide o que é detetado.
Dois. Sobrecarregar de contexto um único prompt é aceitável para revisões pequenas e apertadas, e perigoso para due diligence mais profunda. Uma janela de contexto de 1M não substitui a atenção forçada por documento. Apenas permite que o modo de falha se esconda melhor.
Três. Os problemas entre documentos e de conhecimento externo não vão surgir de uma instrução «encontrar todos os problemas materiais», por maior que seja o contexto. Exigem prompting de agentes especializados, chamadas a ferramentas para fontes autorizadas, ou instruções explícitas de ligação entre documentos. Se o produto não conseguir mostrar-lhe qual destas coisas faz, é porque não as faz.
Quatro. Baseie a avaliação em testes com problemas inseridos, não em impressões. O memorando parece exaustivo. Simplesmente não deteta a lacuna de PI. A única forma de saber é correr uma grelha de respostas contra ele.
O que construiríamos para a HAQQ
Swarm por defeito, com o single-prompt como alternativa mais económica para revisões pequenas ou de triagem. Agentes especializados para as categorias de falha que o swarm genérico não cobre: um ligador entre documentos que enumera explicitamente mapas de entidade-para-documento antes de sinalizar, e um verificador de jurisdição que assinala todas as cláusulas restritivas, cláusulas de lei aplicável e declarações regulatórias com uma verificação de exequibilidade face à legislação relevante.
O benchmark de problemas inseridos mantém-se open-source. Continuaremos a acrescentar problemas - armadilhas na cadeia de titularidade, desvios entre o cap table e o 409A, cláusulas MFN ocultas, side letters que contradizem o contrato principal - e a publicar números sempre que lançarmos uma alteração de arquitetura. Se um fornecedor quiser afirmar que o seu produto é melhor, pode correr o mesmo harness e publicar as provas.
