What Is AI Automation? Examples, Costs and Risks for UK Businesses
AI automation is using a language model to handle the parts of a process that plain code cannot — reading an unstructured document, classifying a free-text enquiry, drafting a reply. Where the input is already structured, conventional automation is cheaper, faster and more predictable. The distinction is the whole decision.
The term covers two quite different things, and conflating them causes most of the disappointment. Conventional automation moves data between systems according to rules. AI automation handles input that has no reliable structure. Many “AI automation” projects are actually the former with a model bolted on, which is slower and more expensive than the version without.
- Use AI where input is unstructured. Use plain code where it is not.
- Cost per interaction matters at volume — model it before committing.
- Anything customer-facing needs a human in the loop or an escalation route.
- Without an evaluation set you cannot tell whether a change improved anything.
Where AI earns its place
| Task | AI or plain code? |
|---|---|
| Copy a field from a form into a CRM | Plain code. Using a model here is expensive and less reliable |
| Extract line items from a supplier PDF | AI. The layout varies and rules do not generalise |
| Route an enquiry by the dropdown they selected | Plain code. |
| Route an enquiry by what they wrote in the message box | AI. Free text is exactly the case it handles |
| Answer a policy question from your documentation | AI, with retrieval and citation |
| Calculate a total | Plain code. Never ask a model to do arithmetic that matters |
What it costs
Two components. The build — a well-defined automation is usually a few thousand pounds; a programme across several processes sits in the same bands as any custom software. And the running cost, charged per token, which is trivial at low volume and genuinely significant at high volume. Modelling cost per interaction at realistic volume before committing is the step most often skipped, and it is where AI projects quietly become unaffordable.
The risks worth taking seriously
- Confident wrong answers. A model will produce something plausible rather than admitting uncertainty, unless you build a refusal path. In customer-facing use this is the main risk.
- Silent failure. An automation that stops working often stops quietly. Alerting and a manual fallback are part of the build, not extras.
- Data boundaries. Decide explicitly what is sent to a model provider and what is not. Enterprise tiers generally do not train on submitted data, but that should be a decision you made rather than an assumption.
- Automating a broken process. The most expensive failure mode. Map it first; automation makes a bad process fail faster and at greater scale.
Frequently asked questions
What is the difference between AI automation and workflow automation?
Workflow automation follows rules you define. AI automation handles input too variable for rules — unstructured documents, free text, classification. Most real projects use both, with the model doing the one step that needs judgement and plain code doing everything around it.
Do we need our own model?
Almost certainly not. Retrieval over your own data with a strong general model is cheaper, faster to build and easier to keep current than fine-tuning. Fine-tuning suits narrow, stable tasks with consistent formatting, which is a smaller category than it sounds.
Is it safe for customer-facing use?
With grounding, a defined scope, a refusal path and an escalation route to a person, yes. Without those, it is a liability — the failure mode is telling a customer something untrue with complete confidence.
How do we start?
Pick one high-volume, rule-shaped, disliked task and automate that first. Resist starting with the most interesting problem; start with the one whose success will be obvious and whose failure is recoverable.
We build these as AI automation and AI agent projects, starting from a process map rather than a tool choice.
