Which Tasks Are Actually Generative AI Tasks? A Practical Sorting Guide

"Generative AI" has become the label for every AI task, which makes it hard to answer a simple question: which tasks are actually generative AI tasks, which are something else wearing the label, and which should not involve a language model at all? Getting this right decides whether a project works, because the three kinds need different engineering.

The test

A task is generative when the output is new content produced from a prompt and context, text, code, an image, a structured draft, rather than found or decided. If the correct output already exists somewhere and the job is to locate it, the task is retrieval. If the job is to assign a label or a number, it is classification or prediction. Generative models can be wrapped around both, but that does not make them generative tasks.

Genuinely generative

• Drafting a document from a precedent, a brief or a template
• Summarising long material into a shorter form
• Writing code from a description of intent
• Rewriting for tone, audience, length or language
• Producing structured output, a form, a record, JSON, from unstructured input
• Answering a question in natural language once the right source has been retrieved

The business value in most of these is highest when the generation is grounded. The model produces from your own documents and data, not from general training. Our enterprise knowledge base methodology covers that grounding layer.

Retrieval wearing a generative label

"Chat with your documents" is mostly not generation. It is search and ranking, find the right passages, followed by a short generative step. Projects that treat it as generation skip the retrieval evaluation and then wonder why the bot answers confidently from the wrong source. The same is true of "AI research assistant," "knowledge assistant" and most internal Q&A tools: the hard part, and the part that fails, is retrieval.

Classification and prediction wearing a generative label

Routing a support ticket to the right team. Scoring a lead. Flagging a transaction. Forecasting demand. A language model can do some of these, expensively and inconsistently; a conventional classifier or forecasting model does them cheaply and reproducibly. The generative model's real contribution is usually explaining the decision in plain language afterwards, not making it.

Tasks that should not be generated at all

Deterministic calculations. Exact lookups. And any decision that must be reproducible and explainable: credit, pricing, eligibility, clinical thresholds. A generated number is not an auditable one. Our note on generative AI in fintech draws exactly this boundary for loan pricing: the model explains, the governed logic decides.

A sorting session, as it actually goes

We ran this exercise with an insurance broker last quarter. They arrived with eleven ideas, all labelled AI. Sorted, four were generative: drafting renewal letters from policy data, summarising claim files for adjusters, rewriting broker notes into client-facing language, and generating structured claim records from emailed PDFs. Three were retrieval wearing the label: the internal policy Q&A, the compliance lookup and the product comparison tool were all search problems with a sentence of generation at the end. Three were classification: routing inbound claims, flagging likely fraud and scoring renewal risk, all better served by conventional models with an explanation layer. One should not have involved a model at all: a premium calculation that had to be reproducible to the cent. The exercise took ninety minutes and changed the project plan completely. The first build was the claim file summariser, because it was genuinely generative, high volume and easy to evaluate.

Why the distinction changes the engineering

It is not pedantry. The three kinds fail differently and are fixed differently. A generative task fails by producing something plausible and wrong, so the engineering is grounding, constraints and review. A retrieval task fails by returning the wrong document, so the engineering is chunking, ranking and a recall measurement, and no amount of prompt work fixes bad retrieval. A classification task fails by being inconsistent, so the engineering is a labelled set, a confusion matrix and a threshold. Teams that treat everything as generation end up prompt-tuning their way around retrieval and classification problems, which works in the demo and degrades in production. Sort first, and each part gets the discipline it needs.

What to do with the ones that are not generative

Retrieval and classification tasks are often the more valuable ones, which is why it matters not to dismiss them once the label comes off. A well-built retrieval layer over your own documents is the foundation the generative tasks will need anyway, so it is usually the right first project even when the generative use case is the one leadership is excited about. Classification tasks are cheap to run and easy to measure, and a good routing or scoring model frequently pays back faster than any assistant. The language model still has a role in both: explaining a classification in plain terms, or writing the final answer once retrieval has found the source. That is the pattern in most production systems we build, a pipeline where generation is the last and smallest step.

A quick reference

Created, found or decided. If a person doing the task would write something new, it is generative. If they would go and look something up, it is retrieval. If they would apply a rule or a judgement to reach a label or a number, it is classification. Two edge cases come up often. Translation is generative but tightly constrained, and needs a review step for anything customer-facing. Data extraction from documents is generative in mechanism but classification in spirit, because the output has to match a schema exactly, so it needs validation and a confidence threshold rather than a fluency check. When a task seems to be all three, it usually is, and the job is to draw the pipeline rather than pick a label.

What we would build first, and why

Given a sorted list, we usually recommend the retrieval layer first, then the highest-volume generative task, then classification. The retrieval layer because everything else depends on it and because it has a clean metric, recall on a set of known questions, that can be improved in isolation. The generative task next because it is where the visible value is, and because with retrieval in place it can be grounded rather than guessing. Classification last, not because it matters least, but because it is the easiest to build well once the labelled data has accumulated from the first two. Teams that start with the flashiest generative demo tend to build the retrieval layer afterwards under pressure, and it shows. The order is less exciting. It also ships.

A last word on the label

The word generative is doing a lot of selling at the moment, and it will keep doing so for a while. That is not a reason to avoid it, only a reason to look underneath it. The test in this article takes an hour with your own list, it costs nothing, and it tends to produce a shorter, better-ordered plan than the one you walked in with. Most of the projects that disappointed people in the last two years were not failures of the technology. They were retrieval or classification problems that were built as if they were generation, and evaluated as if they were demos.

Sorting your own list

Write down the candidate tasks. For each, ask: is the correct output created or found or decided? Created. Generative; engineer the prompt, the grounding and the review. Found, retrieval; engineer and evaluate the search. Decided. Classification; use the cheapest model that is consistent, and let the language model explain. Most real projects are a pipeline of all three, and knowing which stage is which is the difference between a system that works and a demo.

Our generative AI development practice builds the generative stages, our LLM integration work handles the retrieval and routing around them, and our guide to using the GPT API in production covers the operational side.