The AI Pilot Checklist.

Ownership

Who is accountable when it is wrong?

One named person is accountable for this workflow's output. Not a committee, not "the AI team".
That person can change or switch it off without booking a meeting.
Someone owns the data it depends on and is answerable for its quality.
When the output is wrong, it is clear whose job it is to notice.

Acceptance criteria

How do you know it is good enough?

You wrote down what "good enough" means before you built it.
There is a test set of real examples with known-right answers.
You measure against that set on every meaningful change, not by feel.
The bar is a number a non-technical stakeholder agreed to.

Failure handling

What happens when it breaks?

You know its top three failure modes and roughly what each one costs.
When confidence is low it has a defined fallback: hand to a human, apply a rule, or refuse.
Failures are logged somewhere a human actually reads.
A bad output cannot silently reach a customer.

Adoption

Will people actually use it?

The people who must use it were involved before launch, not handed it after.
Using it is easier than the old way, not just better in theory.
There is a plan for the week trust breaks, because at some point it will.
Keeping it alive after the launch buzz is explicitly someone's job.

13–16

Dependable.

You have a system, not an experiment. Scale it, and keep the empty boxes on the roadmap.

8–12

Fragile.

It works until it does not. Close the empty boxes before you put more weight on it.

0–7

Still a toy.

Impressive demo, no safety net. Do not put it in front of a customer yet.

From experiment to operating system

Most pilots stall on two or three of these boxes.

That gap is the work: defining ownership, evidence, failure controls and adoption around one valuable workflow until it is dependable. That is what I help leadership teams do.

Explore a governed pilot Send a project brief