A client email arrives with three requests in one paragraph.
The sender wants to change a delivery date, correct a company address and know whether an attached document is sufficient. The message is written in French, the attachment has an English filename, and the relevant client record sits in another system.
AI can help understand that message. It can identify the requests, extract the new details and prepare a summary.
But should the same AI change the client record, confirm the new date and mark the document as accepted?
Usually, no.
Those actions involve business rules, source-of-truth data and promises made to a client. They need a more dependable path than a model deciding what probably comes next.
This is where many AI projects become harder than expected. AI and automation are treated as the same thing, and then one system is asked to understand, decide, act and record the result. A safer and more useful design gives each part of the work a different job.
AI interprets. Automation executes. People decide.
One messy input, three different kinds of system, and two checkpoints that decide when the work moves forward and when it stops.
Understands language, documents and intent. Produces proposals, never facts.
- Classify the request
- Extract dates and fields
- Draft a reply
Same conditions, same path, every time. Inspectable and repeatable.
- Create and assign the task
- Update status and dashboard
- Write the audit trail
Owns anything carrying risk, cost or a promise to a client.
- Approve the commitment
- Handle the exception
- Take responsibility
Fixed checks compare the AI output with trusted records before any action runs.
Anything unclear, conflicting or irreversible stops here, with a named owner.
AI handles ambiguity. Automation handles commitments.
Traditional automation works best when the rules are clear.
If a form is submitted, create a record. If an invoice is approved, notify the next person. If a deadline is seven days away, send a reminder. If a task is completed, update the dashboard.
The trigger, rule and action can be inspected. Given the same conditions, the workflow should follow the same path.
AI is useful in a different part of the process. It works with language, images and documents that do not arrive in a perfectly structured format. It can classify a request, summarise a long message, extract likely fields, compare text, translate a draft or suggest a response.
It also means AI output should not automatically be treated as a confirmed business fact. A plausible interpretation is not the same as an approved address change, an accepted document or a promise to deliver on Tuesday.
One workflow can use all three
Take that client email again. A well-designed workflow gives each step to the system best suited to it.
Capture the source
The original email and attachment are stored or linked to the correct case. Nothing depends on copied text becoming the only record.
Use AI to interpret the request
The system identifies the likely client, language, request types, dates and missing information, then prepares a structured summary and a draft reply.
Validate the output
Fixed checks compare extracted details with trusted records. If the client cannot be matched, the date is invalid or the request is unclear, the case stops for review.
Run agreed actions through automation
A task is created, the case status changes, the responsible person is notified and the next deadline becomes visible.
Keep judgement with a person
Someone approves the delivery-date commitment, confirms whether the document is sufficient and authorises any change to sensitive or important records.
Record what happened
The final decision, message and next step are written back to the system the team already trusts.
The AI does not need permission to run the whole business process. It needs a clear place inside it.
The automation does not need to understand every nuance of the email. It needs explicit rules for what happens after the interpretation has been checked.
The person does not need to copy information between tools. They need to review the cases where their judgement matters.
Where AI is usually useful
AI is strongest where the input is variable but the desired output can still be reviewed. For an SME, that typically means:
Classifying incoming requests by topic or urgency
Extracting names, dates, reference numbers and requested actions
Summarising a document or conversation for the next person
Comparing a request with existing information and flagging mismatches
Drafting a reply in the appropriate language
Turning free text into a proposed set of structured fields
The word proposed matters.
If an output can affect money, a contractual promise, a client relationship, access rights, sensitive information or a regulated decision, the workflow should define what must be checked before anything happens.
Where deterministic automation should take over
Once the next action is known, ordinary automation is often the better tool.
- Create and assign a task
- Move a case from one agreed status to another
- Send a reminder at a fixed time
- Update a dashboard from trusted fields
- Attach the source document to the correct record
- Notify a named owner when an exception occurs
- Preserve an audit trail of what was approved, changed or sent
These steps may look less impressive than an AI-generated answer. They are often what makes the workflow dependable on a busy Tuesday.
The team needs to know where the current status lives, who owns the next step and what happens when the expected path fails. A model response alone does not provide that operating structure. It is the same invisible admin layer that quietly decides whether a business feels reliable.
Human review is a design choice, not a failure
Some teams treat every manual checkpoint as evidence that the automation is incomplete.
That creates the wrong incentive. It encourages the workflow to hide uncertainty instead of managing it.
The source information conflicts
Two systems disagree about the same fact.
The supporting evidence is weak
The interpretation is possible, but not well supported.
The action is difficult to reverse
Sent messages, paid invoices, changed master records.
The request falls outside agreed rules
The case does not match any path the team defined.
The decision needs judgement
Commercial, legal, ethical or relationship considerations.
The team is still learning
Real exceptions have not all appeared yet.
The aim is not to put a person back into every step. It is to choose the points where a person adds control.
A good exception path should be easy to operate. The reviewer should see the original source, the AI interpretation, the proposed action and the reason the case stopped. They should not have to reconstruct the whole situation from five systems.
Start with the boundary, not the model
Before choosing an AI tool, take one repeated workflow and mark each step as one of three types.
Understanding
Language, documents or unstructured information that has to be read before anything else can happen.
Moving
Moving data, creating tasks, sending agreed notifications or updating status.
Owning
Approving exceptions, commitments or decisions that need accountability.
- 1What is the trusted source for the information used at this step?
- 2What must be true before the next action is allowed?
- 3Which cases should stop for human review?
- 4What record should remain after the action is complete?
This exercise usually reveals that an effective AI workflow is not one large intelligent agent. It is a controlled sequence with a few flexible steps, several explicit rules and a clear owner for exceptions.
Pilot in draft mode first
The safest first version should prepare work before it performs work.
Run the workflow on real but controlled examples. Let AI classify, extract and draft. Let the automation create an internal task or review queue. Keep external messages and important record changes behind approval.
During the pilot, track more than speed:
- How often was the interpretation correct?
- Which fields needed correction?
- Which cases stopped for review?
- How much rework did the proposed output create?
- Did the team understand why the workflow took each action?
- Did the final status and next owner remain visible?
These observations show where the rules are ready to tighten and where human control should remain. Only after the ordinary cases are reliable should the team consider removing a review step — and even then, exceptions need a visible route back to a person.
A bounded pilot also makes the commercial decision easier. The business is not committing to redesign everything at once. It is testing one repeated piece of work, the way a first-response workflow can be measured before anything is extended.
The useful division of labour
AI gives a workflow flexibility around messy inputs.
Automation gives it consistency after the next step is known.
People give it judgement, accountability and the ability to handle the unusual case.
Trying to make one of these replace the other two usually creates either a rigid process that cannot understand real requests, or an intelligent-looking system that is difficult to trust.
The better goal is not maximum AI. It is the right kind of system for each part of the work.
What matters is that the team can still see what happened, correct it and take responsibility for the outcome.
Before adding AI to a process, draw the boundary.
That boundary is where a useful automation starts.