THE DIRECT ANSWER

An AI pilot is ready only when the business can name the work, the owner, the evidence, the limits, and the decision it will make after the test.

A pilot is a business test

The direct answer is simple: do not begin an AI pilot until you can explain what work should improve and what evidence will change your decision. A tool demonstration can be interesting without proving that the business should adopt it.

Treat the pilot as a bounded operating experiment. Give it a clear owner, a real workflow, a start and end, and a decision the company is prepared to make when the evidence arrives.

Define the problem without prescribing AI

Start with the current friction. Work may wait for context, move between too many people, produce inconsistent records, or depend on someone remembering an exception. Write that problem in ordinary language.

This matters because the best correction may be a clearer rule, a smaller form, a better handoff, or simpler software. A responsible pilot is allowed to prove that AI is unnecessary.

Make control part of the design

The person responsible for the outcome needs to know what the system receives, what it produces, and where human review is mandatory. Consequential decisions involving money, safety, employment, privacy, customer commitments, or reputation need explicit authority and escalation.

Also define the manual fallback. If the system becomes unavailable or unreliable, the team should know how work continues and how questionable output is corrected.

Choose evidence before the test

A pilot should measure the operational change it was designed to create. Depending on the work, that might be less time spent gathering context, fewer missed handoffs, faster response, clearer records, or more consistent completion.

Set the measurement and the decision date before the pilot begins. Otherwise the team can move the standard after seeing the result and keep an exciting experiment alive without proving value.

Require three forms of proof

A useful pilot needs more than one attractive output. Check whether the right people adopted the workflow, whether the intended operating outcome improved, and whether a responsible person can inspect the inputs, decisions, exceptions, corrections, and result.

These three proofs prevent a common mistake: calling a pilot successful because the technology ran. Adoption shows that the workflow fits real work. Outcome shows that it mattered. Auditability shows that the business can understand and control what happened.

End with a decision

Every pilot should end in one of four decisions: adopt, revise, pause, or stop. Adoption may still mean a limited rollout with human controls. Revision should name the new hypothesis. A pause should state the missing evidence. Stopping should preserve the lesson.

This discipline keeps AI work connected to operating reality. The goal is not to run more pilots. It is to make better business decisions with evidence.

ORIGINAL WORKSHEET

The eight-question pre-pilot check

Answer these questions in writing before selecting a tool or committing a team. A vague answer is a useful warning: the pilot needs a narrower scope or better evidence.

  1. 01 · WorkWhat recurring piece of work are we improving?Name one workflow or decision, not a department-wide ambition.
  2. 02 · FrictionWhat specifically is slow, inconsistent, or unclear today?Describe the observable problem without assuming AI is the answer.
  3. 03 · OwnerWho is accountable for the result?One role must approve the process and own the outcome.
  4. 04 · InputsWhat information will the system use?List sources, permissions, quality limits, and missing context.
  5. 05 · ControlWhat must a person review or decide?Define approval, escalation, correction, and stop conditions.
  6. 06 · EvidenceWhat change would make the pilot useful?Choose a business measure such as time, misses, clarity, or consistency.
  7. 07 · FailureHow could this create harm or confusion?Name likely failure modes and the manual fallback.
  8. 08 · DecisionWhat will we do when the pilot ends?Set the date and criteria to adopt, revise, pause, or stop.

Original evidence: Tim Yslava’s eight-question pre-pilot checklist, developed from his approved practical-AI operating principles. It uses no customer data or performance claims.

Four takeaways

  • Choose one recurring workflow and describe the current friction.
  • Name one accountable owner and explicit human-control points.
  • Define evidence, failure modes, and a manual fallback before launch.
  • Set the date and criteria to adopt, revise, pause, or stop.

KEEP BUILDING

Read next