17. How AI is changing tech due diligence

The deal team had 19 days from first data-room access to investment committee. The target had 140 applications, three ERP instances, 11 cloud accounts, 400 vendor contracts, and a product codebase nobody on the buyer side had seen before.

The first instinct was to ask the technology diligence team to “use AI” and move faster.

That is the wrong starting point. AI can read, classify, compare, summarize, and spot patterns faster than a human team can. It can also make weak evidence look complete, bury uncertainty inside confident language, and turn diligence into a faster version of the same old questionnaire.

The better question is not whether AI should be used. It is where AI should change the diligence operating model without changing accountability for the finding.

The primary decision is this:

Which parts of technology diligence should AI compress, which parts still require expert judgment, and what governance is needed before AI-assisted findings affect price, timing, terms, or the value plan?

AI changes diligence economics when it changes cycle time and evidence quality

In technology diligence, time is not an administrative constraint. It shapes the answer.

When teams have only two or three weeks, they narrow scope, sample fewer systems, accept more management assertions, and focus on the defects most likely to change the deal. That is pragmatic. It also leaves blind spots.

AI can improve diligence economics in four places:

• Scope coverage: more documents, systems, contracts, tickets, code repositories, and architecture artifacts can be reviewed inside the same deal clock.
• Evidence speed: teams can move from raw data-room files to issue hypotheses in hours instead of days.
• Pattern detection: AI can compare similar artifacts and flag outliers, such as unsupported software, recurring incidents, unusual contract clauses, or inconsistent KPI definitions.
• Expert capacity: senior diligence leads can spend more time on judgment, value impact, and negotiation topics if routine reading and classification are automated.

That value is real. But it only matters if the output changes deal decisions. A 40-page AI-generated application summary that does not affect TSA cost, Day-1 risk, one-time investment, or EBITDA timing is not diligence. It is document processing.

The common mistake: treating AI output as diligence evidence

AI output is not evidence. It is a way to process evidence.

This distinction matters because diligence findings need a clear chain:

1. source artifact
2. extracted fact
3. expert interpretation
4. deal implication
5. decision owner

AI can help with the first two steps. It can support the third. It should not own the fourth or fifth.

The most common failure is a subtle one. The team asks AI to summarize application lists, contracts, incident logs, architecture documents, or code scans. The summaries look clean. The report reads well. But nobody can trace the finding back to the exact artifact, line, system export, or management confirmation.

That creates false confidence. The buyer believes scope was covered. The investment committee sees a polished answer. The post-close team inherits the gap.

For AI-assisted diligence, the standard should be simple:

If the finding could change price, terms, Day-1 readiness, TSA duration, or the first-100-day plan, it must be traceable to evidence and reviewed by a human owner.

Where AI should change the diligence workplan

AI should not be applied evenly across the workplan. It has high value in some diligence tasks and limited value in others.

1) Application and technology inventory

AI can accelerate the first-pass classification of applications, interfaces, data stores, hosting models, business ownership, and likely risk areas.

Good uses:

• normalize inconsistent application inventory fields
• group applications by business process, function, geography, or likely owner
• compare application lists against architecture diagrams, CMDB exports, access reviews, and contract schedules
• identify duplicate or overlapping tools
• flag systems with no owner, no hosting detail, or unclear data sensitivity

What still needs expert judgment:

• whether an application is business critical
• whether duplication creates a rationalization opportunity
• whether separation or integration is harder than the inventory implies
• whether a system can be retired without breaking a revenue, finance, supply chain, or regulatory process

AI helps teams ask better questions faster. It does not decide whether the ERP, CRM, MES, WMS, billing platform, or data warehouse is a deal dependency.

2) Contract, license, and vendor review

Technology diligence often suffers from contract volume. AI can quickly identify contract clauses that deserve review.

Good uses:

• extract assignment, change-of-control, termination, renewal, audit, data residency, and minimum-commitment clauses
• compare renewal dates against expected close, Day 1, and TSA exit milestones
• flag vendor concentration across infrastructure, ERP, security, managed services, and product engineering
• identify licenses that may not transfer in an asset deal or carve-out

