Testing whether an AI company's technology is what the deck says it is

The situation

A private equity investor was preparing to invest in a software company whose growth story rested on AI: models that automated part of its customers' work and data assets that, the deck said, competitors could not replicate. The commercial and financial diligence was well under way. What the deal team lacked was an independent view of whether the technology, the data rights and the team matched the story, and what it would cost to fix anything that did not.

The timeline was set by the deal, so the review had to be structured, evidence-led and focused on findings that could change price, terms or the post-close plan.

What had to be true

• Evidence over assertion: every finding tied to something inspected, not only something said in an interview.
• Proprietary versus borrowed made explicit: which capabilities the company built, and which depend on third-party models or APIs.
• Data rights traced from source to model to product, including customer data used for training.
• Costs that scale: inference and cloud spend modelled against the growth plan.
• A report the deal team can use: risk-rated, with recommended responses, readable by non-engineers.

Architecture

The review was organised into workstreams, each with its own evidence requests and interview plan. AI governance was assessed against the functions of the NIST AI Risk Management Framework (govern, map, measure, manage)¹, with ISO/IEC 42001 used as the reference for what a management system for AI looks like². The comparison is in ISO 42001 vs NIST AI RMF.

The data flow, end to end

Secure development practices were reviewed against the NIST Secure Software Development Framework, which groups practices into preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities³. The full checklist I use is in the AI startup technical due diligence checklist, and supply chain questions in AI model supply chain security.

The hard part: proving data rights, not just data

Showing that a company has data is easy. Showing that it may use that data for the purpose the plan depends on is not. The provenance workstream asked, for each dataset behind a model:

• Where it came from, under which contract or licence, and whether that permits training and commercial use.
• Whether customer data was used to train shared models, and whether customer contracts allow it.
• Whether the dataset is documented in a form like a datasheet, covering motivation, composition and collection⁴.
• Whether models carry documentation of intended use and evaluation, in the spirit of model cards⁵.

Regulation was mapped to where the company sells. For customers in the European Union, the review considered how the EU AI Act might classify the product and which provider or deployer obligations could apply⁶.

How the engagement ran

Key decisions and trade-offs

What I'd do again, and differently

Again: insist on repository and billing access early, and separate verified findings from representations in the report. Differently: start the data rights tracing on the first day, in parallel with legal counsel. It is the slowest workstream and the one most likely to change the deal.

If you're planning an investment, the technical due diligence page describes how I run these reviews, or analyse your challenge and bring the result to a call.