Use an AI readiness checklist

Readiness is practical

An AI readiness checklist is useful when it stops a weak project early and strengthens a good one. The honest prerequisites are modest: a process worth improving, information you can legitimately reach, a person accountable for the result and tolerance for a few rounds of testing. None of these is glamorous. All of them matter more than an impressive demonstration.

A care provider may want faster incident summaries. A wholesaler may want to handle product enquiries more consistently. Both could be good candidates, but only if the underlying work is understood and somebody can decide whether an output is acceptable. If the answer is “we will know it when we see it”, do more discovery before buying a tool or asking a developer to build one.

Use this assessment alongside a build-or-buy decision. Readiness tells you whether to start; it does not assume that custom development is the destination.

Check the process first

Undocumented processes are the most common blocker. AI can cope with variation, but it cannot rescue a task where every person follows a different unwritten rule and no one has authority to decide the right version. Map the process before you automate or assist it: trigger, inputs, hand-offs, exceptions, decision points, systems used, output and the person accountable for quality.

Do not select a process just because it is annoying. Prioritise work that happens often enough to learn from, has a recognisable start and finish, creates avoidable delay or inconsistency, and has errors that people can spot. The best first project is usually a bounded step in a wider workflow, not the whole workflow.

• The process has a named owner who can make decisions about it.
• The current way of working can be described and observed.
• Exceptions are known well enough to test, not merely remembered by one experienced employee.
• A human can review results and decide what “good enough” means.
• The work is important enough to improve, but not so critical that a small pilot would create unacceptable risk.

Be specific about data

“We have lots of data” is not a readiness answer. Ask where the documents and records live, who owns them, how current they are, what format they are in, who can access them and what permissions follow them. A shared drive of scanned PDFs, duplicated spreadsheets and retired templates can still be useful, but it is not the same as a clean source of truth.

Look for practical friction: customer names typed three ways, reference numbers missing, folders open to everyone, information locked in inboxes, data stored in a supplier system you cannot export from, or policies that exist in five competing versions. An AI project may expose these weaknesses; it should not quietly copy them into a new layer of technology.

Permissions are part of readiness

A system that can search internal information will usually respect the permissions it is given. That makes permission hygiene an operational issue, not an IT tidy-up. Review who can see sensitive folders, whether former staff accounts are removed, which shared mailboxes are open and whether managers understand the difference between convenient access and justified access. Shadow AI risk is often a useful signal that these foundations need attention.

Prepare people and governance

Every first project needs a sponsor who can clear obstacles, a process owner who knows the work, a technical or supplier contact, and users willing to test honestly. You do not need a data-science department. You do need enough time in diaries to review examples, explain exceptions and decide when the output is not good enough. Treat user feedback as part of the work, not an optional extra.

Governance begins with a few basics: an approved tool or route, data boundaries, human responsibility for outputs, an escalation path and a record of what was approved. If personal data or a decision affecting people is involved, bring the relevant privacy, HR, security or sector owner in early. A short AI policy provides the everyday rules that prevent a pilot becoming an uncontrolled workaround.

Build capability around real work. A short session using the team’s own low-risk examples, including how to verify an answer and report a concern, is more valuable than a generic presentation about prompting. AI education for business teams should give people judgement as well as techniques.

Size the first project honestly

Commercial readiness means being able to describe why a first project is worth doing and what you will learn if it does not scale. Start with a bounded scope, a named group of users, a realistic period for testing and a decision point. Avoid a vague target such as “improve productivity”. Define the current task, the expected change, the quality threshold and the cost of a bad result.

Include costs that are easy to miss: staff time, data preparation, integration, security review, licences, training, support and maintenance. The purpose of a first project is not to prove that AI is good. It is to establish whether a particular use is useful enough, safe enough and supportable enough to continue. An initial AI consulting assessment can help turn that into a credible scope.

If the project cannot name an owner, a user group, a quality check and a stop decision, it is not a pilot yet. It is a hope.

Score your starting position

Score each statement below as 0 for no, 1 for partly or unclear, and 2 for yes. The number is not a certificate. It is a prompt for an honest conversation about where the first project would break.

A score of 34 or more suggests you can scope a small pilot. Between 22 and 33 means start only after addressing the weak category. Below 22 is a useful not yet, not a failure. Do not force a project through. Map the process, clean and locate the relevant information, assign ownership, fix permissions, document the data rules and run a low-risk learning exercise. Those steps are productive work in their own right and make a later project far more likely to succeed.

Re-score after the preparation work rather than treating the first result as permanent. A clearer hand-off, a controlled document set or a named reviewer can move a proposed use from speculative to viable without buying anything new. This is a more sensible signal of progress than counting tools, prompts or staff accounts.

One weak category can outweigh a respectable total. A high process score does not compensate for uncontrolled personal data, and a clean data set does not help where no one owns the outcome. Read the pattern as well as the number. The preparation plan should address the specific condition that would make a pilot unsafe, unworkable or impossible to support. Return to this AI readiness checklist when the foundation work is complete.