Readiness

Industrial AI Readiness Checklist

A practical checklist for deciding whether one industrial workflow is ready for an AI pilot: ownership, baseline, data, boundary and acceptance.

Last updated 2026-08-03. Free to use and share with attribution.

Use this checklist on one specific workflow, not on the company as a whole. A workflow is ready for an AI pilot when every section below has an answer you could defend in front of the process owner. It is deliberately tool-agnostic: nothing here requires choosing a model or platform first.

1. The decision and its owner

The workflow is written as one sentence: when this event happens, this person decides this action using this evidence.
A named process owner has agreed to sponsor the pilot and supply domain reviewers.
A named production owner will run the system if the pilot succeeds.
The current cost of the problem (delay, error, workload, exposure) is described without assuming AI is the answer.

2. Baseline and success measure

The workflow's current performance is measured using definitions the plant already understands.
The metric that must improve is agreed, with its measurement method written down.
Failure conditions are defined: what result would stop the pilot.
The baseline period is long enough to cover normal variation (shifts, products, seasons).

3. Data and evidence

The records the AI would use actually exist and are retrievable (documents, historian data, images, logs).
The records cover the operating conditions the system must handle, including known edge cases.
Labels or outcomes needed for evaluation are available or can be produced by domain reviewers.
Data quality problems are listed honestly - more rows do not fix missing conditions or inconsistent labels.

4. Boundary and integration

Where data may move and where it may not is documented (site, network zone, cloud tenancy, country).
The systems the pilot must read from - ERP, MES, SCADA, historian, LIMS, document store - are listed with the interface each can lawfully and safely expose.
Write-back to any operational system is explicitly in or out of scope; out is the default.
Identity, access, logging, backup and patching for the pilot environment have named owners.

5. People and fallback

The users who will act on the AI output have been consulted and can attend reviews.
Human review capacity exists for the expected volume of AI output during the pilot.
A safe fallback is defined for when the system is wrong, uncertain or unavailable - usually the existing process.
Safety, quality and regulatory owners have confirmed the pilot does not bypass their authority.

6. Acceptance and what happens next

Pass/fail thresholds per scenario are written before the build starts.
The evaluation set is held out and representative - not the data the system was tuned on.
The decision meeting after the pilot is scheduled, with stop, revise and scale as legitimate outcomes.
Ownership of code, configuration, prompts and evaluation assets after the pilot is stated in the agreement, including third-party licence limits.