What still needs expert judgment:

• whether a clause actually applies to the deal structure
• whether the vendor has commercial power to force repricing
• whether license scope blocks integration, separation, or post-close growth
• whether the risk should be handled through price, escrow, consent planning, or a Day-1 workaround

AI can compress legal and commercial triage. It should not replace counsel, procurement, or IT leadership in deciding the negotiating position.

3) Codebase and engineering diligence

For software-heavy targets, AI can speed early codebase inspection. It can help identify languages, frameworks, dependencies, test patterns, security hotspots, repository activity, and documentation gaps.

Good uses:

• summarize repository structure and likely architecture
• flag outdated dependencies, abandoned packages, license issues, and secrets exposure
• compare commit activity against management’s product roadmap claims
• identify test coverage gaps and high-change modules
• cluster technical debt themes from code comments, issue trackers, and pull requests

What still needs expert judgment:

• whether the architecture can support the growth case
• whether technical debt is acceptable, costly, or thesis-breaking
• whether engineering productivity claims are credible
• whether AI has misread generated code, vendor code, or legacy branches as current product logic

AI is useful for faster inspection. The investment conclusion still depends on experienced product, engineering, security, and architecture review.

4) Cyber, data, and risk signal detection

AI can connect signals across artifacts that are often reviewed separately: incident logs, vulnerability scans, IAM exports, SOC reports, data dictionaries, privacy records, and architecture documents.

Good uses:

• cluster recurring incident types and aging issues
• compare privileged access exports against policy claims
• identify systems holding sensitive data without matching control evidence
• spot inconsistent KPI definitions and data lineage gaps
• summarize open security findings by owner, system, severity, and age

What still needs expert judgment:

• whether control gaps block buyer connectivity
• whether data issues delay value capture
• whether a cyber finding should change terms or require pre-close remediation
• whether missing evidence means low risk or low visibility

AI can help find the smoke. It cannot decide whether there is fire, whether the buyer should connect environments, or whether the model needs to move.

What goes wrong when AI is used badly

AI can make diligence faster. It can also make bad diligence look complete.

1) Coverage expands, but confidence is not calibrated

The team reviews 1,000 files instead of 100. That sounds better. But if the outputs are not tagged by source quality, confidence level, and expert review status, the team may treat weak material as strong evidence.

The mechanism is simple: AI increases volume faster than governance increases discipline.

The consequence is an investment committee pack with more findings but less clarity on which ones are proven, assumed, or still open.

2) The tool repeats management’s version of the truth

If AI is pointed mainly at management presentations, policy documents, and high-level process slides, it will produce a cleaner version of management’s narrative. That is not independent diligence.

For example, a target may state that MFA is deployed, the ERP is single instance, vendor contracts are transferable, or reporting is automated. AI can summarize those claims. It cannot validate them unless the team also provides exports, logs, contract text, system screenshots, and reconciliations.

The consequence is a faster path to the wrong answer.

3) Data-room security and confidentiality are treated as an afterthought

AI tools create new operating risks: upload restrictions, data retention, model training terms, privilege control, prompt logs, cross-client contamination, and regulated data exposure.

In a live deal, the target’s data-room rules, clean-team requirements, customer confidentiality obligations, and securities-law constraints may limit what can be processed and where.

The consequence is not only legal risk. It can damage seller trust, slow access, and force the buyer to redo work in a controlled environment.

4) The team automates work before defining the decision

AI is most useful when the diligence question is precise. It is least useful when teams ask broad prompts such as “analyze the technology function” or “find risks in these files.”

That produces a long list of observations with no deal spine. The team still has to decide which issues affect EBITDA, cash, terms, timing, Day-1 stability, TSA exit, or value capture.

The consequence is a busier diligence process, not a sharper one.

Evidence asks for AI-assisted diligence

The evidence plan should change when AI is used. Teams should request artifacts that support machine processing and human verification.

