Intelligent automation, and what it actually costs

Where the auditors drew the line

When the National Audit Office surveyed government bodies about artificial intelligence, it began by saying what it was not counting. The report excluded simple rules-based automation and any model embedded by default in a tool the organisation already owned, and confined itself to machine learning applied to language processing, predictive analytics and image or voice recognition. That exclusion is the most useful definition of intelligent automation published by a British institution, for the unglamorous reason that somebody had to apply it to real systems in order to count them.

Robotic process automation sits on the excluded side of that line. An RPA licence buys a computer program that operates other computer programs. It reads a field, moves a value, clicks a button and files a record, in a fixed order, on a schedule. It has no view about what it is doing. Its great virtue is that its behaviour is fully specified, which is why regulated firms adopted it first. Its great weakness is that it is bound to an interface it does not control.

Intelligent automation is the name the software industry gave to what it assembled once the easy RPA processes ran out. The bundle usually contains document understanding, a classifier or two, process discovery tooling and, more recently, a language model. The market has already delivered a verdict on the standalone version. Blue Prism, the British company that did more than any other to sell rules-based automation to large organisations and whose software was used by more than 2,000 businesses worldwide, was bought by SS&C Technologies in a deal completed on 16 March 2022 for approximately $1.6bn. A category-defining vendor became a business unit inside a financial services software group.

What the phrase covers when it is used carefully

A working deployment has four parts. Something schedules and orchestrates the work. Something executes the deterministic steps, which is the RPA layer under a newer name. Something makes a judgement, usually a classifier deciding what a document is or which queue a case belongs in. And somewhere a person reviews a subset of the output and can send it back.

Almost everything sold under this heading is a deterministic pipeline with one model in the middle of it. That is not a criticism. It is the shape that survives, because the deterministic parts can be tested and the judgement is confined to one place where its error rate can be measured. Deployments that put judgement everywhere are the ones that cannot be assured, and assurance is what an organisation is actually buying when it puts a machine between a citizen and a decision.

The word doing the marketing is "intelligent". It describes the ambition of the product category rather than the behaviour of any particular installation. The specific claim worth challenging is the one about learning: a system said to learn from your process should be able to answer what it updates, on what trigger, against what held-out data, and who approves the updated version into production. A vendor who cannot answer those four questions is describing a retraining project that the buyer will be running, not a feature that the buyer is purchasing.

The cost that arrives in the second year

Start with the part that is published. Microsoft lists its UK prices for Power Automate openly: Premium at £11.50 per user per month on an annual commitment, Process at £115.30 per bot per month for unattended automation, Hosted Process at £165.30 per bot per month where Microsoft supplies the virtual machine, and the process mining add-on at £3,844.80 per tenant per month.

Read the shape rather than the digits. An unattended bot costs roughly ten times what a human user costs, and the tool that tells you which processes are worth automating costs more per month than either. The vendor is pricing what is scarce, and what is scarce is not execution. Execution has been cheap for years. What is scarce is knowing which process to point it at.

Licences are also the smallest line an automation estate generates, and the only one anybody forecasts accurately. The rest arrive later. Each automation needs a development, test and production environment, and each environment needs its own copy of the credentials the automation uses. Those credentials belong to non-human accounts, which have to be issued, rotated and audited by an identity team that did not size its year around them. Somebody has to watch the queue overnight and know what to do when a run fails at three in the morning. And every automation that drives another system's interface has inherited that system's release schedule, so an upstream change nobody consulted you about becomes a change request you have to fund.

The public sector version of this gap is documented. The Central Digital and Data Office carried out indicative analysis in 2023 and concluded that almost a third of civil service tasks, those it defined as routine, could be automated. The National Audit Office recorded the limitation in the same paragraph: the analysis "did not examine the feasibility of delivering these productivity gains, or make an assessment of cost". A benefits figure without a cost figure is not a business case. It is a headline with a denominator missing, and the same structure turns up in commercial buying decisions every week.

One published figure runs the other way and is worth holding onto for that reason. The same audit records the Incubator for Artificial Intelligence, the Cabinet Office unit set up to build AI capability across government, estimating a five-year funding requirement of £101mn to 2028-29, before inflation. That is a costed number with a horizon attached, which makes it rare in this field. It is also a number for a central capability that builds nothing operational on its own: the departments that deploy what it enables carry their own licences, environments and review capacity on top. Anyone comparing an automation proposal against that figure is looking at the floor rather than the bill.

How to build the number nobody publishes

There is no credible published figure for the total cost of owning an automation estate in a British organisation, and the reason is structural rather than secretive. Run costs land in operating budgets that are not broken out by system. Licences sit with procurement, environment spend sits on a cloud bill nobody attributes, and the maintenance effort is absorbed by people whose job titles say something else. Any number you are shown for total cost of ownership was modelled by whoever benefits from it.

So the number has to be built from records the organisation already holds. Six of them, in order of how badly they are usually underestimated:

• The licence schedule rather than the sales quote. The schedule carries the renewal uplift and the thresholds at which bot counts move to a higher tier.
• The cloud bill, filtered to the automation environments. Development and test environments run for the convenience of the delivery team, and they run at night.
• The change-request log, counting only changes raised against the automation because something upstream moved. This is the line that tells you whether the estate is stable or merely young.
• Service desk tickets whose resolution was that the automation did not run and a person did the work instead. These are recorded as service incidents, not as automation costs, which is why they are invisible in the annual review.
• The rota. Hours of human review the automation requires in order to be safe, at the grade of the people who do it.
• Assurance. Whatever the organisation spends proving to an auditor, a regulator or a court that the thing behaves as described.

