Due diligence automation for evidence-heavy reviews

Diligence model

Scope and source authority must be modeled before automation

Due diligence is not one universal checklist. Acquisition, supplier onboarding, investment, partnership, technology and responsible-business reviews ask different questions and may be governed by different law, policy and professional standards. Define the decision and obtain the right legal, financial, tax, security or domain advice. Automation can enforce the agreed process but cannot decide which legal duty applies.

Create an evidence model that connects request, document, entity, period, source authority, extracted claim, finding and issue. A management presentation is useful but not equivalent to a signed contract or independently verified record. A policy states intended control and may not prove operation. Preserve these distinctions in metadata and user language so relevance is not mistaken for authority.

Evidence operations

Keep the data room, extracted facts and requests synchronized

A document register should be the spine of the review. Hash or otherwise identify files, preserve originals and record versions instead of overwriting. Connect each upload to the request it addresses and the entities and periods it covers. If a spreadsheet is a supporting schedule for a report, capture that relationship. Missing and unreadable documents are first-class states, not empty spaces in a folder.

Extraction creates candidate facts, not final conclusions. Store the exact source region and original representation beside any normalized value. Reconcile repeated facts across sources with explicit definitions. If revenue differs because one source is consolidated and another covers one entity, record that rather than merely flagging unequal numbers. Allow reviewers to reject a document classification, mapping or inferred relationship before issue logic relies on it.

• Preserve original files and every materially reviewed version.
• Link uploads to requests, entities, periods and prior issue states.
• Keep normalization reversible to the source expression.
• Distinguish absent evidence from evidence of absence.
• Require review before a low-confidence relationship drives a finding.

Issue management

An issue needs evidence, consequence, ownership and closure criteria

Open issues should be specific enough to resolve. “Financials unclear” is not actionable. Identify the contradictory values, definitions, periods, sources and the decision they could affect. Assign a domain owner and materiality state, then request the smallest additional evidence or explanation capable of resolving it. Keep linked issues separate where they need different expertise.

Closure means the evidence and accountable conclusion satisfy predefined criteria, not that a reviewer clicked complete. Record whether the issue was resolved, mitigated, accepted, reflected in terms, deferred to monitoring or remains open. If later evidence changes a supporting fact, reopen dependent issues and notify prior approvers. The history should show how the review moved, not only its latest state.

• Write issues around a precise inconsistency, gap or risk proposition.
• Link every issue to source evidence and affected decision criteria.
• Set the specialist, due date and required closure evidence.
• Distinguish resolution from acceptance of residual risk.
• Propagate changed facts to all dependent findings and reports.

AI boundary

Use AI to focus expertise without outsourcing judgment

AI can classify documents, extract values and clauses, compare versions, surface inconsistent claims, suggest request coverage and prepare cited summaries. It can rank work for review using rules agreed by domain owners. It should not silently determine legal compliance, financial quality, technical viability or transaction materiality. Those conclusions depend on context, professional standards and accountable expertise.

Design the interface to counter automation bias. Show the source and alternative evidence before the generated interpretation. Indicate whether an item was found, inferred or remains missing. Require named approval for material conclusions and changes. The OECD describes risk-based due diligence in its responsible-business context, and ISO 31000 provides broader risk-management guidance; the exact framework for a review must still be selected for its purpose and jurisdiction.

• Separate machine-extracted fact from machine-suggested finding.
• Keep source evidence visible in the specialist review.
• Test missing, contradictory and adversarial documents.
• Prevent the model from accessing workstreams outside reviewer permissions.
• Measure whether automation improves review outcomes, not only reading speed.