Why the demo is not the deployment

A demo reads a sample invoice, extracts the amount and posts a neat approval summary. In the actual process, invoices arrive through three channels, some belong to another legal entity, and the approval system accepts only users with a particular role. The extraction still works. The workflow does not. This is an illustrative case, not a customer report.

A discussion of deploying AI into older business systems points to data, existing software and local habits as the stubborn part of deployment. The speaker describes one company’s practice, not a general success rate. The useful distinction is between proving a component and putting it to work.

The demo chooses its environment

A demo can select clean inputs. It can pre-authorize the account, skip the queue, reset a failed run and let its creator explain an ambiguous output. Those choices are reasonable for proving a capability. They become dangerous when the team treats the capability test as proof of operational readiness.

For the invoice example, extraction is only one step. The organization must establish which inbox is authoritative, how duplicates are detected, whether the amount can be changed after submission, who is allowed to approve, and where a failed posting goes. A generated summary cannot answer those questions by being more eloquent.

The boundary is easiest to see by following one work item from arrival to accepted result:

Demo capability prepared input

Local integration data permissions recovery

Operator workflow accepted result

A demonstrated capability becomes useful work only when local data, permission and recovery connect it to the actual operator workflow.

Stage	Demo question	Deployment question
Input	Can the model read this example?	Can it receive every authorized format and reject the rest?
Context	Can it find an amount?	Can it match the right supplier, entity and policy version?
Action	Can it create a summary?	Can it perform only permitted actions and avoid duplicates?
Failure	Can the presenter retry?	Who sees a stuck item, corrects it and resumes safely?
Adoption	Does the output look useful?	Does the responsible person use and trust it in the real queue?

This comparison is conceptual. It does not imply a measured failure rate for AI projects.

Trace the local state

Data integration is often called the last mile, as if it were a cable to attach after the product is finished. The local data model can change what the product means. One business may consider an invoice “received” when it lands in an inbox; another may count it only after a purchase order match. If the system acts on the wrong state, a technically valid API call can still be a business mistake.

Ask where each fact originates and who can correct it. Then ask what the system does when facts disagree. If a source record changes after the model has drafted an approval, should the draft be invalidated? If a permission is revoked while a task is queued, does the worker recheck before acting? These questions are the deployment, not polish around it.

The workflow discovery article starts earlier, with observing what operators actually do. Here the question is what must be true for a demonstrated capability to survive contact with that workflow.

Prototype the capability, then test the workflow

A small prototype can be the fastest way to learn whether a model can do the core task at all. It need not carry production controls on day one. The mistake is to schedule the remaining work as a minor wrap-up without inspecting it.

A useful prototype declares its boundary. It might say: “This reads approved sample invoices, suggests fields and takes no external action.” The next test can use authorized live records while keeping posting disabled. Only after data matching, permissions and recovery are understood should it write to the approval system. Each step answers a different question.

Deployment also has a human edge. A person who already resolves ambiguous invoices needs a way to correct the suggestion, see what was changed and know whether the system will repeat the same error. If the new workflow adds more checking than it removes, usage will tell that story. Do not infer adoption from a successful demonstration.

The release gate can be phrased as an operational question: can a different authorized operator complete and recover one work item without the demo creator in the room? That operator should be able to find the original input, see the proposed action, identify its permission basis and route a failure. A rehearsed rollback matters because a successful first run says nothing about a duplicate or a partial write. The guide to implementing AI in existing workflows offers a broader rollout frame. For this gate, keep the test narrow and repeat it on the one exception most likely to break the happy path.

The result to count is not a generated output. It is an accepted work item in the real process, with a known route for exceptions. Until that path works, the demo remains valuable evidence about one component. It is not evidence that the job is done.