Decide which AI workflow exceptions should stay manual

An AI workflow does not need to handle every invoice, support ticket, or quote request to be useful. The owner must decide which routine cases the system may prepare or complete and which exceptions must stop with a person. If that boundary is not written, a small test can reach decisions about money, customer promises, sensitive data, or actions that are hard to undo.

This guide helps you split one recurring workflow into a routine path and a set of exception classes. An exception class is a group of cases that stop for the same reason and go to the same owner. The result is a smaller automation boundary with a clear response, owner, and restart rule for each type of exception.

Start with one workflow and the consequence of a mistake

Choose one recurring workflow that your team can observe from trigger to result. Name what starts the work, who owns it now, which sources and systems it uses, and what happens when the result is wrong. Avoid a department label such as “finance automation” because it hides different rules, owners, and consequences.

A useful workflow description can fit in a short block:

Workflow: prepare a supplier invoice for accounting review
Trigger: an invoice arrives in the approved inbox
Current owner: accounts payable lead
Sources: invoice, supplier record, purchase order, receiving record, accounting policy
Current result: a complete entry is ready for review, or the case is returned for more information
Possible consequence: the business records the wrong amount, uses unverified bank details, or delays a valid invoice

This description establishes the context before anyone selects a tool. The NIST AI RMF Playbook Map guidance says organizations should document the intended purpose and use context. It also says they should document costs from errors, target scope, knowledge limits, and human oversight. NIST does not decide whether this invoice workflow is suitable for automation. The owner must make that decision from the actual process and its consequences.

Use a representative week or another limited period to inspect the work. Include ordinary cases, corrections, missing records, system outages, policy questions, and cases that staff route to a specialist. Treat this observation as a local baseline, not a benchmark for other businesses.

Put stable, reviewable cases in the routine path

The routine path contains cases that follow a stable rule and produce a result a person or system can check. In the invoice example, a routine case may have an active supplier record, the expected purchase order and receiving record, unchanged payment details, and all required fields. An early AI workflow could extract the fields, show their sources, compare the records, and prepare an accounting entry for review.

Write the routine rule in plain language. Name the allowed input, expected output, required checks, destination, and owner of the final result. A reviewer should see the original records, proposed result, differences, and the action that will follow approval. If staff cannot agree on the rule or the workflow cannot show this evidence, keep the case outside the routine path.

The routine path can remain narrow. It may prepare work while a person keeps approval, posting, sending, or payment authority. Record this manual work in the implementation scope.

Group exceptions by the reason the workflow must stop

Group the observed exceptions by their stop reason. The following six classes are BaristaLabs guidance informed by NIST context, oversight, response, and recovery principles. They are not a NIST worksheet or an official NIST classification.

• Missing input: A required document, field, source, or confirmation is absent. The workflow cannot complete the normal rule from the evidence available.
• Policy ambiguity: Two rules conflict, the case falls between written rules, or the correct response depends on judgment that the policy does not capture.
• Sensitive data: The case contains information, credentials, records, or requested access outside the approved data boundary.
• High consequence: A wrong result could create an important customer, financial, legal, employment, security, or access decision.
• External-system failure: A source or destination is unavailable, returns an uncertain result, or cannot confirm whether an action completed.
• Irreversible action: The next step cannot be reliably undone, or correction would require a new customer-facing, financial, public, or legal action.

These classes can overlap. A change to supplier bank details can involve sensitive data, a high-consequence decision, and an action that is hard to reverse. Use the most restrictive applicable rule.

Use the AI workflow security review worksheet when an exception changes which systems, fields, credentials, vendors, or retention rules enter the workflow. Define the security boundary before you grant access. The business owner must still decide questions about policy, money, or customer commitments.

Give each exception one allowed response

Give each exception class one allowed response that protects the process and gives the owner enough information to continue.

Approve lets a named person accept the case after reviewing the required evidence. Ask for more information requests the missing input from its source. Hold preserves the case while an owner investigates a conflict, outage, or uncertain result. Keep manual sends the full case to the person who owns the important judgment or action.

Approval of one exception does not add that case to the routine path. Change the routine rule only after the owner changes the policy and the team tests the new rule.

Do not use “human review required” as the complete rule. Name the role, evidence, allowed decision, backup owner, and time limit before another escalation.

The NIST AI RMF Playbook Manage guidance calls for an explicit decision about whether an AI system should proceed. It also calls for documented response options, assigned responsibilities, and recovery procedures. The organization must have a way to disengage or deactivate a system when its results conflict with its intended use. The routes below apply those broad principles to one constructed small-business example.

Constructed example: one routine route and five exception routes

