How to prioritize AI use cases before starting a pilot

1. Turn every idea into the same one-page candidate card

Describe each candidate as a change to real work: who has a problem, what happens today, what the AI-assisted step would do and what result should improve. “Use an AI agent” is not a candidate. “Draft a reply from approved service information for an employee to review” is specific enough to compare with alternatives.

Add current volume, handling time, common exceptions, affected users, required systems and the person accountable for the outcome. Google Cloud's official use-case guidance starts with a measurable business goal and explicitly asks whether the expectation needs generative AI, another form of AI or no AI at all. Keep that technology question open until the work is clear.

• Problem and affected user, in one sentence.
• Current trigger, steps, output and process owner.
• Expected change and two possible success measures.
• AI, ordinary automation and process-only alternatives.

2. Apply stop conditions before calculating a total

A high value estimate must not cancel an unresolved legal, safety or data problem. Pause a candidate if its purpose is unclear, no one owns the decision, representative inputs are unavailable, important outputs cannot be checked, or the pilot would process data without an approved basis and access boundary. These are research tasks, not points to hide in an average.

The European Commission describes the AI Act as risk-based and lists employment uses such as CV sorting among high-risk examples. It also identifies transparency duties for certain interactions such as chatbots. Classification depends on the concrete system and context, so a scorecard is not a legal assessment. It should flag uses involving employment, essential services, safety, biometrics or consequential decisions for specialist review before a pilot proceeds.

• Is the intended purpose and accountable owner explicit?
• Can the team test with representative, permitted data?
• Can a person detect and correct an important failure?
• Does the context require legal, security or domain review first?

3. Score business value and measurability separately

Rate business value from 1 to 5 using evidence from the current process. A high score needs a material problem: frequent manual effort, costly delay, repeated corrections, missed capacity or a documented customer need. Strategic excitement without an operational baseline is not a five. Write the reason beside the number so another manager can challenge it.

Then score measurability. Ask whether the pilot can compare a defined sample with today's method using two or three measures such as handling time, substantial-revision rate, correctly routed cases or unresolved exceptions. Microsoft’s business-envisioning guidance compares strategic fit and business impact with user desirability and technical feasibility. Keeping value and measurability separate prevents a large but vague ambition from outranking a smaller problem the team can actually test.

4. Score process, data and integration readiness

Process readiness is high when the trigger, expected output, ordinary path and exceptions are understood. It is low when employees use conflicting rules or the requested result changes by reviewer. Fixing the workflow may be the first project; an AI layer will not make an undefined process stable.

Data and integration readiness cover more than the existence of files. Check whether representative examples may be used, the required knowledge is current, identifiers match, systems expose a supported interface and results can return to the workflow. Record external service costs, access limits and the person who will maintain instructions and data after launch. A demo that works on copied text but cannot operate within the real process deserves a lower score.

• Stable process and explicit exception path.
• Representative inputs with known quality and permission.
• Supported access to the required systems.
• Named owner for operation, monitoring and updates.

5. Score adoption and risk without treating them as opposites

Adoption is not the number of employees who say an idea sounds interesting. Ask whether the people doing the work helped define the problem, can review the output in their normal tools, understand what remains their responsibility and have time to report errors. A technically strong assistant that adds another inbox or an unclear approval step may create more work than it removes.

Risk scoring should describe the consequence and detectability of a bad output, the sensitivity of data, affected people, possible misuse and dependency on third parties. NIST's AI Risk Management Framework playbook asks organisations to document intended purpose, users, context, impacts, system limits and human oversight. Use those questions to reduce risk or narrow scope, not merely to attach a warning label to an unchanged proposal.

6. Make a portfolio decision, not just a ranking

Use a simple 1-to-5 scale with written anchors agreed before scoring. A practical comparison can show value, measurability, process readiness, data and integration readiness, adoption readiness, and risk. Do not manufacture precision by weighting categories to two decimal places. Discuss large differences between reviewers because they usually reveal an assumption that needs evidence.

Place each candidate into one of four decisions: pilot now, research a missing dependency, redesign the process or stop. For the selected pilot, define the users, sample, data boundary, human review, success threshold, stop conditions, cost ceiling and decision date. Keep the runner-up documented; it may become suitable after the team fixes its data or workflow. This guide supports an initial business review and does not replace technical, legal, security or sector-specific assessment.

• One selected pilot with an owner and bounded scope.
• Written reasons for candidates that are paused or rejected.
• Acceptance threshold and stop conditions before testing.
• Decision after the pilot: stop, revise, expand or choose another use case.