The short answer
- AI automation cost follows workflow complexity and consequence, not the label attached to the technology.
- Discovery, pilot, production and ongoing operation are different cost categories.
- A proposal is comparable only when outcomes, exclusions, dependencies and ownership are explicit.
- Model fees are often only one part of the complete operating cost.
- A credible business case uses ranges, baseline evidence and a defined stop decision.
There is no single price for AI automation
The honest answer is that a UK business cannot price AI automation from the phrase ‘AI automation’ alone. A workflow that classifies low-risk internal requests is a different product from a system that reads customer records, writes to a CRM, recommends decisions and triggers external communication. The second system needs more integration, security, testing, oversight and recovery design because a failure has wider consequences.
A useful estimate starts with a named workflow and a testable result. The brief should explain the trigger, inputs, systems touched, decisions made, exceptions, output, human review and expected volume. Without that map, a supplier is pricing assumptions. Those assumptions tend to return later as change requests, operational gaps or a pilot that cannot be moved into production.
The first commercial distinction is between a demonstration and an operating system. A demonstration proves that a model can produce an interesting output from selected examples. A production automation must also handle permissions, incomplete data, unexpected inputs, logging, retries, support, monitoring, deletion and human intervention. Paying for one does not automatically buy the other.
- Define one workflow rather than an ambition to ‘use AI’
- State what the automation may read, create, change and send
- Identify the person accountable for the live process
- Describe a safe fallback when the system is unavailable or uncertain
Separate the four cost layers
Discovery pays for understanding the current process before choosing a solution. It can include stakeholder interviews, workflow mapping, a data and systems review, risk screening, baseline measurement, test-case design and a recommendation. Discovery should produce reusable decisions, not merely a sales presentation. Its output should make a no-go decision possible when the workflow is not ready or the expected value is weak.
A pilot pays for bounded evidence. The team builds the smallest version that can be tested on representative cases, records failure patterns and compares results with the existing baseline. The pilot should have an explicit environment, user group, data boundary, success criteria and end date. It should not silently become a permanent production service without the controls required for live use.
Production delivery turns validated behaviour into a dependable service. Typical work includes integrations, authentication, permissions, review interfaces, exception queues, audit records, security testing, deployment, documentation, training and recovery procedures. Ongoing operation then covers hosting, model or API usage, automation platforms, monitoring, support, vendor changes, evaluation, incident response and controlled improvement.
- Discovery: decide whether and how to proceed
- Pilot: test value and risk within a controlled boundary
- Production: engineer the complete service around the model
- Operation: monitor, support and improve the live workflow
Understand the variables that move the estimate
Process clarity is a major cost driver. Stable rules, consistent inputs and a clear owner reduce uncertainty. Frequent exceptions, undocumented judgement and disagreement about the correct output require more research and testing. Automation does not remove an ambiguous process; it makes the ambiguity executable. A business may need to redesign the workflow before software is the right investment.
Technical effort grows with the number and quality of connected systems. Mature APIs, test environments and reliable identifiers make integration easier. Browser automation, legacy tools, inconsistent records and restricted vendor access increase delivery and maintenance work. Data that is sensitive, fragmented, poorly labelled or retained without a clear policy adds governance and preparation requirements before it should reach an AI service.[3]
Consequence changes the control design. An internal draft that a trained employee checks needs a different assurance level from an automated action affecting a customer, worker or applicant. Higher-consequence use can require stronger evaluation, explanation, access controls, approval, auditability and escalation. NIST’s voluntary AI Risk Management Framework organises this work around govern, map, measure and manage rather than treating risk as a final compliance check.[1]
- Workflow stability and exception rate
- Number, quality and ownership of integrations
- Data sensitivity, availability and permitted use
- Required accuracy and cost of a wrong action
- Human-review and explanation requirements
- Reliability, support and recovery expectations
Compare proposals with one procurement frame
Ask every supplier to respond to the same outcome-based brief. Require a plain description of what the system will do, who will use it, which systems it touches and what remains manual. The proposal should distinguish confirmed scope from assumptions and list the client decisions, access and data needed to keep delivery moving. A shorter proposal with explicit boundaries is more useful than a long proposal built around generic capabilities.
Ownership and exit terms deserve the same attention as build cost. Confirm who owns source code, workflow configurations, prompts, evaluation sets, documentation and newly created data. Ask which components are portable, which are tied to a platform, how credentials are managed, how data is returned or deleted, and what happens if the supplier or a model provider changes its service.[4]
Compare the ongoing operating model separately from the implementation fee. Record expected usage charges, licences, infrastructure, support coverage, monitoring, review work and future change rates. Do not treat a low model-token estimate as the complete running cost. The business still needs accountable people, maintained integrations, evaluated changes and a safe way to handle failure.
- Named outcomes and acceptance evidence
- Deliverables for discovery, pilot and production
- Assumptions, exclusions and client dependencies
- Security, privacy and risk responsibilities
- Intellectual property, portability and exit support
- Operating costs, service levels and change process
Build a business case without false certainty
Begin with the current workflow, not a projected percentage saving. Measure representative volume, active handling time, waiting time, error and rework patterns, external costs and the value of delayed work. Separate time that could actually be redeployed from time that is merely spread across many people. If the baseline is uncertain, present a range and make improved measurement part of discovery.
Model benefits as scenarios rather than a single promised return. A conservative case can assume modest adoption, retained human review and no immediate headcount reduction. A central case can use evidence from the pilot. An upside case can show what becomes possible after reliability and adoption are proven. Each case should include implementation, operation, internal change effort and the cost of managing exceptions.
Set decision gates before work begins. A business should be able to stop after discovery, pause after a weak pilot or narrow the scope when controls outweigh the benefit. Responsible procurement does not force every experiment into production. The best estimate is therefore not the cheapest number; it is a transparent range connected to evidence, risk and a reversible sequence of decisions.
- Document the current baseline and its uncertainty
- Use conservative, central and upside scenarios
- Include internal adoption and governance effort
- Agree the evidence required to continue after each stage
- Retain a clear stop, rollback and supplier-exit route
Sources and further guidance
Blancc uses primary guidance where factual or regulatory context matters. Recommendations remain general and should be assessed against the specific business, audience, product, and risk.
Read Blancc’s editorial standards and corrections policy for source selection, illustrative labels, update dates, software assistance and corrections.