A data room in a mid-sized transaction quickly runs to several thousand pages. Annual accounts, shareholder agreements, leases and employment contracts, litigation, licences. The job of due diligence is not to read all of it but to find what changes the price or the structure.
Language models look made for exactly that. And this is exactly where most implementations fail.
The problem is not the summary
A model summarises a contract reliably. The question is what an advisor is supposed to do with that summary.
Telling a client that the data room contains a change-of-control clause means being able to say, when asked, in which contract, in which section, and in what wording. An answer that cannot do that is at best a pointer to go and look, and at worst an assertion that collapses in the meeting.
So the decisive property of such a system is not the quality of its phrasing but whether every individual statement can be evidenced.
What that means for the architecture
Evidence is not a feature you retrofit. It comes from the answer resting on retrieved passages rather than on the model’s memory.
In practice: documents are OCRed, split into meaningful sections and stored as vectors. Every question first retrieves which sections are relevant. Only those sections are handed to the model along with the question, and the answer points back at them.
That changes what matters in the build. The model does not decide usability; the retrieval step before it does. If the wrong sections come back, the best model only states the wrong basis more convincingly.
Where it actually gets hard
Three things consume most of the time in these projects, and none of them is wiring up the model.
Splitting the documents. A contract is not prose. Cut it by character count and you routinely separate a clause from its definition, leaving both halves meaningless on their own. Section boundaries have to follow the structure of the document.
The language of the field. A search that does not connect “non-compete” with “restrictive covenant” misses half of it. Terminology, abbreviations and the variety of contract language belong in the retrieval logic, not in the prompt.
Handling the absence of an answer. A system that answers a question with no basis in the data room is more dangerous than one that finds nothing. “Nothing on file” has to be a permissible and frequent result.
What realistically comes out of it
The first pass over a data room shortens considerably, because the obvious passages no longer have to be found, only checked. The judgement itself stays entirely with people, and that is not a limitation but the point: the time gained goes into examining the items that are actually negotiating material.
Anyone promising more has either not understood the liability involved or not built the chain of evidence.
