Before You Automate: How to Map Exceptions in an AI Workflow

Elchai Group | Practitioner Analysis

A workflow is ready for AI automation only when its exceptions can be detected, evidenced, routed to a named owner, resolved and, where necessary, reversed safely. The method below tests that before development starts. This is an Elchai practitioner method, drawing on published standards where they say something specific.

Why mapping the normal path is not enough

Automating it also changes who handles everything else. Once the straightforward cases flow unattended, the remaining workload becomes concentrated in difficult cases, arriving without the context an operator picks up in the queue.

Whether a workflow is worth automating is a separate commercial question, covered in our note on where the real ROI sits. This assessment answers a narrower one: can the workflow fail safely?

What counts as an exception

• Missing or contradictory data. A required field is empty, or two systems disagree.
• Policy conflict. Two rules apply and point in different directions.
• Low-confidence output. A model returns an answer it cannot support, such as a cost centre classification scoring below the organisation's validated confidence threshold.
• Authority gap. The action needs an approval level nobody in the automated path holds.
• System or integration failure. An interface times out, a feed arrives late, or a record locks.
• Timing or volume spike. Work arrives out of hours, in a backlog, or faster than the next step absorbs.
• Novel or unknown case. Something the design did not anticipate. This row forces a defined behaviour for the unforeseen.

How to map exceptions before automating

• 1. Define the workflow boundary and the outcome that counts. One line each for the trigger, the end state and what a correct result looks like. Every later judgement is made against it.
• 2. Reconstruct the normal path quickly, then find where it branches. Map it far enough to see the decision points.
• 3. Collect historical exceptions directly into an exception register. Use case records, system logs and interviews with the people who work the queue, which often reveal workarounds system records do not capture.
• 4. Classify each exception against the types above. Classification tells you which control applies: a low-confidence output needs a threshold and a review route, an authority gap needs someone with the delegation.
• 5. Triage each exception by consequence and reversibility. Ask what happens if the system acts wrongly and nobody notices for a day, and whether it can be undone. Anything irreversible with material consequence should generally remain subject to named human approval.
• 6. Assign a named human role and escalation route. Name a role, not a shared inbox. Set the point at which an unresolved case moves on, and to whom.
• 7. Define the response contract. For each row, state the evidence the owner needs, the response time, the immediate system action, the fallback, the rollback, and the stop, retry and approval rules.

• 8. Replay historical cases and conclude. Walk representative historical exceptions from a meaningful operating period through the proposed rules on paper. Cases that produce a wrong or undefined result are design gaps, cheaper to find here than in production.

How to build the exception register

No matching purchase order

• Trigger: No PO reference on the invoice, or none found in the system
• Consequence and reversibility: Nothing posted or paid to reverse while held; the delay still has an operational cost
• Automated response: Hold the invoice, post nothing, queue for review
• Human owner and escalation: AP clerk; AP team lead after two working days
• Required evidence: Invoice, supplier record, PO search result
• Fallback or rollback: Stays unposted; no ledger entry to reverse

Total exceeds purchase order beyond tolerance

• Trigger: Invoice value above the approved PO beyond the policy tolerance
• Consequence and reversibility: Reversible before payment release, costly to recover afterwards
• Automated response: Hold, attach the variance, block scheduled payment
• Human owner and escalation: AP clerk; category buyer, then finance above the delegation limit
• Required evidence: PO, goods receipt note, variance figure, any change order
• Fallback or rollback: Cancel the draft posting, return to held

Suspected duplicate invoice

• Trigger: Supplier, amount and reference match an existing record
• Consequence and reversibility: High if payment is released; recovery depends on the supplier
• Automated response: Block payment, flag both records as a suspected pair
• Human owner and escalation: AP clerk; AP team lead the same day if a payment run is due
• Required evidence: Both invoice records, supplier payment history, submission source
• Fallback or rollback: Remove from the payment run, or raise recovery if released

Worked example: supplier invoice matching

In three-way matching, a missing purchase order leaves a held document and an unpaid supplier, so nothing needs reversing and the cost is delay. A duplicate invoice that reaches a payment run moves money to a real supplier, and recovery depends on that supplier's cooperation. Consequence and reversibility, not frequency, put the tighter control on the second case.

The variance case shows where the authority gap belongs. Below tolerance the system releases, above it a buyer decides, above the delegation limit finance decides. Those levels are illustrative: thresholds and delegations must come from your organisation's approved policies.

What the standards contribute

The NIST AI Risk Management Framework 1.0 supports parts of it. Subcategory MAP 1.1 covers defining and documenting intended purpose, operating context, the expectations that apply and the setting of deployment. MANAGE 2.4 covers assigning responsibility and providing mechanisms to supersede, disengage or deactivate systems whose outcomes conflict with their intended use. MANAGE 4.1 supports parts of the response contract through monitoring, appeal and override, incident response and recovery. NIST is revising the framework, so treat the current version as a reference point rather than a settled one.

Making the go/no-go decision

Automate when exceptions are reliably detectable, the evidence needed to resolve them is available to the automated path or, for escalated cases, to the named human reviewer, and incorrect actions are reversible with limited consequence.

Automate with human oversight when detection and evidence hold up but some cases carry consequences a person should own. Scope oversight to those rows rather than applying blanket review, and keep it running after go-live, which is where our framework for AI agent governance picks up.

Do not automate yet when exceptions cannot be stated as observable triggers, the evidence to resolve them exists in no system, no named role owns a consequential case, or an irreversible action has no stop or rollback. The remedy is process and data work first, then a second assessment.

References

• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023
• ISO/IEC 42001:2023, Information technology. Artificial intelligence. Management system.
• UAE Charter for the Development and Use of Artificial Intelligence, UAE Government.