The conversation in most deal rooms used to follow a predictable pattern. The buyer's technical team would ask about the tech stack, security posture, integration risk. Then someone would raise AI as an afterthought, and the seller's team would pull up a slide deck. "We have an AI roadmap." Maybe a pilot in production. Maybe a few screenshots.
That worked in 2022. It stopped working sometime around 2024. By now, strategic buyers are running structured AI diligence as a standard part of the process. They are not asking whether a portco is using AI. They are asking: can you prove it, can you quantify it, and can we underwrite the revenue contribution after close?
The portcos that built their AI infrastructure with that question in mind are commanding measurable exit premiums. The ones that ran AI pilots without governance trails are taking valuation haircuts. I have seen both.
The data stack question that precedes this one
Before we get into what buyers are looking for at exit, it is worth anchoring this to the foundational layer: clean data infrastructure is the prerequisite for everything here. We covered that case in the August piece on data infrastructure as a valuation problem. The question this piece addresses is what happens once the infrastructure is in place: how the AI built on top of it gets valued in an M&A process, and what the diligence team is actually looking for when they open the data room.
When the data room opens
The moment of truth for an AI-instrumented portco is not the deal announcement. It is day one of the data room.
Strategic acquirers, particularly platform companies and tech-enabled service businesses, are underwriting AI revenue contribution as a discrete line item. To do that, they need more than deployment evidence. They need documentation that can withstand a senior technical review team asking hard questions on behalf of an investment committee.
What has emerged over the last eighteen months is a consistent set of four questions that sophisticated buyers use to separate real AI capability from theater. Get these four right, and you have a defensible AI premium at the table. Miss them, and even a genuinely impressive AI deployment gets discounted.
Provenance: where did the training data come from?
When an AI system produces an output, a recommendation, a classification, a forecast, a scored lead, can you trace it back to the data it was trained on?
Buyers want to understand whether the AI runs on licensed data the portco owns, proprietary operational data that is genuinely defensible, or loosely assembled data with unclear rights. This distinction matters enormously at close. Data without provenance documentation is a liability, not an asset. Strategic acquirers building AI-compounding platforms need to know what they are buying, and if they cannot answer that question from the data room, they will either discount the asset or structure indemnities that accomplish the same thing.
The provenance question also surfaces dependency risk. If the AI capability relies on a third-party data provider under a contract that does not survive a change of control, the buyer has to price that transition cost.
Governance trail: eighteen months of documented usage
This is where most portcos that ran AI pilots fall short. A governance trail means you have twelve to eighteen months of documented AI usage: what models ran in production, on what data, with what human review process, what version was deployed at each point, and what the outputs drove in terms of downstream business decisions.
It is the AI equivalent of a financial audit trail. Without it, a buyer cannot underwrite the forward revenue contribution. With it, they can. The governance trail is also what separates an AI capability that survives post-acquisition integration from one that depends on institutional memory held by the team that built it.
Portcos that built governance discipline from the start of their AI deployments, not as a retrospective documentation exercise in the twelve months before exit, can typically walk a technical diligence team through the trail in a structured review session. That clarity converts into a defensible multiple. Portcos that cannot produce the trail spend the diligence period trying to reconstruct it, which neither the timeline nor the buyer's patience will accommodate.
Cost-at-load: the AI infrastructure P&L
AI infrastructure costs behave differently from traditional SaaS costs. They scale with inference volume, model complexity, and API dependencies in ways that can compress margin significantly at the buyer's projected scale of operation.
Strategic buyers are now building cost-at-load models for AI workloads as a standard part of financial due diligence. They want to see the portco's actual token economics, compute costs, and API dependency costs broken out as a discrete line item. They want to understand how those costs move when volume doubles or when the buyer integrates the AI capability into their own platform at higher throughput.
If the portco does not have that data, if AI infrastructure costs are buried in general cloud spend with no granular visibility, the buyer will assume the worst on margin trajectory. The habit of tracking AI infrastructure costs separately from the earliest deployments gives the operating team the data it needs to make a clear case at exit.
Model and key-person dependency: does this capability survive the acquisition?
The question buyers are quietly asking in every AI diligence process: if the two engineers who built this leave in the first six months post-close, does the AI capability walk out with them?
Productionized, well-documented AI that runs as infrastructure is worth acquiring. A model that lives in someone's notebook, or an AI capability that cannot be operated without the person who wrote it, carries a key-person risk that shows up in the valuation. Buyers underwriting a platform acquisition need to know they are acquiring a durable capability, not a team dependency.
The model registry is the artifact that answers this question. A living document or versioned system that tracks what models are in production, what data they run on, what version is deployed, and who holds operational responsibility is the difference between an AI capability that can be handed off and one that cannot.
Two portcos. Different outcomes.
I will work from a composite pattern here, because the specifics belong to confidential engagements. But the arc is one I have seen repeatedly across portfolio work.
The first type of portco enters the exit process with eighteen months of clean AI infrastructure: documented model versions, a governance log showing usage and decision influence, AI costs tracked as a discrete line item, and a training data provenance record. When the technical review team arrives, they get what they came for. They can trace outputs to sources, review governance decisions, and build a credible projection of AI's contribution to the forward EBITDA case. That portco's multiple reflects a buyer paying for an underwritable, de-risked AI capability.
The second type has run AI pilots, in some cases sophisticated ones with genuine business impact. But there is no governance trail. Model versions were not logged. Usage was not instrumented against business outcomes. Data sources are described loosely in internal documentation that was never structured for external review. When the technical team arrives, they cannot make the AI contribution legible to the investment committee. What was presented as an AI-enabled business gets valued as a traditional business with AI experimentation in the footnotes. The haircut is real, and it is entirely preventable.
The difference is not the sophistication of the AI. It is the auditability.
What building the trail actually looks like during hold
The natural question for an operating partner reading this: what do I actually do in months one through twenty-four?
The work is less glamorous than it sounds. It is mostly discipline applied to the AI deployments you are already running or planning to run.
At minimum, portcos that exit well on AI have three things in place. First, a model registry: a living record of what models are in production, what data they run on, what version is deployed, and who owns it. Second, a usage log tied to business outcomes: not just confirmation that the AI ran, but documentation that the AI recommendation drove decisions in a given workflow, with downstream revenue attribution where possible. Third, a cost dashboard that shows AI infrastructure spend as a discrete line item, broken out from general cloud spend.
None of this requires a significant data engineering investment on day one. It requires assigning ownership in the first portfolio review after acquisition and treating AI governance as an operational discipline rather than a pre-exit documentation sprint.
The portcos that get this right typically start the conversation in the first six months. Because twelve months before exit, you cannot manufacture eighteen months of clean governance history. You can only work with what exists.
The exit premium is earned during hold, not at the data room
There is a version of this conversation that happens in the data room and goes badly. The technical review team asks for the governance trail, and the answer is: we are building that documentation now. At that point, the multiple conversation has already happened, and it happened without the AI premium.
The version that goes well starts eighteen months earlier. An operating partner sits down with portco leadership, asks which AI deployments are going to production in the next twelve to eighteen months, and makes one clear request: build it instrumented from the start. Log the governance. Track the infrastructure costs separately. Document the data sources at the moment of deployment, not in retrospect.
The payoff comes when the data room opens and the technical review team gets what they came for: a clean, auditable record of an AI capability that a strategic buyer can underwrite.
That is what the exit premium is built on. Not the sophistication of the model. The legibility of the evidence.