How to Commission AI Due Diligence Around an Investment Question

Commission AI technical due diligence by naming the investment question, the evidence needed to answer it, and the limits of authorised access. Agree how the reviewer will select cases, examine operating effort, and report uncertainty before work starts. The deal team needs to see which conclusions hold, which depend on management's account, and what it still can't establish.

Write a question that can change the decision

“Review the AI” leaves the reviewer to guess what matters to your investment thesis. Start with an uncertainty and the decision it affects. For example: can the company onboard its next group of enterprise customers without increasing founder-led configuration work at the same pace?

That question connects technical design to delivery capacity. It directs attention to customer-specific code, configuration, permissions, implementation records, and the people who resolve difficult deployments. It also establishes why a model benchmark alone can't answer the brief.

For a PE acquisition, the question may concern an internal workflow: does management's automation plan account for exception handling and continuing staff coverage? For a venture investment, it may concern product repeatability or a dependency that limits customer deployment. State the target workflow and business population in either case.

Write down the evidence that would change your view. If recent deployments use the same maintained connector with bounded configuration, that supports a different delivery assumption from deployments that need undocumented founder intervention. The reviewer should explain what each observation establishes and where it falls short.

The technical diligence questions guide can help identify the initial uncertainties. Choose the material questions for this assignment rather than giving every topic equal review time. The investment team still owns the investment decision and any change to its assumptions.

The method below is our proposed commissioning approach, with an illustrative onboarding example. It isn't a reported client engagement. Waypoint offers AI technical due diligence; apply the same evidence and independence questions to our work.

Agree access and consent before the review

Put the investment sponsor, target contact, and reviewer into an agreed information-sharing process. Name who can authorise document access, technical sessions, customer contact, and any controlled testing. Specify the reporting audience and the deadline for making evidence available.

Target agreement doesn't automatically establish permission to disclose every customer record or third-party document. Ask the target's responsible owners to confirm the permitted material and restrictions. Request an approved export, redacted trace, or supervised demonstration when those can answer the question with less disclosure.

Define the reviewer's environment and tools. Identify who can read the material, where copies go, and when access and retained copies end. If the reviewer proposes an AI assistant for document analysis, agree that use explicitly, including the service configuration and handling terms.

The OAIC's commercial-AI guidance asks organisations to consider suitability, testing, oversight, privacy and security risks, and who can access inputs or generated information. Use those questions when assessing proposed review tools, with the responsible privacy advisers addressing the actual handling arrangement.

Keep production changes outside the diligence permission. Source inspection, supervised replay, a load test, and a change to live configuration each need a clear boundary. Agree a test environment, allowed actions, and stop conditions before any active testing.

Where access is unavailable, record the reason and an alternative. A supervised view can answer a narrow question while limiting independent reproduction. Describe that limitation in the final finding rather than presenting the substitute as equivalent evidence.

Build a claim-to-evidence schedule

Translate each investment question into a short schedule: management's claim, requested evidence, review method, source owner, and expected limitation. This helps the target prepare relevant material and lets the sponsor see early where the assignment may stall.

A venture-capital discussion about AI data-room analysis raises a practical concern about verifying claims rather than relying on a summary of supplied documents. Treat that discussion as a reader question, not evidence of how often reviews fail. Ask your reviewer how each material conclusion will connect to an inspectable source.

For the onboarding example, request the deployment inventory and the rule used to identify completed implementations. Then ask how the reviewer will choose examples from that population. A hand-picked success can show a working route, but it doesn't describe the distribution of delivery effort.

Connect artifacts that refer to the same deployment. A release record, implementation ticket, support history, and interview can illuminate different parts of the work. Conflicting dates or definitions need explanation before the reviewer combines them into a finding.

Give each evidence item an identifier, date, scope, and access note. A screenshot of a dashboard may support what appeared on that screen; it may leave the underlying event definition unverified. Preserve that difference when drafting the report.

Allow a discovery checkpoint to revise the schedule. If the target has no deployment-level labour records, the reviewer may need to reconstruct selected cases through tickets and interviews. Agree the narrower conclusion that reconstruction can support before spending the remaining review time.

Set evaluation coverage and sampling limits

Specify what a successful task means in the operating workflow. A generated answer, an accepted draft, and a correctly completed transaction are different outcomes. Record human correction, blocked actions, and work returned to staff alongside the system's output.

Ask for the evaluation set's origin, selection process, scoring rules, and relationship to actual users. Identify cases the developers used while changing prompts or code. A later replay on those cases can't establish performance on unseen work.

Agree how the review covers difficult inputs and consequential failures. For an enterprise document product, that may include missing source material, an outdated document, and a user who lacks permission to see the answer. Select cases because they test a relevant claim or failure consequence.

