What is AI due diligence, and when do you need one
AI due diligence is an independent assessment of a company’s AI systems, claims, and risks, run before an investment or acquisition. It answers four questions the pitch deck will not: does the AI actually work in production, is it defensible, what does it cost to run at scale, and what could blow up later, legally or technically. Funds commission it when the valuation depends on the AI being real.
That last clause matters. Plenty of companies use some AI somewhere. What triggers a dedicated review is a thesis that prices the AI itself: a product sold as an AI product, a margin story built on automation, a roadmap that assumes capabilities the team has not shipped yet.
What AI due diligence covers
A serious review looks at six things. Production reality: what share of the advertised AI runs in production, on real traffic, versus in demos. Evaluation practice: how the team knows quality holds when prompts, models, or data change. Architecture and dependencies: what the system is built on and what happens when a model provider changes prices or deprecates an API. Unit economics: the full cost of serving a request and the gross margin at scale. Data rights: where training data came from and what the contracts and GDPR allow. Team: who holds the knowledge, and how concentrated it is.
Defensibility runs through all of it. Since the underlying models are available to everyone, the question is what survives commoditization, a topic we treat separately in evaluating an AI moat.
How it differs from classic technical due diligence
Classic tech DD asks whether the software is well built: architecture, code quality, security, scalability, delivery process. AI due diligence keeps all of that and adds the questions specific to systems that work some percentage of the time: how that percentage is measured, how it moves, and what happens on the wrong side of it. The full argument, and what a generalist read walks past, is in why funds now add an AI-native reviewer alongside the classic workstream.
What the deliverables look like
The output is not a pile of notes. A useful engagement produces an executive summary a partner can read in ten minutes, a scorecard across the assessed dimensions, and a risk register ranked by severity, where each risk comes with a concrete consequence and a remediation cost. For AI-heavy targets, add an AI assessment that says plainly what is real, what is fragile, and what is marketing, and, for PE deals, a value-creation view: what the technology could support that the current owners have not built.
The ranking is the point. Every codebase has problems. The report exists to separate the findings that should change the deal from the ones that are just the normal texture of a real system.
When funds commission one
Three moments, in practice. Before a term sheet, as a short focused read of 3 to 4 days when a fund wants to know if the AI story survives contact before investing more process in the deal. Between term sheet and close, as the full 2 to 3 week review that feeds the investment committee and the final price. And post-close, more often than people admit, when an owner wants an honest map of what they bought before writing the value-creation plan.
The stage changes the depth, not the questions. At seed the review leans on the team and the architecture choices; at growth and buyout it leans on production data, contracts, and economics.
If a target in your pipeline is priced on its AI, an independent technical and AI audit is the cheapest insurance in the deal: it turns the AI story from a claim you are underwriting into a set of facts you have checked.