Every AI use case in this program is built on the same underlying pattern: AI produces a first-pass output, and a named human verifies it before the output is used. That pattern is what makes AI assistance safe in a business where output matters — and it is the thing that separates an adopted workflow from an abandoned tool.
This guide covers how to design that workflow properly: where the human sits, what they check, who is accountable, and how the check is recorded. It is part of the Use Cases & Workflows pillar.
“Human in the loop” is not a disclaimer. It is a designed step with a name, a check and a record.
The six steps
The pattern holds across documents, proposals, support responses and research.
1. Input. The human defines the task, selects the source material and sets the constraints. AI never chooses its own inputs for consequential work.
2. Draft. AI produces a first-pass output against a defined structure. Structure matters: it constrains the output and makes the check faster.
3. Check. A named human verifies the output at the points that matter. What is checked depends on the use case; that it is checked does not.
4. Correct. The human edits. Corrections are logged, because they are signals about the prompt, the source or the training.
5. Approve. The accountable owner signs off before the output leaves the team.
6. Record. What was used, what was checked and who approved it, so the workflow is reproducible and the control is evidenced.
Where a workflow is missing a step, the failure it produces is predictable: no check means unsafe, no approval means unowned, no record means unmeasurable.
Where the human belongs
The placement of the check is the main design decision. Three considerations settle it.
- Put the check where an error would be most expensive. For a client report, that is the figures. For a proposal, it is the commercial terms. For support, it is anything resembling a commitment.
- Put the check where it is cheap. If verifying takes as long as doing the work, the workflow will not survive.
- Put the check before the output leaves the team. Reviewing after delivery is not a control; it is an apology.
A useful heuristic: the smaller the set of things that must be checked, the more reliably they will be checked. Narrow the AI task until the check is short.
What to check, by use case
| Use case | The non-negotiable checks |
|---|---|
| Document production | Figures against source; claims against evidence; citations opened |
| Proposals | Commercial terms; capability claims; client references and permission |
| Support | Answer against the knowledge base; no commitments; escalation rules |
| Research | Every citation opened; every claim traced; limits stated |
| Finance commentary | Figures against frozen source; variance causes against evidence |
| Marketing | Factual claims; brand constraints; claims register followed |
The pattern is consistent: facts, commitments and anything consequential. Style and structure are the AI’s to draft; accuracy is the human’s to own.
Recording the check
The record is what turns a control into evidence, and it need not be elaborate.
- A tick in a checklist, retained with the output.
- A version note, naming the verifier and the date.
- An approval in the system, where the workflow runs through one.
The test is simple: if the output were questioned six months later, could you show that it was checked and by whom? Where the answer is no, the control exists only as an intention.
Why the pattern survives tool changes
The value of designing the workflow independently of the tool is that it survives replacement. Businesses change assistants within a year and still run the same six steps, because the steps describe the work rather than the software.
That is also why the workflow should be documented in your own terms — task, source, check, approval — rather than in the vocabulary of a particular product. A workflow that can only be described in one vendor’s language is a workflow you do not yet own, and one that will have to be rebuilt at the next purchase.
A worked design
A firm designs the workflow for its monthly client report.
- Input. The client lead supplies the frozen figures, the prior month’s report and the delivery record. The client lead, not the model, chooses what the report is based on.
- Draft. AI drafts the performance narrative against the frozen figures and the prior structure. It is instructed not to calculate anything.
- Check. The client lead verifies every figure against the finance system, every delivery claim against the record, and reads the narrative for anything unsupported.
- Correct. The client lead edits, and logs the corrections — three narrative adjustments and one figure that had been copied forward from last month in error.
- Approve. The client lead signs off, and the version is recorded.
- Record. The snapshot, the version and the completed check are retained with the report.
The correction log is the most valuable artefact. It showed that the copied-forward figure — a failure mode of the old process — was still occurring, and it prompted a change to the input step: figures are now supplied fresh each cycle rather than read from the previous report.
The cost of getting it wrong
Two failures illustrate why the design matters more than the tool.
- No check. A figure is drafted rather than taken from source, it looks plausible, and it reaches a client. The cost is not the correction; it is the client’s revised estimate of the firm’s reliability.
- A check without a record. The report is questioned three months later, and no one can show whether the figure was verified or by whom. The control existed in practice and not in evidence.
Both failures are avoided by the same two things: a named verifier and a recorded check.
Common mistakes
- A check with no owner. “The team reviews it” means nobody reviews it, and the failure surfaces only when the output is questioned.
- A check after the fact. Reviewing after delivery is not a control.
- A check that costs as much as the work. The workflow will be quietly abandoned.
- No record. The control cannot be evidenced.
- The human approving without reading. Approval becomes a formality, and a formality is worse than no control because it creates the appearance of one.
- Designing the workflow around one tool. It will not survive the next purchase.
Frequently asked questions
What is a human-in-the-loop workflow?
A workflow in which AI produces a first-pass output and a named human verifies it at defined points before it is used. The human is accountable for the result; the AI is a drafting mechanism.
Where should the human check happen?
Where an error would be most expensive, where the check is cheapest, and always before the output leaves the team. Narrowing the AI task until the check is short is the most reliable design move.
What must always be checked?
Facts against source, commitments and commercial terms, and any citation. Style and structure can be left to the drafting; accuracy cannot.
Do we need to record the check?
Yes. Without a record, the control exists as an intention rather than evidence, and it cannot be demonstrated if the output is questioned later.
Is one reviewer enough?
For internal output, usually. For anything client-facing or regulated, a second pair of eyes on the figures is worth the few minutes, because that is where errors are most expensive.
Does this pattern apply to every use case?
It applies wherever output leaves the team or informs a decision. Fully autonomous handling is a separate design with much narrower conditions — a maintained knowledge base, defined escalation and disclosure.
How do we handle a workflow where the human is the bottleneck?
Narrow the AI task until the check is short, and distribute the check across the roles closest to the output. Where the check remains the bottleneck, the use case is not ready at its current scope.
Should the check be a different person from the drafter?
Where the output is internal, one person can do both. Where it is client-facing, regulated or financially material, a second person on the figures is worth the minutes it costs.
Who decides where the check goes?
The use-case owner, with the people who do the work. The check belongs where an error would be most expensive and where it is cheapest to run, which the practitioner usually identifies first.
Next step
Take one use case, write the six steps down, name the verifier and decide how the check is recorded. See the Human-Verification Checklist for a ready-made check, or book an AI adoption call to design the workflow with you.
Sources
- Workflow design reflects standard control practice applied to AI assistance: defined inputs, a first-pass output, a named verification step, recorded approval, and a retained record.
No statistic in this article is invented; where figures appear in the linked guides, they are cited there with their source and date.