AI use cases for business: seven that pay back, and how to size one first

Most AI projects fail before anyone trains a model

There is a particular kind of AI project that arrives fully formed from a board meeting. It has a budget, a sponsor and a name, and it does not have a problem statement. Some months later it has a demonstration that impresses people who do not do the work and irritates the people who do.

That failure is structural rather than technical. A project beginning with “we should be using AI” has no way to decide what good looks like, so it optimises for the only visible milestone available: launching. A project beginning with “coding supplier invoices occupies two people for most of a week every month, and we already know the error rate” has a target on day one, and can be stopped cheaply when the numbers do not hold.

The adoption data is consistent with this. The ONS reports that self-reported AI use among UK businesses with 10 or more employees rose from around 12% to around 35% between late 2023 and June 2026. Over the same period the average number of AI technologies used per adopting business moved only from about 1.4 to 1.6, and the largest single category in June 2026 was large language models, at 18%. Adoption is wide and shallow: a great many organisations have bought a chat tool and have not yet changed a process. Larger firms are further along — 49% of businesses with 250 or more employees report use — but the shallowness looks much the same at every size.

The most useful corrective comes from Google’s own machine learning guidance, which opens with the least fashionable advice in the field: “Don’t be afraid to launch a product without machine learning.” Its accompanying estimate is worth memorising before any vendor meeting — “If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.” A sorted list, a threshold rule and a better-designed form recover much of the available value, and they tell you cheaply whether the other half is worth funding.

The six numbers to write down before you fund anything

Every use case below is worth doing under some conditions and not worth doing under others. What separates the two is arithmetic, and the arithmetic needs six inputs. Put them on one page before anybody builds a prototype.

Number	Why it decides the project
Volume per month	Below a few hundred repetitions, the maintenance burden usually exceeds the saving. Automation is a fixed cost amortised over instances.
Unit time and loaded cost	What one instance costs in salaried minutes today. This is the numerator of every saving you will later claim.
Realistic automation rate	The share you can handle with no human involved. Never assume all of it. Systems designed for full automation fail; systems designed for two thirds with a clean handoff succeed.
Cost of a wrong answer, and who absorbs it	A mis-coded invoice costs a correction. A mis-priced quote costs margin. A wrong credit or medical decision costs far more, and changes the regulatory picture entirely.
Whether a record of past decisions exists	You cannot learn from decisions nobody wrote down. This one question kills more proposals than any other.
Standing run cost	Inference or licence fees, monitoring, retraining, and the named human who owns it when it misbehaves.

The last row is where estimates are most often wrong, and Google Cloud’s MLOps guidance explains why: “only a small fraction of a real-world ML system is composed of the ML code.” The rest is configuration, data validation, testing, serving infrastructure and monitoring. The model is the part that demos well and the smallest part of what you will maintain. Google’s fourth rule follows from the same observation — keep the first model simple and get the infrastructure right.

Two practical tests fall out of that table. If you cannot fill in the volume and unit cost rows from systems you already have, then your first project is not an AI project at all, it is measurement work, and the data readiness checklist is the faster route to finding out what is missing. And if the business case only closes at a very high automation rate, it does not close, because the last few per cent of any real workload is where the strange cases live.

1. Document, invoice and form extraction

Pulling structured fields out of unstructured documents is the most reliably fundable AI use case in an ordinary business, because every term in the table above is knowable in advance. You know how many invoices, claims forms, delivery notes or applications arrive, and what a person spends on each. And you have ground truth: the invoice total either matches the purchase order or it does not.

The machinery is mature and mostly bought rather than built. Document processing platforms separate into families that digitise (optical character recognition with layout and image quality analysis), extract (form parsers returning key-value pairs and tables, plus custom extractors for document types specific to you), and classify (splitters that break a scanned bundle into its constituent documents). Most of the work in a real deployment is not model work. It is deciding what happens to the output.