The NIST AI RMF Core calls for documented test sets and metrics, measurement under conditions similar to deployment, and explicit limits on generalisation. It also asks teams to document risks they can't measure. Those principles support a review that states its test conditions and unresolved coverage.

Separate a purposeful failure probe from a representative sample. A reviewer can deliberately select a permission edge case to examine a control. That result doesn't estimate how frequently the case occurs in production. Conversely, a sample with no such case doesn't establish the control works.

If the timetable allows only a small review, request the inspected cases and their selection rationale. Don't accept a population-wide reliability claim from that sample without a defensible sampling and measurement basis. The evaluation-set diligence guide covers the underlying evidence in more detail.

Match operating economics to the same workload

Ask the reviewer to reconcile activity and effort for the same customer group and period. Start with the definition of a completed customer task. Trace how usage records relate to model calls, retries, infrastructure, human review, and support.

Separate customer onboarding from continuing operation. In the illustrative enterprise product, a connector may work consistently after launch while still requiring extensive setup for each customer. The investment question about repeatable delivery needs both parts of that record.

Ask how the company allocates shared costs and records founder time. A provider invoice can establish a bill without showing which workload caused it. An interview can reveal omitted work without providing a reliable total. Keep measured allocations, reconstructions, and assumptions separate.

Include failed and abandoned work in the population definition. Counting only accepted output can hide the effort behind attempts that staff repeated or completed manually. Explain which costs belong to the selected work and which the company can't yet attribute.

For a growth scenario, vary the drivers the review actually identified: task mix, customer-specific configuration, review demand, and provider constraints. Label the scenario as a projection. Higher volume doesn't prove that support effort or failure frequency will follow the same pattern.

Coordinate the definitions with the financial diligence team. The technical reviewer can explain the operating evidence and its limits; the responsible financial advisers assess accounting treatment and the deal team's model. Agree who resolves a mismatch between product events, delivery records, and financial reporting.

Keep missing evidence and confidence visible

Give every material question a clear evidence status. Distinguish a claim the reviewer observed under stated conditions, a management assertion, an unresolved contradiction, and an area the review couldn't inspect. A single overall score can hide these differences.

Explain confidence with reasons. It may depend on the completeness of the population, the recency of the records, independence of the source, and ability to reproduce a result. Avoid precise confidence percentages without a method that supports them.

An unavailable record doesn't prove that a control failed. It limits what the reviewer can establish about that control. A directly observed failure warrants its own finding, including the conditions and impact; keep the two situations distinct.

Record contradictory evidence without averaging it away. If an interview describes automatic deployment but tickets show repeated manual intervention, ask management to explain the difference. A later correction may resolve the discrepancy or narrow the original claim.

Attach a next evidence request to an unresolved question, with an owner and the decision it informs. That lets the sponsor decide whether to extend the review, seek another source, or carry the uncertainty into its deliberations. Deadline pressure doesn't change the evidence status.

Disclose prior work and commercial interests before accepting the assignment. A reviewer who built the target's integration has first-hand knowledge and an independence limit. Proposed follow-on delivery also needs disclosure so the sponsor can assess the relationship.

Specify a report the deal team can interrogate

Ask for a decision briefing supported by a traceable findings record. Each material finding needs the question, inspected source, observation, interpretation, limitation, and further evidence that could change the conclusion. Keep source access appropriate to the audience.

The following schedule shows what to request for the illustrative onboarding question. Adapt the evidence to the target's maturity and the actual decision. These are proposed review requirements, not findings about a company.

Agree a factual-response process with the target. Keep management's response distinct from the reviewer's conclusion and preserve material unresolved disagreements. Give the investment sponsor an early route for issues that may affect its decision timetable.

State the evidence cutoff and reviewed product version. A change after testing can alter the result. Identify material changes that need re-examination before the sponsor relies on an earlier finding.

Keep technical findings within the agreed discipline. Legal interpretation, financial audit, specialist penetration testing, and investment recommendations need their responsible owners. A technical diligence report can identify dependencies on that work and explain what its own review established.

Send a bounded commissioning brief

Send the reviewer the investment question, target workflow, decision date, proposed access, and named contacts. Include the claims you need to examine and known restrictions. Ask for a work plan that identifies the evidence dependencies and expected limits before agreeing the assignment.

Define the deliverables and review audience. Request an early access checkpoint, an escalation route for material issues, and a briefing that lets the deal team challenge the findings. Establish who approves a scope extension if the initial evidence changes the question.

Finally, specify what happens to access and supporting material when the review ends. Any post-investment remediation has its own scope, sponsor, and permissions. Bring this brief to an AI technical due diligence discussion so the first conversation can establish what the evidence and timetable allow.