Enterprise Generative AI Use Cases That Reach Production, Grouped by What Each One Needs

Enterprise generative AI use cases reach production when their prerequisite already exists, not when the model improves. Three prerequisites decide it: clean documents with governed retrieval, system access with approval steps, and governed data for natural-language query. Most such use cases sit in the EU AI Act's minimal or transparency tiers; hiring and credit decisions do not.

Use of AI in UK business has roughly tripled in under three years. The Office for National Statistics reported in July 2026 that self-reported AI use among UK businesses with 10 or more employees rose from around 12% in late 2023 to around 35%. Large language models were the most widely used technology, at 18% of those businesses in June 2026.

The same ONS analysis shows how shallow that adoption still is: the average number of AI technologies used by each adopting business rose only from around 1.4 to around 1.6 over the period. The Bank of England and FCA survey of UK financial services, published in November 2024, found 75% of firms already using AI, yet foundation models made up only 17% of all AI use cases, and 56% of AI-using firms reported ten or fewer use cases.

Use-case lists are usually sorted by department, which makes them easy to write and hard to fund from: two use cases in one department can need entirely different foundations. What follows groups them by what each needs to reach production, where each fails, and its likely regulatory tier.

#What Counts as a Production Use Case

A use case is in production when a named team relies on its output to do its job, and someone would notice within a day if it stopped. A demo that impressed a steering committee does not count.

Three properties mark the difference. The use case has an owner who answers for its output and funds its running cost. It has an evaluation set, a fixed collection of representative questions or tasks with agreed correct answers, that is rerun whenever the model, the prompt or the source data changes. And it sits inside a workflow, so its output lands in a ticket, a document or a decision rather than in a chat window that nobody revisits.

Generative AI here means models that produce text, code or images from an instruction, usually large language models called through an API. Enterprise use cases pair such a model with the organisation's own content or systems, and that pairing is where the prerequisites come from.

#The Use Cases at a Glance

What this means for you: read the final column first; it tells you which use case your estate can support today.

The tier column is the likely EU AI Act classification for a typical deployment; the tier follows the purpose, not the model.

Six of the eight rows sit in the minimal-risk tier, so for most of the list the binding constraint is the prerequisite, not the regulator.

#Use Cases That Need Clean Documents and Retrieval

What this means for you: if your documents are duplicated, out of date or locked in personal drives, fix that before funding any use case in this group.

These use cases answer questions from the organisation's own text, using retrieval-augmented generation, in which the system finds the relevant passages first and the model writes an answer grounded in them. A vector database usually finds those passages by meaning rather than keyword.

#Knowledge assistants for policy and procedure

An assistant that answers staff questions about HR policy, IT procedures or product documentation is where most shortlists start. It fails when two versions of the same policy sit in the index and the assistant quotes the superseded one with full confidence. Staff stop trusting it after the first wrong answer they catch.

The prerequisite is a document collection with an owner, a retirement process for old versions and access controls that the retrieval layer respects. Without the last, the assistant can surface a salary band or a disciplinary note to someone who should not see it.

A retrieval system is only as current as the least maintained folder it indexes.

#Contract review and document extraction

Extracting clauses, dates and obligations from contracts or filings pays back where a reviewer already works from a checklist: the model fills it, the reviewer checks it. It fails on scanned documents with poor optical character recognition, and on documents whose meaning depends on relationships between clauses rather than on any single passage. That second failure is where graph-based retrieval earns its cost, and semantic AI and knowledge graph work is the usual fix.

#Customer service reply drafting

Drafting replies for a human agent to edit works because a person checks every output before a customer sees it. Sent without review, a wrong draft becomes a commitment made on the company's behalf, and a system that talks directly to customers carries transparency duties under the EU AI Act.

The next group needs more than read access. It needs permission to change something.

#Use Cases That Need System Access With Approval Steps

What this means for you: these use cases pay back faster than document assistants, but only where the systems they touch expose documented interfaces and a person approves consequential actions.

