How does AI generate value?

A practical answer for people who have to fund the decision · Updated 20 September 2026

AI generates value by lowering the cost and the latency of cognitive work: reading, classifying, drafting, extracting, summarising, deciding. That’s the whole mechanism, at bottom. But cheaper cognition only becomes money through a small number of specific routes, and knowing which route applies to your case is the difference between a project that pays for itself and one that produces an impressive demo and a permanent maintenance bill.

There are six of them. Most failed AI initiatives either picked the wrong one, or picked a real one and then leaked the value before it reached the P&L.

The six mechanisms

1. Substitution — the machine does work a person was doing

The route everyone talks about, and the hardest to actually land. Value here equals labour removed from the process.

It works when three things are true at once. The task is high volume. Checking an answer is much cheaper than producing one. And the organisation will actually remove or redeploy the freed capacity. Miss that third one and you’ve bought a productivity improvement that never shows up in anybody’s budget.

Good fits: ticket triage and routing, document data extraction, first-line responses to repetitive questions, classification and tagging, structured data cleanup.

2. Augmentation — the same person does more, or better

The model drafts, the expert edits. Value equals throughput per person, or quality per hour.

It’s where most real-world value sits today, and it’s also the one people over-claim most. Minutes saved by twenty people don’t become cash unless that capacity gets pointed at something measurable. Model it as a percentage improvement in output, tied to a specific outcome, not as automation.

Good fits: engineering, sales outreach, analysis, content production, code review, research.

3. Expansion — work that was never economic becomes possible

Often the largest and most overlooked mechanism, because there is no existing cost line to compare against. Previously you sampled 2% of support calls for quality; now you can read all of them. Previously nobody reviewed every contract for a given clause; now that is a nightly job. Previously leads were enriched only when a human got round to it.

The value here is not saved labour — nobody was doing the work. It is better decisions, discovered revenue, and risk you can now see. It needs a different business case than substitution, and it tends to be where the durable advantage is, precisely because competitors are still arguing about headcount reduction.

Good fits: full-coverage quality monitoring, contract and policy review at scale, exhaustive data enrichment, proactive anomaly detection across everything rather than a sample.

4. Speed — the same output, much sooner

Where latency has a price, compressing it is worth money independent of any labour saving. Inbound lead response time has a well-established relationship to conversion. Incident resolution time maps to churn. Time-to-quote decides who wins the work.

This one is easy to measure and easy to attribute, which makes it a good first project even when the labour saving is modest.

5. Consistency — the rule is applied the same way every time

Humans apply policy with variance, especially at 4pm on a Friday and especially across a distributed team. A system applies it identically at every hour. Where variance itself is the cost — compliance exposure, inconsistent pricing, uneven customer experience, audit findings — removing it is the value, even if total labour is unchanged.

6. New products — capability you can sell

Features that were not previously buildable at all: natural-language interfaces over your own data, automated analysis as a paid tier, instant personalisation. The value is revenue rather than cost, and it is the only mechanism on this list where being early is itself worth something.

Where the value actually lands: verification asymmetry

If you take one idea away from this page, take this one. The return on an AI project is mostly set by how much cheaper it is to check an answer than to produce one.

So the first question about any AI initiative isn’t “can the model do it?” It’s “how would we know if it got it wrong, and what would that cost us?”

Why value leaks before it reaches the P&L

Plenty of projects create genuine value and still show no return. The usual leaks:

• The review tax. If every output is checked by a person, you converted doing into checking. Sometimes that is a win; often it is not, and it is rarely modelled.
• Diffuse savings. Four minutes saved across thirty people is not a line item. Without a removed cost or redeployed capacity, the saving is notional.
• Error costs set downstream. A mistake costs whatever it costs where it lands (a wrong quote, a bad refund, a compliance breach), not what the task cost to perform.
• Maintenance. Models deprecate, prompts drift, upstream APIs change. Budget 15–25% of build cost annually, permanently.
• Displaced rather than removed cost. Work moves from one team to another and the total is unchanged. Common, and invisible unless you measure both sides.
• The 80% trap. A system that handles 80% of cases saves far less than 80%, because someone must still identify which cases those were.

Each of these is quantifiable. The ROI model and calculator puts numbers against all of them, including an interactive version you can run with your own figures.

Five questions that predict the outcome

1. Which mechanism is this? Substitution, augmentation, expansion, speed, consistency or product. If the answer is “several”, it is probably none of them yet.
2. How cheaply can we verify an answer? If there is no cheap check, expect augmentation at best.
3. What does an undetected error cost, and how often will it happen? Multiply them. That product has sunk more projects than model quality ever has.
4. Which budget line moves, and who owns it? A named cost that goes down, or a named revenue that goes up. No name, no ROI.
5. What is the volume? Below a few hundred tasks a month, custom build cost rarely amortises. Buy something, or do not do it.

A sensible sequence

Teams that get value out of this technology tend to follow the same order, and it is not the order that makes the best slide:

1. Pick a task with cheap verification and real volume. Boring beats impressive. The goal of the first project is a working delivery pipeline and an honest measurement, not a showcase.
2. Build the evaluation harness before tuning anything. Without measurement you cannot tell improvement from noise, and every later decision inherits that blindness.
3. Ship behind a human, then measure the real automation rate. It will be lower than the pilot suggested. That number, not the demo, is the business case.
4. Raise automation where errors are cheap; keep the human where they are not. Tune the threshold with evidence rather than ambition.
5. Handle security as an architecture question from the start. Access control, tool permissions and data egress are far cheaper to design in than to retrofit.
6. Re-measure quarterly against the original model. Replace every estimate with a measurement as it becomes available.

When AI does not generate value

• The real problem is upstream (a badly designed form, a missing field, an unclear policy) and the model is being used to paper over it. Fix the cause; it is cheaper and it stays fixed.
• Volume is too low to amortise a build.
• Nobody can check the output efficiently, and errors are expensive.
• The process changes faster than the automation can be maintained.
• The initiative exists because AI is on a roadmap, not because a problem was identified. This is the most expensive failure mode, because it survives review for longer than the others.

A well-argued “no” is a good outcome. It costs a few days of analysis and saves a quarter of engineering.

Finding the opportunities systematically

Everything above evaluates one initiative at a time, which is fine when someone has already proposed one. The harder question is how to find the opportunities in the first place, across a whole operating domain, rather than waiting for use cases to be suggested. That is a mapping problem, and the method is set out in decision engineering — building a portfolio of the decisions a business actually makes, tracing each to the metrics it moves, and ranking by where cognition is worth pointing.