Divide the total by transactions processed. That produces a cost per transaction, which is the only figure that can be set against the manual process it replaced. Most business cases never produce it, and the reason is uncomfortable: the manual cost per transaction was never measured either, so the comparison being claimed has no baseline on either side.

There is a trap underneath all of this that British organisations fall into repeatedly. The National Audit Office's 2023 report on digital transformation lists the hidden costs government cannot see in its own services, and the first item is "additional business processes, often manual, to compensate for missing functionality in the legacy systems". Those workarounds are precisely what an automation pilot goes looking for, because they are repetitive, visible and unloved. Automating one converts an unfunded manual workaround into a funded software workaround. The underlying system is still missing the functionality, and now there are two things to maintain instead of one.

Where it has worked, and what those cases share

The most honest evidence available in Britain is not a vendor case study. Public bodies are required to publish a record of the algorithmic tools they use under the Algorithmic Transparency Recording Standard, and the repository holds 141 records. The entries are more instructive than marketing material because the organisation had to describe the tool in its own words, name an owner and say what happens when it is wrong.

The published records include the Department for Work and Pensions' Universal Credit Advances Model, which performs fraud risk assessment on advance payments, the DVLA's contact centre chatbot, which answers customers and collects information before a webchat adviser picks up, the Standards and Testing Agency's language model tool for generating examples of pupils' writing at the end of key stage 2, and Newcastle City Council's Magic Notes, which helps adult social care staff record case notes. Four organisations, four narrow problems, four named owners.

That narrowness is the finding. Every entry in the repository that has survived contact with an auditor shares the same profile: bounded input, high volume, a defined human step, and somebody whose name is attached to it. None of them is a general-purpose reasoning system dropped into a department. The National Audit Office counted 74 deployed use cases across the 87 government bodies that responded to its survey, typically one or two in each. Just over a third had deployed anything at all, and a further third were piloting or planning.

The commercial picture has the same shape at a larger scale. The Office for National Statistics reports that the proportion of businesses with 10 or more employees using at least one AI technology rose from around 12% to around 35% between late 2023 and mid-2026. Over the same period the average number of AI technologies per adopting business "increased only modestly, rising from around 1.4 to 1.6", and only 10% of businesses report using AI extensively. Adoption widened. It did not deepen. A firm that put one classifier into one process is counted identically to one that rebuilt a function around it, and the headline percentage cannot tell them apart.

Where it has not

The Home Office operated a streaming tool from 2015 that sorted visa applications by risk before a caseworker saw them. The Joint Council for the Welfare of Immigrants and the legal non-profit Foxglove brought judicial review proceedings arguing that it was discriminatory under the Equality Act 2010. In August 2020 the Home Office agreed to stop using it and to redesign the process, while declining to accept the allegation of bias. Five years of live operation ended without a published evaluation of what the tool had done to the applications it sorted.

That case is usually told as a story about bias, and it is one. It is also a story about ownership, and the ownership problem is measurable. Of the 87 government bodies the National Audit Office surveyed, 21% had an AI strategy. Among the 32 that had deployed something, fewer than half said their use cases were always or usually identified at organisational level before deployment. Only 30% of all respondents had risk and quality assurance processes that explicitly incorporated AI risks.

Read those three numbers together and the failure mode is not technical. A tool that nobody chose at organisational level has nobody obliged to defend it when it is challenged, nobody required to evaluate it while it runs, and nobody arguing for its budget in year three. It survives on the enthusiasm of the team that built it, which is a funding model with a known half-life. What a decade of rules-based deployment taught British organisations about the processes worth automating applies unchanged to models, and the lessons that carry across are the operational ones rather than the technical ones.

The four questions a second-year business case has to answer

The proposals that survive their second year are not the ones with the best benefits model. They are the ones that can answer four questions in writing before anything is signed.

• What breaks this, and whose release schedule is it on? If the answer is another team's product, the maintenance budget belongs in this business case rather than theirs.
• What is the cost per transaction, and what was the manual cost per transaction? If the second figure does not exist, the saving being claimed is an estimate compared against an estimate.
• Who owns it, by name, and what are they accountable for when it produces a wrong answer at scale? An unnamed owner means the tool is defended by whoever happens to be in the room.
• What is the human review step, who staffs it, at what grade, and does the benefits case still work once those hours are counted as a cost rather than a rounding error?

None of these questions is about the model. That is the point. Foundry4 covers this territory across its AI and automation section, and the pattern holds from a decade of RPA into the agentic era: the technology changes faster than the organisational problem, and the organisational problem is what determines whether anything survives its first renewal.

The Department for Science, Innovation and Technology and the Government Digital Service put the national prize at "over £45 billion per year of unrealised savings and productivity benefits, 4-7% of public sector spend", achievable through full digitisation of public services. That figure is a statement about processes and the people who run them. It is not a statement about software, and no licence purchase moves it. The constraint on British automation was never the quality of the models. It is that the run budget and the accountable owner are settled by people who were not in the room when the licence was signed.