AI diligence: is it a product or a wrapper?

The CIM says the product is AI-powered. The demo is impressive. Management talks about a proprietary engine. None of that tells you whether the company owns a capability or rents one by the call from a model provider that can change its prices, limits or terms next quarter.

Most targets that claim AI are telling the truth. The question is not whether AI is in the product. It is where the value sits, who controls it, what it costs to run, and what happens when something outside the company changes. A standard financial and legal review is not built to answer that. It reads contracts and revenue. The answer sits in the code, the prompts, the data pipeline and the invoices from the model provider.

This piece is the buyer's working list. It is written for private equity, strategic buyers, search funds and independent sponsors, and for sellers who put AI on the first page of their deck and want to know what a reviewer will check.

What "AI-powered" can mean in a deal

The same sentence covers very different systems. At one end, the product sends user input to a general-purpose model with a well-written instruction and shows the reply in a clean interface. At the other end, the company runs a pipeline of retrieval, several models, validation steps and its own measurement, built on data it has collected and has the right to use. Both demo well. Only one is hard to copy.

A wrapper is not a bad business by default. A thin layer with strong distribution, sticky customers, deep integrations and healthy margins can be a better acquisition than an ambitious system nobody can maintain. The risk is a mismatch: a business priced as if its AI were a moat when the moat is really a supplier's model and a few pages of prompts.

Our engineering partner PERETZ looked at the same problem from the measurement side in The AI Wrapper Problem: Why "We Use AI" Doesn't Mean What Buyers Think. This article turns that question into a diligence procedure: the signals to look for, the documents to request and the questions to put to management.

Wrapper and product signals side by side

No single signal decides it. A reviewer reads them together and asks where they point. The table below lists what we look for in each area and how it usually reads.

A target with most answers in the left column can still be worth buying. It should be priced, structured and planned as a software business that buys a key input from a supplier, not as an AI asset.

The model provider is a supplier

Treat the model API like any other critical supplier, with one difference: its terms change faster than most. Pricing per token moves. Rate limits change. Model versions are deprecated on the provider's schedule, and a replacement version can answer differently to the same prompt. Usage policies can restrict a use case the product depends on.

What to read:

• The provider agreements actually in force: the account holder, the plan, any committed spend or enterprise terms, and whether the account belongs to the company or to a founder or contractor.
• The provider's usage policy, checked against what the product does. Regulated areas such as health, credit, employment and legal advice deserve a close read.
• Deprecation notices received in the last year and how the team handled them.
• Where API keys live, who can see them, and whether production and test use separate keys and budgets.
• Any spending cap or alert, and what the product does when the provider is slow, down or refuses a request.

An account in a founder's personal name, on a personal card, is common in young companies. It sits in Layer 01, Ownership & IP, next to the same finding for domains and cloud accounts. It is usually easy to fix before closing, and it belongs on the closing checklist either way.

Switching cost is the number that matters

Every dependency can be replaced. The question is how long it takes and what breaks. If the product calls one model directly from dozens of places, with prompts tuned to that model's habits and no test set to tell whether a new model is as good, a switch is a project measured in months. If calls run through one internal layer and a test set gives a score for any candidate model, a switch can be a matter of weeks. A reviewer estimates that range in engineer weeks, with the assumptions written down, and the estimate goes into the findings register with its severity.

Prompts, data and evaluation are the assets

When a company does not train its own models, the defensible parts are usually three things: the instructions and workflow around the model, the data it feeds in, and the way it measures quality. These are what a buyer actually acquires. They need the same care as source code.

Prompts and workflow

Prompts are code in plain language. Check that they live in the repository, have a history, and are covered by the IP assignments of the people who wrote them. A prompt library written by a contractor without an assignment is the same ownership problem as code written that way. Look at the workflow around the calls: retrieval from the company's own content, chaining of steps, checks on the output, fallbacks. That logic is where most real product work sits, and it is often the part a competitor cannot see in a demo.

Data

Proprietary data is the strongest claim and the one that most needs proof. Ask what the data is, where it came from, how it was labeled, how often it is refreshed and what right the company has to use it for this purpose. Data scraped from websites, licensed for one use and used for another, or taken from customers without a clear clause, can turn an asset into a liability.

Evaluation

A team that cannot measure quality cannot safely change the model, the prompt or the provider. Good practice is a fixed set of real cases with expected results, scored on every release, plus monitoring in production: complaints, corrections, refusals, wrong answers caught by users. Ask to see the last few score reports. If there are none, the honest description of the product is that it works as long as nothing changes.

