AI due diligence is difficult because the most impressive part of the company is often the least reliable evidence. A polished demo can be real, useful and commercially exciting while still concealing serious questions about data quality, architecture, operating process and technical debt.
Investors know how to test revenue, pipeline, contracts and management narrative. AI businesses require another layer of scrutiny. The question is not simply "Does the technology work?" The better question is "Can this company keep making the technology work as it grows?"
The demo is not the operating system
A demo shows possibility. It does not show resilience. It may rely on curated data, manual intervention, narrow examples or infrastructure that cannot support real customer volume.
Good diligence separates product capability from production capability. That means looking at deployment architecture, data pipelines, monitoring, incident response, model evaluation, security, access control and the path from customer feedback to product improvement.
If the answer to a technical question is "the founding engineer handles that", the company may have a key person dependency rather than a scalable capability.
Data rights are often under-tested
AI companies can be vague about data. Investors should understand what data the company uses, how it was obtained, what rights attach to it, how it is stored, whether customers can withdraw it, and whether the model depends on data that may not be available in future.
Data quality matters as much as data access. A large dataset can be commercially weak if it is inconsistent, poorly labelled, biased, stale or disconnected from the real decision the product claims to improve.
Model performance needs context
Accuracy figures are rarely enough. Performance should be examined against the actual workflow. What happens when the model is uncertain? What is the cost of a false positive or false negative? How does performance vary across customer types, sectors or edge cases? What monitoring exists after deployment?
For many AI products, the business risk is not that the model fails all the time. It is that it fails quietly in commercially important situations.
Architecture reveals commercial pressure
Technical architecture is a record of business decisions. Shortcuts are not always bad. In young companies, some shortcuts are rational. The issue is whether the team understands the shortcuts, has contained them, and has a credible plan for the next stage.
Technical debt becomes an investment risk when it blocks onboarding, creates reliability problems, makes security difficult, or slows every new customer implementation.
The team matters as much as the code
AI companies need more than clever model builders. They need engineering discipline, product judgement, customer empathy, operational maturity and honest communication with the board.
During diligence, I pay close attention to how the team talks about trade-offs. Strong teams know where the system is fragile. Weak teams describe every weakness as temporary and every roadmap item as easy.
What good diligence should produce
Good AI diligence should not only produce a red flag list. It should produce a value creation agenda. What must be fixed in the first 90 days? Which risks are acceptable at the current stage? Which risks change the valuation or deal structure? What technical leadership does the company need after investment?
The aim is not to punish early-stage companies for being early-stage. The aim is to understand whether the technical reality supports the commercial story.
That is where standard frameworks often fall short. AI diligence needs to connect architecture, data, model performance, team capability and go-to-market assumptions into one view of risk.