Automating workflows with AI: where it saves time and where it creates risk

Connect an AI model to your inbox, spreadsheet and accounts software, and a lot of routine work can run by itself: invoices read and logged, enquiries sorted, first replies drafted. Done well, this frees hours each week. Done carelessly, it creates errors that nobody spots until a customer, supplier or auditor does.

This guide looks at which kinds of work suit AI automation, where the risks sit, and two controls that make the difference: human review in the right places and a clear audit trail. It complements our separate piece on working with AI agents, and focuses on fixed, repeatable business processes.

Workflows and agents are different things

Anthropic’s engineering guide, Building effective agents, draws a useful line. Workflows are “systems where LLMs and tools are orchestrated through predefined code paths.” Agents are systems where the model decides its own steps and which tools to use. Most small-business automation should be a workflow: you decide the steps, and AI handles the parts that need reading or writing.

The same guide advises finding “the simplest solution possible, and only increase complexity when needed.” It also notes that more autonomy brings higher costs and the potential for compounding errors, where a small mistake early on is carried through every later step.

Where AI saves time

The best candidates are tasks that are frequent, mostly about language or documents, and easy to check. Common examples:

• Sorting and routing: classifying incoming emails or tickets and sending them to the right person or queue. Anthropic calls this pattern routing.
• Extracting data: pulling supplier name, date, amount and VAT from invoices or order forms into a spreadsheet.
• Drafting: first replies to common enquiries, meeting notes or product listings for a person to edit.
• Summarising: turning long threads, calls or reports into short briefs.
• Checking steps: breaking a job into a chain of steps with a check between each, which Anthropic describes as prompt chaining with gates.

Where it creates risk

• Actions you cannot undo: paying a bill, deleting records or emailing a customer are much riskier than adding a row to a draft sheet.
• Decisions about people: refusing a refund, rejecting an applicant or flagging an account as fraud can fall under data protection rules on automated decisions. In the UK, the Data (Use and Access) Act provisions on automated decision-making came into force on 5 February 2026.
• Untrusted input: the National Cyber Security Centre’s guidance on AI and cyber security warns that prompt injection lets crafted input make a model behave in unintended ways. An automation that reads incoming emails is reading text written by strangers.
• Silent failure: AI rarely crashes. It produces a plausible wrong answer, and the process carries on.
• Automation bias: the ICO describes how people “routinely rely on the output generated by a decision-support system and stop using their own judgement.” A reviewer who approves everything adds no protection.

Put human review in the right places

The UK government’s AI Playbook sets out a principle of “meaningful human control at the right stages,” and says humans should “validate any high-risk decisions influenced by AI.” The ICO’s guidance on individual rights adds that reviewers need “the authority to override the output” and must be confident they “will not be penalised for so doing.”

Three patterns cover most needs:

1. Approve before action: AI prepares, a person approves. Use it for anything sent to customers, any payment and any decision about a person.
2. Exception queue: AI handles routine cases and sends anything unusual, low-confidence or above a threshold to a person.
3. Sample checks: for low-risk, high-volume work, a person checks a fixed share of items each week and tracks the error rate.

Keep an audit trail

When something goes wrong, you need to know what the system saw, what it produced and who approved it. The AI Playbook talks about “retaining traceability throughout the AI project” and documenting each stage. For a small business, a simple log per item is enough:

• the input (or a link to it) and a timestamp;
• the prompt or instructions version used;
• the model and version, since OpenAI recommends pinning production apps to a specific model snapshot;
• the output;
• who reviewed it, what they changed and what action followed.

Keep personal data in the log to the minimum you need and set a retention period, because the log itself is a record that data protection rules apply to.

A worked example

An example (illustration only): a small wholesaler receives about 300 supplier invoices a month as email attachments. Keying them in takes roughly 15 hours a month.

Most invoices now need only a quick approval, while the riskiest ones, such as changed bank details, always get a person’s attention. The time saved is the keying, not the judgement. The finance manager still owns every payment, and the log shows exactly which invoices the AI read, what it extracted and who approved the run. If an extraction error slips through, the team can find every invoice processed with the same prompt version and recheck them.

Roll it out in stages

1. Map the current process and pick one step that is frequent and easy to check.
2. Run the AI in shadow mode for two to four weeks, alongside the manual process, and compare results.
3. Agree an acceptable error rate and the cases that must always go to a person.
4. Set stopping conditions, such as a maximum number of retries, as Anthropic suggests for agents.
5. Go live with approval before action, then relax to sampling only when the error rate stays low.
6. Review the logs monthly and update prompts and rules from the mistakes you find.

Common mistakes

• Automating a messy process before fixing it.
• Letting AI send customer emails or make payments with no approval step.
• Reviewers approving everything because the queue is too long.
• No log, so errors cannot be traced or explained.
• Updating the model or prompt without re-testing on past cases.
• Choosing an agent when a fixed workflow would do the job.