AI is easy to add to a workflow. The hard part is deciding what should happen when it produces a plausible but wrong answer.
Consider a shared mailbox that receives invoices, delivery notices, and ordinary questions. Sorting those messages may involve interpretation. Checking an invoice number against known records or sending a notification after approval does not. Those tasks are usually easier to test and operate with ordinary software. A model may still help classify or extract information, but its output remains uncertain.
Define the exact step
Write down the step you want to automate and the consequence of getting it wrong. “Use AI to process emails” is too broad to assess. “Read incoming messages, identify invoice requests, and send the relevant ones to the accounts queue” is specific enough to examine.
Then ask what the step actually requires:
- copying data from one system to another;
- applying a fixed business rule;
- looking up a record;
- calculating a value;
- interpreting text, images, or speech; or
- recommending an action to a person.
The first four usually call for normal application code, a database query, or an integration. The last two may justify a model, but only if the workflow can handle an uncertain result.
A fixed rule may be enough
A model is a poor substitute for a condition that can be stated directly. Use ordinary automation when the task is to:
- copy a customer number from an approved field;
- reject an import when a required value is missing;
- route an order based on country or order type;
- calculate a total from defined values; or
- create a document from a fixed template.
Rules have a useful property here: the same input produces the same result, and a failed condition can explain why it stopped. The implementation may still need error handling, permissions, and logging, but the decision itself is inspectable.
Adding a model to a deterministic step introduces another dependency without removing the underlying rule. It can also make a simple failure harder to diagnose.
When the input is messy
AI can be appropriate when the input is difficult to handle with a short list of rules. Examples include classifying an email that does not follow a fixed format, extracting information from documents supplied by different organizations, or producing a first summary for a person to review.
That does not make the output trustworthy by default. The model may misunderstand a phrase, omit a detail, or return a plausible value that was never present in the source. The surrounding workflow has to make those cases visible.
A useful boundary is:
- preserve the original input;
- ask the model for a constrained output;
- validate the output in application code;
- send uncertain or invalid results to a person; and
- record what happened for later review.
The model can assist with interpretation. It should not silently change the system of record.
Put a boundary around the result
Before connecting a model to a live process, describe its output as a contract. Define the allowed categories, fields, formats, and values. Reject output that does not meet that contract.
For an invoice-extraction step, the contract might require a supplier name, invoice number, date, currency, and total. The application can check that the date has a valid format, the currency is supported, and the total can be parsed as a number. It can also compare the extracted supplier against known records.
Those checks do not prove that the model read the document correctly. They do prevent malformed output from moving further into the workflow.
Confidence scores need the same caution. A score supplied by a model is not automatically a calibrated probability. Use it as one signal alongside validation rules, known-record checks, and a review threshold. Set the threshold from observed results rather than choosing a number because it looks reassuring.
Evidence before deployment
A demonstration prompt is not a test plan. Collect representative examples before deployment, including normal cases, incomplete inputs, unusual formats, and cases where the correct action is “I cannot decide.” Remove or protect personal data as required, and keep the assumptions behind the test set.
For each example, record:
- the expected category or fields;
- the model output;
- whether the output passed validation;
- whether a reviewer accepted or corrected it; and
- what happened when the input was ambiguous.
Look separately at false positives and false negatives. Sending an ordinary enquiry to an invoice queue may be inconvenient. Missing a document that requires urgent attention may have a different consequence. The acceptable error pattern depends on the workflow, so a single accuracy figure is rarely enough.
Repeat the test when the prompt, model, provider, document format, or business rule changes. A workflow that works on last month’s examples can behave differently after its inputs change.
A review queue needs an owner
“Someone can check it” is not a review design. A reviewer needs a queue, the original source, the extracted or classified result, the reason for escalation, and a clear way to accept or correct it.
The correction should be useful. If a person changes a supplier name or rejects a classification, record that decision where it can support troubleshooting and future evaluation. Do not force reviewers to approve an output they cannot inspect.
Review also needs an owner and a response time appropriate to the process. If nobody handles the queue, the model has only moved the manual work to a less visible location.
Decide what happens when it fails
A provider may be unavailable, a document may exceed the input limits, the output may fail validation, or a model may return an answer with no usable evidence. Each case needs an explicit result.
Depending on the workflow, the safe response may be to:
- leave the item in a retryable state;
- send it to manual processing;
- request corrected input;
- record the failure and notify an owner; or
- continue with a limited action that does not change important data.
Do not make the fallback “continue as if the model were right.” Preserve the item and its status so that an operator can see what still needs attention.
Include maintenance and review
Compare the AI option with a rule, a standard product feature, an API integration, or a small internal tool. Include the work around the model, not only the call itself:
- preparing and protecting the input;
- validating and storing the output;
- reviewing uncertain cases;
- monitoring failures and provider changes;
- checking results as the input changes; and
- maintaining a fallback path.
Document that choice, including who handles exceptions, before the first live run.