The AI prototype worked. Who promised the launch?

“Sure, we can figure it out.”

Earlier in my career, I used those words to avoid an uncomfortable conversation. I meant I would assess the request and explore what was possible. The person asking could hear that I had accepted the work and would deliver what they wanted.

I learned to be explicit, sometimes to the point of repeating myself. What felt redundant to me helped someone else understand what I was actually promising.

Consider this scenario. Joe, a colleague in operations, builds an AI assistant that answers questions about internal procedures. He tests it against a small collection of documents. His colleagues find the answers useful and want to use it. Their manager suggests launching across the department next month. IT agrees to assess how it would connect to the company’s knowledge base.

By the next executive meeting, the update reads: “Assistant complete. Awaiting IT integration.”

A demonstration has become a launch commitment. IT’s offer to investigate has become the remaining task.

Clarify the promise before the date travels

Before explaining what Joe’s assistant still needs, I would ask what his prototype reveals about us.

He understood a recurring frustration: colleagues spending time searching for procedures or asking someone who knew where to look. He produced something they found useful. If that improvement would have spent months in our backlog, we should examine why.

Did we underestimate the problem? Was our intake process too demanding for the size of the request? Did watching colleagues use the assistant reveal something a requirements document had missed?

The prototype gives us evidence worth investigating. We can see which questions people ask, which documents help them and where the existing knowledge base makes answers difficult to find.

That first conversation matters. If we respond mainly with requirements Joe has not met, colleagues may learn that involving IT makes their work harder. They may bring us the next application even later.

Before asking why IT is holding up the launch, I would ask what everyone heard when we agreed to help.

Joe thinks he has demonstrated a promising solution. IT has agreed to assess a connection. The manager expects a launch.

Everyone can leave the same meeting encouraged without recognizing that they have understood it differently.

Our language helps that misunderstanding take hold. “We’ll take a look” leaves the next step undefined. “We should be able to support this” may sound like confirmation that the proposed date is achievable.

Correcting the interpretation gets harder once the date has been shared. Asking questions then can look like retreating from a promise others believe we made.

The discomfort deserves attention. Are we leaving an assumption unchallenged because we want to appear responsive? Are we worried that clarifying the work will sound like resistance?

Before the date travels further, I would say plainly: “We have agreed to assess the connection. We have not yet confirmed the work or the launch date.”

Explain the work behind the launch

During the assessment, IT discovers that Joe manually selected the documents used in the demonstration. The wider knowledge base contains older versions of procedures and documents with different access restrictions. The prototype has not been tested against conflicting sources or questions the documents cannot answer.

Nobody has agreed who will maintain the source material or investigate an incorrect response after launch.

IT needs to make that remaining work understandable. “Security review pending” tells the sponsor where the assistant is sitting, but little about what needs to happen.

A more useful explanation is: “The wider knowledge base includes documents with different access permissions. We need to verify that employees cannot receive information through the assistant that they are not authorized to access in the source documents.”

Then explain who owns that work, what happens next and when the sponsor can expect an estimate. If a decision is needed, name it.

I would hold IT accountable for those answers. A team that identifies concerns without providing a route forward can become the bottleneck colleagues describe. Better wording will not fix an indefinite review queue.

We also need to justify the level of scrutiny. A limited trial using approved, nonsensitive documents may warrant a lighter assessment than an assistant searching restricted information or advising employees on consequential decisions.

Microsoft’s guidance for Copilot Studio distinguishes personal experimentation, departmental use and mission-critical enterprise applications, with governance controls suited to each. I would use that distinction to discuss what the proposed launch actually involves.

Agree on the next commitment

Gartner’s 2026 survey found that only 31% of CIOs reported having guidelines for deciding when an AI pilot should not advance to production. At the first discussion about wider adoption, I would ask three questions to establish what we are ready to promise.

1. What has the prototype demonstrated?

Give the sponsor an accurate account to share: “Joe has shown that an assistant can help colleagues find answers in a selected collection of procedures. We have not yet assessed it against the wider knowledge base, different access permissions or conflicting sources.”

2. What must be true for the next intended use?

I would first agree on the next step. A supervised trial with five users and approved documents is a different commitment from departmental access to the wider knowledge base.

For that step, identify the essential conditions, who will meet them and how readiness will be judged. Agree on representative questions, expected answers and what the assistant should do when it cannot find sufficient information. NIST’s Generative AI Profile identifies pre-deployment testing as a central consideration in managing generative AI risks. I would ask the team to show what its tests establish about this intended use.

Name the business owner responsible for the source material alongside the technical owners responsible for access, integration and support.

Keep Joe involved where his knowledge helps. His initiative should not automatically make him responsible for maintaining the assistant indefinitely.

3. What would we need to change to commit to it?

Establish whether the work fits within available capacity. If it does, say so. If it competes with existing commitments, identify which ones and involve the affected owners.

“Capacity is tight” gives the sponsor little to act on. “This needs the integration team assigned to the migration” makes the choice visible. Explain the consequence and recommend a workable option.

Include the business work too. Reviewing procedures and resolving conflicting documents require time from people outside IT. A launch plan that assumes their availability without agreement is incomplete.

Before the meeting ends, ask the sponsor to describe what they will report to the executive team. If they say “launch next month” while your team believes it has agreed to an assessment, the misunderstanding is already present.

Resolve it there. Once the date enters the executive update, clarifying the commitment may look like changing it.

If Joe’s assistant needs the integration team assigned to a platform migration, I would bring a recommendation to the discussion.

I would assess whether to revise a migration milestone, obtain qualified capacity or narrow the initial deployment. A trial limited to approved documents could help the team evaluate usefulness while the broader connection is assessed.

Explain the consequences, identify what remains uncertain and state which option you support.

We also owe Joe’s idea a fair comparison with work already approved. His prototype may reveal a better use of resources. Are we protecting the migration because its next milestone matters more or because it is already in our plan?

The next executive update is a test of whether that discussion worked.

“Assistant complete. Awaiting IT integration” conceals the decisions still needed. A useful update might say:

“Joe’s prototype helped colleagues find answers in selected procedures. We have approved a five-user trial using a reviewed document set. Broader launch remains subject to permissions testing, content ownership and a decision about integration capacity.”

Sometimes IT really is taking too long. We owe colleagues a proportionate assessment, a recommendation and a credible next step.

We also owe our teams clarity about what we have promised. Before the next demonstration becomes a launch announcement, ask the sponsor what they believe has been agreed.

Then ask yourself: did my offer to help sound like a promise to deliver?