Technical Due Diligence on an AI Codebase Is Different

Technical due diligence on an AI codebase has to check things a normal code audit never touches. The code is the smallest part of what makes an AI product work. The data it was trained or tuned on, the model weights and their provenance, the prompts, the eval harness, and the pile of notebooks nobody productionized all carry risk that a standard repo audit walks right past. I have seen AI companies where the code was clean and the actual value, the data and the models, was legally or technically radioactive. Audit the code the normal way, then audit the four things that only exist in AI systems.

Why the code is the least of it

In a conventional software business, the code is most of the asset. In an AI business, the code is often a thin layer around a model and a data pipeline, and the moat, if there is one, lives in the data and the training process, not the repo. So a beautiful codebase can sit on top of a worthless or dangerous foundation, and a scrappy codebase can wrap something genuinely valuable.

That inverts the audit. You still run the normal structural pass, the scan-then-expert-review sequence that any repo due diligence uses. But you cannot stop there, because the parts that determine the company's value are not in the code at all.

Data provenance is the first question

Where did the training and tuning data come from, and do they have the right to use it, and to sell a company built on it? This is the question that kills AI deals after close. Scraped data with no license, customer data used for training without consent, datasets bought under terms that forbid resale: any of these can turn the core asset into a liability the moment you own it.

Ask for data lineage, the same data lineage discipline a well-run AI product should already have internally. If the target cannot tell you where their data came from and prove they can use it, that is not a gap, it is a finding, and often the finding. Clean code around unlicensed data is worth less than messy code around data you actually own.

Model provenance and reproducibility

Next, the models. Can the team reproduce their model from scratch, or does the whole thing rest on a set of weights in someone's cloud bucket that nobody can regenerate? A model you cannot reproduce is a model you cannot improve, retrain, or defend, and if it was fine-tuned on a base model with restrictive licensing, you inherit those terms too.

Check what the product actually depends on. If it calls a third-party model API, the real dependency is that vendor, and you should read that like any other single point of failure, because a model provider can change pricing, deprecate the model, or get acquired out from under you. The capability you are buying might be rented, and rented capability is not a moat.

The notebook and eval problem

AI teams live in notebooks, and notebooks are where discipline goes to die. A repo full of experimental notebooks with no tests, no versioning, and no path to production tells you the team has not industrialized its work, which means the "product" may be closer to a demo than a system. The ReformCode scan will show you how much of the repo is throwaway experimentation versus production code, which is a ratio that matters far more for an AI company than for a normal one.

Then the evals. Ask to see the eval harness and the results. An AI company with no systematic way to measure whether its model is getting better or worse is flying blind, and you would be buying a product whose quality nobody can actually verify. No evals is the AI equivalent of no tests, except worse, because model behavior drifts on its own even when the code does not change.

What the AI audit protects you from

The failure mode is buying an AI company on the strength of a clean codebase and a good demo, then discovering the data was never yours to use, the model cannot be reproduced, and the whole thing depends on a vendor API that reprices next quarter. None of that shows up in a normal code audit, because none of it is in the code. Run the standard review, absolutely. Then audit the data provenance, the model reproducibility, the third-party model dependencies, and the eval discipline, because in an AI business those four are the asset, and the code is just the wrapper around them.