Human-in-the-loop AI workflow: an operating model

“Human in the loop” is often where an AI workflow description stops being useful. It names a safety intention but leaves the operating questions unanswered: Which human? Reviewing what? Before or after which action? With what evidence? What happens when they reject it?

A workable model assigns authority at every step. The system may collect, extract, classify, draft, or recommend. A named person approves the action that can affect a customer, payment, policy, legal position, or operating record. Exceptions have somewhere to go. Corrections change the next run instead of disappearing in chat history.

This is the model to use before connecting an AI workflow to the tools where work actually happens.

Start with the authority map

Map the workflow as a set of decisions, not a list of software features.

For each step, record five things:

1. Input: the source material the step may use.
2. Prepared output: the artifact the system can produce.
3. Decision owner: the person or role with authority to accept, reject, or change it.
4. Execution boundary: the exact action that cannot happen before approval.
5. Exception path: where missing, conflicting, sensitive, or high-risk cases go.

A support workflow, for example, might allow the system to classify a request and draft a reply. The support lead still approves refunds, policy exceptions, legal complaints, account changes, and any message where source context is incomplete. The execution boundary is the send or account mutation, not the draft.

The phrase “a human reviews it” is too weak. Name the role, the artifact, the consequence, and the point in the workflow where authority changes hands.

Use six operating stages

A reviewed AI workflow usually needs six stages. Some simple workflows combine them, but none should vanish by accident.

1. Intake

Collect inputs from approved sources: a form, inbox, CRM record, document set, helpdesk ticket, spreadsheet row, or internal note.

The intake rule should say which source wins when records disagree, which fields are required, and which data is too sensitive for the workflow. Access to a source is not permission to use everything in it.

2. Preparation

Have the system perform bounded work such as extraction, research, summarization, classification, or drafting. The result should be a reviewable artifact rather than a freeform chat answer.

Useful artifacts include:

• a cited lead brief;
• a document review queue;
• a support triage note with a proposed reply;
• an executive briefing with open questions;
• a content brief with claim sources and approval flags.

The artifact must preserve enough source context for the reviewer to check the work without reconstructing the whole task.

3. Review

Route the artifact to the person who owns the decision. Give that person the source references, proposed action, reason, known uncertainty, and consequence of approval.

A review screen that shows only “approve” and “reject” is usually under-designed. The reviewer needs to know what will happen next.

4. Decision

Record a clear outcome: approved, rejected, returned for correction, or escalated. Bind the decision to the exact artifact and proposed-action revision the reviewer saw, then capture the decision owner and time. If the reviewer changes a consequential field, preserve the before-and-after values or an equivalent audit note.

Silence is not approval. A timeout should leave the item pending or escalate it, never quietly execute the proposed action.

5. Execution

Only the approved action should run. The execution step needs an idempotency or duplicate-prevention rule when retries could send a message twice, create two records, or apply the same account change more than once.

Execution failure should return the item to a visible error state. Approval is permission to attempt the action; it is not proof that the action completed.

6. Correction

Log misses, reviewer changes, false escalations, and execution failures. Decide whether each correction changes a prompt, source rule, field map, routing rule, access boundary, or reviewer guidance. A corrected consequential action must return to needs-review; approval never carries forward to a changed revision.

Without this stage, “human review” becomes permanent manual cleanup. The system keeps making the same mistake while the humans quietly repair it.

Assign decisions to three lanes

A practical authority model separates routine preparation from consequential action.

“Low risk” should describe a defined consequence, not a mood. Internal preparation may be safe to run automatically when the source, output, and recovery path are clear. External messages and consequential record changes deserve a stricter gate.

Make approval a state transition

Approval should change a durable workflow state. It should not be an informal reply in a side channel that the system may or may not notice.

A small workflow can use states such as:

• prepared — the artifact exists but nobody has reviewed it;
• needs-review — the correct reviewer has received the item;
• approved — a named reviewer approved the exact artifact and proposed-action revision;
• needs-correction — the reviewer returned the item for a defined change;
• rejected — the action must not run;
• escalated — the item needs a different authority or specialist decision;
• executed — the approved action completed;
• failed — execution was attempted but did not complete;
• corrected — the artifact or rule changed after review and is ready to re-enter needs-review.

The exact labels can vary. The important part is that the system can distinguish preparation, authority, and execution. A timeout leaves the item in needs-review or moves it to escalated; it never advances the action. Any consequential change to the artifact or proposed action invalidates the prior approval and requires a fresh review. Otherwise a retry, stale browser tab, or ambiguous webhook can turn an old approval into the wrong action.

Give the reviewer a complete packet

A reviewer should not have to open five systems to understand one approval request. The packet should contain:

• the workflow item and current state;
• the source references used;
• the prepared artifact;
• the proposed external or record-changing action;
• missing, conflicting, or low-confidence information;
• the reason this item needs review;
• approve, reject, correct, and escalate options;
• the resulting destination if approved;
• the correction note or audit record after the decision.

This packet is also the best first proof artifact. It shows whether the workflow is reducing preparation work while keeping consequential decisions inspectable.

See the sample AI workflow audit report for a synthetic example of how a workflow boundary, pilot path, and no-go risks can be documented before implementation.

Know when human review is safety theater

A nominal approval step does not make a workflow safe. The gate is weak when:

• the action already happened before the reviewer saw it;
• the reviewer cannot inspect the source material;
• the queue is too noisy, so approval becomes rubber-stamping;
• the system hides uncertainty behind polished prose;
• every exception goes to the same person with no priority or consequence signal;
• rejection does not stop retries or later execution;
• corrections are not recorded;
• nobody owns the rules after launch.

If the review step cannot change the outcome, remove the theater and keep the workflow advisory. If the review queue overwhelms the operator, narrow the workflow or improve exception routing before expanding it.

Test the boundary with real examples

Before a build, collect recent examples that include the normal path and the ugly cases: missing fields, contradictory sources, unusual requests, sensitive context, policy exceptions, and prior mistakes.

For each example, ask:

1. What may the system prepare?
2. What must the system cite or expose?
3. Which action requires approval?
4. Who has that authority?
5. What should force a stop?
6. What proves execution succeeded?
7. How does a correction reach the next run?

If the team cannot answer those questions, start with a workflow audit. The useful output is an authority map and a smallest safe pilot, not a model recommendation.

If the answers are clear and the artifact can be reviewed, an operations sprint can implement one bounded path. Keep the first sprint narrow enough that rejection, escalation, retry, and correction can be tested before more authority is connected.

The standard to hold

A serious human-in-the-loop workflow makes four things visible: what the system prepared, what the human decided, what action actually ran, and what changed after a correction.

That operating trail matters more than an “AI-assisted” badge. It is how a team keeps human authority real after the demo ends and the workflow starts meeting ordinary operational mess.