Enterprise AI Use Cases: What Actually Reaches Production


There is no shortage of enterprise AI use case lists. Most are inspiration catalogues: fifty things AI can theoretically do, arranged by department, with no indication of which survive contact with a production environment.
That gap matters, because the failure rate is not evenly distributed. MIT’s Project NANDA found in 2025 that only about 5% of task-specific enterprise AI tools reached production at all. The ones that made it were not the most technically ambitious. They were aimed at processes with clear boundaries, a measurable baseline, and a person still making the final call.
This article covers the enterprise AI use cases with documented production results, the evidence for each, and what each typically breaks on. It is organised by function rather than industry, for a reason set out below.
Where returns actually appear
Start with the misallocation, because it shapes everything after it.
MIT found roughly half of generative AI budget going to sales and marketing, while the sharper documented returns appeared in back-office automation. The reason is not that anyone believes sales AI is more valuable. It is that sales metrics are easier to attribute — demo volume and email response time map cleanly onto board-level KPIs, while fewer compliance violations and a faster month-end close do not.
S&P Global’s 2026 research points the same way from the buyer’s side: process efficiency (64%) and employee productivity (59%) dominate stated objectives, while head count reduction is named by 24%. The value most organisations pursue is operational, not commercial.
The practical filter: unglamorous processes with a measurable current cost outperform visible ones with attributable-looking metrics. A use case that would demo well and measure badly is a poor first choice.
Two families of use case, and why the difference matters
Almost every current list treats enterprise AI as synonymous with generative AI. That is a recent distortion, and it hides the most important selection criterion available.
Predictive and classification use cases — forecasting, anomaly detection, scoring, segmentation, routing — can be validated against history before anyone builds anything. You have last year’s data. You can test whether a model would have predicted what actually happened. The accuracy question is answerable in a week, on a laptop, for the cost of an analyst’s time.
Generative use cases — drafting, summarising, answering, extracting from unstructured text — cannot be validated that way. There is no historical ground truth for “what the ideal draft would have been.” Evaluation has to be constructed, usually by having humans grade sample outputs, and the criteria are argued over rather than measured.
This asymmetry should drive sequencing more than it does. If two candidates look equally valuable and one is predictive, the predictive one carries substantially less risk — not because the technology is better, but because you can find out whether it works before committing to it.
Both families appear below, and the distinction is noted per use case.
The use cases, by function
1. Customer support and service
Type: generative, with classification components
What it does. Drafts responses, classifies and routes incoming requests, retrieves account or product information, resolves routine enquiries end to end, and summarises interactions for whoever touches the ticket next.
The evidence. The most consistently documented category. Google Cloud’s 2025 research found 63% of executives reporting improved customer experience from generative AI, with specific deployments achieving 120 seconds saved per contact and $2 million in additional revenue attributed to better routing and information management. MIT’s documented outsourcing elimination — worth $2–10 million annually in the cases examined — came substantially from this function.
What it breaks on. Knowledge base quality. A support assistant is only as good as what it retrieves, and most organisations discover mid-build that their internal documentation is contradictory, outdated, or scattered. The second failure point is autonomy: teams that let the system send customer-facing responses without review usually roll that back within weeks.
Related capability: AI agent development
2. Document and knowledge processing
Type: generative, retrieval-based
What it does. Extracts structured data from unstructured documents, classifies and routes them, summarises long material, and answers questions against internal document sets with sources attached.
The evidence. The other half of MIT’s documented outsourcing elimination. This is also where retrieval-based systems have the strongest track record, because the correctness criterion is explicit — the answer either matches a source document or it does not. That makes it one of the few generative categories where evaluation is nearly as tractable as it is for predictive work.
What it breaks on. Data preparation, which for document-heavy use cases frequently exceeds the build cost. Gartner’s Q3 2024 survey of 248 data management leaders found 63% either lacked the right data management practices for AI or were unsure whether they had them, and Gartner predicted that through 2026 organisations would abandon 60% of AI projects unsupported by AI-ready data.
Related capability: Generative AI development
3. Recruitment and HR operations
Type: generative extraction plus scoring
What it does. Screens applications in bulk, scores candidates against role requirements, extracts and normalises information from CVs in inconsistent formats, and routes shortlists into the existing HR system.
The evidence. A textbook version of the pattern above — high volume, a clear baseline in hours and cost per hire, and a human making the final decision. CodeIT built exactly this for its own recruiters: a Python application with an integrated language model, connected to the HRM platform so CVs arrive automatically rather than being imported by hand. It analyses each application against job requirements, scores it using a custom formula weighted towards technical skill match, and returns a per-requirement breakdown with reasoning for each score.
The published results: a 30% reduction in cost-per-hire and a 90% reduction in resume review time. A team of three delivered it — a Python developer, a business analyst, and a UI/UX designer.
Two details are worth borrowing. The scoring returns reasoning per criterion rather than a single opaque number, which is what makes recruiters willing to act on it. And the integration removes manual CV import entirely, which mattered more than the scoring itself — the original problem was as much about isolated systems as about review time.
What it breaks on. Bias exposure and regulatory scrutiny. Automated screening sits in a regulated area in several jurisdictions, and a scoring system that cannot explain itself per criterion is difficult to defend. Systems that surface reasoning survive review; systems that emit a number do not.
4. Forecasting, anomaly detection, and classification
Type: predictive — validatable against history
What it does. Demand and capacity forecasting, churn and risk scoring, fraud and anomaly detection, quality inspection, predictive maintenance, lead and transaction classification.
The evidence. This family has the longest operational history in enterprise settings, and a structural advantage the generative categories lack: you can backtest. Before building anything, you can take last year’s data, run a candidate model against it, and compare the prediction to what actually happened. The accuracy question is answered before the budget is committed rather than after.
That does not make these projects easy — RAND’s 2024 study of AI and machine learning project failure, based on interviews with 65 practitioners, found the leading root cause was stakeholders misunderstanding or miscommunicating the problem, which applies equally here. But it removes the single largest unknown that generative projects carry into their build.
What it breaks on. Data history and drift. Backtesting requires enough clean history to be meaningful, and models degrade as the underlying patterns change — which means monitoring and retraining are not optional extras but part of the running cost. A forecasting model with no retraining plan has a shelf life measured in months.
Related capabilities: Machine learning · Predictive analytics
5. Finance, risk, and compliance operations
Type: mixed — classification with generative drafting
What it does. Pre-checks transactions and documents against rules, drafts first-pass risk assessments, reconciles records across systems, and flags exceptions for human review.
The evidence. MIT documented roughly $1 million a year saved on outsourced risk checks at a single financial services firm. The economics are unusually clean because the alternative is often an external contract rather than internal headcount, which means the saving appears in the ledger as a line that used to exist and now does not.
What it breaks on. Accuracy thresholds. Most operational processes tolerate a small error rate; compliance processes frequently do not. If the accuracy the business requires exceeds what current models reach on your data, no amount of engineering closes the gap — and discovering that in week six of a proof of concept is a far better outcome than discovering it in month fourteen.
6. Software engineering
Type: generative
What it does. Generates and reviews code, writes tests, drafts documentation, and increasingly executes multi-step changes with limited supervision.
The evidence. The strongest adoption numbers of any category, and the clearest cost warning. Uber rolled agentic coding tools across its engineering organisation in December 2025; adoption climbed from 32% to 84% of roughly 5,000 engineers by March 2026, with around 70% of committed code AI-generated and 11% of backend updates written by fully autonomous agents. By April, the entire 2026 AI budget was gone.
What it breaks on. Consumption cost, and attribution. Uber’s chief operating officer said publicly that increased token consumption was not translating into proportionally more shipped features: “That link is not there yet.” Bain reported in June 2026 that token costs halved between December 2024 and December 2025 while consumption grew 450% — falling unit prices invite heavier usage rather than reducing spend. The FinOps Foundation’s 2026 survey of 1,192 practitioners found 73% of organisations exceeded their original AI cost projections. Budget this one with caps and monitoring from day one.
7. Security operations
Type: mixed — anomaly detection with generative summarisation
What it does. Triages alerts, correlates signals across tools, drafts incident summaries, and accelerates investigation.
The evidence. Google Cloud reports a 70% reduction in breach risk and 50% faster mean time to respond. Treat the first figure carefully — breach risk is not directly observable, since you cannot count incidents that did not happen, so it is an executive assessment rather than a measurement. The mean-time-to-respond figure is the more verifiable of the two.
What it breaks on. Review capacity, paradoxically. S&P Global’s 2026 data ranks cybersecurity as the most acute skills shortage affecting AI initiatives, at 64% reporting moderate or severe impact — ahead of machine learning and AI development at 59%. The team that would run a security AI initiative is often the same team already blocking everyone else’s.
Related capability: Security assessment
8. Sales and marketing
Type: generative
What it does. Drafts and personalises content, qualifies and enriches leads, prepares call materials, optimises campaigns.
The evidence. Real but smaller than the category’s budget share implies. Google Cloud reports 32% quicker content editing and 46% faster content creation. MIT found around 40% faster lead qualification and a 10% improvement in retention, alongside a 30% reduction in external creative and content spend — which is, notably, the back-office-shaped part of the marketing use case.
What it breaks on. Attribution, and the fact that this category attracts roughly half of all generative AI budget on the strength of metrics that look attributable rather than metrics that are. If a marketing AI case is worth building, it is usually worth building for the external spend it removes rather than the pipeline it promises.
The industry dimension
Function determines feasibility. Industry determines constraints.
The same document-processing use case is straightforward in e-commerce and heavily constrained in healthcare, not because the technology differs but because the data cannot leave certain systems, the audit requirements are stricter, and the acceptable error rate is lower. That is a scoping question, not a capability one.
Three things change by sector, and all three belong in the business case rather than in the use case selection:
- Where data is allowed to go. Regulated sectors frequently rule out third-party model APIs entirely, which removes most off-the-shelf products from consideration before evaluation begins.
- The accuracy threshold. A 5% error rate is unremarkable in marketing content and disqualifying in clinical or financial contexts.
- What evidence an auditor will accept. Some sectors need the decision trail, not just the decision.
CodeIT’s sector work spans fintech, healthcare, logistics, and manufacturing, among others — and in practice the sector shapes the architecture far more than it shapes which use case is worth doing first.
What this article does not cover
Three categories are deliberately excluded.
Consumer-facing AI products. Building AI into a product you sell is a different discipline from applying it to your own operations, with different economics and a different risk profile.
Industry-specific use cases. Clinical decision support, algorithmic trading, autonomous driving and their equivalents each require domain treatment that a general article cannot give responsibly.
Anything without documented production evidence. Several widely promoted categories — fully autonomous multi-agent operations, AI-run decision-making without human review — appear in most use case lists and in very few production environments. S&P Global found only 22% of AI projects target a fully autonomous end state at all.
When not to build
The most useful thing a use case review produces is sometimes a decision not to proceed. Four signals, any one of which should stop a candidate before the build:
The required accuracy is above what current models reach on your data. This is RAND’s fifth root cause of AI project failure — the problem is genuinely too difficult — and it is the one most often discovered late. A week of testing against sample data answers it.
The process is unstable. Automating a process that changes every quarter means rebuilding every quarter. Fix the process first, or pick a different one.
No one can name the data owner. Not “the data is in Salesforce” — a person who can approve access and answer quality questions. Initiatives without one stall at exactly the point where momentum matters most.
The saving is entirely reallocated time, with no plan for the time. Freed hours become money only when headcount changes or the capacity is visibly redeployed. Otherwise the business case will not survive its first review by finance.
Scoring candidates against each other
Ranking is the hard part. Most organisations have thirty plausible candidates and no agreed order. A simple scoring matrix, applied consistently, resolves most of the argument.
Score each candidate 0–2 on six dimensions and compare totals.
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Baseline | No current measurement exists | Measurable with effort | Finance already reports it |
| Spend type | Internal time only | Mixed | External contract attached |
| Validatability | Generative, evaluation to be designed | Generative with explicit source-matching | Predictive, backtestable against history |
| Data readiness | Owner unknown or access blocked | Owner known, quality untested | Owner named, quality tested for this decision |
| Accuracy headroom | Requirement above current capability | Close to the threshold | Comfortable margin |
| Review design | Output must be trusted wholesale | Spot-checkable | Verifiable per item, with reasoning shown |
10–12: fund it. 7–9: scope a proof of concept to close the specific gap. Below 7: the constraint is upstream of engineering and more delivery capacity will not fix it.
The third row is the one most lists omit, and it is frequently the tiebreaker between two otherwise similar candidates.
Score your shortlist against your actual data
What the sequence looks like in practice
The pattern that works is narrow and unglamorous: pick one process with a measurable current cost, prove it, then reuse the data and integration work on the adjacent process.
The FMCG support automation CodeIT delivered followed that shape — infrastructure assessed, case volumes and request types mapped, then a platform configured rather than a system built from scratch, producing 50–65% of support cases automated, response times 25–35% faster, and support costs down 20–30%. Full write-up: AI support automation for a global FMCG company
The recruitment tool followed it at a much smaller scale, inside CodeIT’s own operations. Both started from a process where someone could already say what it cost — which is the only thing the two engagements have in common, and the thing that mattered.
Where the answer is to build rather than configure, that work sits with custom AI development. Organisations that want an outside read on the ranking, particularly where internal teams disagree about sequencing, often bring in AI advisory services for the prioritisation rather than the whole programme.
FAQ
Customer support and service, document and knowledge processing, recruitment and HR operations, forecasting and anomaly detection, finance and compliance operations, software engineering, security operations, and sales and marketing. The back-office categories have the strongest documented production results, largely because baselines are measurable and external spend is often attached.
Those that remove external spend rather than internal time. MIT’s 2025 research documented business process outsourcing elimination worth $2–10 million annually in customer service and document processing, a 30% cut in external creative spend, and roughly $1 million a year saved on outsourced risk checks at a financial services firm. Gains came without material workforce reduction.
Predictive, where the two look equally valuable. A forecasting or scoring model can be backtested against last year’s data before anything is built, which answers the accuracy question for the cost of an analyst’s time. Generative use cases have no historical ground truth to test against, so evaluation has to be constructed and the accuracy question stays open until the build is underway.
Because the constraint is rarely the model. MIT found only about 5% of task-specific enterprise AI tools reached production, with failures tracing to unclear problem definition, data that was not ready, absent production infrastructure, and adoption designs that assumed unquestioning users. RAND’s interviews with 65 practitioners identified misunderstanding the problem as the leading root cause.
Back office, in most cases. Roughly half of generative AI budget goes to sales and marketing while the documented returns concentrate in back-office automation — a gap that exists because sales metrics are easier to attribute, not because the value is greater. Back-office processes also tend to carry external contracts, which makes the saving visible in the ledger.
Less than most business cases assume. S&P Global found only 22% of AI projects target a fully autonomous end state; the majority sit at minimal autonomy where AI recommends and a person decides. Trust in AI outputs has declined since 2023 rather than grown, so systems designed for a sceptical user with verifiable output tend to survive adoption while systems designed for unquestioning acceptance do not.
Score each candidate on six dimensions: whether a baseline exists, whether external spend is attached, whether the approach can be validated before building, whether data ownership and quality are established, whether the required accuracy is within reach, and whether the reviewer can verify output per item. Candidates scoring low on the first two are not bad ideas — they are ideas that will be hard to prove.
When the required accuracy exceeds what current models reach on your data, when the underlying process changes too often to be worth automating, when no individual can be named as the data owner, or when the entire saving is reallocated time with no plan for redeploying it. Any one of those is sufficient to stop a candidate before the build.

