Bob had owned the technology, the data, and the security at three companies, which is why Alex called him before signing anything. Bob’s answer was a story about the one time he bought from the safe option.
It was the safe option that cost him.
The vendor was a global automation company with a recognized name and customers on every continent. Its AI product was presented as proven, supported, and already running in production elsewhere. Reference customers came up repeatedly in conversation and were never produced, citing confidentiality. The demonstrations were convincing. His team signed a two-year commitment.
They did not sign it with the global company. The paper came through a third-party reseller, presented as a procurement formality and accepted as one.
Who Actually Built the Product
The product had been built by a company of about two dozen people. The global vendor had contracted the relationship, not the capability. Development ran through that small team, and so did support.
When the system failed to do what had been demonstrated, the small company could not fix it at Bob’s scale. The global vendor would not stand behind a product it had not built and did not understand.
Bob told the reseller his company would stop paying for software that did not work. The reseller agreed with him, which turned out to be irrelevant. It had already committed to the global company for the full term and could not recover the money. It could not fix the product either, because it had never had access to the people who built it. Caught between a customer who would not pay and a supplier that would not refund, the reseller did the only thing available to it and sued Bob’s company for the balance.
None of this was a breach. The contract had been written by people who assumed the technology worked, and it protected the party that had been careful. Bob spent a year in litigation with the one company in the arrangement that had done nothing wrong, over a product built by a company he had never contracted with, sold under the name of a company that was not party to the agreement at all.
“That layer is not an accident,” Bob told Alex. “It is the product. They keep their name on the demonstration and their signature off the contract. We checked what we were buying and never checked who we were buying from — and I am not certain they would have told us if we had asked.”
Why the Usual Diligence Does Not Protect You
Enterprise software buying evolved around products with a decade of production history, a visible customer base, and a support organization a buyer could inspect. Most of that infrastructure of trust does not exist yet. Many products are only a few years old. Many of the companies behind them are smaller than their websites suggest. Some will not exist when the contract renews.
It helps to understand the market’s structure. There are tens of thousands of AI tools and no reliable count, because new ones appear constantly and others disappear without announcement. Only a handful of companies build the underlying models many of those tools depend on. Much of what a company evaluates as an AI product is an interface, a set of instructions, and a contract wrapped around a model the buyer could reach directly.
Some of those wrappers are genuinely valuable. They encode a workflow, a body of domain knowledge, or an integration that would take a year to build. Others are a login screen and a markup. From a demonstration, the two look identical.
Meanwhile every vendor claims the full range of capability, and every one has a demonstration that works. The claims are not usually lies. They are closer to promises about a roadmap, delivered in the present tense.
Three Questions That Are Not on the Comparison Sheet
The first is who actually built this and who actually supports it. Not which logo is on the contract, but which engineers fix it when it breaks, at which company, and how many of them there are. If the answer involves an acquisition, an original equipment arrangement, or a partner, the buyer needs the same diligence on that second company as on the first, because that is the company the product depends on.
The second is who is actually on the paper. Reseller arrangements are ordinary in enterprise software and usually harmless. They stop being harmless when the product is unproven, because the counterparty becomes a company that cannot repair what it sold and has no leverage over the company that can. If a vendor will not contract directly, make the builder a party to the agreement through a support commitment, a step-in right, or a direct warranty, so the obligation to make the product work sits with someone capable of doing it.
The third is what happens when it does not work. A demonstration proves a system can produce a good answer under conditions the vendor selected. It proves nothing about the distribution of answers on your data, in your edge cases, at your volume. The only reliable evidence is the vendor’s product running on your data, measured by your standards, before the commitment.
On references, Bob had become skeptical of any vendor that could not produce them. Confidentiality can be a real constraint, but he wanted several production customers rather than one carefully selected example. He wanted to know what had gone wrong, how long it took to fix, and whether the reference had been compensated through discounts, credits, or early access. Then he wanted those representations reflected in the agreement, where they carry more weight than a sales promise.
Protection Is Negotiated While You Still Have Leverage
The commercial terms follow from the same logic: commitments tied to performance, terms short enough to survive a bad decision, clarity about who actually provides support, and an exit that returns your data in usable form without making a failed product expensive to leave.
None of that is unusual to ask for. It is unusual to ask for it in a market where buyers are worried about being late.
Bob raised one more exposure before they hung up, and it sits outside the contracts most teams are focused on. If your company uses an outsourcer, a managed service provider, or an offshore delivery partner, that partner may be using AI tools inside the work without your knowing which ones. The provider chose them, evaluated them, and is under commercial pressure to use them. Your data flows through software you never assessed, under terms you never read.
The remedy is unglamorous. Ask in writing. Require disclosure of any AI system used in delivering the service, with notice before it changes. Most providers will answer. The ones who resist have supplied useful information too.
The Decision Underneath the Purchase
All of this sits on top of a more basic question, which is what the company cannot afford to lose control of.
If the work is common, buying it may be enough. If it carries company-specific judgment or advantage, the company needs to own more of the logic. If the expertise is missing, a partner can help without taking over the design.
The question was never whether to build, buy, or partner. It is what you have to own, what you can rent, and what you need to keep changeable. Answer that first, and the contract you sign is a consequence of a decision you made rather than a decision someone else made for you.
Adapted from Feasible, Not Achieved: Why AI Transformation Stalls and the NINE Decisions That Finish It, by Weston A. Jones, MBA and Jacob C. Roxon, PhD (JRNine Press).
The Jones-Roxon Nine™ is the Operator’s System for AI Transformation.