Choose which team workflows to hand to AI

In this topic, a workflow is a recurring piece of business work: something arrives, a person produces an output, and someone uses that output. It is a business process, not an engineering pipeline.

Describe the work before you pick a tool:

• What arrives, and how often?
• What is produced, and who uses it?
• What happens if the output is late or wrong?

Then name the outcome that matters: hours saved, a faster answer for the customer, or fewer errors. Some tasks improve more with a template, a form, or a simple rule than with AI, so compare against that option too.

The UK government's AI Playbook makes the same point for public-sector teams: use cases should be led by business and user needs, not by what the technology can do, and sometimes AI is not the best solution.

Ask the same five questions of every workflow. They are the criteria for every decision in this guide.

Volume tells you how much is at stake, not how far to automate. The level comes from the other four questions.

NIST's AI Risk Management Framework (voluntary guidance, not law) asks teams to document the expected benefits of an AI system and the costs of its errors (Map 3.1 and Map 3.2), and to define how people oversee it (Map 3.5).

Two rules turn a list of workflows into hours:

• Weekly hours = weekly volume x minutes per item / 60.
• The most that checking each item can save, per item = minutes to do the task today minus minutes to check (and fix) the AI output.

Worked example from another setting (all figures synthetic). A school office writes 200 letters a week at 6 minutes each. Checking an AI draft takes 2 minutes.

If checking takes as long as doing the work, checking every item saves nothing.

A check also counts only if the checker can catch the error: they know the facts, can read the output, and have the source in front of them. Automation bias is the tendency to accept what an automated system produces; NIST's Generative AI Profile describes it as excessive deference to automated systems. A check that takes a few seconds is often not a check at all.

An automation level says how much of the work the AI does and where a person stays involved. This guide uses five levels. The examples come from other settings.

• One workflow can have steps at different levels. For example, a recruiting team might let the AI check that each job advert has the required sections at Level 4 while every hiring decision stays with people at Level 1.
• Levels are earned. Start lower, raise the level with evidence, and drop a level when errors rise or the work changes.
• The idea comes from automation research: Parasuraman, Sheridan, and Wickens (2000) show that each function of a system (gathering information, analyzing it, deciding, acting) can sit at its own level, from fully manual to fully automatic. These five levels are a simplified version for team decisions, not their scale.

A checkpoint is the point where a person checks the AI's work. Write it as three facts: who checks, what they look at, and when.

• When. Put it before the point of no return: before an output reaches a customer, before money moves or a commitment is made, and before a decision about a person takes effect.
• Exceptions. Simple rules send unusual items to a person: no matching record, low confidence, a large amount, or certain words.
• Random sample. A regular random sample of the items nobody checked one by one measures their error rate. Compare it with today's error rate, measured the same way.
• The checker. They need the knowledge to judge the output, the source on screen, the time, and the authority to change or stop it.

An approval rate shows what reviewers did, not whether the outputs were right. The UK AI Playbook's Principle 4 asks for meaningful human control at the right stages, with people validating high-risk decisions that AI influences.

This question decides where a checkpoint goes and who staffs it. Review screens and review capacity are covered in depth in the Responsible AI & Governance Easy question, "Make human oversight meaningful" (a prerequisite of this one).

List the data the work would put into the tool: customer names and addresses, messages, photos taken inside homes, payment details. Then check what the tool is approved for. If a data-use review is still pending, the workflow waits or uses only approved data. The rules themselves are covered in this topic's data-use question, "Set team rules for AI tools and company data".

Next, ask who bears a wrong output:

• Staff, who redo the work.
• Customers, who receive wrong information.
• A person a decision is about, such as someone whose request is refused. Decisions about a person call for a person deciding. The UK AI Playbook advises caution with fully automated significant decisions, and NIST's Map 5.1 asks teams to weigh how likely and how large each impact is.

The staff whose work changes are affected too. Involve them early.

A pilot is a small, time-boxed trial that tells you whether to go further. A good first pilot lets you learn safely:

• Errors are cheap and can be undone.
• A person can check an output quickly and reliably.
• The tool is already approved for the data.
• A small team runs it, with enough volume to measure within a few weeks.
• A baseline exists: today's error rate or time, measured the same way the pilot will be measured.

Weigh the size of the saving against how far a mistake would reach: how many staff need training and how many customers would see the output.

Start one level below the target. Check every item first to measure the error rate, then move to sampling if the rate holds.

Before the pilot starts, write down four things: the success measure, the stop rule (the result that makes you pause or drop back a level), the owner, and the decision date. Measuring a pilot's full cost and return is this topic's Medium question, "Measure an AI pilot's quality, cost, and return".

Use the two tables and the facts in the scenario above. Work every row before you open the hidden columns.

Interviewers often change one fact after your answer. Try each change against the levels you chose in the previous exercise.

A later workflow at the same company reports a high approval rate, and the team wants to raise its level. Decide what the evidence supports.