AI tools in technical due diligence: what they can and cannot do

A deal team gets access to a data room with a few hundred documents and a repository with several hundred thousand lines of code. Someone asks the obvious question: could a model read all of this and tell us what is wrong? The tools are good now. They summarize contracts, explain code and write fluent reports in minutes.

The honest answer is that a model can do a real share of the reading, and none of the judging. It can shorten the path to the right questions. It cannot stand behind an answer, because it has not seen what it is talking about in the way a buyer needs. A technical review exists to put evidence under a price, a structure and a plan for the first year. Fluency without evidence is the most expensive kind of mistake in that setting, because it looks finished.

This piece is for buyers, sponsors, lenders and the advisors around them who wonder whether AI changes what a technical review is, what it costs and how far to trust one. It describes where these tools help a reviewer, where they fail, how deal data has to be protected, and what to ask any provider who uses them.

What a model actually reads

A language model works from the text it is given and the patterns it learned in training. In a diligence that means the files someone chose to feed it: code, documents, exports, interview notes. It does not log in to the cloud console. It does not see the billing account, the admin list or the backup that was never restored. It does not know which documents are missing from the data room, and it does not notice that the lead engineer hesitated before answering a question about the release process.

That limit matters more in technical diligence than almost anywhere else. Many of the findings that change a deal live outside the written record: a domain registered to a former contractor, a production password shared by the whole team, a service that only one person can deploy. The six layers we read in every review (ownership, infrastructure, data, code, security and team) are full of facts that exist in systems and in people, not in documents.

Where AI tools help a reviewer

Used with care, model-based tools take time out of the reading and leave more of it for checking. These are the tasks where they earn their place.

Reading a large codebase for structure

A model can walk a repository and describe its shape quickly: the main modules, how requests flow, where billing, sign-in and data access sit, which parts look generated or abandoned. That gives a reviewer a map before the line-by-line reading starts. The map is a hypothesis. It tells the reviewer where to look, not what is there.

Listing dependencies and licenses

Dependency and license inventories are pattern work, and automated tools of every kind are good at pattern work. A model can also explain in plain language what an unfamiliar package does and why a copyleft license such as the AGPL might matter for a hosted product. The inventory still needs a person to confirm what is actually shipped, what is only used in development, and whether a flagged license creates an obligation in this product. That last question also goes to counsel.

Summarizing documents

Architecture notes, vendor contracts, policies, incident write-ups and old audit reports can run to hundreds of pages. A summary helps a reviewer decide what to read in full first. It is a reading aid, not a substitute for the document, and anything a finding will rest on is read in the original.

Drafting questions

Turning a first pass through the data room into a sharp question list for management is a real use. A model is good at noticing that a document mentions a system nobody has described, or that a policy refers to a process with no evidence behind it. A reviewer then cuts the list down to the questions that could change the deal.

Comparing claims across documents

This may be the most useful task of all. The deck says the platform runs in one cloud; the invoices show two. The privacy notice says customer data stays in the United States; a vendor contract names a processor elsewhere. A model can line up statements across many files and flag where they disagree. Each flag is a lead to follow, and some of them turn out to be wording rather than fact.

Where they fail

The failures are not rare edge cases. They come from how these systems work, and they tend to look like good work.

• Confident wrong facts. A model can state a framework version, a license or a support date with full assurance and be wrong. The sentence reads the same either way.
• Filling gaps with plausible numbers. Ask for an estimate of cloud cost, team size or effort to upgrade, and a model will produce one. If the input was thin, the number came from general patterns, not from this company. Once it is in a draft, it starts to look like a finding.
• Agreement between models is not verification. Running the same files through a second or third model and getting the same answer feels like confirmation. It is not. The models read the same material and share many of the same habits, so they can agree and be wrong together. Our engineering partner PERETZ explores this effect, from the side of how outsiders read a company, in Four AIs Agreed. We Still Hadn't Verified Anything.
• No access to what is not written down. Who really knows the billing code, which workaround keeps the nightly job alive, why a migration stopped halfway: these are answered in conversations and in systems, not in files.
• No judgment of people. In a walkthrough, a reviewer watches whether an engineer can open the deployment pipeline and explain it, or talks around it. Whether an answer is rehearsed, whether a team is stretched, whether one person carries a system alone: a transcript loses most of that.
• Severity without context. A model can label something critical. It does not know what the buyer plans to do with the product, what the contracts promise, or what the deal can absorb. Severity is a judgment about this deal, made by people who understand it.

Task by task: tool and reviewer

The table sets the common tasks side by side. The right column is the part that does not go away.

The rule: evidence a person has seen

Our approach page already says it about automated scanning: tool output is evidence, not a finding, and every finding is checked by a person. The same rule applies to any AI-assisted reading, with more force, because model output is written in the same confident prose as a finished report.