This table is a constructed example. It does not describe a BaristaLabs client or a tested outcome. It does not show a typical exception rate. Replace its rules and owners with those from your business.

Scroll sideways to see all 5 columns.

Route	Why the case stops or proceeds	Allowed response	Human owner	Evidence needed to restart or complete
Routine invoice preparation	Supplier, purchase order, receiving record, required fields, and payment details match the active records	Prepare the entry and send it to the normal review step	Accounts payable reviewer	Original invoice, matched record IDs, extracted fields, differences checked, and proposed destination values
Missing input	Purchase order, receiving record, required field, or supplier confirmation is absent	Ask for more information	Accounts payable lead	The missing record or an approved explanation of why it is not required
Policy ambiguity	Price, quantity, tax, receipt, or approval status does not fit one clear written rule	Approve	Procurement or finance policy owner	The conflicting records, the applicable policy, and the owner’s written decision
Sensitive data	Bank, tax, credential, or identity information falls outside the approved data boundary	Keep manual	Controller or security owner, based on the data involved	Verification through an approved channel, access decision, and review record
External-system failure	The accounting or approval system is unavailable, or the workflow cannot confirm the destination state	Hold	System or integration owner	Destination health, request ID, current record state, and destination state check
High-consequence or irreversible action	The case requests a bank-detail change, payment release, write-off, or another action that needs separate authority	Keep manual	Controller or authorized signer	Verified source records, required approvals, final action record, and correction path where one exists

The last row combines two exception classes because the same manual route fits this example. The tests remain separate. A high-consequence action can be reversible, and an irreversible action can be small in value. Your rules should identify both conditions before the case reaches the final action.

Preserve enough evidence for the owner to restart the case

An escalation should carry the completed work. Preserve the case identifier, source references, proposed result, stop reason, system state, owner, and allowed next decision. After review, record the decision, correction, approver, and restart point.

Match the evidence to the stop reason. A missing-input route needs the missing-field list and its expected source. A policy route needs the conflicting facts and rule. A failed-system route needs the request ID, last confirmed state, and a destination check before any retry.

The restart owner must have authority over the decision. A developer can repair an integration but may not own a payment rule. An operations lead can clarify a handoff but may not approve a new data exposure. Name both owners when the case needs business and technical decisions.

The AI workflow controls guide shows how the exception boundary connects to approval policy, a shadow run, review queues, run records, monitoring, rollback, and escalation. Use the controls that this workflow needs.

Run a pilot only if the routine path is useful by itself

Measure both paths during the observation period. Record local case volume, review work, corrections, unresolved cases, and important misses. BaristaLabs has no public dataset that establishes a normal exception rate for these workflows, so use only your records for an estimate.

A small pilot can run the proposed routine path in shadow mode, where it prepares results without changing the destination. Route every exception to the named owner and check whether the evidence arrives with the case. Test each known exception class as well as ordinary examples.

The SBA’s AI guidance for small businesses recommends that small businesses start with a small test. It says they should test whether a tool adds value. The guidance also recommends that another person review products from free AI tools or software. It says a person should assess AI-generated outreach. These points support a small, reviewed test. They do not define the exception classes or prove value for a specific workflow.

Approve the pilot only when the routine path creates a useful result with the manual routes still visible. If the team cannot name the exception owners, narrow the scope, prepare the process, or keep the workflow manual.

Use the AI implementation path decision matrix after you define the routine path, exception routes, security boundary, and owners. Then decide whether the next step is a self-serve tool, internal configuration, discovery, a pilot, or implementation support.

Keep the exception boundary in the implementation scope

The implementation brief should state the routine rule and every known exception class. For each class, it should name the allowed response, owner, escalation evidence, and restart rule. It should also state that unknown exceptions stop the workflow until an owner classifies them. No initial list can predict every unusual case.

BaristaLabs helps teams define and test these boundaries through process automation services. If you have one recurring workflow, BaristaLabs can help you separate the routine path from retained manual work. You can review the exception boundary before you select a larger implementation.

Source note and evidence limits

The NIST AI RMF Playbook offers voluntary suggestions rather than a required worksheet or sequence. Its live Map and Manage pages state that AI RMF 1.0 is being updated. They state that the Playbook will be updated after the framework revision. The routine-path and exception classification in this article is BaristaLabs guidance. It is informed by the current Map and Manage functions and by the SBA’s small-test and human-review guidance.

No cited source establishes typical exception rates, implementation savings, or outcomes for the example workflow. The table is constructed, and businesses must supply their own policies, owners, data boundaries, volume, review effort, and failure consequences.