These use cases read a ticket, look up an account, draft a fix and propose an action in another system. That makes them closer to agentic AI systems than to chat, and the engineering effort sits in the interfaces and the approval steps rather than in the model.

#Service-desk triage and resolution

Classifying incoming requests, gathering the context a resolver needs and proposing a resolution suits request types such as access requests and known-error fixes. It fails when the ticketing or identity system has no reliable API, so the model ends up guessing at the state of a system it cannot read.

#Code assistance and legacy migration

Generating tests, explaining unfamiliar code and translating legacy code into a modern language rest on a prerequisite many engineering teams already have: automated tests and peer review on every change. Without those gates, generated code adds defects faster than the team can find them.

#Finance operations exceptions

Investigating an unmatched payment and drafting the correcting entry for approval suits generative AI: each exception differs, but the definition of resolved does not. It fails when exceptions are resolved informally by email, because there is no history to evaluate against.

The approval step is not a brake on the use case; it is what makes the business willing to switch it on.

How much authority to hand over, and when, is a separate question, set out in our piece on what it takes to trust an agent to act. The way multi-step tasks are broken down and checked is covered in the guide to orchestration patterns for multi-step LLM work.

#Use Cases That Need Governed Data for Natural-Language Query

What this means for you: if two departments report different revenue figures today, a natural-language interface will give each of them a confident third answer.

Asking a question of business data in plain English and getting a chart back is a popular request that is hard to deliver. The model is not the hard part; it can write SQL. The hard part is that "revenue", "active customer" and "headcount" each have several defensible definitions in most enterprises, and the model has no way to know which one the questioner means.

The use case reaches production when the model queries a semantic layer, a governed set of metric and entity definitions, rather than raw tables. The model then chooses between named, owned metrics instead of inventing joins. Scope it to one domain, and evaluate it against questions whose answers finance has already signed off.

The same prerequisite supports drafting management commentary around a set of figures. Where the figures come from a governed source, the reviewer checks only the prose; otherwise the reviewer checks everything, and the saving disappears.

#Use Cases That Rarely Survive a Pilot

What this means for you: if your shortlist contains any of these, expect a strong demo and a weak business case unless the underlying condition changes.

Some use cases fail for reasons a pilot is not designed to surface: the demo uses a clean sample, a forgiving audience and no running cost.

The common thread is that none has a natural place for a human check, or the check costs as much as the work it replaces.

#Where Regulation Changes the Order of the List

What this means for you: for most of your shortlist the regulation sets disclosure and record-keeping duties; for people and credit decisions it can decide whether the use case is worth starting.

The EU AI Act sorts AI systems into four tiers by risk: unacceptable, high, transparency and minimal. The European Commission states that the Act does not introduce rules for AI deemed minimal or no risk, which covers most internal drafting, search and coding assistants.

High-risk use cases are listed in Annex III. The Commission's own examples include CV-sorting software for recruitment and credit scoring that can deny a citizen a loan. Article 6(3) lets an Annex III system fall outside the high-risk tier where it performs a narrow procedural task and does not materially influence the outcome of a decision, but the same article states that an Annex III system which profiles natural persons is always high-risk. A tool that ranks job candidates profiles them, so it stays in the high-risk tier.

Article 50 adds transparency duties for systems intended to interact directly with people and for AI-generated text published to inform the public, so a customer-facing assistant has to make clear that the customer is talking to a machine.

#Dates and reach

According to the Commission, the Act became applicable on 2 August 2026, with exceptions. Following the AI Omnibus amendment, which entered into force on 27 July 2026, the high-risk rules for Annex III use cases apply from 2 December 2027. Under Article 2(1)(c), the Act reaches providers and deployers established outside the EU where the output of their AI system is used in the Union, which brings many UK businesses into scope.

