A business wants AI to copy an invoice number from one system to another. The number is already in a structured field.
Somewhere, a very ordinary integration is wondering what it did wrong.
The short answer: use traditional automation for stable, explicit rules and structured inputs. Consider AI when interpretation or unstructured material is central to the task. Combine them when AI can propose an answer but deterministic checks should control the action. Choose the simplest mechanism that handles the actual variability.
Separate interpretation from execution
Traditional automation follows rules you specify: when an approved invoice reaches a state, copy the reference into the accounting system. It can be sophisticated without using a language model.
AI can help interpret an email, classify a request or draft a response where the input varies. Its output still needs validation appropriate to the consequence. A plausible account number is not an acceptable substitute for the correct account number.
Break the workflow into steps. You may need AI for one small part and ordinary software for everything else. That is often easier to test, cheaper to operate and simpler to explain.
Use the decision matrix
| Workflow characteristic | Starting choice | What to test |
|---|---|---|
| Structured input and fixed rule | Traditional automation | Boundary values, missing data and duplicates |
| Unstructured input with a limited category set | AI-assisted classification | Misclassification and escalation |
| Drafting from approved material | AI with review | Unsupported claims and reviewer effort |
| Financial or external action | Rules and explicit authority controls | Limits, approvals and duplicate execution |
| Rare, ambiguous, consequential decision | Human-led process | Evidence quality and escalation route |
| Unstable process with no owner | Fix ownership and process first | Whether the workflow can be described |
This is a suggested starting matrix, not a guarantee that a particular model can perform a task. Test your examples and your failure conditions.
Work through three concrete cases
Invoice processing: use rules for known fields and duplicate checks. AI may help extract information from varied documents, but compare extracted values against required formats and records. Route uncertain or inconsistent cases for review. Keep payment authority separate from extraction.
Customer enquiries: AI may classify free-text messages and draft from approved policies. Rules can route urgent categories and enforce required fields. A person should resolve uncertain or sensitive cases and approve commitments where required.
Weekly reporting: ordinary queries should calculate totals. AI may explain patterns from verified figures, but it should not invent or recompute the financial record. Link the narrative to its source data and review material interpretations.
Each case uses a different division of labour. “AI-powered” is not a useful design specification.

Count the exception work
Measure the full process: preparation, execution, review, correction and recovery. If AI saves drafting time but increases checking, report the net effect. Include the time spent maintaining prompts, sources and test cases.
Use a baseline from the current workflow. Test representative work and deliberately difficult examples. Keep a separate count of severe errors so they are not concealed by a high average success rate.
The NIST AI RMF provides a voluntary structure for risk work. Your operational test must still establish whether the proposed workflow is useful and tolerable.
Design the fallback before launch
Decide what happens when the model is unavailable, its output fails validation or the input does not fit a known case. Options include retrying safely, asking for clarification, sending to a queue or reverting to the manual process.
Avoid endless automatic retries that create duplicates or cost. Record the reason for escalation so reviewers can act without reconstructing the entire conversation.
For UK and UAE teams, test the languages and document formats actually used. Do not assume performance on English demonstration messages transfers to mixed-language customer traffic.
When should you avoid AI?
Avoid it when a reliable rule already solves the problem at acceptable cost, when there is no representative test evidence, or when the organisation cannot manage the consequences of error. You can revisit the decision later.
A smaller, predictable system is a perfectly respectable result. The customer cares whether the job gets done, not whether the architecture qualifies for a keynote.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.

