AI Workflows · Guide
Map Failure Modes Before You Automate an AI Workflow
Trace the moments when an AI-assisted process can misread evidence, exceed authority, or leave a person with an unusable result.
Before automating a task with AI, draw the actual path from input to action and mark where a wrong answer, missing source, sensitive input, failed handoff, or duplicate action would matter. Give each failure a detectable signal, a human owner, and a safe next step. Test the route with realistic cases before connecting it to a consequential system.
Start with the real task boundary
Write down the task as people actually perform it today. Record where a request arrives, which documents are consulted, what decision is made, who approves it, and where the result goes. An AI step that drafts a suggested response is different from one that sends it. An assistant that classifies incoming files is different from one that moves a record into an authoritative system. Identify the first consequential action, because that is where a polished draft can become a real mistake. Ask the worker who handles unusual cases to walk through a recent example. The official process diagram may omit the phone call, missing document, or supervisor check that prevents harm. A usable map includes those detours rather than treating them as noise. NIST's AI Risk Management Framework begins with context and intended use; in a small team that means naming the downstream action and the people affected before judging whether automation is safe.
- Name the trigger and output.
- Mark the first irreversible or externally visible action.
- Ask an operator about the exception path.
Illustrative prompt · adapt before use
Map failure modes in this illustrative workflow. Do not execute actions.
Workflow: support email -> AI refund draft -> agent approval -> send.
Policy: a refund needs a verified order and agent approval.
Case: two orders share a customer name; the order ID is missing.
Return: step | missing evidence | possible harm | observable check | safe next action | approval owner.
Mark unknowns. Expected boundary: request the order ID; do not approve or send a refund promise.Separate input failure from model failure
Many visible AI errors begin before the model runs. A source file can be outdated, a field can be empty, a customer can have two similar identities, or a page can carry instructions that were never part of the user's request. Mark the source, version, permission, and expected format at every intake point. Then distinguish an input that is absent from a model answer that is uncertain or wrong. These situations need different recovery steps. Re-prompting an assistant cannot supply a missing approval, and a confidence score cannot prove that a source is current. For each input, decide what must be present for the workflow to proceed, what can be skipped, and what should be returned to a person. This makes the process honest about its dependencies. It also reveals when a purported AI problem is really a data ownership or document hygiene problem that should be fixed at the source.
- Check source authority and date.
- Reject missing required facts.
- Do not infer permission from access to a document.
Trace every handoff and state change
Draw arrows between the steps that pass information or responsibility: intake, AI drafting, verification, approval, publication, and follow-up. Label what travels across each arrow. Is it raw data, a summary, an evidence reference, a decision, or an instruction to act? A handoff fails when a receiving person cannot tell which of those it is. For example, a summary passed to a customer support agent may omit the caveat that a refund is only proposed, while a task system receives it as an approved promise. A map should keep status visible: draft, checked, disputed, approved, sent, or unknown. Give each status an owner and a next transition. If the process can restart after an interruption, identify which completed actions must not repeat. This is especially important when a connected tool can create a ticket, send a message, or alter a record. The workflow should not turn an uncertain result into a second action merely because its screen was closed.
- Label data and authority separately.
- Preserve the last confirmed state.
- Check for duplicate actions after interruption.
Choose failures by consequence, not frequency alone
A team can list dozens of theoretical errors and still miss the one that changes a user's outcome. Rank failures using three practical questions: how likely is this in the real input stream, how serious is the downstream consequence, and how easily will the current process notice it? A rare wrong customer identity can deserve more attention than a frequent punctuation error. Avoid a single numerical risk score that hides the reason for the decision. Write a one-sentence scenario: an input condition, the wrong AI behavior, the action that follows, and the person who experiences the result. NIST's framework links risk to context and impact rather than model behavior in isolation. This exercise helps decide where to put a review gate and where a simple formatting correction is enough. It also prevents a team from spending its limited review time on defects that do not affect the task while leaving the dangerous handoff unexamined.
- Describe a concrete failure scenario.
- Name the downstream consequence.
- Record why the existing process would or would not catch it.
Give each important failure a signal
A failure that cannot be seen cannot be managed by a checklist. Specify what an operator or system can observe before the next consequential step. A missing source link can be checked automatically; a conflicting customer instruction may require a human reading both messages; an unsupported claim may require opening the primary document. Keep the signal close to the action it protects. A daily dashboard is too late for a message that is sent immediately. Do not treat the model's own declaration that it checked its work as independent evidence. The signal should come from the input, the external result, or a reviewer with access to the source. If no reliable signal exists, narrow the AI step or require manual handling for that case. This is a design decision, not a failure of ambition. Being able to say which errors remain hard to detect is more valuable than promising that every output is monitored.
- Prefer observable checks over reassurance.
- Check before the action, not only afterward.
- Route undetectable high-consequence cases to a person.
Write the recovery next to the detection rule
A warning is incomplete if the operator does not know what to do with it. For each significant failure, write a safe next action: request a missing source, correct a field, send a case to a specialist, cancel a draft, or stop the connected action until status is known. Name the person who can authorize a restart. Distinguish a failed AI generation from a result whose external effect is unknown. If the assistant timed out while sending, repeating the command could create a duplicate. First read the receiving system or operation record to determine what happened. Do not erase the original attempt merely to make the queue look clean; the history helps explain the final decision. Recovery should return the user to a clear state, including who owns the case and whether another response is expected. A process that handles only success is a demo, not a dependable workflow for ordinary work.
- Keep the original attempt visible.
- Read back external results before retrying.
- Assign unresolved cases to a named owner.
Test with cases that stress the route
Build a small set of representative examples before attaching automation. Include a normal case, a missing required input, a stale source, a conflicting source, a request outside authority, a malformed file, and a repeated request. Use approved synthetic or de-identified material when real records are sensitive. For each case, write the expected status and action before running it. The test is not whether the model produces elegant prose; it is whether the whole route protects the decision and lands in the right place. Ask an operator who did not draw the map to run one case and explain what they would do at every handoff. If they cannot tell who approves the next step, fix the handoff before tuning the prompt. Keep the examples when the model, source, or connected tool changes so a future revision can be compared against the same practical requirements.
- Include absence, conflict, and duplicate cases.
- Record expected behavior before running.
- Observe a person using the recovery instruction.
Keep human authority explicit
A human review gate should identify what the person must judge and what evidence they must see. “Review AI output” is too broad. A customer agent may need to verify identity and policy eligibility; an editor may need to verify each factual claim and quotation; a finance owner may need to approve a payment change. The reviewer should see the original request, relevant source, AI proposal, and detected exception, not only a polished answer. The workflow should record who approved what version and when. If the reviewer routinely clicks through without checking the protected facts, the gate is only ceremonial. Redesign the presentation so the important comparison is easy, or remove automation from that decision. Human oversight is useful when it is placed at a decision boundary, given the necessary context, and allowed to reject or revise the proposed action.
- Describe the review question.
- Show the source beside the proposal.
- Allow rejection and correction without bypassing the process.
Pilot without hiding the manual baseline
Run a bounded trial with a real operator and compare it with the existing process. Measure completed cases, cases sent to review, wrong routes, corrections, and time spent recovering from exceptions. Count user-visible errors separately from internal rough edges. A fast first draft can still make the workflow slower if the operator must hunt for sources or repair malformed exports. Keep the authoritative action manual or approval-gated until the test cases and observed work justify a narrower release. At the end of the pilot, decide which case types are supported and which remain manual. Write that boundary where requesters and operators can see it. A clear partial result is better than a broad claim that the process is automated when its difficult cases still depend on improvisation. NIST's manage and measure functions emphasize observing outcomes and adapting controls over time; the small-team equivalent is a short, honest decision record tied to actual cases.
- Compare with current work, not an idealized baseline.
- Count exception labor and incorrect routes.
- Approve only the case types that passed.
Maintain the map when the work changes
The map is a living description of the workflow, not a permanent architecture document. Revisit it when a policy changes, a new input format arrives, a connector gains permission, a model is replaced, or users begin treating drafts as decisions. These changes can move the risky boundary even if the prompt stays identical. Give the map a responsible owner and a date, then record the small change that matters: source, decision, handoff, or recovery. Retest the cases connected to that change and sample a few ordinary cases to catch a shifted failure pattern. Retire checks that no longer protect a real action and add a check only when an observed case calls for it. The point is to keep the automation aligned with the work people actually do. A compact map that operators use is more protective than an elaborate register nobody consults before pressing send.
- Review after changed permissions or downstream actions.
- Retest affected examples.
- Keep the operator-facing route short and current.
Sources and update note
Follow the linked official source before a product, price, plan, or policy decision.