Generative AI earns its keep in a narrow set of jobs: drafting text and code, summarizing long documents, answering questions from your own content, pulling structure out of messy inputs, and producing first-pass images or audio. Each of these works when a wrong output is cheap to catch and a named human owns the final version. Everything else is a research project.
What counts as a generative AI use case?
Generative AI produces new content: text, code, images, audio, structured data. That is different from the AI already sitting inside your accounting software or your ad platform, which mostly scores, ranks, forecasts or classifies. A fraud model that flags a suspicious transaction is not generative. A model that writes the analyst's summary of why the transaction looked odd is.
The distinction matters commercially. Predictive features usually arrive bundled with software you already pay for and need no new governance. Generative features need a decision from you about what the model is allowed to touch, who reviews the output, and what happens when it is confidently wrong. The wider boundary is covered in this guide to what AI automation means for a business.
Which generative AI use cases work by business function?
The use cases that hold up in production cluster around work that is already text-heavy, repetitive in shape but variable in detail, and reviewed by someone before it leaves the building. A workable way to scope this is by function.
| Function | Use case | What it needs from you | Who checks the output |
|---|---|---|---|
| Customer support | Suggested reply drafted in the agent console | Ticket history and current product docs | The agent, before sending |
| Support (self-serve) | Answer bot over your help center | Accurate, deduplicated help articles | Deflection and escalation review weekly |
| Sales | Account research briefs and first-draft outreach | CRM notes and public company information | The rep, before sending |
| Finance and admin | Field extraction from invoices, POs and forms | Document samples and a field schema | Auto-post below a value threshold, human above |
| Engineering | Code suggestions, test scaffolding, migration drafts | Repository access and a real test suite | Code review and automated tests |
| Marketing | Outlines, variant copy, bulk product descriptions | Brand rules and factual product data | An editor who can say no |
| Operations | Free-text requests turned into routed, structured tickets | A defined taxonomy and routing rules | An exception queue for low-confidence cases |
| Legal and compliance | Contract summaries and clause flagging | Contract corpus and a clause checklist | A lawyer, always, on every output |
Notice what is missing. Autonomous decisions about money, medical guidance, hiring outcomes and public statements do not appear, because the cost of one bad output swamps the savings from a thousand good ones.
How much productivity gain should you expect, and from whom?
Expect a moderate average gain that is very unevenly distributed across your team. The largest published field study of generative AI at work, covering 5,179 customer support agents at a Fortune 500 software company, found that access to a generative AI assistant raised issues resolved per hour by about 14 percent on average.
The average hides the finding that should shape your plan. The gain was 34 percent for novice and low-skilled workers and close to zero for experienced, high-performing ones. The authors' explanation is that the model spreads the working habits of the best agents to everyone else. If your team is small and senior, budget for a modest lift. If you are growing headcount or fighting long ramp times, the case is much stronger.
A NBER Digest summary of the same study breaks the 13.8 percent gain into roughly 9 percent less time per chat, about 14 percent more chats handled per hour, and about 1.3 percent more chats resolved, with no significant change in customer satisfaction. That summary describes the low-skill gain as 35 percent, and an ITIF write-up puts it at 38 percent, so read it as a band between 34 and 38 percent rather than a single number.
One caveat carries the weight: the study covers one company in one function in 2023, and it measures assistance inside an agent's workflow rather than a bot answering customers directly, which is a different risk profile entirely.
Which use cases are safe to run without a human check?
Sort every candidate by one question: if the model is wrong, who finds out and how much does it cost? That single test separates the use cases you can ship this quarter from the ones that need months of controls.
- Cheap to catch, contained blast radius. A drafted email the sender reads, a code suggestion that fails a test, a meeting summary the attendees can correct. Ship these fast. The reviewer is already in the loop and costs you nothing extra.
- Cheap to catch, wide blast radius. Bulk product descriptions, marketing variants, translated help content. Errors are visible but they reach customers, so add sampling: review a percentage of output and every item in a sensitive category.
- Expensive to catch. A fabricated policy detail in a customer-facing answer bot, a wrong clause summary in a contract, an invented figure in a board pack. Nobody notices until the damage is done. These need retrieval from a source of truth, citations back to the source document, refusal behavior when the answer is not in the corpus, and a human approving anything consequential.
- Do not automate. Outputs that create legal or clinical obligations, or that determine someone's money, employment or care. Use the model to prepare the material for a human decision, not to make it.
Customer-facing chat sits awkwardly across these tiers. The safer sequencing is to put the generative assistant behind the agent first, and only move it in front of customers once deflection and error rates are boring. The same order applies to any customer-facing chatbot build.
Does the saving survive the human review step?
Often it does not, and this is the failure nobody puts in the pilot report. The arithmetic is simple: the use case pays only if the time to write from scratch exceeds the time to generate, read, verify and fix. When verification requires opening the same three systems the person would have opened anyway, the saving evaporates.
Three signals that review overhead is eating your return: reviewers rewrite more than roughly a third of outputs, verification takes longer than drafting did, or the team quietly stops using the tool, which is the most honest metric you will get.
Design against this from the start. Give the model the same source data the reviewer would check, and make it cite where each claim came from so verification is a glance rather than an investigation. Constrain the output format so errors are visually obvious. Set a confidence threshold that routes uncertain cases straight to a person instead of producing a plausible guess.
Decision rule: run the use case manually for two weeks with a stopwatch on the current process. If you cannot state the current minutes per unit and the current error rate, you cannot tell whether the pilot worked.
How do you govern generative AI use cases?
Use a published framework rather than inventing your own checklist, because auditors, insurers and enterprise buyers recognize the named ones. NIST released NIST AI 600-1, the Generative AI Profile of its AI Risk Management Framework, on July 26, 2024. It is US government issued and exists specifically to identify risks unique to generative systems and suggest actions against them.
The profile is more usable than most governance documents because of its shape: more than 200 suggested actions across twelve risk categories. You do not adopt all of it. You pick the categories that apply to a given use case and lift the actions that make sense at your size. A marketing drafting tool touches a handful of categories. A customer-facing bot with access to account data touches many more.
If you operate in critical infrastructure, NIST released a concept note in April 2026 for a further profile on trustworthy AI in that setting. Regulated sectors get the same use cases with a shorter autonomy leash and a longer audit trail.
Common mistakes when choosing use cases
- Starting with the technology instead of a queue. Pick the function with the longest backlog and the most repetitive text, then ask whether generation helps. Teams that start from "we should use AI" end up with a demo nobody opens.
- Assuming a uniform lift across the team. The evidence says the gain concentrates in less experienced staff. Plan the rollout, the training and the business case around that, and do not promise your best people the headline number.
- Pointing a model at data nobody has cleaned. Retrieval-based use cases inherit the quality of your documents. If your help center has three contradictory refund policies, the model will confidently pick one.
- Skipping the baseline. Without before-numbers you cannot prove the pilot worked, and the project dies at the first budget review.
- Building custom when a vendor checkbox would do. If your CRM or helpdesk already ships the feature, turn it on and measure. Build only when the workflow, the data or the accuracy bar is genuinely yours. When that is the case, our AI development work is usually about wiring models to your own systems and putting real checks around them rather than producing another chat window.
Choose a vendor feature if: the use case is generic, your data already lives in that tool, and an average result is fine. Choose a custom build if: the value depends on your proprietary data, the output feeds another system, or you need audit trails and refusal behavior the vendor does not offer. Fine-tuning is rarely the first answer; better retrieval and clearer prompts fix most quality problems before a training run is justified.
Pick one function from the table, measure how long the task takes today and how often it goes wrong, then run a four-week pilot with a named reviewer. That baseline is worth more than any list of use cases, including this one.