AI does the reading, drafting and sorting. A person keeps the judgement.
AI workflow automation means putting a language model to work inside a business process, at the steps where the work is fuzzy and language-shaped: reading a document, drafting a reply, categorising an enquiry, summarising a thread. Rules-based automation follows fixed instructions and returns the same output for the same input, so a deterministic workflow stays predictable and auditable. A large language model (LLM) is different: it reads meaning, forms a judgement, and writes language back.
Most tools make the model run the whole workflow. We build it the other way round: rules, integrations and state machines do everything they can be trusted with, and the model is added only where a step genuinely needs judgement.
AI last, not AI first: the deterministic parts of a workflow run everything they can, and a language model supplies the judgement layer only where a step is genuinely fuzzy.
The intelligence belongs on top of your existing business process automation, not bolted on beside it as a generic chatbot. That is what AI business process automation should be: build the judgement into a system you own, not bolt something generic onto the side. The rest of this guide works through it.
Which steps suit AI, and which it must never touch
The judgement layer earns its place on a narrow set of step types. A step suits a language model when it runs at high volume, tolerates a quick human review, and is shaped by natural language rather than fixed fields. Take invoice-field extraction: a supplier PDF arrives, the model reads the supplier name, date and line totals, and a person confirms the figures before payment. A wrong reading is caught in seconds, so the model is helping, not deciding.
Hold the line in one sentence: the model may read, sort and suggest, but the moment a step is final, regulated, or turns on an exact number, a rule or a person owns it. Within the suitable side, the same four task patterns come up again and again.
Document extraction
Reading fields from a scanned or PDF document (OCR), the reading half of intelligent document processing (IDP). The invoice example lives here, with the human check left in.
Drafting
Writing a first-pass reply a person edits, never the final wording sent under your name.
Classification and triage
Sorting an incoming enquiry by type and urgency so the right rule or person picks it up.
Summarisation
Condensing a long email thread or set of notes into a short brief someone can act on.
Human in the loop: designing the review layer
Keeping a human in the loop is the mechanism that makes every step above safe, and it is a design job rather than a reassuring word to drop into a proposal. In practice it means the model is never trusted blind: it proposes, and a person confirms or edits before anything acts on the result. We call this the draft-and-approve pattern, and it is the spine of every AI step we build. Human-in-the-loop (HITL) design then comes down to one decision, which cases a person actually needs to see and which are safe to pass through.
Where you set the confidence threshold tunes the balance directly: raise it and more cases land in the review queue, so fewer errors slip out; lower it and more pass automatically, so the team handles less. On top of that, any case type you have marked as sensitive follows a separate exception routing path to a named person, whatever the model's confidence, so the delicate work never rides on a score alone.
Every pass is recorded: the loop leaves an audit trail recording what the model produced and who approved it, so a wrong output can be traced back and corrected rather than disappearing unnoticed.
Where AI goes wrong: hallucination, drift, and silent errors
Every AI step carries three failure modes, and naming them plainly is the first move towards designing against them. These are not rare edge cases. They are the ordinary ways a language model lets you down, and each one needs its own guard.
Hallucination
The model returns something confidently wrong: an invented figure, a supplier that was never named, a total that does not add up. It reads as certain, which is exactly what makes it easy to trust.
Model drift
Quiet degradation over months as your inputs change. New document layouts, new phrasing, new product lines: nothing breaks loudly, but accuracy slides while no one is watching.
Silent failure
Plausible-but-wrong output that passes unnoticed because it looks right and nothing flags it. This is the dangerous one. The other two get caught in the end; this sits in your data until it causes harm.
No single defence covers all three, so we fit four guardrails and rely on the combination rather than a favourite.
-
Schema validation Code checks every output against a fixed structure before it is accepted, the same structured output the next section covers in depth.
-
Deterministic fallback path When validation fails or confidence runs low, the step routes back through the deterministic workflow it falls back to, so an uncertain model never has the final say.
-
Human checkpoint A person reviews the cases the model is least sure of, the review layer already described put to work.
-
Monitoring Sampled outputs are watched over time, so drift surfaces as a trend rather than a nasty surprise.
Silent errors do the most damage: no one is looking for them, so build the guard before you need it, not after the wrong number has already gone out.
Sending customer data to AI: UK GDPR and where the model runs
Yes, you can send customer records and documents to an AI service and stay within UK GDPR, the data protection law that governs how you handle personal information. What keeps you safe is which arrangement you pick and what its contract says. A third-party API sends your text to an outside provider's servers over the internet; a hosted or self-run model runs on infrastructure you control. That choice decides where the data physically sits, whether it feeds model training, and how much of it you can see.
| What you care about | Third-party API | Hosted or self-run model |
|---|---|---|
| Where the data goes | Sent to the provider's servers over the internet. | Stays on infrastructure you control. |
| Training use | Depends on the contract, so insist on a training opt-out. | Never used to train anyone's model. |
| Data residency | Wherever the provider's data centres sit, often overseas. | The region you choose, the UK if you need it. |
| Control | You rely on the provider's terms and word. | You hold the keys and set the rules. |
Two contract terms settle the rest. Before any text leaves your systems, PII redaction strips names, account numbers and other personal details, so the model reads the shape of a case without the person behind it. In the provider agreement, confirm the retention period and get a training opt-out in writing. The ICO's guidance on AI and data protection is where UK firms check the fine detail.
UK GDPR Article 22: a decision with a legal or similarly significant effect on a person needs meaningful human involvement, not an automated verdict on its own. The review layer described earlier is that involvement, so the compliance answer and the trust answer are the same answer.
Making an AI step reliable: grounding, structured output, and cost
A reliable AI step is not a clever demo; it is a few engineering habits applied every time. Get these three right and the model earns its place; skip them and you are left with a party trick that fails the moment your inputs shift.
-
Grounded context Retrieval-augmented generation (RAG) pulls the relevant passages from your own company knowledge before the model answers, so it works from your facts rather than its general habits.
-
Validated output The model returns a fixed JSON schema your code checks every result against, the schema validation named earlier as a guardrail put to work.
-
Right-sized model Careful prompt design plus a smaller, cheaper model handle the simple steps, and a stronger model is reserved for work that genuinely needs it.
Cost stays predictable because these services charge by the token, roughly the volume of text going in and out, so a step's price tracks its work rather than surprising you. Latency follows the same logic: an interactive step needs an answer within its latency budget of a few seconds, while heavy batch extraction can queue and run as a background job overnight.
AI agents for business: what most firms actually need
The marketing promise behind AI agents for business is a system that plans and runs the work itself. An AI agent is a language model given tools and the autonomy to plan and carry out several steps on its own, and that is what agentic AI describes. For most firms of five to fifty people, autonomous multi-step agents are still immature and carry real risk: the more a model does unwatched, the more a single wrong move can cost. What you almost always want instead is a bounded AI step, reviewable and slotted into a process you control. If a generic chatbot returned nothing, the fault was usually the shape of the AI, not the idea of it.
| What differs | Autonomous agent | Bounded reviewable step |
|---|---|---|
| Autonomy | Plans and runs many steps on its own. | Does one defined step, then hands back. |
| Reviewability | Hard to follow after the fact. | Every output is checked before it counts. |
| Failure blast radius | One error can cascade down the chain. | An error stops at the single step. |
| Fit for a 5-to-50-person firm | Rarely worth the risk yet. | The sensible default today. |
Where to start: one reviewed step, measured
The safe way to start is small and specific: pick one step where a mistake is caught before a customer ever sees it, high in volume, shaped by language, and already tolerant of a quick human check. From there, widening is a matter of watching two numbers.
Pick one reviewed step
Choose a single low-risk step inside an existing workflow, high in volume, language-shaped and review-tolerant, so every output passes a person first.
Measure two numbers
Track the review rate, how many cases need a person, and the override rate, how often that person corrects the model.
Expand once the numbers justify it
Widen the step only when the figures hold steady, and keep monitoring for drift as your inputs change.
The two numbers tell you different things. The review rate shows how much work still lands on a person: as it falls and holds, the step is carrying its share. The override rate shows whether to trust it, because a reviewer who rarely corrects a draft is telling you the model has earned its place, while creeping overrides are drift showing early. Both need somewhere they can be seen month on month, so give the people running the workflow visibility into how often the model is overridden. Widen only when the evidence holds: incremental adoption, not a leap of faith.
Start with one reviewed step
We design the reviewed AI step, the guardrails that catch a wrong output, and the audit trail behind it, fitted to a workflow you already run and costed to track the work rather than surprise you.
Talk to us about your workflow →Related: business process automation
