Disciplines → 2 of 6
Who does the work, who approves it and what happens when an agent gets stuck, decided by risk tier rather than by convenience.
Human–AI Workflow Design decides how work is split between people and AI. For every step it answers three questions: who does it, who approves it, and where it goes when something is unclear or fails. The risk tier of the work sets the answer, not the capability of the tool or the pressure of the deadline.
Most organisations already have the building blocks: responsibility matrices, process maps, change categories and on-call rotas. This discipline extends them so AI appears in them as a participant with defined limits. The outcome is a workflow in which every AI contribution has a named human owner, every approval is a real decision, and no piece of work can disappear between an agent and a person.
| Practice | Today | With Human–AI Workflow Design |
|---|---|---|
| Responsibility matrix (RACI) | Roles assigned to people and teams | AI agents appear as performers of named steps; accountability for each step stays with a named person, never with an agent |
| Process maps | Steps, hand-offs and decision points between people | Each step marked human, AI or both, with its tier, autonomy level, approval gate and escalation route |
| Change management | Standard changes pre-approved, normal changes reviewed | Low and medium-tier AI-assisted changes with passing gates qualify as standard changes; high and critical keep full review and cannot be reclassified by the agent |
| On-call and incident escalation | Alerts page a person who escalates by severity | Agent uncertainty, bound violations and failures page a named human queue; AI actions and escalations appear in the incident timeline |
| Code and content review | Reviewer checks whatever arrives | Review depth set by tier, reviewer load capped, and each handoff carries the context needed to decide |
Map the workflow, then assign each step to a human, to AI, or to both, using the tier criteria: blast radius, reversibility, data sensitivity and regulatory exposure. The highest applicable criterion wins. A single workflow often mixes tiers: an agent may draft a customer notice (medium) while the decision to send it to regulators stays with a person (critical). Record the delegation where the process is documented, so auditors and new team members read the same rules the agents follow.
Autonomy is a setting, not a property of the tool. Define a small number of levels and let the tier set the ceiling. Raising a step's level is a change like any other: proposed with evidence, approved by the process owner and recorded.
| Autonomy level | What the agent does | Highest tier allowed |
|---|---|---|
| 1 Suggest | Offers analysis or options; a person does the work | Critical |
| 2 Draft for approval | Produces the output; nothing takes effect until a person approves it | High |
| 3 Act with approval | Prepares and executes the action once a person approves that specific action | Medium |
| 4 Act within bounds and report | Acts on its own inside defined limits and reports what it did | Low |
Each tier maps to a gate: auto-approve at low tier when automated checks pass; one qualified human reviewer at medium; enhanced review at high, with two reviewers including a specialist and an evidence bundle; and human-only at critical, where AI may inform but never decides or acts. Gates are enforced by the pipeline or workflow tool at the Verify and Release stages, not by convention, and the agent cannot lower its own tier.
AI to human: the agent hands over what the reviewer needs to decide, not just the output. That means the goal it was given, what it changed, the context it used, what it could not verify and where it was uncertain. Human to AI: the person hands over a clear specification, including acceptance criteria, boundaries and a definition of done. A vague instruction produces output nobody can review against.
When an agent is uncertain, hits a boundary or fails, the work goes to a named human queue with an owner and a response target, the same way an alert pages on-call. Retry limits are explicit; after them the agent stops and escalates. Nothing is silently dropped, retried forever or quietly downgraded to a lower tier. During Operate, an incident commander decides and every AI action is visible in the timeline.
Human review only controls risk if the reviewer has the time, context and authority to say no. Cap review load per reviewer, so queues are sized to people rather than to agent throughput. Watch for automation bias: approvals that take seconds on large changes, or rejection rates near zero, signal rubber-stamping. At low tier, replace blanket review with sampling, so human attention goes where the risk is. Findings from sampling and overrides feed back into tiers and autonomy levels at the Learn stage.
| Tier | Prevent (Guardrails) | Prove (Audit Trail) | Detect (Self-Monitoring) |
|---|---|---|---|
| Low | Autonomy up to level 4 inside action limits; kill switch; auto-approve only when automated checks pass | Action log with agent identity, context used and outcome | Sampled review of auto-approved work; rollback and escalation rates |
| Medium | Autonomy capped at level 3; one qualified reviewer; reviewer load limit | Approval record naming the reviewer, what was reviewed and the decision | Human override rate; review turnaround against target |
| High | Autonomy capped at level 2; two reviewers incl. a specialist, independent of the requester | Both approvals and the evidence bundle linked to the release record | Rubber-stamp signals such as review time against change size; open escalations past target |
| Critical | Human only; agents hold no credentials to act; AI limited to suggestions | Documented rationale for the human decision; second-line oversight record | Any attempted AI action is treated as an incident |
Deployers of high-risk AI systems must assign human oversight to people with the necessary competence, training and authority (EU AI Act, Art. 26); tier-based gates, named reviewers and load limits make that oversight real rather than nominal. Using AI to evaluate or monitor workers is itself high-risk (Annex III, point 4), which is why reviewer measures describe teams and workflows, not individuals. ISO/IEC 42001 expects operational control of AI use (clause 8) and documented information (clause 7.5); the delegation map, approval records and escalation log provide both.