Due diligence on an AI business

Due diligence on an AI business asks questions a buyer reviewing a typical small business rarely has to think about: where did the training data come from, who actually owns the model, and how much of the product’s value depends on one person who might not stay after the sale. A generic small-business diligence checklist — financials, leases, contracts — still applies, but it isn’t enough on its own here. Buyers who skip straight to the financials, the way they might for a more conventional business, tend to discover the harder questions only after the deal is already signed.

Data provenance and privacy

Every AI business’s diligence should start with a documented trail of where the training data came from: licensed, purchased, scraped, user-submitted, or generated internally. Where any of it includes personal information, the buyer needs to understand whether its collection and use has been consistent with Canadian privacy law and with whatever consent or terms it was originally gathered under. A business that can’t produce this trail clearly isn’t necessarily hiding something, but it does mean the buyer is taking on unquantified risk, and that risk should be reflected in price, structure, or both. Where data provenance can’t be fully documented, buyers sometimes address the gap through specific representations, warranties and indemnities in the purchase agreement rather than walking away outright.

IP ownership: model, weights, code

Confirm who legally owns the model, the trained weights, and the underlying code — not who built it, but who has documented rights to it. This means reviewing employment agreements, contractor agreements and any open-source licences the product depends on. The most common gap found in this review is a contractor who built a core piece of the system without ever signing an assignment of IP rights, which leaves the company’s ownership of that component genuinely unclear until it’s fixed. A clean answer here also affects financing — a lender is unlikely to lend against IP whose ownership is genuinely unclear.

Key-person and technical dependency

AI products, more than most small businesses, can depend heavily on one founder’s or one engineer’s specific knowledge of how the model was built, tuned and maintained. Diligence should assess how documented that knowledge actually is — is there technical documentation a new team could work from, or does the entire system live in one person’s head? A buyer should also ask directly whether key technical staff intend to stay through and after the transition, since losing them can functionally mean losing the ability to maintain or improve the product. Retention arrangements, whether through an earnout, a consulting agreement or simply a compelling transition role, are worth structuring early rather than assuming key staff will stay by default.

Third-party and infrastructure dependency

Map every third-party service the product depends on — the underlying foundation model if it’s not proprietary, cloud infrastructure, data vendors, specialized tooling — and understand the terms and cost structure of each. A business that looks profitable today can look very different if a key API provider raises prices or changes usage terms, and a buyer should understand how much of the product’s economics are within the seller’s control versus dependent on a third party’s decisions. Understanding contract terms with each provider, including notice periods and any exclusivity commitments, matters as much as understanding the cost itself. Buyers should also check whether the business has a documented fallback plan if a key provider became unavailable or unacceptably expensive.

Open-source licence review

Cataloguing the open-source components in the product’s stack and checking their licence terms is a standard part of technical diligence for any software business, and it applies just as much to AI products, which often depend on open-source training frameworks or, increasingly, open-weight models. Some licences carry obligations — around disclosure, attribution or commercial use — that a buyer needs to understand before relying on the product being freely commercializable in its current form. This review is inexpensive relative to the risk it heads off, and most technical due diligence providers can complete it quickly as part of a broader code review.

Financial and revenue diligence, with AI-specific adjustments

• Confirm compute and API costs are treated as a real ongoing cost of goods, not normalized away as one-time items.
• Separate recurring subscription or contract revenue from one-time implementation or pilot project revenue.
• Check customer concentration specifically — a small number of large early customers is common in this category and changes the risk profile.
• Verify any usage-based or consumption pricing model’s actual margin, since AI compute costs can erode margin in ways a flat-fee product wouldn’t show.
• Model how a meaningful compute price increase from a key provider would affect margin, as a stress test rather than an assumption.
• Confirm whether any revenue comes from pilot programs or proof-of-concept engagements that haven’t yet converted to a standing contract.