Design around a confidence threshold from the beginning. High-confidence extractions post automatically; low-confidence ones queue for a person, with the values pre-filled and the source region highlighted. The metric that matters is the straight-through processing rate — the share needing no human touch — not accuracy, which can look excellent while the process saves nothing.

The usual failure mode is scope. An organisation with three hundred supplier formats attempts all of them, and the two hundred rarest consume most of the effort for a fraction of the volume. Rank formats by count, take the head of that list, and leave the tail on the manual process without apology.

2. Support deflection with retrieval over your own documentation

Retrieval-augmented generation is the pattern where a model answers only from passages retrieved out of your own documentation, with citations back to the source. It is the right architecture for support, because the knowledge changes weekly and the model must not invent policy.

Start by assisting agents rather than replacing them. Nielsen Norman Group’s aggregate across three controlled studies found generative AI tools raised throughput by an average of 66%, but the individual results matter more than the headline: support agents handled 13.8% more inquiries per hour, while business writers produced 59% more documents per hour and programmers completed 126% more projects per week. Support sits at the bottom of that range, and the quality gain in the support study was a negligible 1.3%. The genuinely interesting finding was distributional — the worst-performing 20% of agents improved throughput by 35%, far more than the best did. That is a levelling and training effect, not a headcount argument.

The uncomfortable part is that retrieval quality is a content problem wearing a technology costume. Where documentation contradicts itself, retrieval surfaces the contradiction faster and far more confidently than a human would. Budget for rewriting the twenty articles that generate most of your ticket volume before you index anything.

Measure deflection honestly. A ticket resolved without a human is only deflected if the customer does not come back tomorrow, so track re-contact rate alongside it, and never count an abandoned session as a success.

3. Demand and inventory forecasting

This is classical machine learning rather than anything generative, and for a business holding stock it is usually the highest-value model in the building. The payoff is not really forecast accuracy; it is working capital and service level.

Insist on a baseline. A seasonal naive forecast — this week last year, adjusted for trend — is embarrassingly hard to beat, and if a proposed model cannot beat it on held-out data you have learned something valuable for very little money. A vendor unwilling to be measured against that baseline is telling you something.

The data requirement is specific: daily history across at least two annual cycles, plus the events that distorted it. Promotions, price changes and stockouts above all. A stockout censors demand — sales were zero because there was nothing to sell, not because nobody wanted it — and a model trained on unadjusted sales learns to under-order precisely the lines that sell out. It is the most common defect in forecasting work and it is invisible in the accuracy metric.

None of it pays unless the replenishment decision changes. If purchase orders are placed by someone who overrides the system on instinct, the model is an expensive opinion. Decide who acts on the output before you build it.

4. Lead scoring and churn prediction

These are the same problem in different clothing: a binary outcome, plenty of historical labels, and data already sitting in a CRM. That makes them cheap to attempt and unusually easy to get wrong.

The first trap is leakage. A field only populated once a deal closes, or a support flag only set after someone has phoned to cancel, will make a model look extraordinary in testing and useless in production. The test is whether you can reconstruct the record as it existed at the moment of the decision. If you cannot, the model is reading the answer off the back page.

The second trap destroys measurement. Once you act on a churn score you change the outcome you were predicting, so accuracy against subsequent reality becomes meaningless. The only way out is a control group who receive no intervention, which the commercial team will resist and which you should insist on anyway.

The third is that a score tells you who, not what to do. Retention value comes from the intervention, and the intervention needs its own test. A model that identifies at-risk accounts perfectly, feeding a discount that was never necessary, loses money with great precision.

5. Personalisation and recommendation

Recommendation pays in proportion to catalogue depth. With forty products, ranking them well is a merchandising and information architecture problem, and a good category page beats a mediocre recommender comfortably. With forty thousand, no human can do the ranking and a model earns its keep.

Two facts govern the build. Cold start is real: new products and new visitors have no history, so a system with no fallback will quietly recommend nothing at the moments that matter most. And a popularity baseline is strong — recommending what is selling anyway captures much of the available lift, which makes the honest question how much your model adds over popularity, not how it looks in isolation.

