Enterprise GenAI: choosing the right first use case

Choose a workflow before choosing a model

A first GenAI project should answer a specific operational question: which task will change, who does it today and what will count as a better result? “Give every employee an assistant” is too broad to establish a useful baseline. “Help the service team prepare a sourced answer to a defined class of product questions” is easier to test.

Our recommendation is to shortlist tasks with repeated language or document work, a clear owner and a manageable cost of error. Include the work required to verify the answer. A draft produced in seconds is not an efficiency gain if its reviewer spends longer correcting it than writing from scratch.

Use five questions to screen the shortlist

• Volume: does the task occur often enough to justify building and maintaining a solution?
• Grounding: are approved, current source materials available, with a person responsible for them?
• Verification: can a reviewer distinguish a correct answer from a plausible but wrong one?
• Consequences: what happens if the output is incomplete, outdated or disclosed to the wrong person?
• Ownership: who will review quality, manage changes and decide whether the pilot should expand?

Keep the first architecture proportionate

Anthropic distinguishes predefined workflows from agents that decide how to use tools, and advises starting with simpler approaches where they are sufficient. That distinction matters when the business process already has a known sequence. See Anthropic’s guidance on effective agents.

For a first knowledge workflow, consider a read-only assistant that drafts answers with source references. Introduce actions such as updating customer records only after the read-only stage has demonstrated useful results and the approval process is defined. Permissions and logs belong in the initial scope, not a later clean-up project.

Run a pilot that can change your decision

Create a test set containing routine cases, exceptions and questions the system should decline to answer. Hold some cases back from development. Compare the existing process and the assisted process on completion time, reviewer corrections and unacceptable errors.

For example, a support team could test one product family with a fixed set of approved manuals. The pilot report should explain where retrieval failed, where source material was ambiguous and where the model added unsupported detail. Those findings guide the next investment more reliably than a polished demonstration.

Agree the expansion gate

Before starting, define the evidence required to expand, revise or stop. Include a quality threshold, an owner for unresolved errors and an operating-cost estimate at expected volume. Avoid treating adoption alone as success: frequent use can coexist with poor answers.

Begin with one team and one accountable workflow owner. A successful first project should leave behind an evaluation set, a maintainable source collection and a clear decision about what comes next.