There is a common assumption that AI due diligence is just technical due diligence with a model review added on. Buy the standard tech DD, ask someone to glance at the model, done. That assumption is why a lot of AI risk gets missed, because the questions that decide whether an AI system actually works are not the questions a standard technical review is built to ask.
What they share
The two overlap on the foundations. Both care about code quality, architecture, scalability, and security. A well-built AI product still needs to be well-built software, and a team that cannot ship reliable code will not be saved by a clever model. So the technical DD layer does not go away. It is necessary. It is just not sufficient.
Where AI DD diverges
Three areas separate AI due diligence from the technical kind, and they are exactly the areas a standard review tends to skip.
Data. An AI system's behaviour is determined by the data it was trained and evaluated on. Where did that data come from, was it licensed for the use, is it representative of production conditions, and could it carry bias. None of this appears on a software architecture checklist, and all of it can sink the product.
Evaluation methodology. Software either works or it does not. An AI model works probabilistically, and the meaning of its performance numbers depends entirely on how they were measured. AI DD interrogates the evaluation itself: what dataset, which error types, what baseline, under what conditions. A 95 percent accuracy claim is a starting question, not a finding.
Governance and regulatory exposure. AI systems carry obligations that ordinary software does not. Whether a system is high-risk under the EU AI Act, how training data was licensed, whether outputs have been evaluated for fairness. These can be the difference between a system you can deploy and one you cannot, regardless of how clean the code is.
Why bundling them often fails
When AI DD is treated as an add-on, it gets the time and depth of an add-on. The reviewer confirms the model exists, notes the accuracy claim, and moves on. The data provenance, the evaluation rigour, and the regulatory classification, the parts that take real work and carry the real risk, get a paragraph. We have seen deals where the technical DD was thorough and the AI-specific risk that later caused problems was never examined, because everyone assumed it was covered by the model review that was never actually scoped to cover it.
The practical takeaway
If you are commissioning diligence on an AI company, scope the AI assessment as its own workstream with its own depth, not as a line item under technical DD. Confirm that whoever does it will examine data provenance, evaluation methodology, and regulatory exposure as first-class questions. The model review everyone pictures is the easy part. The questions around the model are where the decision actually lives.
If you are weighing an AI investment, acquisition, vendor selection, or training programme, our team is happy to start with a conversation about scope and approach.
The views and findings in this article are shared for general information only. They are high-level perspectives, not legal, financial, regulatory, or other professional advice, and should not be relied upon for any specific decision or circumstance. For guidance tailored to your situation, please consult a qualified adviser.