The AI Readiness Checklist: Twelve Questions Before You Build
Most failed AI projects were decided before anyone wrote a prompt. These twelve questions surface the reason in an afternoon, and you can run them yourself.
I've never seen an AI project fail because the model wasn't good enough. I've seen a lot of them fail because the field everyone planned to use was populated about half the time, and nobody checked until month four.
Readiness assessments have a reputation for being consultant-ware, and often they earn it: a scored radar chart, six workstreams and a recommendation to buy more consulting. The useful version is smaller. Twelve questions, answered honestly, will tell you most of what a three-week engagement would, and you can run them yourself this week.
The rule for using this: an answer of "probably" counts as a no. Every one of these has a specific, checkable answer, and "probably" means nobody has looked.
Data: four questions
1. Can you name the exact fields the use case depends on, and how often they're populated?
Not the tables. The fields. Then go and count the nulls in a real extract rather than asking the person who owns the system, because the person who owns the system will tell you what it's supposed to contain. This single check kills more projects than any other, and it takes about twenty minutes.
2. When two systems describe the same customer, order or product, do they agree?
Pull fifty records that exist in both and compare them. If your CRM and your ERP disagree about which company an order belongs to, any system reasoning across both will inherit the disagreement and present it confidently.
3. Do you have enough history to build an evaluation set?
You need real past cases with known correct answers to test against. A few hundred is usually enough. Without them you have no way to tell whether the system works, and quality becomes a matter of opinion in a meeting.
4. Can someone actually get the data out, this month?
Not in principle. This month. If the answer involves a vendor ticket, a professional-services quote or a database nobody has credentials for, that's your first project and it isn't an AI project.
Systems: two questions
5. Does the system of record have a usable API?
If the output has to land somewhere to create value, and the only way in is a screen a human types into, you're building a robot to operate a keyboard. Sometimes that's the right call. It should be a deliberate one, priced accordingly.
6. How long does it currently take you to ship a small change to production?
If the honest answer is six weeks, that's your iteration speed for AI too, and AI systems need more iteration than conventional software, not less. A company that can't deploy weekly will struggle to tune a system that drifts.
Process: three questions
7. Who owns the process end to end, by name?
A workflow that crosses three departments and belongs to none of them is not a technical problem, and no vendor will solve it for you. If you can't name the owner, name them before you start.
8. Do you know the current volume, handling time and error rate?
Three numbers. Without them there's no baseline, so there's no way to prove improvement and no way to build a defensible business case. Most companies have never measured these, and gathering them takes a week.
9. What happens to the exceptions today, and how often do they occur?
The exception rate determines the whole design. A process where four percent of cases are unusual gets built very differently from one where thirty percent are, and companies routinely underestimate their own rate by half.
People and governance: three questions
10. Is anyone on your team already using AI seriously, without being asked?
Shadow use is the most reliable readiness signal there is. If people are quietly solving their own problems with these tools, you have latent capability and a distribution problem. If nobody is, you have a capability problem, and that's slower to fix.
11. Can your operations staff supervise output they didn't produce?
Reviewing a machine's draft is a different skill from doing the work. Some teams take to it. Others rubber-stamp within a fortnight, which is worse than no review at all because it manufactures the appearance of oversight.
12. Has anyone decided what data may go where, and what AI may decide alone?
If not, the first real use case will stall in a security conversation nobody prepared for. Two pages settle it. Deciding it now costs an afternoon; deciding it in month five costs a quarter.
Reading the results
Count your genuine yeses.
Ten or more, and your constraint is choosing the right first project rather than capability. Six to nine is the most common result, and the gaps are usually clustered in data and process rather than scattered, which makes them cheap to close. Below six, the honest read is that an AI project would surface problems you'd need to fix anyway, at the worst possible time and under a deadline.
Almost nobody scores twelve, including companies already running AI in production successfully. The point isn't the score. It's knowing which two things to fix before you commit a budget.
What to do with a low score
Resist the instinct to launch a data quality program. Those run for a year, cost a fortune and rarely finish, because they're scoped against everything rather than against a use case. Pick the single use case you most want, then fix only the data it depends on. That's a six-week project with a visible end, and it produces something rather than a cleaner warehouse nobody uses.
The full version of this, with the rubric and the interview guide, is published free, and it's a genuine framework rather than a lead magnet. If you'd rather have someone from outside ask these questions, so nobody has to score their own department, that's the readiness assessment.
Run the twelve first. If the answers are clear, you may not need anyone. Send me the ones that came back ambiguous and I'll tell you which matter.