From AI demo to useful workflow: what needs to work?

An AI demonstration is designed to show what a model can do. A model drafts a proposal, summarises a contract or suggests a change to a piece of code, and the result looks good. The demonstration answers one question: can the model produce a plausible output? It leaves most of the others open.

In daily work, the output is only one part of what has to function. Someone has to know what it is for, supply it with the right information, judge whether it is correct and put it to use in a process that already exists. If any of those parts is missing, a strong output can still produce little value, or create extra work.

Start with the task, not the tool

A useful starting point is a defined task with an intended business outcome. “Use AI in sales” is not a task. “Prepare a briefing before a first meeting with a prospective customer, so the account manager arrives knowing the customer’s context and the most relevant questions” is. The more specific the task, the easier it is to judge whether the AI contribution helps, and to notice when it does not.

Information and permissions

Every task depends on information. A meeting briefing might draw on customer records, recent correspondence, market information and the organisation’s own positioning. Each source raises practical questions: is the information current, is it reliable, and may the system use it for this purpose? Permissions matter as much as availability. An output built on records the user should not see, or on outdated data, is a problem however fluently it reads.

What AI prepares, and who decides

It helps to be explicit about the division of work. In many workflows, AI is well placed to prepare: gathering, structuring, drafting or proposing. A person then evaluates the outputs that have consequences, such as anything sent to a customer, committed to a system or used to make a decision.

Human review is often presented as a safeguard, but it only works under three conditions. The review needs an owner: a named person or role responsible for the decision, not a shared inbox. The reviewer needs usable evidence: the sources the output drew on, what would change and why, and where the system was uncertain. And there need to be clear acceptance criteria, so the reviewer knows what “good enough” means for this task. A generic approval button meets none of these conditions if the reviewer cannot actually assess the work in front of them.

The NIST AI Risk Management Framework makes a related point. Its core asks organisations to define, assess and document processes for human oversight, and to test AI systems before deployment and regularly while they are in operation. NIST AI RMF Core

Connecting accepted work to the process

An accepted output still has to go somewhere. A briefing should be available where the account manager prepares; an approved code change should enter the normal review and release process; a checked document should be stored where colleagues expect to find it. If people have to copy results between systems by hand, the workflow depends on goodwill and tends to erode.

Two illustrations from the studio

Two ventures at Xablu Venture Studio work on versions of these questions. GoToM8 is being developed to connect customer, market and system signals with validated strategy and knowledge, so that commercial and operational teams can prepare and carry out their work more consistently. The emphasis is on preparation that a person uses and judges, not on automated decisions. Whether that approach holds up across different teams and data environments is part of what its validation has to show.

CodeChat, a venture in development and validation, starts from software development. A proposed code change is only useful if the developer reviewing it can see what would change, why and how it was checked, and if an accepted change follows the team’s existing review and release process. Its approach is still being validated, and no conclusions about its effect on development work can be drawn yet.

Evaluating real use

Once a workflow runs with real users, the evidence that matters comes from use, not from demonstrations. The questions below are suggestions for that evaluation; each organisation will need to adapt them to its own task and risks.

Some answers will be disappointing, and that is useful. A workflow in which review takes longer than doing the task directly may not be worth keeping in its current form. One in which corrections decrease and use grows is worth developing further.