In the UK there is no single AI statute. UK GDPR Articles 22A to 22D, inserted by the Data (Use and Access) Act 2025 and in force since 5 February 2026, set the conditions for significant decisions based solely on automated processing. Government guidance lists the safeguards: telling people about such decisions, letting them make representations and challenge the outcome, and letting them obtain human intervention.

The roles and gates that satisfy these duties are set out in our GenAI governance operating model.

#When a Generative AI Use Case Is the Wrong Investment

What this means for you: before funding any use case on the list, check whether a cheaper tool would do the same job.

Generative AI is the wrong choice in four common situations. The first is a task with a fixed sequence of steps and structured inputs, which a rules engine or workflow tool handles more cheaply and with a self-explanatory audit trail.

The second is a task where the answer has to be exactly right every time and there is no affordable review step, such as calculating a payment or a tax figure. A language model can help write the code that does the calculation; it should not be the calculation.

The third is a process that runs a few dozen times a month, too rarely to repay an evaluation set, monitoring and an owner. The fourth is a use case nobody will own after launch. If no team will fund the running cost and answer for the output, the pilot is the whole project.

#How to Choose the First Use Case to Fund

The first production use case does not require a platform programme. It requires one use case whose prerequisite already exists, or can be built for a narrow scope in weeks rather than quarters.

Sort the shortlist into the three prerequisite groups using the table above. For each candidate, ask whether its prerequisite exists today for one specific scope: one document collection, one system, one data domain. Defer anything whose prerequisite cannot be built for that scope within a quarter.

From what remains, choose the candidate with a cheap review step and a named owner. Build its evaluation set before its prompt: twenty to fifty real questions or tasks with answers the owner has signed off. It is also the evidence a risk function will ask for.

If several candidates share one missing prerequisite, that prerequisite is the real first project. Broader readiness is the question our agentic AI readiness framework answers, and an AI readiness assessment scores the shortlist by feasibility, data readiness and risk before money is committed. A first use case scoped this way typically reaches production in weeks to a quarter; extending the pattern across the organisation is multi-quarter work.

#Frequently Asked Questions

#What are the main enterprise use cases for generative AI?

The main candidates are internal knowledge assistants for policy and procedure, contract and document review, drafting replies for customer service agents, service-desk triage, code assistance, finance exception handling and natural-language query over business data. Each depends on a different foundation: clean, governed documents; documented system interfaces with approval steps; or agreed metric definitions. The foundation, more than the model, decides which reach production.

#Which generative AI use cases are high-risk under the EU AI Act?

Use cases listed in Annex III of the EU AI Act are high-risk, including AI used in recruitment and worker management, such as CV sorting, and credit scoring for individuals. An Annex III system that profiles people is always high-risk. Most internal drafting, search and coding assistants are minimal risk, while systems that interact directly with people carry transparency duties requiring them to disclose that the user is dealing with AI.

#Why do generative AI pilots fail to reach production?

Most pilots stall because a prerequisite is missing rather than because the model is weak. Common gaps are outdated or duplicated documents behind a knowledge assistant, systems without reliable interfaces for an assistant to act through, and disputed metric definitions behind a data query tool. Pilots also stall when no team owns the use case after launch, or when nobody built an evaluation set to prove it works.

#How long does an enterprise generative AI use case take to deliver?

A narrowly scoped use case, such as an assistant for one document collection and one user group, can reach production in weeks where its prerequisite already exists. Use cases that need new system interfaces or agreed metric definitions typically take one to two quarters for a first scope. Extending any use case across an organisation is multi-quarter work, because each new scope brings its own data and approvals.

#Do UK rules restrict generative AI used in automated decisions?

Yes, where the decision is significant and made solely by automated means. UK GDPR Articles 22A to 22D, inserted by the Data (Use and Access) Act 2025 and in force since 5 February 2026, require safeguards: informing people about such decisions, letting them make representations and contest the outcome, and providing human intervention. Drafting and search assistants that support a human decision maker generally fall outside these rules.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing which generative AI use case to fund first, book a discovery call and we will work through it with you.