An AI demo becomes safe to pilot only when a named person can approve its access, own its outputs, and stop it when the workflow changes. Model quality matters, but authority over the live process decides whether the work can begin.
At 4:40 on a Friday, Kojo was still holding his coffee because he had forgotten to drink it. He had spent the last twenty minutes showing a small operations team how the AI could read incoming requests, pull the relevant fields, and prepare a draft for review. It handled the awkward examples. It asked for missing information. Nobody had to rescue it.
Then someone asked the question that ended the room’s momentum.
“Who can approve it touching the live queue?”
The operations lead looked at the product manager. The product manager looked at the head of customer support. The support lead said the queue belonged to their team, but the data came from another system and access sat with IT. IT was not in the meeting.
By Monday, a promised pilot could have become another demo people remembered as impressive but unsafe. The customer still had the same backlog, and Kojo’s team still had a working product. Neither fact gave anyone authority to let it cross into production.
The demo answered the wrong question
A good demo proves that the product can do something useful. That is often enough to get a second meeting, especially when a founder has built the workflow around examples the customer recognizes.
It does not prove that the customer has made the internal decision required to use it.
I have seen this gap show up across teams in Africa, Germany, and the US. The language changes. The structure stays familiar. A department wants the outcome, a technical team controls access, a manager worries about accountability, and no one has agreed who can make the call when the AI gets something wrong.
That last part matters more than most teams admit.
An AI tool can create a draft, classify a request, or suggest an action. Once it enters a live workflow, somebody needs to decide what it may read, what it may write, which actions require review, and who owns the exception when the process changes on a busy Tuesday. If those decisions are spread across four people who each believe somebody else has the final word, the pilot has no real path forward.
The same ownership problem appears when everyone approves the code but nobody owns the workflow. Technical approval can be sincere and still leave the operational decision untouched.
A useful meeting changes shape at the point of friction
Kojo could have filled the silence by offering another walkthrough. Instead, he closed the demo tab and asked the support lead to describe the first live request the AI would touch.
It was an ordinary request, the kind that came in late on a Friday and created a chain of manual follow-up. The support lead knew where it arrived. The product manager knew what information had to be collected. The IT contact, reached by phone after the meeting, knew which integration could expose the data safely.
None of them had been asked to make the decision together before.
That is the turn worth looking for in a sales or discovery meeting. The conversation moves from “Can the AI do this?” to “What has to be true for us to allow this one action?”
The answer should be small enough to test. One queue. One class of request. A named reviewer. A written rule for what the AI can prepare and what it cannot send. A way to pause access if the team sees a failure mode they did not anticipate.
Broad promises create a meeting full of agreement and a pilot full of ambiguity. A narrower first workflow creates a decision that someone can actually own. Tayo’s team learned that after a broad automation promise failed.
Authority has to be visible before access is granted
There is a practical test I use before calling a demo successful: can the people in the room name the person who can approve the first production action?
If the answer is “we will need to check,” the product is still in discovery. That is useful information. It prevents the founder from mistaking enthusiasm for readiness and prevents the customer from agreeing to a scope they cannot operationally support.
The owner does not need to carry every responsibility. They need the authority to gather the right people, approve the boundary, and make a call when the workflow needs to change. Their name should appear in the pilot plan beside a specific decision, not as a vague executive sponsor.
Teams often try to solve this with a longer security questionnaire or another technical review. Those may be necessary. They do not answer the ownership question. The constraint can sit in a customer’s process even when the model is accurate and the integration is ready.
That is why the first question after a successful demo should be operational: “Who owns this workflow on the day we turn it on?”
The first pilot should make the decision reversible
Kojo left the customer with a smaller proposal than the one he had prepared. The AI would prepare drafts for a limited part of the queue. A support manager would review every output. The product manager would own the weekly decision on whether to expand the scope. IT would approve the access boundary before anything connected to live data.
The product had not become less capable. The customer had made the risk legible.
On the following Friday, Kojo’s coffee was cold again, but the meeting was different. The support manager had brought three edge cases from the week. One revealed a missing rule. Another showed that the drafts were saving time. The third was paused because nobody could explain the right response yet.
That pause was progress. Someone had the authority to make it.
Comments
No comments yet.