AI Readiness Checklist: What to Fix Before You Automate

AI readiness is not a score for how many AI tools a company has bought. It is the ability to put automation into a real workflow, give it reliable context, assign ownership and judge whether it improves the business. A polished prototype can hide weaknesses in all four areas.

Use this checklist before choosing a model or vendor. A weak answer does not always mean “stop.” It shows what the first phase of the work should fix.

1. Is the business problem specific?

Name the delay, cost, error or missed opportunity you want to reduce. “Use AI in sales” is not specific. “Reduce the time required to research and qualify an inbound lead” is. A clear problem gives the project a boundary and prevents technology from becoming the objective.

Write down who experiences the problem, how often it occurs and what happens if nothing changes. If the team cannot agree on those facts, begin with process discovery rather than a build.

2. Can you map the current workflow?

Document the trigger, inputs, decisions, handoffs, outputs and exceptions. AI automation works inside a system; it does not remove the need to understand that system. Hidden manual steps and unwritten approvals are common reasons a demonstration fails in production.

Choose one workflow with enough repetition to test. Rare, highly variable processes are usually poor first projects because they provide little evidence and demand too many exceptions.

3. Is the required context available and trustworthy?

List the documents, records, messages and business rules a capable employee uses. Check whether they are current, accessible and legally appropriate for the proposed use. AI cannot compensate for conflicting price lists, missing customer history or policies that only exist in someone’s memory.

You do not need perfect data. You need a defined source of truth, known gaps and a safe response when the system lacks evidence.

4. Is there a named owner and a human review point?

Every operating AI system needs an owner for outcome, quality and change. “The innovation team” is not an owner. Name the person who can decide what good looks like, provide real examples and resolve trade-offs.

For an early release, specify which outputs require human review and what the reviewer checks. This makes risk visible and creates feedback the system can use.

5. Have you defined acceptable risk?

Consider the consequence of a wrong answer, missed case or unintended disclosure. Drafting, classification and research assistance are often safer starting points than autonomous customer promises, payments or high-stakes decisions.

Set boundaries before the pilot: prohibited data, required approvals, audit records, access controls and a fallback path. Risk management should shape the design, not appear as a final compliance gate.

6. Can success be measured against a baseline?

Capture the current time, cost, throughput, error rate or conversion outcome. Then define a small set of measures for the pilot. Useful measures combine efficiency and quality: minutes saved per case, percentage accepted without major edits, cases escalated correctly and user adoption after several weeks.

Avoid measuring only output volume. Faster production of low-quality work is not transformation.

7. Can the first version be narrow and reversible?

A strong first release handles one workflow, a controlled source set and a limited user group. It can be switched off without disrupting the company. This keeps the learning cycle short and prevents an unproven prototype from becoming critical infrastructure.

If most answers in this checklist are clear, the company is ready for a focused pilot. If they are not, the next step is still valuable: map the process, organise the knowledge and define ownership. That work turns AI interest into an operating foundation.