The AI Readiness Assessment: 20 Questions Before You Build

The most expensive AI lessons are the ones organisations learn after the build: the knowledge base that turned out to be unusable, the workflow nobody would change, the compliance question that surfaced in month five. Almost all of them were knowable in week one — if someone had asked.

This is the assessment I use before any serious AI commitment. Twenty questions, five dimensions, answered honestly for one specific use case. It works as a leadership workshop, a due-diligence checklist or a self-audit. What it is not is a maturity model that awards your company a grade; readiness is always readiness for a particular capability.

Strategy and value: questions 1–4

One: what business outcome does this capability change, and how will you measure the change against today’s baseline? Two: who is the executive owner — the person whose objectives include this outcome? Three: what happens if you do nothing for a year — is this urgent, or merely fashionable? Four: is the value case specific enough to fail? A case that cannot fail is not a case; it is a slogan.

If questions one and two have crisp answers, most downstream decisions get easier. If they do not, stop here. The commonest failure I see is not bad technology but a missing owner — the pattern behind most of the stalls I described in From Pilots to Capability.

Data and knowledge: questions 5–8

Five: where does the knowledge this capability needs actually live — and how much of it is in people’s heads rather than systems? Six: what is its condition: current, owned, deduplicated, permissioned? Seven: can the system respect your access boundaries — who may see what — without a rebuild? Eight: what data are you prohibited from using, by regulation, contract or your own ethics?

Knowledge condition is the most underrated readiness factor, and for most enterprises it is the real moat — the argument I made in Enterprise Knowledge Is the Real AI Advantage. Models are available to everyone; your organised, permissioned, current knowledge is not.

People and adoption: questions 9–12

Nine: whose daily work changes if this succeeds, and have they been in the room? Ten: what happens to the time saved — is there a plan for it, or an unspoken fear about it? Eleven: who can evaluate the system’s outputs for quality — do you have the judgment in-house? Twelve: what is your plan for the sceptics: the people whose doubt is actually expertise in disguise?

Capability adoption is a workforce question before it is a technical one. For founders and smaller teams, I covered the practical route in AI for Founders; the principle scales: systems get adopted when the people affected help shape them.

Operations and engineering: questions 13–16

Thirteen: who runs this in production — monitoring, incidents, cost — and do they know it is coming? Fourteen: how will you evaluate quality continuously, not just at launch? Fifteen: what is the recovery path when the system is wrong, slow or unavailable — does the workflow degrade gracefully? Sixteen: do you understand the unit economics — cost per task at realistic volume, not demo volume?

These four questions decide whether a successful pilot can become an operated capability. If the honest answer to thirteen is “nobody yet”, the pilot should not scale.

Governance and risk: questions 17–20

Seventeen: what is the risk class of this use case — who is affected when it is wrong, and how reversibly? Eighteen: which obligations apply — the EU AI Act, sector rules, customer contracts? Nineteen: what evidence will you keep — evaluations, logs, decisions — and where? Twenty: who can say no — is there a working path to not deploying, or has the decision already been made by momentum?

If these questions feel heavy, use the structure in An AI Governance Framework CTOs Can Actually Run — four layers that answer all four questions without a governance department. The NIST AI RMF remains the best free scaffolding for the practice.

How to score it — and what to do next

Score each question red, amber or green for the specific use case. The pattern matters more than the total. Green strategy with red knowledge means fix the knowledge estate first — that work pays back regardless. Green everything except operations means build, but budget for running, not just launching. Red strategy means do not build yet, whatever the demo looked like.

Run the assessment again when the use case changes, because readiness is not a state you achieve once. And treat every red as good news arriving early: each one found now is a failed deployment you did not pay for. If you want a second pair of eyes on your answers, that is a conversation I am always glad to have.

Go deeper

Everything on The Practical CTO in the AI Strategy & Readiness cluster, for readers who want to go further.

• AI for Founders: A Complete Guide to Adopting AI in Your Team
• The AI-Native Organisation
• From Pilots to Capability: Why Enterprise AI Stalls
• An AI Governance Framework CTOs Can Actually Run
• Microsoft’s New Copilot Is an AI Operating System for Work
• AI Adoption Strategy for Frontline Smart Glasses, 2026
• Enterprise AI Strategy: a 30-day vendor-risk playbook
• Anthropic IPO S-1: A CTO’s Checklist for Risk and Cost

Services: AI Readiness Assessment  ·  AI Strategy Advisory  ·  Executive AI Workshops  ·  Expertise: Enterprise AI Strategy hub