In practice the rule means three things. First, every finding in the findings register cites a specific source: a file and line, a console screen, an invoice, a contract clause, a statement in an interview with the date. Second, a person looked at that source directly, not at a description of it. Third, numbers carry their assumptions. A cost to fix of two to four engineer weeks says who does the work and what it assumes about the code, so the reader can disagree with an assumption rather than with a number from nowhere.

A model can help find the file. It cannot be the evidence. If a reviewer cannot point to what they saw, the item is a question for management, not a finding, and the report should say so. The same applies to the gaps: what the reviewer could not see belongs on the first pages, whatever any tool inferred about it.

Deal data and where it may go

Confidentiality is where AI use in diligence most often goes wrong without anyone noticing. A seller hands over source code, contracts, customer lists and sometimes samples of personal data under a non-disclosure agreement. Pasting any of that into a tool that keeps inputs, lets its staff read them, or uses them to train future models can breach that agreement and expose the seller's most sensitive assets. The reviewer may never know it happened.

Our access protocol sets the frame: read-only, named and time-limited accounts; no copies of personal data, which we look at in place or as masked samples; a list of everything received; access closed at the end with written confirmation of what is kept. A tool that stores deal material outside that frame works against all of it. Whatever tools a reviewer uses, the same promises have to hold.

If a provider uses AI tools on your deal, or on a seller's material, ask them in writing:

• Which kinds of material go into which tools, and whether code and data room documents are ever sent to an outside service.
• Whether that service keeps inputs, for how long, and whether it uses them to train or improve its models.
• Where processing happens and which subprocessors are involved.
• Whether the use is covered by the NDA with the seller, and whether the seller has been told.
• Whether personal data is ever included, and how that squares with the data processing terms in place.
• How deal material is deleted from every tool at the end of the engagement, and who confirms it.

Sellers should ask the same questions of every party that gets access, and can set limits in the NDA or the data room rules. Whether a given use breaches a given agreement is a question for counsel; the facts above are what counsel needs to answer it.

Reading the report, choosing the provider

Signs of a report that stands on evidence

A report drafted with AI help is not worse by default, and a report written entirely by hand is not better by default. What matters is whether it stands on evidence. A few signs help a buyer tell the difference.

• References on every finding. Each item points to something specific you could ask to see. Findings without a source are opinions.
• Facts about this company. Generic paragraphs about best practice, true of any software company, suggest the reading stayed on the surface.
• Numbers with assumptions. Cost ranges and timelines state who does the work and what they assume. Round numbers with no basis are a warning.
• Limits stated plainly. A good report says what was not reviewed and why. A report that seems to know everything, including systems nobody was given access to, deserves a closer look.
• Consistency with your own data. Spot check two or three findings against the data room. If a cited document does not say what the report claims, ask how the finding was made.
• People behind it. You should be able to talk to the reviewer who wrote a finding and get a direct answer about what they saw.

The same habits help when reading the seller's own materials, which may also have been drafted with AI help. A technical section of the data room that reads well but cites nothing is a reason to ask for the underlying documents.

Questions for any diligence provider

A buyer comparing providers can use this checklist in the first call. The answers say more about the quality of the work than any claim about tools.

• Do you use AI tools in a review, and for which tasks?
• Which tasks are never delegated to a tool?
• How is each finding tied to evidence, and who checks that the evidence says what the finding claims?
• Has a person read the code where billing, sign-in and data access sit?
• Do your people run the management sessions and the walkthroughs themselves?
• How do you produce cost-to-fix estimates, and what assumptions do you state?
• Does any deal material leave the access you are given? Where to, and on what terms?
• Do any tools you use keep inputs or train on them?
• How do you delete deal material at the end, and do you confirm it in writing?
• Who signs off the report, and can we speak to the people who did the work?
• What does the report say about what you could not see?

Speed is a fair question too, but the answer should not be "days" for a full review of a real product. Tools can shorten the reading. They do not shorten the access requests, the management sessions, the walkthroughs or the time it takes to check a finding properly. Our view on how long a review takes and why is in the FAQ.

What this means for your deal

AI tools make a careful reviewer faster at reading and better at spotting contradictions. They do not make a review that skips access, conversations and checking any more reliable. Where a model produced the picture alone, a buyer is reading a well-written guess. The value of a technical review is still a set of findings a buyer can rely on in a negotiation and act on after closing, each tied to something a person has seen, with a severity and a cost.

If you are a buyer inside exclusivity, technical due diligence reads all six layers in full, with every finding rated, costed and referenced. If the question is whether to go further at all, a red-flag memo looks for deal-level risk first. For the wider picture of what a buyer-side review covers, see technical due diligence for buyers; if the target itself sells AI, AI diligence: product or wrapper covers that case.

Questions