The AI Wrapper Problem: Why "We Use AI" Doesn't Mean What Buyers Think

Why AI claims are becoming part of the acquisition thesis, and why almost nothing in a standard deal process actually verifies them.

The wrapper is only the visible symptom. The larger problem is that AI capability is increasingly becoming part of an acquisition thesis without a consistent way to measure how much of that capability is actually owned, integrated, defensible, and replaceable.

The seller is not lying. The buyer is simply asking the wrong profession to verify the claim.

THE CLAIM

The Claim

"AI-powered" now appears on pitch decks and CIMs across a huge range of technology businesses, and it's rarely a false statement. Most of these companies genuinely do use AI, somewhere. What the phrase doesn't tell a buyer is how deep that usage actually goes, whether it's a differentiated, defensible capability or a thin layer wrapped around a general-purpose API call.

In practice, AI claims can affect how buyers value a business, particularly when the story attached to them is durability, why this capability keeps generating value rather than why it happens to demo well today. That's a reasonable thing for a buyer to want to pay for. The problem is verifying, before the price is set, whether it's actually there.

THE PROBLEM

The Problem

The same phrase, "we use AI," can describe genuinely different architectures. A product that fine-tunes a model on years of proprietary domain data, and a product that forwards user input to a general-purpose API behind a well-written system prompt, can both use that exact sentence honestly. Both can look identical in a demo. Only one of them may contain meaningful proprietary technical differentiation, and even then, technical defensibility is only one component of a business's overall defensibility, alongside distribution, customer data, integrations, switching costs, and domain expertise that have nothing to do with the model itself.

This isn't a story about deception. It's a measurement problem. Nothing about a standard pitch, or a standard financial or legal review, forces that distinction into the open before a deal closes.

IMPLEMENTATION DEPTH

The Distinction: AI Implementation Depth

The honest way to tell these apart isn't philosophical, it's architectural, and it tends to fall into a handful of recognizable levels.

The AI Implementation Depth Framework

An AI system should not be evaluated by whether it uses AI. It should be evaluated by where the value resides, how deeply the capability is integrated, how dependent it is on external providers, and how replaceable those dependencies are.

Implementation depth is a descriptive framework, not a quality score. None of these levels is inherently better than another, a level-two product with strong revenue, healthy margins, and low vendor risk can be a considerably better acquisition than a level-five system nobody can actually maintain. The problem is specifically when a business is priced as if it sits at level four or five while the underlying implementation sits at level one. Using a third-party model is not the issue, most strong AI products do, somewhere in the stack. The issue is where the claimed differentiation actually lives, and whether that location matches the price.

Implementation depth answers where the capability lives. It's a separate question from dependency risk, what happens if something outside the company's control changes. A useful way to hold the two together: risk concentrates where dependency, business criticality, low replaceability, and high replacement cost overlap, not from depth alone. By AI capability, we mean the technical systems and dependencies materially responsible for the AI-related functionality being represented in the acquisition thesis, the model, the data, the inference layer, and whatever workflow or infrastructure sits around them.

THE RISK

The Risk: What a Thin Layer Actually Costs After Closing

This is the part that rarely shows up before closing and almost always shows up after. Consider a realistic version of it. An acquired product generates a given level of revenue and gross margin, with AI inference costs built into that margin at the vendor's current pricing. The underlying model provider then changes its pricing, tightens rate limits, or deprecates the model version the product depends on. Inference cost rises sharply. Gross margin compresses. The product's own pricing, set before the change, becomes uncompetitive. Replacing the dependency turns out to require a meaningful, sustained engineering effort, not a configuration change, and the roadmap slips while that work happens.

Consider a hypothetical acquisition to make this concrete. A product generates five million dollars in annual recurring revenue at a seventy-two percent gross margin, with roughly thirty-five percent of its inference cost tied to a single model provider. That provider changes its pricing. Gross margin compresses meaningfully. The product's own customer pricing, set before the change, becomes uncompetitive. Replacing the dependency turns out to require several engineers working for months, not a configuration change, and the roadmap slips while that work happens. None of that appeared in the revenue statement on the day of the deal. All of it becomes visible the first time the vendor changes something, and by then it's the buyer's cost to absorb, not the seller's. The acquired asset was priced, in part, on the assumption that its AI capability was a durable moat. If it was actually a dependency on someone else's roadmap, the buyer has taken on a risk that never appeared in the numbers, exactly the same category of hidden dependency covered more broadly in what you own vs what you're renting, specific here to the AI layer of the stack. What determines how much that risk actually costs is a combination worth naming directly: how dependent the business is on the vendor, how critical that dependency is to the core product, how replaceable it actually is, and what replacing it would cost in time and money.

