The company is not the capability: Rethinking diligence in AI transactions

In July 2025, Google paid a reported USD 2.4 billion for something unusual. It did not buy Windsurf, the AI coding startup formerly known as Codeium. It did not buy the product, the customer base or the brand. It hired the company's chief executive and core research leadership and took a non-exclusive licence to Windsurf's technology. Days later, Cognition AI, the startup behind the coding agent Devin, acquired what remained i.e. the intellectual property, the product line, the brand, the operations and, most importantly, the engineering, product and go-to-market teams.

One company, with two buyers. Windsurf as a legal entity and operating business went to Cognition AI, whereas, Windsurf as a concentration of talent, know-how and technology access went, in commercially significant part, to Google. It thus turns out that "Who acquired Windsurf?" is the wrong question. The right question is "which capability did each of them acquire"?

Every transaction turns on a clear understanding of what is actually being acquired. Historically, that was straightforward, and consisted of shares, assets, intellectual property, software, data, employees or contractual rights. In AI transactions, it can be a lot more complex. The capability a buyer is paying for may depend on source code, training datasets, customer inputs and feedback, third-party models and APIs, and the individuals who understand how these elements work together.

AI has not displaced the traditional subjects of technology contracting. What has changed is how easily those components can now be separated, legally and commercially. A company may own some of them, others may be licensed from vendors or controlled by third parties or exist mainly as employee know-how. Acquiring the entity does not necessarily secure the capability, and simply acquiring the code or licensing the model may not preserve the ability to improve, deploy or commercialise it.

Lawyers must therefore contract not merely for ownership of a company, technology or output, but for the continuing ability to develop, deploy and commercially exploit the capability the parties are paying for. A transaction that misses a necessary component may deliver an AI system with little commercial value at all.

Regulators have already caught up with this reality. In March 2024, Microsoft hired the core team of Inflection AI, including two of its co-founders, and took a non-exclusive licence to its intellectual property. Microsoft did not acquire the company. The UK Competition and Markets Authority ("CMA") nonetheless concluded that it had jurisdiction to review the arrangement because a relevant "merger situation" had been created. The CMA cleared the deal at Phase 1 in September 2024, but the jurisdictional finding gives us the lasting lesson that moving a team with the relevant know-how, together with associated arrangements, can by itself amount to a merger.

Every AI transaction should therefore begin with a mapping exercise to identify the capability being acquired and the terms on which it will continue. This is not a technical formality. It determines the diligence perimeter, the allocation of risk and, ultimately, valuation.

The cost of skipping it is easy to illustrate. A buyer paying for a continuously improving enterprise AI product may receive far less than expected if it acquires the software but cannot keep using deployment data to improve it. A customer licensing an AI tool may not get the benefit it anticipated if the provider can swap the underlying model, discontinue a critical feature or use the customer's information in ways never contemplated at signing. Equally, a contractual promise to provide an AI service is worth little if the provider loses access to the model, data or compute needed to perform it.

The map closes that gap by connecting each source of value to the legal right, contractual permission, individual or external dependency on which it rests. Three categories deserve particular attention: inputs, outputs and people.

"Input" is often used as if it were a single category of information. In practice, an AI system receives information at several stages and from several parties: training data, fine-tuning data, customer documents, user prompts, confidential business information, personal data, feedback, corrections, and material retrieved from connected databases. Each may be governed by a different set of rights and restrictions.

The contract should establish where that information came from, why it was collected, what rights the supplying party holds, and what restrictions flow from confidentiality, privacy or third-party intellectual property. It should say whether information may be used only to deliver the contracted service or also to train, test and improve the system; whether it may be combined with other customers' information; whether it may be retained after termination; and whether the rights survive an acquisition or assignment.

A generic representation that a party owns or may use "all data" answers none of this. The agreement should distinguish data that is owned, licensed, accessed on a customer's behalf, generated through use of the system, or inferred from other information; and separate the right to process information for the immediate service from the right to use it for model training or product improvement.

The distinction matters under the Digital Personal Data Protection Act, 2023, which ties the processing of personal data to a lawful purpose and, where consent is relied upon, to the purpose communicated to the data principal. Its obligations are coming into force in phases through 2027, but the direction is settled: a corporate acquisition or contractual assignment does not, by itself, establish that personal data may be repurposed for retraining, testing or a materially different commercial use. The diligence question is not whether the target possesses a dataset. It is whether the post-transaction business may lawfully continue to use that dataset in the manner the valuation model assumes.

The hardest rights questions often concern neither the original inputs nor the immediate outputs but what the system generates while it runs, i.e., evaluation datasets, reinforcement feedback, prompt templates and workflows, customer-specific configurations and improvements derived from deployment. Put simply, the system gets better as it is used, and the things that make it better are assets in their own right. Yet they are routinely included under broad labels such as "feedback", "usage data", "improvements" or "derivative works".

The agreement should identify who owns each category, who may use it, whether use is confined to providing the services, whether it may be generalised into the provider's platform, and what happens when the relationship ends. A customer may reasonably expect that a bespoke model built on its confidential information will not benefit its competitors; the provider may reasonably want to keep general learning and platform improvements. Neither expectation survives an undifferentiated clause granting ownership of "all intellectual property developed under the agreement."

A more workable approach is a rights matrix with customer information and customer-specific artefacts on one side, and provider technology, generalised improvements, model-level changes, genuinely anonymised operational information on the other. The drafting should follow the technical architecture of the system rather than forcing materially different assets into a single ownership category.

As Windsurf and Inflection AI show, much of an AI company's capability sits with its people. However, Indian law makes that component difficult to lock in. Section 27 of the Indian Contract Act, 1872 renders agreements in restraint of trade void, subject to a narrow exceptions.

Retention has to be designed into the transaction instead with continued employment, meaningful incentives, deferred consideration, knowledge-transfer obligations, confidentiality, intellectual-property protections, and conditions tied to the continued participation of identified individuals. The point is not to treat employees as transferable property. It is to recognise that the commercial premise of the deal may fail if the people who can operate and improve the technology do not stay.

The future of AI contracting is not the abandonment of conventional contract principles, but their application to a less static subject matter. The bargain now runs from what is fed into the system to what the system produces, from the original technology to what is created through use, and from legally owned assets to the people, permissions and infrastructure that keep the system running.

For transactional lawyers, that changes the sequence of analysis – first identify the capability the parties are paying for, then map every component that capability needs to continue, and then determine which components are owned, licensed, personal, contractual or dependent on third parties. Only once all that has been carried out can the structure, diligence scope and contractual protections be settled.

In many AI transactions, the company, the software or the output will remain central to the bargain. It may no longer, however, be the whole bargain.

About the authors: Ashima Obhan is a Senior Partner and Arzu Chimni is an Associate Partner at Obhan Mason.

Disclaimer: The opinions expressed in this article are those of the author(s). The opinions presented do not necessarily reflect the views of Bar & Bench.

If you would like your Deals, Columns, Press Releases to be published on Bar & Bench, please fill in the form available here.