The work we cover
AI technical due diligence examines the evidence behind a company's product and delivery claims. We work with VC, PE, and family-office teams on the technical questions that affect a decision. The review connects observed behaviour, architecture, data, customer deployment, and operating effort to the investment team's stated concerns.
We cover product capability, evaluation quality, model and supplier dependency, data provenance, integration, reliability, scaling, technical ownership, and operating economics. For an AI-enabled established business, the scope can also examine internal workflows and the credibility of a proposed improvement. The target and decision determine which areas need attention.
A demonstration establishes what happened in that demonstration. Diligence asks how the system performs on representative work, what human effort supports it, and what changes as customers or volume increase. We distinguish repeatable product behaviour from custom delivery and management assertions from inspected evidence.
How we deliver
We agree the investment questions, deadline, information request, authorised access, and reporting audience before starting. The target's consent and technical contacts are important dependencies. A compressed timetable changes what can be established; it does not turn missing evidence into a clean finding.
The review follows a real product task through the system. We inspect the input, data access, model behaviour, tools, validation, human intervention, and resulting customer outcome. Where permitted and useful, we reproduce representative examples and examine failure cases rather than relying entirely on a selected walkthrough.
We assess evaluations for coverage, provenance, and relevance. A test set must relate to the intended users and tasks. We examine how it was selected, whether difficult cases are represented, and what happens after a model or retrieval change. A benchmark can support a narrow claim without proving customer value or production reliability.
We also trace the effort and dependencies behind delivery. That includes provider limits, customer-specific integrations, support load, founder concentration, and cost allocation. Security and data-rights questions are recorded with their evidence and specialist dependencies. Penetration testing and legal interpretation require separately agreed specialists.
An illustrative engagement
This example describes an illustrative review, not a target or client result. An investment team is assessing an AI document product whose management reports strong automation and attractive margins. The principal question is whether delivery and support effort rises materially with each enterprise customer.
We agree access to representative deployments, architecture, evaluation history, usage, provider invoices, and implementation records. The review separates automatic processing, staff correction, customer configuration, and founder intervention. We inspect whether the cost information covers the same customers and period as the claimed results.
The findings describe what the inspected evidence supports, where selection limits confidence, and what remains unavailable. A repeatable deployment pattern and a one-off integration have different implications. The investment team receives the unresolved questions and the evidence that would change each conclusion, with management responses kept distinct from observed findings.
How we measure value
The engagement succeeds when it answers the agreed decision questions within the available evidence and records the limits clearly. Findings identify the claim examined, source, observation, implication, and follow-up. Material uncertainty remains visible in the decision briefing.
For performance, we examine accepted task completion, error consequences, coverage, and human intervention. For economics, we connect usage, model and infrastructure cost, implementation labour, and support to the same population. Estimated future costs are labelled as assumptions and tested through scenarios where the evidence permits.
For scale, we distinguish observed production load, a controlled test, and an untested forecast. We inspect tenancy, permissions, release and recovery, queue behaviour, and responsibility for incidents. The existence of cloud infrastructure does not establish that the application or support operation scales economically.
We also record conflicts of interest and prior involvement. A review of delivery we previously performed has different independence limits from a review of another supplier's work. Your deal team decides how to use the findings alongside commercial, financial, legal, and other specialist diligence.
What your team owns
The deliverable is a decision-focused findings record and briefing, with material dependencies, unanswered questions, and recommended follow-up work. Supporting material is handled under the agreed confidentiality and access arrangements. We avoid including unnecessary target information in wider distribution.
We walk the deal team through the significance of findings, the strength of evidence, and the consequences of unavailable access. Post-deal remediation can be translated into a delivery plan, but it has its own sponsor, access agreement, and acceptance criteria. Diligence does not automatically authorise changes to the target's systems.
Questions before you start
Can you work to a deal deadline? We scope backwards from the decision date and available access. The output states what was examined and what the time or evidence prevented us from establishing. Bring the deadline and principal questions to the first discussion.
Is this a financial audit or investment recommendation? No. We provide technical and operational evidence to support your team's decision. Financial audit, legal opinions, valuation, and investment decisions remain with the responsible advisers and investment team.
What follows after acquisition or funding? A PE sponsor and company leadership can use portfolio AI delivery to scope operational work. A venture-backed operator building its product or customer integrations can use AI product engineering.