Measure with a holdout. Clicks on recommended items are among the most misleading metrics in online retail, because a large share of them would have happened anyway through search or navigation. Split the traffic, compare revenue per session, and accept the answer you get.

6. Visual inspection and anomaly detection

In physical operations, automated visual inspection catches defects at a consistency no human sustains across a shift. In digital operations, the same statistical idea catches unusual transactions, unusual usage and unusual infrastructure behaviour.

Both share a characteristic that trips up newcomers: severe class imbalance. If three units in a thousand are defective, a model declaring everything acceptable is 99.7% accurate and completely worthless. Judge these systems on recall at a fixed false-alarm rate, never on accuracy, and agree that rate with the people who will act on the alerts.

For visual inspection, most of the achievable gain is physical rather than algorithmic. Fixed lighting, a repeatable fixture, a consistent camera angle and a clean background will do more for detection rates than a larger model will. Spend on the rig first.

For anomaly detection over logs and transactions, the binding constraint is triage capacity. A system generating more alerts than the team can investigate produces alert fatigue, and alert fatigue produces ignored alerts, which is worse than no system at all. Tune the threshold to the investigations you can genuinely staff, not to the anomalies that exist.

7. Internal knowledge search

Search across the shared drive, the wiki, the ticket history and eleven years of accumulated documents is the use case everyone asks for and the one that most often disappoints. The machinery is the same retrieval stack as support deflection, but three things are harder.

Permissions are messier. An index built over a corporate file store will happily answer a question using a document the person asking should never see, and the fix is not a filter applied after the fact — retrieval has to respect the source system’s access controls, per document, at query time. OWASP lists both sensitive information disclosure and vector and embedding weaknesses in its 2025 Top 10 for LLM applications for exactly this reason.

The corpus contradicts itself. Four versions of the expenses policy exist and only one is current. Retrieval cannot know which, so the answer is governance rather than modelling: mark documents current or archived, and keep the archive out of the index.

And the value is hard to measure. The workable approach is to seed thirty real questions with known answers, time how long people take to answer them today, then re-run the exercise after launch. That is a modest study producing a defensible number, which is more than most internal AI projects offer. It also tends to reveal the uncomfortable finding: the largest improvement often comes from deleting and consolidating documents rather than searching them better. That work needs no model at all, and is frequently the whole project.

Build, buy or fine-tune: a decision rule

Option	Use when	What you own	Main risk
Buy a product	The capability is generic and not a competitive difference: transcription, translation, meeting notes, standard document capture	Configuration, and your data if the contract says so	Per-seat cost growth, and a roadmap you do not control
Assemble	The knowledge is yours and the capability is generic — retrieval over your documents, your workflow, a hosted model behind it	The workflow, the index and the evaluation set	You now run software; the integration is the real project
Fine-tune	Output format or behaviour must be consistent across thousands of calls, and you have hundreds of good examples	A model artefact tied to a base version	Examples go stale, base models move on, and evaluation becomes your job
Train from scratch	Almost never, at the scale most businesses operate at	Everything, including the problem	Cost and expertise far beyond the value for nearly all commercial uses

The distinction that saves the most money is between retrieval and fine-tuning, and it is widely misunderstood. Retrieval fixes a context problem: the model does not know your prices, your policies or last quarter’s minutes. Fine-tuning fixes a behaviour problem: the model knows enough but will not respond in a consistent form, or you want the same result out of a smaller and cheaper model. OpenAI’s accuracy guidance frames fine-tuning as being for task accuracy or for efficiency, and offers a useful caution — in one of its own case studies, adding retrieval to an already fine-tuned model reduced accuracy by four points. More machinery is not automatically better, and every layer needs its own evaluation.

Most businesses reading this need the second row. The build cost then sits mainly in the application around the model rather than in the model itself — authentication, the review queue, audit logging, the admin screens — which follows the same cost drivers as any web application and needs the same application engineering discipline. The review interface deserves attention too: a human-in-the-loop process where the reviewer cannot see why the system proposed something degrades into rubber-stamping quickly, and that is a design problem as much as a technical one.

