AI due diligence: what to check before you invest in an AI company

AI due diligence is the part of a technical review that tests whether an AI company's product will keep working, within its licences and data obligations, at a sustainable cost, after you invest in it or acquire it. It covers who owns the models and data, and how much the product depends on third-party AI APIs. It also checks the evidence that the AI performs, how it is secured, how personal data is handled, who can run it, and what each customer action costs to serve. This article is general information to help buyers prepare their questions. It is not investment advice.

What does AI due diligence add to a standard technical review?

Standard technical due diligence reviews code quality, architecture, infrastructure, security and the team. An AI company adds three problems. Part of its product may be rented: a model reached through an API, on terms the company does not control. Its outputs vary from run to run, so a polished demo proves little about production quality. And its gross margin depends on inference costs that move with usage, model choice and vendor pricing.

Before any acquisition in our Venture Lab we review code, data, infrastructure and AI risk, and look closely at security and the team that runs the product. The sections below cover the questions that are specific to AI.

Who owns the models and data, and who controls them?

Model and data provenance

Start with an inventory of every model the product uses, where it comes from and under which licence. Open-weight model licences differ in detail. The Llama 3.1 Community License (July 2024), for example, requires anyone who distributes the Llama materials to display "Built with Llama". A distributed model built or improved with Llama materials or outputs must carry "Llama" at the start of its name. A company whose products had more than 700 million monthly active users on the release date must request a separate licence from Meta. Clauses like these matter when a buyer plans to rebrand, distribute or scale the product.

Then trace the data. For each dataset used to train, fine-tune or evaluate a model, ask where it came from, under what licence or contract, and whether customer data was used. Settle three questions first: was any data scraped, was any dataset licensed for research only, and was customer data used beyond what the customer contract allows? If the company presents a fine-tuned model as its core asset, ask for the data lineage and the scripts that reproduce the model.

How dependent is the product on third-party AI APIs?

Many AI products are built on models from a small number of providers. That is a reasonable engineering choice, but it ties part of the product's risk to the vendor's roadmap and terms. Vendors retire models on their own schedule. Anthropic's model deprecation policy, as published in October 2026, commits to at least 60 days' notice before a publicly released model is retired, and states that requests to a retired model fail.

Ask the target to show:

• which model versions run in production, pinned by exact ID rather than by alias;
• its history of model migrations and how long each one took;
• the evaluation set it re-runs before switching models;
• a tested fallback to a second model or provider, where the business needs one;
• the vendor terms on data use, retention, rate limits and processing locations.

Evaluation evidence, security and data protection

Evaluation evidence

Ask for the test sets, scores, dates and model versions behind every quality claim in the pitch deck. A company that cannot show a locked test set and a record of results over time is relying on demos. If the product serves Arabic-speaking users, check that the tests cover the dialects those users write as well as Modern Standard Arabic.

Security

Review the AI layer against the OWASP Top 10 for LLM Applications 2025, which lists risks including prompt injection, sensitive information disclosure, supply chain, excessive agency and unbounded consumption. Check where API keys are stored, who has administrator access to model and cloud consoles, whether multi-factor authentication is enforced, and what the incident log shows. Keep the review read-only: no active testing of the target's systems without separate written authorisation.

Data protection

Map which personal data flows to which AI vendor, and where it is processed. In Saudi Arabia, the Personal Data Protection Law (Royal Decree No. M/19 of 9/2/1443H, as amended) permits transfers of personal data outside the Kingdom only under the conditions set in the law and in the Regulation on Personal Data Transfer Outside the Kingdom. The Saudi Data and AI Authority (SDAIA) publishes both, with the Implementing Regulations, on its data governance platform. Jordan's Personal Data Protection Law No. 24 of 2023 restricts transfers to recipients outside the Kingdom that offer a lower level of protection, subject to listed exceptions, and requires a data protection officer in cases that include transferring databases abroad. In the UAE, Federal Decree-Law No. 45 of 2021 Regarding the Protection of Personal Data sets requirements for cross-border transfers; companies in free zones with their own data protection law, such as the DIFC and ADGM, follow those rules instead. This is general information, not legal advice; obligations depend on the company's sector, its customers and the data it processes.

Governance records help too. Some targets run an AI management system against ISO/IEC 42001:2023, or map their controls to the voluntary NIST AI Risk Management Framework. Ask for the risk register, the policies and the review records, not only a statement of alignment.

Team, operations and cost to serve

An AI product often depends on a few people who understand the prompts, the evaluation set and the deployment. Map knowledge and access by role: who can deploy, who holds the credentials, who could rebuild the model pipeline. If one engineer holds all of it, the deal terms need to address that.

Then build the unit economics from invoices, not from the pitch. Take 12 months of cloud and model-vendor bills and divide them by a business unit, such as cost per conversation, per document processed or per active customer. Compare that with what the customer pays. Check how cost changes as usage grows, and which levers the team already uses, such as smaller models for simple tasks, prompt caching or batch processing.

AI due diligence checklist and red flags

A red flag does not have to end the deal. It should shape the terms: a condition to fix before completion, a specific protection in the agreement drafted by your advisers, or a decision to stop.

After the deal: post-acquisition AI operations

The due diligence findings become the first operating plan. In the first 100 days, a new owner usually needs to:

1. Rotate credentials and move administrator access to named accounts with MFA.
2. Pin model versions and turn the evaluation set into a regression test.
3. Put model and cloud costs on a monthly dashboard with alerts.
4. Write a model migration playbook before the next retirement notice arrives.
5. Document prompts, pipelines and runbooks so the product no longer depends on one person.

How to start

Our Venture Lab runs Technical & AI Due Diligence before any acquisition, carries the findings into Acquisition & Negotiation, and turns them into an operating plan through Post-Acquisition AI Operations. If the target's product was built with tools such as Lovable, Bolt, Replit or Cursor, our AI-built app review covers the code. If you are weighing an AI deal, book the free AI Exposure Scan: a 45-minute conversation that ends in a written next step.

Related lab: Venture Lab ↗