What the research actually says
Pax8’s Q3 2026 SMB AI Pulse report gives four useful UK findings:
- 54% of AI-engaged businesses surveyed had built AI solutions already in regular use.
- 23% reported formal, documented review of internally built AI, the lowest of the four markets.
- 24% of AI-engaged businesses had discovered unapproved AI operating during the previous six months.
- 44% of decision-makers spent at least three hours a week reviewing AI-generated work.
The UK sample was 350 leaders at businesses employing 5–499 people. These are survey responses, with different questions applying to different groups. They do not mean that 54% of every UK small business has built an agent, or that the other 77% never check anything. Informal checking and a documented review process are different things.
There is a similar concern in larger firms. IBM’s UK findings, in a release dated 15 October, say eight in ten UK executives surveyed had seen an AI incident reach their board or senior leadership. Only 35% of those organisations cited a resulting change to governance policy or frameworks. That study concerned organisations with at least 1,000 employees; it is separate evidence, not an SME comparison.
Review the whole job, including the checking
Our practical reading is that getting a workflow running is only part of the job. Someone still has to decide whether its output is usable, deal with exceptions and keep the connections working.
Take a fictional wholesaler using AI to turn incoming emails into draft orders. A tidy demonstration reads the product, quantity and delivery address correctly. Everyday work includes an old attachment, a customer changing their mind halfway through a thread, two products with similar names and the same order arriving twice.
A useful review asks what happens in each case. Does the system flag a missing product code? Does a person see the original email beside the draft? Can it create a duplicate order if a connection times out? Can it promise a delivery date without checking stock?
Those answers matter more than how quickly the first draft appears. Measure the whole journey: reading, checking, corrections, exceptions and the eventual handover. Time spent reviewing may be entirely worthwhile, but it belongs in the calculation.
An AI workflow checklist before it goes live
Use this with the person who knows the job and whoever built the automation. Record the answers in one shared document. A vague answer is something to resolve before expanding the trial.
- Name the job and its owner. Write one sentence describing what the workflow should achieve. Name the person responsible for it, a backup and who can approve changes. “The AI handles orders” is too broad; “prepare draft orders for the sales team to check” gives you a testable boundary.
- List what it can read and change. Record its connected inboxes, folders, databases and external services. Give it only the access needed for this job. Test with a restricted user as well as an administrator. Our guide to AI permissions explains why access needs checking separately from answer quality.
- Choose the human approval points. Be explicit about who approves customer messages, prices, payments or changes to live records. During an initial trial, draft output can stay in a review queue. Enforce approval in the software: an instruction asking the model to be careful is not an access control.
- Test awkward work as well as clean examples. Include missing information, conflicting records, unreadable attachments, duplicates and requests outside the agreed task. Use authorised test data. Write the expected behaviour first, including when the workflow should stop and ask someone.
- Check that outside content cannot grant new permissions. An email or document may contain instructions to ignore the task or disclose information. Treat that content as input to examine. Test that it cannot authorise a tool call, expose another customer’s records or bypass an approval.
- Keep a useful record of what happened. Capture the source record, proposed action, approval and final result, with the workflow version and time. Restrict access to these records and agree how long to retain them. A reviewer should be able to understand a disputed outcome without reconstructing it from memory.
- Set limits and a recovery route. Agree spending alerts, run limits and what happens after repeated failures. Test the stop control and the manual fallback. If the automation changes records, test how to identify and correct those changes without overwriting later legitimate work.
- Review after launch and after changes. Set a review date, inspect exceptions and compare total handling time with the previous process. Repeat the relevant tests when a model, prompt, connector, permission or source format changes. Keep the evidence of that review with the workflow.
A small review record you can copy
Workflow: What job does it do, and what is outside its scope?
Owner and backup: Who keeps it working and handles exceptions?
Access and actions: What can it read, draft, send or change?
Approval: Which actions need a person, and how is that enforced?
Tests: Which examples passed, what failed, and where are the results?
Limits and recovery: How do we cap spend, stop it and continue manually?
Decision: Limited trial, ready for the agreed scope, or more work needed?
Next review: Named reviewer, date and changes that trigger an earlier check.
This is a starting record for an operational review. The depth of testing should follow the consequences of a mistake. A tool suggesting an internal filing label and one changing a customer’s account need different scrutiny.
Start with one workflow already doing work
Choose something people are relying on today. Sit with its owner and follow one real job through it. Find out where data goes, where a person checks the result and what happens when the connection fails. That will give you a more useful starting point than buying another tool.
Sometimes the right fix is a clearer approval screen or a tighter permission. Sometimes a predictable step should be handled by ordinary software. Keep AI where interpretation helps, and make the surrounding process understandable to the people responsible for it.
Inferred is based in Horsham and works with owner-managed businesses across Sussex, Surrey and the wider South East. Our AI consultancy in Sussex starts with the work, the data boundaries and whether a change is worth making. Bring one workflow and show us where you are unsure about it.
See how our AI consultancy works →
Sources and scope
- Pax8 announcement, dated 12 October 2026, and the original Q3 report, particularly PDF pages 3, 8 and 9. The online survey covered 1,150 business leaders in four countries. Pax8 notes that smaller subgroups should be interpreted directionally.
- IBM UK announcement: the page is labelled 14 October and its release dateline is 15 October 2026. Censuswide surveyed 3,221 executives, including 504 in the UK, during 14–24 September. The 35% figure above is the UK result; the separately reported EMEA result is 40%.
Both studies were commissioned by technology suppliers. The checklist, review record and fictional wholesaler example are Inferred’s practical interpretation, not findings from either survey or a claim about an Inferred customer.