THE BLIND SPOT

The Blind Spot

Traditional financial and legal diligence is not designed to answer this specific question. It's built to verify what shows up in documents, revenue recognition, contracts, cap tables, IP assignments, customer concentration, and it does that well. Confirming whether an AI capability sits at implementation level one or level four requires reading the actual system, the data pipeline, the orchestration logic where one exists, not the pitch deck describing it.

Depending on the deal, a technical diligence provider may already cover part of this. But AI-specific dependency mapping and implementation-depth assessment is a narrower, more specific exercise than a general code or architecture review, and it's frequently not where a generalist technical review spends its time. That gap is where this risk tends to live unexamined.

WHAT THIS IS NOT

What This Audit Is Not

It's worth being precise about scope, since this kind of review sits close to several others without being any of them. It is not a model benchmark, a cybersecurity audit, a general code quality review, a substitute for full technical due diligence, or a judgment on whether the company is a good investment.

It is a specific, evidence-based assessment of what the claimed AI capability actually consists of, what it depends on, and what happens if those dependencies change.

WHAT AUDIT PRODUCES

What the Audit Actually Produces

The output isn't a verdict on whether the business is good or bad. It's a specific set of deliverables built to answer the question the rest of the deal process wasn't built to answer.

What a Buyer Actually Receives

WHO IS ASKING

Who's Actually Asking

"Buyer" undersells how differently this question lands depending on who's asking. A buyer wants to know what they're actually acquiring. A seller preparing for a process wants to know what they can credibly substantiate before claims become part of a CIM. A PE operating team wants to know what a dependency will cost after closing, once it's their balance sheet. An M&A advisor wants to know what risks could derail the thesis or move the number before the deal is signed. The underlying architecture being examined is the same. What each party needs from the findings is not.

VALUATION IMPLICATION

The Implication for Valuation

None of this is an argument against paying for real AI capability. When it's genuine, it's one of the strongest differentiators a technology business can have, and it deserves to be priced accordingly. The argument is narrower: the premium should attach to verified capability, not to a phrase that appears identically on strong products and thin ones alike.

Verify the AI claim the way you'd verify any other material asset before allowing it to influence the price.

The buyers who get this right aren't the ones who distrust every AI claim. They're the ones who verify it before it becomes part of the number, the same way they would any other material asset.

The question in an AI acquisition was never really whether the company uses AI. It's what part of that capability the buyer actually owns after closing, what remains dependent on someone else's roadmap, and what it would cost to replace.

That is the difference between buying an AI-enabled business and buying the story of one.

What is AI due diligence?

An evidence-based review of what a company's claimed AI capability actually consists of, where it sits on the implementation-depth scale, what it depends on externally, and what would happen if those dependencies changed. It sits alongside standard financial, legal, and technical diligence rather than replacing any of them.

What is an AI wrapper?

A product where the AI capability is essentially a general-purpose model call behind a prompt and an interface, with little proprietary logic, data, or orchestration underneath. It sits at the lowest level of implementation depth, and it isn't inherently a problem, only a mismatch when it's priced as something deeper.

Is using OpenAI, Anthropic, or another foundation model automatically a risk in an acquisition?

No. Most strong AI products depend on a foundation model somewhere in the stack. The relevant question is where the differentiation actually lives, proprietary data, orchestration, integration, and evaluation built around that model, not whether a third-party model is used at all.

How does AI dependency actually affect a company's valuation?

Through the combination of how dependent the product is on an external vendor, how critical that dependency is to the core offering, how replaceable it is, and what replacement would cost in time and engineering effort. A high-dependency, low-replaceability capability priced as a durable moat is where the real valuation risk concentrates.

What should AI technical due diligence actually include?

An architecture map of what powers the product, a full dependency map of every model and vendor involved, an assessment of where proprietary capability genuinely resides, a scenario analysis of realistic vendor changes, and a concrete estimate of replacement cost and time if a dependency needed to be removed.