The demo went well. The business sponsor was excited, the pilot worked, and everyone agreed the platform could save the team real time.
Six months later, the deal is still in security review. Or legal. Or procurement. Nobody said no. The answers just never quite arrived.
This happens so often that many AI vendors treat it as a sales-cycle problem. It isn't. It's a design problem, and it shows up in procurement because that's where someone finally asks a different question.
The demo asks: what can it do? Procurement asks: what happens when it goes wrong?
Demos prove possibility. Procurement assesses consequence.
A demo is built to show the best case. That's its job. But the people who have to sign off on an AI platform aren't evaluating the best case. The security team, the risk function, legal counsel, internal audit and, increasingly, the insurance broker are paid to think about the worst one.
Novelty doesn't reassure them. Evidence does.
The questions that actually decide the deal
Across industries, the questions that stall AI purchases are remarkably consistent.
1. Where does our data go, and who else touches it? Which model providers, which subprocessors, which regions. Whether anything is retained or used for training. A vague answer here ends most conversations.
2. Can you show us what happened? Not a dashboard. A record of what each agent did, on whose authority, with what data, that can be exported and read without the vendor's software.
3. Who carries the liability? AI vendors typically limit their own liability in their contracts. Insurers are adding AI exclusions to standard policies. And, as a March 2026 report from Gallagher Re, MIT and Testudo put it, liability is increasingly being placed on the organizations that operate AI rather than the providers of the technology. That leaves the buyer holding the risk, so the buyer needs controls they can point to.
4. What changes without our knowledge? Model versions, behavior, terms, pricing. Buyers have learned that the system they approve can quietly become a different system.
5. Can it run inside our boundary? For many organizations, "our data never leaves" needs to be an architectural fact, not a contractual promise.
6. Who approves what the agents do, and where is that recorded? This is the question from the first article in this series, and procurement asks it directly.
7. Can we leave? If we switch vendors in year three, do we keep our agents, their definitions, their history and our evidence? Or have we, in effect, rented a cage?
Why platforms fail these questions
Most AI platforms fail these questions for reasons that were decided long before the sales cycle started.
They were built for the builder, not for the risk function. The first customer was a developer or a business team, and the product delighted them. Governance was added later, as features rather than design.
Their evidence is locked in. Activity is visible inside the product, in a proprietary format. That helps the operator. It doesn't help an auditor, who needs to check the record independently.
They mark their own homework. When the vendor that supplies the model also enforces the policy, keeps the only record of what happened, in its own environment and format, and reports on whether it complied, every control shares one point of failure. Risk teams notice.
They make leaving expensive. Lock-in that looks like a commercial advantage to the vendor looks like concentration risk to the buyer.
None of this is solved by a better demo or a longer security questionnaire response. It's solved by designing for the second question from the start.
A practical suggestion for both sides
For buyers: bring security, risk, legal and audit in during the first week of an evaluation, not the twelfth. Ask for evidence as part of the demo: show us an action that was blocked, a decision that was escalated, and the record of both.
For vendors: treat the procurement questions as product requirements. If a question can only be answered with a slide, it's a gap in the product.
Designing AI people can trust
That brings this series to a close. Across six articles, the argument has been the same from different angles: people trust AI systems when the humans in them have real decisions to make, when errors are understood and not just counted, when behavior is bounded and repeatable, when change is visible, when every agent has an owner, and when all of it can be shown to someone who wasn't in the room.
None of that is a constraint on what AI can do. It's what allows organizations to let it do more.
We built Operon for this conversation: agents are built, run and governed on one platform that stays independent of the model providers underneath it, with the evidence produced as the work runs and kept in storage you control, in our cloud or yours. Our answers to the hardest procurement questions are public: operonstudio.com/cto.html