Inference costs in the gross margin

Classic SaaS has costs that fall per customer as it grows. AI features can work the other way. Every request costs money, heavier users cost more, and a flat subscription price can hide customers who lose money on every month of use. The model bill is part of the cost of revenue, and the buyer needs it broken down.

• Inference cost by month for the last twelve months or more, matched to the provider invoices.
• Cost per request and per active customer, and the spread: the heaviest users, not only the average.
• Cost by feature and by plan, so the buyer can see which plans carry the AI cost and which subsidize it.
• What is done to control cost: caching, smaller models for simple tasks, limits per plan, batch processing.
• The effect of a price change at the provider on gross margin, worked through at least for an increase and for a forced move to a newer, different model.

This sits in Layer 02, Infrastructure & cost. A finding here is rarely about whether the margin is good today. It is about whether the margin in the model is the company's or the provider's to set. Free credits from a provider or a cloud program deserve a line of their own: a product that looks profitable on credits may not be once they run out.

Data rights, privacy and customer contracts

Two separate questions often get merged. First: does the company have the right to use the data it trained, tuned or built retrieval on? Second: what happens to customer data when it is sent to a model provider?

For the first, read the sources and the licenses. For the second, read three documents together: the provider's data terms (retention, whether inputs are used for training, where processing happens), the company's own customer contracts and privacy notice, and the actual account settings. They should agree. A common finding is that the customer contract promises data stays in the United States or is never shared with third parties, while every request goes to a provider whose processing location or retention was never checked. Health data, children's data and data under state privacy laws such as California's raise the stakes.

Two more points worth a line in the report. Output ownership: some customers expect to own what the AI produces for them, and the contracts should say so clearly. Security: a product that feeds user text or documents to a model can be steered by instructions hidden in that text, and a product with tools that act on the customer's systems needs limits on what the model can trigger. These belong in Layer 03, Data & privacy, and Layer 05, Security & access.

Questions to ask management

Ask these in the management session and ask for the evidence behind each answer. A good answer is specific, shows a document or a screen, and admits limits. A weak answer is general, refers to the future, or relies on one person's memory.

1. Which models and providers does the product use, for which features? Good answer: a list by feature, with model versions, and the share of cost per provider.
2. What would happen if your main provider raised prices sharply or retired the model you use? Good answer: they have thought it through, can name the alternative, and have tested it, or can say plainly what a switch would take.
3. Have you ever changed model or provider? What broke? Good answer: a real story with dates, what the test set showed and how long it took.
4. How do you know a release did not make the answers worse? Good answer: a test set of real cases and a score per release they can show you.
5. What data does the product use that a competitor cannot get, and what gives you the right to use it? Good answer: a named source, a license or contract clause, and how it is kept current.
6. Is customer data used to train or tune anything, yours or the provider's? Good answer: a clear yes or no, the setting that enforces it, and the contract clause that tells customers.
7. What does inference cost per customer, and who are your most expensive customers to serve? Good answer: numbers from a dashboard or invoices, not an estimate made in the meeting.
8. Who in the team can change the prompts and the pipeline safely? Good answer: more than one name, with documentation that a new engineer could follow.
9. Which accounts, keys and agreements are not in the company's name? Good answer: none, or a short list with a plan to move them before closing.

Management answers are a starting point. The review checks them against the repository, the provider consoles and the invoices, under a read-only, time-limited access protocol.

What is defensible, and what to do next

After the review, the buyer should be able to say in a sentence where the value sits. Usually it is some mix of the customer base and distribution, integrations into the customers' work, proprietary data with clear rights, a workflow that took real effort to get right, and measurement that lets the team change models safely. The model itself is rarely the asset unless the company trained it. If the answer is "a prompt and a provider account", the price should reflect a software business with a supplier risk, and the purchase agreement may need specific representations on data rights and provider terms. That is a conversation for your counsel, with the facts in hand.

For sellers the same list works in reverse. Move accounts into the company's name, version the prompts, build a test set, track inference cost per customer, and line up customer contracts with provider terms. Each of those is cheaper to do before a buyer asks.

If you are a buyer inside exclusivity, technical due diligence covers the AI layer as part of all six layers, with every finding rated and costed. If time is short, a red-flag memo answers the first question: product or wrapper, and what it means for the deal. Sellers who want to substantiate an AI claim before it goes into a CIM can start with exit readiness.

Questions