1) Structured system and application exports

Ask for application inventory, CMDB exports, architecture repository exports, integration lists, data classification fields, hosting information, owner fields, and usage or cost data.

Why it matters:

AI can normalize and compare structured inputs quickly. It performs worse when every answer is buried in a PDF or slide.

2) Source documents behind management claims

Ask for the artifacts that prove the claims in the management deck: IAM exports, endpoint coverage, vulnerability trackers, contract text, ERP instance lists, cloud account inventories, ticket trends, uptime reports, and KPI dictionaries.

Why it matters:

AI should compare claims to operating evidence. If it only reads the claims, the process has not improved diligence quality.

3) Data-room processing rules

Ask the seller, legal team, and deal counsel what can be processed by AI, where it can be processed, who can access outputs, whether prompts and outputs are retained, and whether customer, employee, or regulated data must be excluded.

Why it matters:

The AI workflow is part of diligence governance. It cannot be separated from confidentiality and clean-team controls.

4) AI output traceability requirements

For each AI-assisted workstream, require source links, document IDs, page references, extraction dates, confidence flags, reviewer names, and unresolved questions.

Why it matters:

Traceability turns AI output into reviewable work product. Without it, the team cannot defend a finding or hand it to post-close execution.

5) Expert review logs

Ask each workstream lead to mark which AI outputs were reviewed, which were rejected, which were validated by source evidence, and which remain assumptions.

Why it matters:

AI should reduce reading time, not remove accountability. A review log makes that accountability visible before findings reach the deal model.

Decision triggers that should change the diligence approach

AI should change the workplan only when the task and risk profile justify it.

Trigger 1: Data-room volume exceeds what the team can review manually inside the deal clock

If the team has more than roughly 300-500 relevant technology artifacts and less than three weeks to report, use AI for first-pass classification, clustering, and issue extraction.

What it changes:

• expand document coverage beyond the usual sample
• require source-linked outputs for every material finding
• move senior experts from first read to issue review and implication testing

Trigger 2: The target has more than 75 applications or more than 10 material interfaces

If the application estate is broad, use AI to normalize inventories, identify missing fields, compare sources, and group systems by business process.

What it changes:

• move from anecdotal application review to coverage-based triage
• isolate ERP, CRM, billing, HRIS, WMS, MES, data, identity, and customer-facing systems early
• identify where interviews should focus before the first management session

Trigger 3: The deal depends on software product quality or engineering throughput

If product scalability, roadmap delivery, AI product claims, or engineering efficiency is part of the investment thesis, use AI-assisted code and repository analysis. Do not rely on management demos alone.

What it changes:

• request repository metadata, dependency manifests, issue trackers, release history, and test evidence
• separate generated, archived, vendor, and production code before drawing conclusions
• require engineering expert review before any finding affects valuation

Trigger 4: AI outputs cannot be traced back to source artifacts

If the tool or process cannot provide source references for material findings, do not use AI output in the investment committee pack as evidence.

What it changes:

• treat outputs as hypotheses only
• require manual validation for price, terms, timing, and Day-1 findings
• limit AI use to internal triage until traceability is fixed

Trigger 5: Deal data includes regulated, customer-confidential, or clean-team restricted information

If the data room contains health, payment, employee, customer contract, export-controlled, or competitively sensitive information, require legal and clean-team approval before processing it with AI.

What it changes:

• restrict processing to approved environments
• exclude sensitive fields where possible
• keep prompt and output logs inside the agreed deal perimeter
• document who reviewed and approved the workflow

How the best teams govern AI in diligence

The best teams do not create a separate AI diligence track. They embed AI into the normal diligence spine.

They start with the decisions that matter:

• Can we underwrite the value case?
• Can we connect or operate safely on Day 1?
• Can we exit TSAs on the timetable assumed?
• Can we capture cost, growth, or working-capital value in the first 100 days?
• What needs to change in price, terms, funding, or governance?

Then they assign AI to bounded tasks with clear owners.

Define the AI use case before opening the data room

