Assess evidence, not enthusiasm
A readiness assessment is most useful when a team can point to evidence for its answers. “We have a data platform” does not tell you whether the proposed users can access the right information, whether it is current, or whether the system will respect document permissions.
Use these six dimensions to structure a conversation across operations, technology, data, and risk. Score the proposed workflow rather than the organisation in the abstract. Different use cases can have very different prerequisites.
Open the free interactive readiness tool →
Six questions, suggested next steps, and printable results. No account required.
Six dimensions to examine
1. Strategy and outcomes
Can you name the user, task, business owner, and decision this pilot will support? Ask for a written value hypothesis and a baseline. “Increase productivity” needs to become something measurable, such as total time to prepare a reviewed work package at an agreed level of quality.
2. Data readiness
Can the team legally and operationally use the required source material? Check document ownership, freshness, coverage, and permissions. Ask someone to trace an example answer back to the current approved source. A folder containing many files is not evidence that retrieval will be reliable.
3. People and skills
Who owns the workflow, who can evaluate output quality, and who will support users? Look for allocated time from domain experts as well as engineering capacity. A pilot needs a sponsor able to resolve trade-offs and users able to explain how work actually happens.
4. Platform and architecture
Can the proposed system enforce access, retain the required logs, and fit the operating environment? Compare the simplest available approaches before committing to custom model work. Ask for an architecture sketch that includes identity, source systems, evaluation, and the human review step.
5. Trust, risk, and governance
What happens when the answer is wrong, unsupported, or disclosed to the wrong person? Name the owner for each material risk and the control that addresses it. Require evidence that critical controls work; a policy document alone cannot demonstrate that the implementation enforces access rules.
6. Delivery and change
How will people adopt the workflow, report problems, and fall back to the existing process? Look for a rollout plan, support ownership, agreed evaluation thresholds, and a stop decision. Include the time needed for training and reviewing outputs when estimating benefits.
Use the score as a conversation starter
The interactive tool uses a five-point self-rating for each dimension. Treat the average as a compact summary, not a certification. A strong strategy score cannot compensate for a broken access control or an unacceptable operational risk.
| Rating | What to look for |
|---|---|
| 1 — Nascent | No shared process or evidence for this workflow. |
| 2 — Emerging | Initial experiments or plans; ownership and repeatability remain unclear. |
| 3 — Defined | Named owners, documented practices, and evidence from a bounded pilot. |
| 4 — Advanced | Practices are used consistently, monitored, and reviewed with real users. |
| 5 — Pioneering | The team systematically evaluates and improves its practices across relevant workflows. |
If participants disagree, record the evidence each person is using. Differences between the sponsor’s view and an operator’s experience can reveal the most useful next action.
Turn gaps into a short action plan
Choose the two gaps most likely to prevent a useful pilot. For each, name one action, one owner, the evidence of completion, and a review date. Avoid creating a long improvement programme before understanding what the chosen workflow actually requires.
For example, “improve data quality” becomes “identify the approved maintenance-manual versions for this asset group and confirm who can access them.” “Improve governance” becomes “test that the assistant refuses questions outside the user’s document permissions.”
Use the pilot roadmap and charter to connect these prerequisites to an evaluation plan. The NIST AI Risk Management Framework is a useful reference for broader risk-management work; this self-assessment does not imply NIST approval or certification.