Before You Build: What an AI Readiness Assessment Actually Looks For
A readiness assessment is not a verdict on whether you're allowed to use AI. It is a map of what is currently in the way- and a sequence for removing it.
The phrase "AI readiness assessment" invites a certain suspicion- that it is a paid opinion about whether you are permitted to proceed, delivered as a slide deck, followed by a proposal.
A useful assessment is not that. It answers a narrower and much more practical question: of the things you would like AI to do, which ones can actually be built with what exists here today, and what has to change before the rest become possible?
That answer is arrived at by looking at five things.
1. Where the data really lives
Not where the architecture diagram says it lives. Where it actually is.
This means opening things. Which systems hold the records that matter, how far back they go, whether historical data survived the last migration intact, whether the field everyone relies on is consistently populated or blank for 2019 through 2021 because of a form change nobody documented.
This step routinely produces the most valuable finding of the whole exercise, and it is frequently not an AI finding. It is a reporting finding- the discovery that two departments have been measuring the same thing differently for years.
2. Which decisions are candidates
An inventory of the repeated, data-informed decisions across the business, with rough volumes attached and a note on what happens when each one is wrong.
The output is deliberately unglamorous: a list, ranked by value against feasibility. Most items on it will not be the thing leadership arrived hoping to hear about. Some of the best candidates are invisible from the top, because they live inside an operational team who have simply absorbed the work for years.
3. What the systems will let you connect to
A model that cannot receive inputs or deliver outputs is a research project. Integration surface is therefore a hard constraint, not a detail.
Does the core system expose an API, or is the only route a nightly export? Who controls that platform- you, or a vendor whose roadmap you do not influence? Is there a staging environment, or is every change tested in production by the people using it?
This is often where a promising candidate quietly drops down the ranking, and it is far better to learn it in week two than in month five.
4. What the rules are
Any use of personal, financial, or health data carries obligations, and they vary by jurisdiction and by sector. Beyond the legal position there are commitments you have already made- what your privacy policy says, what contracts with clients specify, what customers were told when the data was collected.
There is also the internal question, which fewer organisations have addressed: for a given decision, does someone need to be able to explain why the answer was what it was? If yes, that constrains which techniques are appropriate, and it should be decided before a model is chosen rather than after it is deployed.
5. Who will own it once it exists
The most consistently underestimated factor. A model in production is not finished- it needs monitoring, retraining as conditions shift, and someone who notices when its outputs start drifting from reality.
If nobody's job description contains that, the system will degrade quietly. Assessing readiness means asking who, specifically, is going to hold it.
The output that matters
A good assessment ends with a shortlist and a sequence: two or three candidates worth building, the prerequisite work each depends on, and an honest note about what should not be attempted yet and why.
The "not yet" section is usually the most valuable page in the document. It is the one that prevents an expensive year.
