Dos pipelines de due diligence. El mismo modelo, la misma data room, la misma clave de respuestas. Uno detectó 5 de 5 problemas materiales plantados. El otro detectó 3 de 5. Los dos que se le escaparon son justo los dos por los que te despedirían.
Lo esencial
Los tres problemas que ambos pipelines detectaron eran los evidentes: el tipo que un asociado competente marca con resaltador amarillo. Los dos que se le escaparon al prompt único exigían conectar dos documentos entre sí o aplicar conocimiento jurídico externo a una cláusula que a simple vista parece correcta. Esas son exactamente las categorías donde las herramientas de due diligence con IA fallan en silencio, y exactamente las categorías que todo discurso de venta de un proveedor de IA para M&A pasa por alto.
Datos clave
- El prompt único detectó 3/5 problemas materiales plantados; el swarm de 3 agentes detectó 5/5 — ambos con precisión 1.0, mismo modelo (Claude Opus 4.7, contexto de 1M), mismo data room de 30 documentos. El artículo aclara que las cifras están calibradas de forma simulada para demostrar el harness de código abierto.
- El data room de 30 documentos (~13.200 palabras / 24.000 tokens) cabe en una sola llamada con contexto de 1M, dejando ~976K tokens de margen — el tamaño del contexto no era la limitación.
- El swarm ejecutó 32 llamadas al LLM (30 de investigación + 1 de señalización de riesgos + 1 de resumen) a un costo aproximadamente 2-3 veces mayor que el prompt único.
Construimos ambos pipelines, los ejecutamos sobre los mismos datos y publicamos la clave de respuestas.
Por qué hicimos la prueba
Todo discurso de venta de due diligence con IA que hemos presenciado esquiva la misma pregunta: ¿cuál es la arquitectura? ¿Un único prompt gigante saturado de contexto? ¿Un pipeline multiagente? ¿RAG sobre documentos fragmentados? La mayoría de los discursos no lo dicen. La demo es un memo pulido y un dashboard. La arquitectura es 'propietaria'.
Eso es un problema, porque la arquitectura es el producto. Un único prompt saturado de contexto y un swarm de 3 agentes ejecutados sobre el mismo modelo producen memos dramáticamente distintos sobre el mismo data room. Quisimos medir cuán dramática era esa diferencia.
Así que construimos ambos. Mismo modelo — Claude Opus 4.7, contexto de 1M —, mismos documentos, mismo harness de evaluación. Las diferencias en el resultado reflejan la arquitectura del prompt, no la elección del modelo. Un LLM-as-judge evaluó los resultados contra una clave de respuestas con los problemas plantados, a la que sí tenía acceso, mientras que los propios pipelines no.
Una aclaración antes de las cifras: este es un experimento controlado sobre datos sintéticos. Las cifras del pipeline simulado se calibraron para demostrar el harness de principio a fin. Aun así lo publicamos porque el patrón de fallo — el prompt único pierde la vinculación entre documentos y los problemas de conocimiento externo — es lo que creemos que se replica con llamadas reales al LLM, y el diseño del experimento es reutilizable. El código es de código abierto.
El data room
Treinta documentos en markdown, siete categorías, ~13.200 palabras / 24.000 tokens en total. Construido para reflejar la densidad de señal de un data room de una ronda Serie D de una empresa de terapéutica, con nombres de empresa claramente ficticios para que nadie lo confunda con una filtración (Acme Sprockets, NorthStar Therapeutics, Helix BioSystems, Meridian Bio).
Todo el corpus cabe en una sola llamada a Claude Opus 4.7 con contexto de 1M, dejando ~976K tokens de margen. Esto elimina la excusa más común de por qué el prompt único rendiría peor. No le estamos pidiendo al modelo que recupere información de un corpus demasiado grande para su contexto. Todo el data room está en la ventana.
Los cinco problemas plantados
Cinco problemas materiales están plantados en documentos de apariencia ordinaria, no en encabezados, sin anticiparlos. Con dificultad de detección deliberadamente variada:
- Tres problemas de un solo documento, visibles a simple vista: un gatillo de cambio de control en un contrato de suministro, una contrademanda por litigio que supera el 10% del precio de compra, y una salvedad de negocio en marcha en el informe del auditor. Ítems de checklist. Si fallas el checklist, fallas el due diligence.
- Un problema entre documentos: un vacío en la cadena de titularidad de la PI, visible solo al conectar el registro de cesión de PI (que señala a un ingeniero sin PIIA firmado), una licencia principal (que nombra a ese mismo ingeniero como inventor de la plataforma licenciada) y la carta de oferta de ese ingeniero (que dice 'PIIA adjunto' sin ningún anexo). Ningún documento por sí solo contiene la señal completa.
- Un problema de conocimiento externo: una cláusula de no competencia de 2 años a nivel nacional para la Directora Científica, regida por la ley de California. Para saber que carece de valor hay que saber que la Sección 16600 del California Bus. & Prof. Code anula la mayoría de las cláusulas de no competencia para empleados, y que la AB-1076 (vigente desde enero de 2024) añadió además una obligación de notificación.
La clave de respuestas completa con los criterios `must catch` para el LLM-as-judge está en `fixtures/known-issues.md`. No se la mostramos a los pipelines.
Pipeline 1: prompt único
Concatenar todos los documentos. Envolverlos en un system prompt de abogado senior. Una llamada al LLM. Obtener el memo. Así es, por debajo, la mayoría de los discursos de 'usamos un modelo de frontera con contexto de 1M'.
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.`;Una sola llamada al modelo. ~24K tokens de entrada, ~3K de salida, menos de 15 segundos de tiempo real, unos pocos centavos por ejecución. Barato, rápido, estructuralmente simple.
Resultado: 3/5 detectados. Precisión 1.0. Se le escaparon: el vacío en la cadena de titularidad de la PI y la no competencia de California.
Acertó de lleno con la cláusula de cambio de control, la exposición al litigio y la salvedad de negocio en marcha. Un memo limpio y bien citado. Sin alucinaciones. Se veía, sinceramente, bastante bien, hasta que lo comparabas con la clave de respuestas.
Pipeline 2: swarm de 3 agentes
Tres agentes, cada uno con una llamada al modelo separada y su propio system prompt:
- Investigador (30 llamadas en paralelo, una por documento). Resumen estructurado por documento: contrapartes, plazo, términos económicos, lenguaje de cambio de control, disposiciones inusuales, preguntas abiertas.
- Señalizador de riesgos (una llamada). Lee los 30 resúmenes del investigador. Devuelve una lista en JSON de problemas materiales con severidad, justificación y citas de fuente.
- Resumidor (una llamada). Convierte la lista de señalamientos en un memo para el equipo de la operación.
Total: 32 llamadas al LLM. Mayor costo: el investigador paga tokens de entrada 30 veces en lugar de una. El costo total es aproximadamente 2-3 veces el del prompt único, según la verbosidad de la salida.
Fíjate en el campo `sources` del esquema del señalizador de riesgos. El esquema obliga al modelo a atribuir cada señalamiento a uno o más documentos. Esa única decisión de diseño es lo que hace que los problemas entre documentos salgan a la luz: se le pide al modelo que piense a través de los resúmenes, no solo dentro de cada uno.
Resultado: 5/5 detectados. Precisión 1.0.
Qué se le escapó al prompt único y por qué
Esta es la parte que importa. Ambos fallos son estructurales a la arquitectura de prompt único, no fallas aleatorias.
Fallo 1 — El vacío en la cadena de titularidad de la PI
El registro de cesión de PI señala que el ingeniero Wei Lin tiene 'una carta de oferta firmada en archivo pero ningún PIIA contrafirmado registrado — pendiente de seguimiento.' La carta de oferta tiene una línea de marcador de posición que dice `[PIIA adjunto como Anexo A]` sin ningún anexo. La licencia principal, en una carpeta separada, nombra a Wei Lin como inventor de la plataforma central licenciada. Conecta los tres y tienes un problema crítico: es posible que el comprador no sea realmente dueño de la PI por la que está pagando $250M.
El modelo de prompt único puede ver los tres documentos. Simplemente no los conecta bajo una instrucción de 'encuentra todo problema material'. Los contextos largos difuminan la vinculación entre documentos: el modelo produce un excelente escaneo por documento, pero rara vez da el paso extra de preguntarse '¿es el ingeniero del documento X la misma persona que en el documento Y, y eso cambia el panorama?' No hay ningún incentivo en el prompt para hacerlo.
El swarm lo detectó porque la entrada del señalizador de riesgos son resúmenes estructurados por documento con entidades nombradas destacadas. Cuando el prompt de estilo socio ve 'ingeniero con PIIA faltante' en un resumen e 'ingeniero nombrado como inventor' en otro, la conexión está a un solo paso de inferencia, no enterrada en 24K tokens de prosa contractual.
Prueba HAQQ AI gratis
Experimenta la redacción e investigación legal con IA
Fallo 2 — La no competencia inaplicable de California
La Directora Científica tiene una cláusula de no competencia de 2 años a nivel nacional en su contrato de trabajo. Rige la ley de California. Ella vive en Palo Alto.
Para cualquiera que haya leído la Sección 16600 del California Bus. & Prof. Code, la cláusula es, en la práctica, nula. La AB-1076, vigente desde enero de 2024, la endureció aún más: los empleadores deben notificar afirmativamente a los exempleados con este tipo de cláusulas que son inaplicables, o enfrentar responsabilidad adicional.
El modelo de prompt único lo sabe. Pregúntale directamente — '¿es aplicable esta no competencia en California?' — y te lo dirá. Simplemente no saca a relucir ese conocimiento sin que se le pida, bajo una instrucción genérica de 'encuentra todo problema material'. La cláusula parece correcta a simple vista. Nada en el documento en sí grita 'pregunta si soy aplicable.'
El swarm lo detectó porque el system prompt del señalizador de riesgos encuadra al modelo en un rol de socio que aplica un umbral de materialidad a través de los resúmenes, y en ese rol formula preguntas jurisdiccionales sobre cláusulas restrictivas. Con un agente más especializado (un revisor dedicado de derecho laboral, o una llamada a herramienta contra una base de datos de estatutos), esto se vuelve determinista. Con un prompt único genérico, es cuestión de suerte.
Estos no son modos de fallo exóticos. La vinculación entre documentos y el conocimiento estatutario externo son las dos categorías donde el due diligence agrega más valor. También son las dos categorías donde saturar de contexto a un modelo de frontera te da la peor falsa sensación de seguridad, porque el resultado parece exhaustivo.
El equilibrio entre costo y calidad
El prompt único es más barato, más rápido y produce un memo más coherente. En un data room de 30 documentos es aproximadamente 3 veces más barato y 3 veces más rápido que el swarm.
El swarm detecta más, deja un rastro de auditoría por documento y permite intercambiar agentes especializados (regulación de la FDA, ERISA, fiscal, derecho laboral específico de cada jurisdicción) sin reescribir el pipeline.
¿Cuándo justifica el esfuerzo el costo?
- Menos de 10 documentos, operación por debajo de $25M, primera lectura con tiempo acotado: el prompt único funciona bien. La superficie entre documentos es pequeña.
- 30+ documentos, operación por encima de $100M, cualquier cosa antes de la firma: swarm. La diferencia de costo en una operación de $100M es irrelevante frente a un problema material que se escape.
- Industrias reguladas (ciencias de la vida, servicios financieros, defensa): swarm, con al menos un agente especializado para el regulador correspondiente.
- Cualquier cosa por la que perderías tu trabajo si se te escapa: swarm.
En el tamaño de operaciones para el que está pensado, unos pocos dólares extra por ejecución son un error de redondeo frente al costo de que se te escape uno de estos problemas al momento de firmar. El default es el swarm. El prompt único es una herramienta de triaje, no de due diligence.
Qué significa esto si estás comprando IA para M&A ahora mismo
Cuatro cosas. Ninguna favorece a los proveedores.
Uno. No confíes en un 'asistente de due diligence con IA' que no te diga su arquitectura. Si la respuesta a '¿prompt único o multiagente?' es 'propietario,' vete. La arquitectura decide qué se detecta.
Dos. Saturar de contexto un prompt único está bien para revisiones pequeñas y acotadas, y es peligroso para due diligence más profundo. Una ventana de contexto de 1M no sustituye la atención forzada por documento. Solo hace que el modo de fallo se esconda mejor.
Tres. Los problemas entre documentos y de conocimiento externo no van a surgir de 'encuentra todos los problemas materiales', sin importar cuán grande sea tu contexto. Requieren prompts de agentes especializados, llamadas a herramientas contra fuentes autorizadas, o instrucciones explícitas de vinculación entre documentos. Si el producto no puede mostrarte cuáles de estas cosas hace, es que no las hace.
Cuatro. Basa la evaluación en pruebas con problemas plantados, no en impresiones. El memo parece exhaustivo. Simplemente no detecta el vacío de PI. La única forma de saberlo es correrlo contra una clave de respuestas.
Qué construiríamos para HAQQ
Swarm por defecto, con el prompt único como alternativa de ahorro de costos para revisiones pequeñas o de triaje. Agentes especializados para las categorías de fallo que el swarm genérico no cubre: un vinculador entre documentos que enumera explícitamente los mapas de entidad a documento antes de señalar, y un verificador de jurisdicción que etiqueta cada cláusula restrictiva, cláusula de ley aplicable y declaración regulatoria con una verificación de aplicabilidad contra el estatuto correspondiente.
El benchmark de problemas plantados sigue siendo de código abierto. Seguiremos agregando problemas — trampas de cadena de titularidad, desviaciones entre la tabla de capitalización y el 409A, cláusulas MFN ocultas, cartas adicionales que contradicen el acuerdo principal — y publicaremos las cifras cada vez que lancemos un cambio de arquitectura. Si un proveedor quiere afirmar que su producto es mejor, puede correr el mismo harness y publicar las pruebas.
