In a growing share of mid-market deals, some part of the investment thesis now depends on AI — on a product feature, an operating efficiency, a competitive moat, or a forward-looking margin expansion that assumes AI will continue to do what the management deck says it does. The diligence playbook has not caught up.
Traditional technology diligence is built to evaluate stable categories: infrastructure, applications, cybersecurity, vendor concentration, IT spend, key-person risk. AI does not sit cleanly in any of those buckets. It pulls from all of them, introduces exposures that are not yet standardized in diligence checklists, and is moving fast enough that what was true at LOI may not be true at close.
That gap is where deal teams are now being surprised — not by whether the company has AI, but by what the AI actually is, what it depends on, and what happens to the thesis if the assumptions underneath it shift.
When the Thesis Depends on AI You Haven’t Assessed
The clearest signal that AI diligence is required is not in the target’s product. It is in the deck.
When the IC memo cites AI as a reason the company will grow faster than its category, take share from less sophisticated competitors, defend margin against rising labor costs, or unlock a new product line that justifies the multiple — the thesis is now exposed to whatever the AI actually is. If that exposure is not surfaced before LOI, it becomes a post-close discovery.
The pattern is familiar from earlier waves: cloud migration claims that didn’t survive an architecture review, SaaS renewal economics that didn’t survive a usage audit, cybersecurity postures that didn’t survive a documented assessment. AI claims are now in the same category. The deck describes a capability. Diligence has to determine whether the capability is real, durable, and economically supportable on the terms the thesis requires.
Three Types of AI Exposure in Mid-Market Targets
Before asking detailed questions, deal teams need a framework for what kind of AI they are actually looking at. In practice, mid-market targets fall into three categories — each with a different risk profile.
AI-claimed. The company markets AI capability but, under the hood, the product runs on rules, scripts, decisioning logic, or conventional machine learning that predates the current AI wave. There may be a small AI component — a chatbot, a content summarizer, an embeddings-based search — that is real but peripheral to the value proposition the deck is selling. The diligence risk here is reputational and competitive: if buyers, customers, or regulators eventually examine the claim, the gap between marketing and reality becomes a liability.
AI-embedded. The company relies on AI features provided by third-party platforms — Microsoft Copilot inside the productivity stack, Salesforce Einstein, Adobe Firefly, an embedded LLM feature in the vertical software the company runs on. The AI is real, but the company does not own it. The diligence risk is dependency: vendor pricing changes, feature deprecation, license entitlement complexity, and the fact that a competitor using the same platform has access to the same capability.
AI-built. The company has trained, fine-tuned, or meaningfully integrated AI as part of its own product — a proprietary model, a retrieval-augmented generation pipeline against company data, a custom agent workflow embedded in customer-facing software, or a feature that sends customer data to an external model provider on a per-call basis. The diligence risk here is the broadest: data lineage, intellectual property, compute economics, talent concentration, and the contractual posture with whatever model providers sit underneath.
The same deal can contain all three at once. Distinguishing among them is the first job of AI diligence, because the questions that matter differ materially across the three.
What “AI-Enabled” Actually Means in Practice vs. in the Deck
The single most useful diligence question on AI is not technical. It is: If the AI stopped working tomorrow, who would notice, and what would change in the financial statements ninety days later?
This question forces specificity. It gets past the marketing language and into the operating reality. The honest answers tend to fall into a small number of patterns.
In one pattern, the AI is producing measurable operating leverage — deflecting support tickets, accelerating sales cycles, reducing per-unit labor on a clearly defined task. The leverage is observable in the metrics, and the company can describe what would change without it. That is a real AI capability, and the diligence work shifts to whether it is durable.
In another pattern, the AI is in pilot, used by a small number of employees or a small subset of customers, and the company is not yet able to attribute revenue or cost outcomes to it specifically. That is a directional bet, not a value driver, and the thesis should be sized accordingly.
In a third pattern — and this one is more common than buy-side deal teams expect — the AI is largely a feature in the marketing site and the sales conversation. The product technically has an AI component. The customer-facing impact is modest. The thesis sizing implied by the deck is not supportable by the operating data. That is a material finding.
Sorting deals into these three patterns does more work than any technical questionnaire. It is also faster, because it can be done in a sixty-minute conversation with the right management team members — product, customer success, and the engineer or vendor manager who actually built or bought the AI.
The Technical Questions Deal Teams Don’t Know to Ask
Once the type of AI is identified and the operating reality is sized, a small set of technical questions does most of the remaining work. These are not generic technology questions. They are specific to how AI behaves as an exposure.
Model dependency and concentration. Which underlying models does the product use? Are they API-based from OpenAI, Anthropic, Google, or another provider; self-hosted open-weight models; or some combination? What is the contractual relationship with the model provider, what is the unit economics per call, and what happens to gross margin if the per-token cost moves materially in either direction? What is the fallback plan if the specific model is deprecated, repriced, or restricted by the provider’s usage policy?
Data lineage and consent posture. What data was used to train, fine-tune, or ground the AI? Where did that data come from — the company’s own customers, publicly available sources, licensed datasets, or scraped content? Is there a documented record of consent or licensing? If the AI is trained on customer data, do the customer contracts permit that use, and does the privacy policy disclose it accurately? These are not theoretical questions; they are the foundation of any future representation a seller will be asked to make.
Compute economics and gross margin behavior. What is the variable cost of inference as a percentage of revenue, and how has it moved over the last twelve months? AI features have unusual cost behavior: they can be highly profitable at low usage and quietly compress gross margin at scale, especially when usage growth was a thesis assumption. If the deck assumes both rapid AI feature adoption and margin expansion, those two assumptions need to be reconciled with the underlying unit economics.
Talent concentration and documentation. How many people in the company actually understand how the AI works? Is there documentation sufficient for a successor to maintain and extend it, or does the capability live in the head of one or two engineers? Key-person risk is a familiar diligence concern; AI capabilities concentrate that risk more aggressively than most other categories of software work.
Regulatory and policy exposure. Does the AI use case fall under the EU AI Act, sectoral rules in healthcare or financial services, state-level laws on automated decision-making, or contractual restrictions in enterprise customer agreements? Is the company governance posture — an AI usage policy, a documented review process for new use cases, an inventory of where AI is deployed — commensurate with the risk?
How AI Risk Maps to Reps and Warranties
The AI questions above do not stay theoretical. They surface again at the reps and warranties stage, where the seller will be asked to make statements that the buyer’s diligence findings are expected to support. Three areas warrant specific attention.
The first is intellectual property representations. If the product relies on AI components built using third-party models, open-source code, or training data the company does not own outright, the standard IP reps need to be examined carefully against what the diligence actually found. A clean rep against a dirty data lineage is a finding waiting to happen.
The second is customer data usage representations. If customer data flows into a third-party model as part of normal product operation, the privacy and data-handling reps need to align with what the customer contracts actually permit and what the company’s privacy policy actually discloses. Misalignment here is the most common AI-specific deal finding we see in mid-market targets.
The third is cyber insurance posture. Cyber policies have begun to introduce AI-specific exclusions, sub-limits, or controls requirements. A buyer’s diligence on cyber insurance should now include AI-related provisions explicitly, not as a footnote. A claim that was denied because an AI-related control was not in place is a finding that travels into a future exit.
A Pre-LOI AI Sanity Check: Five Questions in 48 Hours
Most deal teams cannot run a full AI diligence stream before LOI. They can, however, run a structured sanity check in forty-eight hours that materially reduces the chance of post-close surprise. Five questions:
- Where exactly in the revenue does AI live, and what percentage of revenue depends on it? A specific answer, with numbers, sized against the thesis.
- Is your AI inference cost a fixed percentage of margin, or does it move with usage in ways that have not yet shown up in the trailing financials? Pulling the per-call economics into the LTM margin picture.
- Which models do you use, who provides them, and what is the fallback if any of them are deprecated, repriced, or restricted? A named dependency and a named contingency.
- What customer or training data was used to build the AI capability, and where is the consent or license record? A documented answer, not an assurance.
- Who is the single person who could leave and put the AI capability at risk? A named individual, with an honest assessment of documentation and bench depth.
None of these require a technical questionnaire. They require a conversation with the right two or three people at the company — typically the product leader, the technology leader, and whoever in finance has visibility into the cost of goods sold. The diligence value comes from the specificity of the answers, not from the volume of artifacts collected.
The Practical Implication for Deal Teams
AI diligence is not a new line item on the existing technology checklist. It is a different lens that has to be applied across several lines — intellectual property, vendor concentration, gross margin, cybersecurity, talent, and regulatory posture — whenever the thesis depends on AI in a way that would not have been true two years ago.
The cost of running this lens before LOI is small. The cost of skipping it shows up later: in price renegotiation when buyers in a future exit run the diligence the original deal team did not, in cyber insurance claims that are quietly denied, in customer contracts that surface a privacy exposure during a renewal, in a single engineer whose departure puts the differentiation at risk. None of these outcomes are theoretical. All of them are now visible in mid-market PE diligence work.
This is the kind of diligence Vertex was built to run alongside deal teams — not as a generic technology review, but as a focused assessment of whether the AI claims in the thesis can be supported by the AI reality in the company. Done before LOI, it shapes the offer. Done after close, it shapes the value creation plan and the exit-readiness work that follows.