The wrong first AI project is usually too broad, too risky or impossible to measure.

“Use AI in sales” is not a use case. “Draft a follow-up after a qualified lead enters the CRM, with human approval before sending” is one.

The UK government's Generative AI Framework recommends selecting cases that meet a clear need, fit the technology and avoid high-risk uses. That is a better starting point than choosing a model first.

Define one unit of work

Describe the trigger, permitted input, expected output, owner, exception and completion event. If these cannot fit on one page, the pilot probably contains several projects.

Use the map of 15 automatable processes to generate candidates, then narrow them with evidence.

Score seven selection factors

Rate each factor with evidence, not enthusiasm. A high-value case with poor data and irreversible consequences is not a good first pilot.

  1. Business value: does the case reduce delay, manual effort, rework or missed revenue?
  2. Frequency: does it occur often enough to produce a meaningful sample?
  3. Data readiness: are inputs digital, permitted, current and representative?
  4. Output clarity: can an accepted result be distinguished from a failure?
  5. Error cost: can a mistake be caught before it affects a customer or decision?
  6. Integration effort: how many systems, permissions and owners are involved?
  7. Reversibility: can the pilot run in draft mode and be stopped safely?

Add gates that cannot be averaged away

NIST's AI Risk Management Framework links context, measurement and risk treatment. A weighted score cannot compensate for a missing owner or an unlawful data source.

  • A named business owner accepts responsibility for the result.
  • The lawful and permitted data boundary is documented.
  • A baseline exists before the AI system runs.
  • A human can review uncertain or high-impact results.
  • Logs and a stop condition exist before external actions.

Reject weak first pilots

  • An autonomous system that sends or publishes externally on day one.
  • A use case whose success is described only as “better” or “smarter.”
  • A decision with legal, medical, employment, credit or safety consequences.
  • A process that is already inconsistent and undocumented.
  • A project requiring broad access to sensitive systems before value is proven.
  • A case chosen only because a vendor demonstrated it.

Design the smallest credible pilot

A pilot should process real examples but limit permissions and consequences. Begin with recommendation, draft or shadow mode.

Specify the sample size, evaluation set, acceptance threshold, exception rate and end date before launch. Compare the result with the previous process.

The distinction between a chatbot, fixed workflow and agent in AI Agent vs Chatbot vs Workflow Automation helps keep autonomy proportional to the task.

Measure the completed outcome

Model latency and token volume are technical metrics. They matter for cost, but they do not prove business value.

  • cycle time per completed case;
  • human minutes per accepted result;
  • acceptance without correction;
  • false routing or extraction errors;
  • exceptions handed to a person;
  • total cost per completed case;
  • incidents and rollback events.

Choose architecture after the case

Use deterministic code for identity, permissions, calculations, limits and writes. Use AI for language, classification, extraction and flexible reasoning where it has been evaluated.

Start with the controlled process described in AI Automation for Small Business, then expand only after measured evidence.

The UK AI Playbook also treats secure, responsible adoption as an organisational task, not just a model configuration.

How I selected a narrow case

For the multilingual blog system, the broad idea “automate publishing” was too risky and vague.

I chose a narrower first case: assemble three language versions, validate SEO fields and HTML, create an API draft and require an explicit publication decision. Editorial judgment and final authority stayed outside the automated step.

That case worked because every handoff was visible, a draft was reversible and all eight technical checks had binary outcomes.

Questions and answers

Should the highest-value use case always go first?

No. The first case should balance value with data readiness, low error cost, clear ownership and reversibility.

How many ideas should be scored?

Enough to compare alternatives. Five to ten specific processes usually reveal a safer pilot than a single executive suggestion.

What is a measurable AI goal?

For example, reduce human minutes per accepted invoice while keeping correction and exception rates below agreed limits.

When is data ready?

When it is permitted, current, representative, accessible and labelled well enough to evaluate the intended output.

When should a pilot stop?

When error, incident, cost or adoption thresholds are breached, or when the baseline comparison shows no business improvement.

Sources