Each use case should have a short charter:

• question to answer
• artifacts in scope
• artifacts out of scope
• output format
• required source references
• human reviewer
• decision it supports

If a use case does not support a deal decision, cut it from the plan.

Separate hypotheses from findings

AI is good at generating hypotheses. Diligence needs findings.

A practical status model helps:

• Hypothesis: AI identified a pattern or issue, but no human has validated it.
• Evidence-backed: source artifacts support the point, and a reviewer has checked the extraction.
• Management-confirmed: the target has confirmed the fact or provided additional proof.
• Deal-impacting: the workstream lead has tied the issue to price, terms, timing, risk, or value capture.

Only the last two should shape the investment committee narrative.

Build a source-linked issue register

Every AI-assisted workstream should feed the same issue register used by the diligence lead. At minimum, include:

• issue statement
• source artifacts
• affected systems, contracts, or data domains
• confidence level
• reviewer
• value impact
• open questions
• required management follow-up
• decision deadline

This keeps AI from creating a parallel universe of findings that never reach the deal plan.

Use AI to prepare sharper interviews

The biggest near-term benefit may not be report writing. It is better management sessions.

AI can compare documents before the first call and identify contradictions:

• the application inventory says one ERP; architecture diagrams show three.
• the cyber policy says quarterly access reviews; IAM exports show dormant privileged accounts.
• the contract schedule says key systems are transferable; contract text requires vendor consent.
• the KPI deck shows automated reporting; data lineage shows manual spreadsheet steps.

Those contradictions make interviews more productive. They also reduce the risk of spending scarce management time on generic questions.

How to decide what AI should not touch

Some diligence work should be kept outside AI workflows unless the governance is clear.

Use a higher bar for:

• employee records, payroll data, and HRIS extracts
• customer-level data, pricing, contracts, and protected health or payment data
• legal advice, deal negotiation positions, and draft term language
• clean-team restricted material in competitive processes
• privileged security findings that could create disclosure or notification issues
• proprietary source code when the seller restricts external processing

The rule is not “never process sensitive data.” The rule is that the buyer must know the data class, approved environment, retention policy, access rights, and review owner before processing begins.

What this means for diligence scope

AI does not remove the need to choose. It changes what a well-scoped diligence effort can cover.

For a small platform acquisition with one ERP, fewer than 50 applications, no software product, and clean contract schedules, AI may add speed but not change the answer. Use it selectively for document triage and evidence extraction.

For a carve-out with shared systems, short TSA windows, broad application dependency, and thin documentation, AI can materially improve coverage. Use it to map dependencies, flag missing fields, and prepare targeted management asks.

For a software or data-heavy target, AI should be part of the diligence design from day one. Use it for repository analysis, dependency review, issue clustering, and data lineage checks, with expert review before findings reach the model.

For a highly regulated or clean-team process, AI may still be useful, but governance comes first. The approved environment and processing rules may define the scope more than the tool capability.

Monday morning actions

The next diligence cycle should start with five actions.

First, the diligence lead should identify the 5-7 deal decisions where technology findings could change price, timing, terms, or the first-100-day value plan.

Second, each workstream lead should define one or two AI use cases tied to those decisions. Avoid broad prompts. Use bounded tasks such as contract clause extraction, application inventory normalization, IAM gap detection, repository triage, or KPI lineage comparison.

Third, legal, deal operations, and the buyer’s security owner should approve the AI processing rules before files are uploaded or prompts are run. Name the tool, data classes, retention rules, access rights, and clean-team restrictions.

Fourth, the team should require source-linked outputs and a review log. No source, no finding. No expert review, no deal implication.

Fifth, the diligence report should label AI-assisted findings by status: hypothesis, evidence-backed, management-confirmed, or deal-impacting.

AI can compress the diligence clock. It can expand what teams see before signing. It can also create a faster path to false certainty. The teams that get value from it will not be the ones that automate the most work. They will be the ones that connect AI to the deal decisions, govern the evidence, and keep expert judgment where the economics are decided.