Governance questions to answer before go-live

Governance here means being able to answer specific questions, not producing a policy document nobody reads. NIST’s AI Risk Management Framework, released in January 2023 and explicitly voluntary, organises the work into four functions — govern, map, measure and manage — which is a reasonable skeleton to hang answers on. The UK’s Department for Science, Innovation and Technology publishes an accessible introduction to assurance techniques covering similar ground in British regulatory vocabulary.

The questions worth answering in writing:

1. Which risk tier does this fall into? The EU AI Act sorts systems into unacceptable, high, transparency and minimal risk. Prohibitions and AI literacy obligations applied from 2 February 2025, general-purpose AI and governance rules from 2 August 2025, and the bulk of the regulation from 2 August 2026, with high-risk obligations phasing in after that. Uses touching employment, education, credit or biometrics land in the high-risk tier, which changes a project substantially. Most internal productivity tooling does not.
2. What personal data is involved, and on what lawful basis? The European Data Protection Board’s Opinion 28/2024, adopted in December 2024, addresses when an AI model can be considered anonymous, when legitimate interest can support training, and what follows when training data was processed unlawfully. If you are training or fine-tuning on customer records, that is required reading rather than optional.
3. Where does the data go? Which provider, under what retention terms, and is your input used for training. Answer it per tool, in a register, and tell staff plainly which tools are approved.
4. What is logged? Inputs, outputs, the retrieved sources and the human decision. Without that you cannot investigate a complaint or diagnose a regression, and both will happen.
5. Who reviews consequential decisions? For anything affecting a person’s money, employment or access to a service, a review that is genuine — with the authority and the information to overturn the system — rather than nominal.
6. What does the threat model include? Prompt injection, sensitive information disclosure, excessive agency and misinformation all appear in OWASP’s Top 10 for LLM applications. The mitigation for excessive agency is unexciting and effective: grant read access before write access, and write access long before anything that moves money.
7. How will you know it has degraded? Models decay in more ways than conventional software does, and training-serving skew — features computed differently in production than in training — is the classic silent failure. Monitor input distributions and output quality rather than only uptime, and define in advance what triggers a rollback.

What we would not fund yet

Autonomous agents with write access to production systems. The demonstrations are impressive and the failure modes are not yet well characterised. Read-only research assistants and drafting tools with a human approving the send are a different proposition, and often worth doing now.

A chatbot as the primary conversion path on a marketing site. It intercepts people who were going to convert anyway and adds friction for those who were not. Fix what the page says first.

Training a foundation model. For any business that is not itself an AI company, the cost and expertise required sit far beyond the value returned.

High-volume AI-written content aimed at search. Generating articles at scale to chase rankings treats a symptom of a strategy problem, and search systems are increasingly good at recognising the pattern. If the goal is visibility inside AI-generated answers, the work is structural and editorial — see our note on optimising for generative engines.

Any headcount reduction justified by pilot numbers. The productivity research shows gains concentrated among the least experienced workers and varying widely by task. Compressing that distribution is valuable. Treating an average from a controlled study as a staffing plan is not.

Anything where you cannot state the metric. If nobody can complete the sentence “this succeeds if X moves from A to B”, the project is not ready, whatever the technology.

The shortest useful first step

Pick one repeated process. Fill in the six numbers. Build the heuristic version first — the rule, the sorted list, the better form — and measure it against the baseline you recorded before you started. If the heuristic closes half the gap, you now know what a model would have to be worth, and you have a working pipeline to put one into when you decide it is.

That sequence is deliberately unexciting, and it is the difference between an AI capability and an AI announcement. If you want a second opinion on which of your processes clears the bar, that is the conversation we prefer to have before any machine learning work gets scoped — we would rather tell you a use case does not pay than build it anyway. Send us the process, the volumes and what a mistake costs, and the arithmetic usually answers the question on its own.