Workflow selection

How to choose the first workflow for governed AI

AI WorkBook editorial team22 July 20265 min read

The best first workflow is rarely the most impressive use of AI. It is valuable work with a clear outcome, an accountable owner and boundaries that can be tested before the organisation makes a wider commitment.

Begin with the work, not the model

“Where can we use AI?” sounds like a sensible starting question, but it puts the technology before the outcome. It can lead teams towards whichever task is easiest to demonstrate, even when that task has little operational value.

A stronger question is: “Which recurring piece of work is difficult to coordinate, evidence or improve?” Look for a request, review, report, decision or client output that moves through recognisable stages. It may currently span inboxes, spreadsheets, documents, applications and individual knowledge. People may know how it should work, while still relying on informal handoffs and memory to make it work in practice.

This is where a first workflow can teach the organisation something useful. It creates a bounded place to decide what should be automated, where AI assistance genuinely helps and which decisions must remain with accountable people.

A good first workflow sits between two extremes

At one extreme is the trivial task: easy to automate, easy to demonstrate and too small to test whether the organisation can operate AI-supported work responsibly. At the other is the organisation’s most sensitive and interconnected process, where every unresolved dependency becomes part of the first experiment.

The useful middle is meaningful but bounded. The workflow should matter enough that improvement is valuable, while remaining narrow enough for a team to understand its sources, roles, exceptions and intended outcome. A focused workflow can be a complete solution in its own right; it does not have to become a large platform programme to be worthwhile.

Use six tests before choosing

The following tests turn a broad list of AI ideas into a more credible shortlist.

• Value: Does the outcome matter to a customer, operational team or accountable leader? Can they explain why improving it is worth attention?
• Recognisable route: Can people describe how work moves from an initial request to a decision, output or completed action—even if the current route is inconsistent?
• Available context: Can the relevant records, policies, documents, data and prior decisions be identified? Missing context can be a scenario to test; completely unknowable context is a warning.
• Accountable ownership: Is there a person who owns the outcome and can decide what acceptable work looks like? A technology sponsor is not a substitute for an operational owner.
• Bounded judgement: Can the team distinguish predictable rules, interpretive assistance and consequential human decisions? If nobody can say what AI must not decide, the boundary is not ready.
• Observable evidence: Can the team inspect what happened and judge whether the workflow helped? Useful evidence may include missing inputs, review decisions, exceptions, elapsed time, rework and the quality of the final output.

A candidate does not need to be perfect on every test. The purpose is to surface what must be learned, rather than hiding uncertainty behind an exciting demonstration.

Choose a real outcome, not an abstract capability

“Knowledge management”, “an AI assistant” or “better reporting” are themes, not workflows. A stronger candidate has a recognisable beginning and end: assess a supplier response, prepare a reviewed decision pack, coordinate a client onboarding step, or turn an operational request into an approved output.

That specificity makes design choices visible. The team can identify the request, the information needed, the stages the work passes through, who reviews what, how exceptions are handled and what record should remain afterwards.

It also creates a fairer basis for evaluation. Instead of asking whether the AI produced an impressive answer, the organisation can ask whether the whole piece of work was understandable, reviewable and useful.

Define success before building

A first workflow should begin with an explicit success statement. Avoid vague promises to “increase productivity” unless the team has agreed what that means and how it will be observed.

More practical measures might include fewer incomplete requests reaching review, a clearer evidence trail, more consistent application of agreed criteria, faster identification of exceptions, or less time spent reconstructing why a decision was made. These are still hypotheses until the workflow is used and reviewed, but they give the prototype something honest to test.

Success also includes learning where the proposed design fails. Missing information, changing permissions, rejected recommendations and awkward exceptions are not distractions from the prototype. They are evidence about whether the operating model is credible.

What a credible first engagement should produce

The output should be more than a promising screen. By the end of a focused first engagement, the customer should be able to see:

• a map of the workflow, outcome, stages and important exceptions;
• a source register showing the information the work depends on;
• defined roles, decision rights and human approval points;
• a working prototype that uses realistic scenarios rather than only a happy path;
• an evidence pack showing what was tested, learned and left unresolved; and
• a reasoned next decision: stop, refine, operate the focused workflow, or extend the pattern.

This keeps the first step proportionate. It gives leaders something concrete to review before they commit to broader integration, scale or organisational change.

Questions to take into the first conversation

Ask the operational owner to bring one real example of the work and answer five questions:

1. What outcome must this work produce, and for whom?
2. Where does the context currently come from?
3. Which decisions require accountable human judgement?
4. What goes wrong often enough to deserve testing?
5. What evidence would justify the next investment decision?

If those questions produce a useful, bounded conversation, the workflow is probably worth exploring. If they expose several different processes, no clear owner and no agreed outcome, that is valuable too: the organisation has learned what must be clarified before technology is introduced.