Can the AI Capability Survive the Acquisition?

By Mark | strategy | 6 min read

An AI related acquisition may appear to offer a valuable model, dataset, product, or team. The buyer's decision is narrower and harder: will the capability that makes the target attractive still work, remain available, and be worth owning after the transaction? Demonstrating current performance is only a starting point. The buyer needs to understand the conditions that produce that performance and which of those conditions can survive a change of owner.

This article proposes a capability transfer test for diligence. It does not replace the wider acquisition thesis, financial review, or legal advice. It asks whether a particular claimed capability can be reproduced and maintained under the buyer's ownership. That question is different from whether the buyer has an attractive overall deal, and different again from whether the buyer is ready to integrate a new organization. Keeping those decisions separate helps the deal team identify where a premium rests on evidence and where it rests on hope.

Define the Capability Before Valuing It

The label AI capability can cover very different assets. One target may have a proprietary collection of domain specific data. Another may have a well designed workflow around a widely available model. A third may have an engineering team that can adapt systems quickly but little owned technology. These may all be valuable, but they involve different dependencies, rights, and costs. The buyer should state which capability it expects to own and how that capability produces customer or operational value.

A proposed test begins with a dependency map. Trace the claimed result backward through product workflow, model, data, infrastructure, people, and external providers. Then ask which components the target controls, which it licenses, which depend on customer permissions, and which require particular people or relationships. The map should show where the result might change if a supplier changes its terms, a customer revokes access, a key engineer leaves, or the system runs on different data.

Do not assume that owned data is automatically useful or that licensed technology is automatically weak. Exclusivity may matter in one market and not another. A licensed model may support a defensible product if the target's workflow, customer access, implementation skill, or data rights are difficult to replicate. Conversely, ownership of a model may have limited value if customers can obtain comparable outcomes through another service. The acquisition question is the durability of the entire capability, not the attractiveness of any one label.

Verify Performance Under Relevant Conditions

A demonstration shows that a system can produce an output. It does not establish how reliably that output serves the proposed use. Independent technical reviewers should understand the evaluation method, comparison baseline, relevant errors, and conditions under which performance changes. Where access permits, tests should use data that the target did not select to flatter the system and cases that resemble the buyer's intended environment.

Reviewers should ask whether training and test data were separated appropriately, whether the system relies on information that would not be available at the moment of use, and whether apparent success holds across materially different customers or conditions. They should examine the cost and effort required to maintain performance, including monitoring, retraining where appropriate, and human review. Not every system degrades on a predictable schedule; deterioration depends on the use case and changing conditions. The right question is how the target detects and responds when the environment changes.

Hypothetical example: A target demonstrates strong predictions on its existing customers' records. The buyer expects to use the system in a different business line. Independent testing with permissioned records from that business line shows weaker results, especially where key fields are incomplete. This does not prove the product has no value. It may support a narrower use case or additional investment. It does mean the buyer should not pay as though the broader deployment were already established.

Technical access can be constrained by confidentiality, customer obligations, or a live auction. A buyer can use staged access, independent reviewers, defined evaluation protocols, and appropriate protections rather than demand unrestricted copies of sensitive materials. If a decisive test cannot be completed, the gap belongs in the valuation and approval discussion. A carefully documented limitation is more useful than a confident conclusion based on a controlled demonstration.

Test Rights and Dependencies, Not Just Possession

The ability to access data today is not the same as the right to continue using it after a change of control or for a new purpose. The same distinction applies to model weights, third party services, code, customer feedback, and improvements created under commercial agreements. Counsel and technical reviewers should jointly map the permissions required for the precise post closing use proposed in the investment case. The relevant agreement, jurisdiction, data type, and transaction structure all matter; no general statement about ownership resolves every case.

The practical test is continuity. What services or permissions are necessary to serve customers on the first day after closing? Which can be terminated, repriced, or restricted? Are there credible alternatives, and what would a transition cost? The goal is not to treat every outside dependency as disqualifying. It is to identify dependencies that are material to the premium and determine whether the buyer can control, contract for, or reasonably replace them.

Human knowledge also sits in the dependency map. Ask who understands the data pipeline, model evaluation, deployment process, and customer exceptions. Review documentation and the distribution of that knowledge across the team. A retention agreement may help, but it cannot make tacit knowledge portable by itself. The buyer should consider whether essential people want to remain, whether their roles after closing are coherent, and whether the capability can be maintained if a particular individual departs.

Connect Findings to the Decision

A proposed decision matrix can classify findings as demonstrated, conditionally transferable, or not yet demonstrated. A demonstrated capability has relevant performance evidence, usable rights, and a credible maintenance path. A conditionally transferable capability depends on defined actions, such as obtaining consent, completing an independent test, retaining identified knowledge, or funding an infrastructure change. A capability that is not yet demonstrated may still be attractive, but the buyer should describe it as an investment to develop rather than an asset already proved.

Those classifications should affect the economics. For each material dependency, identify its owner, the action required, the likely cost, and the consequence if the action fails. A buyer might change the scope of the deal, stage deployment, adjust the price, seek a contractual condition, or decide that the uncertainty is too consequential. The appropriate response depends on the transaction; the framework does not dictate a universal discount or legal term.

This is where diligence can produce a useful counterargument to itself. Extensive testing can delay a deal, consume specialist resources, and require access the seller cannot safely grant. A rapid purchase of a capable team may sometimes be rational even when a product cannot be fully validated in advance. In that case the buyer should be explicit that it is buying talent and an opportunity to develop, not a proven model advantage. Clear classification allows speed without disguising what remains uncertain.

AI is not a reason to abandon conventional diligence. Revenue quality, customer commitments, security posture, contractual obligations, and the costs of running the business remain central. Nor should a technically impressive system dominate a decision if customers will not pay for it. Capability diligence earns its place when it links technical evidence and rights to the specific benefit the buyer expects after closing.

The useful output is not a declaration that the target has AI. It is a decision record explaining what works, under which conditions, through whose efforts, with which permissions, and at what continuing cost. Only then can executives decide whether they are acquiring a durable advantage, a promising but unfinished capability, or a dependency they are not prepared to own.

Executive Imperatives

Executive Imperative: Define the capability that supports the proposed premium. Map its product, data, model, provider, infrastructure, and people dependencies before treating the demonstration as proof of transferable value.

Executive Imperative: Commission a proportionate independent performance assessment using relevant comparison cases where access permits. Record limitations openly and test the intended use, not just the target's preferred demonstration.

Executive Imperative: Have legal and technical reviewers examine together whether required data, software, and service rights support the precise use planned after closing. Document material permissions and dependencies that remain unresolved.

Executive Imperative: Classify each material capability as demonstrated, conditionally transferable, or not yet demonstrated. Connect that classification to price, transaction conditions, development costs, and the decision to proceed.