Good AI (artificial intelligence) use cases are found, not announced. They come from watching real work, counting where time and errors go, and then asking a narrow question: can a model help here, safely, in a way someone can check? This chapter covers discovery, scoring, the limits of the technology, and the cases where the right answer is not AI at all.
1. Discover from the work, not the tool
Start with the process, not the product brochure. The enablement lead and the team walk the work together and write down where it hurts. Every candidate needs a baseline before it starts, or nobody can show value later.
| Method | What the team does | What it yields | Watch out for |
|---|---|---|---|
| Process walk | Follows one item (a story, a release, a policy question) from start to finish | The steps, the waits, the hand-offs, the rework loops | The documented process is rarely the real one |
| Pain-point log | Each role notes, for two weeks (illustrative), the tasks it finds slow, repetitive or error-prone | A ranked list in the team's own words | Loud pain is not always large pain; check against the baseline |
| Baseline sample | Measures time per task, error rate and rework on a sample of today's work | The "before" number every later claim is measured against | Measure the whole task, including review, not just the drafting step |
| Defect and rework review | Reads recent incidents, rejected changes and reopened tickets | Where quality, not speed, is the real cost | Fix the root cause first; AI may not be the answer |
| Listening sessions | Short, open conversations with each role about their week | Context the log misses: workarounds, fears, ideas | People describe tools they want, not problems they have; ask about the problem |
| Open intake | Anyone can submit an idea on the intake card | A steady pipeline from the edges of the organization | Without triage, intake becomes a wish list |
2. Score value × feasibility × risk
Each candidate gets a value score and a feasibility score from 1 to 5, and a risk tier from intake. Value × feasibility ranks the list. Risk is not multiplied in: it is a gate that sets the controls, the cost, and whether the use case is allowed at all.
- Value: time saved net of review, errors avoided, people affected, strategic weight.
- Feasibility: the data is available and allowed, the output can be checked, an evaluation set can be built, the tool is approved.
- Risk tier: Low, Medium, High or Prohibited, from the tier table in chapter 2.
Six candidates from the running example, plus one that is not an AI problem. The scores are illustrative.
| Candidate use case | Role | Value | Feasibility | Rank score | Risk tier | Decision |
|---|---|---|---|---|---|---|
| Story drafting from a ticket and the team context | BA (business analyst), PO (product owner) | 4 | 5 | 20 | Medium | Start at Stage 1; promote to a reusable prompt at Stage 2. The PO accepts every story |
| Test generation from acceptance criteria | QA (quality assurance) engineer | 4 | 4 | 16 | Medium | Stage 3 pilot with an evaluation set; generated tests land in a PR (pull request) a human reviews |
| Release-notes drafting from merged PRs and the change record | Release manager | 3 | 5 | 15 | Medium | Delegated task; the release manager edits and approves the notes |
| Internal policy assistant for contact-center staff | Contact center, compliance | 4 | 3 | 12 | Medium | Internal decision support: trained staff independently verify each consequential answer before they act or speak to a customer. Build with retrieval, citations and abstention; evaluate before staff use it; never takes an action. Escalates to High if answers reach customers directly or staff use them without verification |
| Live AI generation of customer reminder wording for the due date | Product, compliance | 3 | 4 | 12 | High | AI output would reach customers directly. Prefer the safer design: AI drafts variants offline, compliance approves one fixed template, no live generation per customer |
| Automated hardship decisions | Collections | 5 | 3 | 15 | Prohibited | Stop. A fully automated adverse customer decision is not allowed at any stage |
| Due-date conversion for display | Developer | 4 | 5 | 20 | Not AI | Use shared-datetime; the rule is deterministic and belongs in code |
Two rows show why risk is a gate. Automated hardship decisions rank above the policy assistant on value × feasibility, and still stop. Reminder wording ranks the same as the policy assistant, and needs far more controls.
3. Limitations and fit
A model is a useful but unusual component. It is non-deterministic, it knows only what it was given, and people tend to trust it too much. A good use case is one where these limits are designed for, not discovered.
| Limitation | What it means | Design response | In this example |
|---|---|---|---|
| Non-determinism | The same input can produce different output | Keep the output as a reviewable draft; test with an evaluation set, not one demo | Story drafting gives different wording each run; the acceptance criteria are what the PO checks |
| Grounding limits | The model answers from its context, and fills gaps with plausible text | Retrieve approved sources; require citations; abstain when no source supports the answer | The policy assistant cites the policy section or says "I don't know" |
| Freshness | The model and its sources can be out of date | Date every source; re-index on policy change; show the source date to the user | A policy updated on Monday must not be answered from last month's copy |
| Tool errors | A tool call can fail, time out or return the wrong record | Validate tool output; make actions idempotent; fail closed on consequential steps | A failed catalog lookup must not be read as "no asset exists" |
| Automation bias | Reviewers approve what the machine suggests, especially when busy | Show evidence with each draft; sample reviews; track override and rejection rates | A QA engineer who approves every generated test is not reviewing them |
| Context window | The model can hold only so much at once | Give it the right slice: the instructions file, the relevant asset, the ticket | The agent sees the temporal-domain contract, not the whole repository |
4. When not to use AI
Some of the best decisions in an AI program are "no". Saying no early is cheaper than a pilot that never ships.
| Signal | Why AI is the wrong tool | Do this instead |
|---|---|---|
| The rule is deterministic | A rule with one right answer belongs in tested code, not a probabilistic draft | Write or reuse the code; the due date uses shared-datetime |
| The process is broken | Speeding up a bad process gives faster bad results | Redesign first: remove the duplicate approval, the re-keyed data |
| Nobody can check the output | An unchecked draft is an unchecked decision | Wait until an owner and an evaluation method exist |
| The data is not allowed | Restricted data cannot go to a tool that is not approved for it | Use an approved configuration, or drop the use case |
| The use case is prohibited | Some decisions must stay with accountable humans | Stop at intake; record why |
| The volume is tiny | Setup, evaluation and review cost more than the work | Do it by hand, or use a simple template |
5. Write the intake card
Every candidate that survives this chapter becomes an intake card: one page that names the owner, the task, the data, the risk tier, the baseline, the evaluation method and the stage it starts at. Triage reads the card, confirms the tier with the risk partners, and either approves a path or stops it.
| Card field | Filled for test generation |
|---|---|
| Owner | QA lead of the statements team |
| Task | Generate unit and contract tests from acceptance criteria for date display |
| Data | Proprietary source and acceptance criteria; no customer data |
| Risk tier | Medium |
| Baseline | Hours per story spent writing tests, and escaped date defects last quarter (illustrative) |
| Evaluation | An evaluation set of 40 (illustrative) criteria, including DST (daylight saving time) and date-only edge cases |
| Starts at | Stage 3, behind an approval gate; tests land in a PR |
The blank and filled card are in templates. The lifecycle after intake (triage, approval, exception, periodic review, retirement) is in chapter 3.