AI readiness assessment: the ten questions before you build
Is your company ready to build AI? The ten questions to answer first?
AI readiness is not about ambition; it is about data you can access, systems you can integrate, a decision the AI will change, a budget for running costs and an owner. These ten questions tell you whether to build now, prepare first, or buy instead.
Most failed AI projects were not bad ideas. They were good ideas started before the organisation was ready: the data lived in three systems with no consistent identity, nobody could give an engineer API access, the running cost was never budgeted, and when the pilot worked there was no one to own it. An AI readiness assessment is a short, honest look at those conditions before money is spent. Here are the ten questions we ask in the first week of every strategy engagement, what a good answer looks like, and what to do when the answer is no.
1. Which decision will the AI change?
Not "where can we use AI" but "which decision or task, made by whom, how often, with what cost of getting it wrong?" If you cannot name the decision, you have a technology looking for a problem. Good answer: "The onboarding team decides whether a loan application is complete and consistent, 400 times a day, and errors reach credit assessment."
2. Is the data accessible?
Can an engineer get a representative sample this week, with permission, through an export or an API? Data that exists but cannot be reached is not ready. Good answer: a sample of 200 anonymised cases delivered in three days.
3. Is the data good enough to evaluate against?
AI systems are measured on golden sets: real inputs with verified outputs. Do you have historical decisions, resolved tickets, verified extractions? Without them you cannot know whether the system works. Good answer: two years of decisions with outcomes recorded.
4. Do the systems it touches have APIs?
Every read and write is an integration. A modern CRM with a documented API is a day; a legacy ERP with none is a week of wrapping, and sometimes the honest recommendation is to modernize first. List the systems and mark each: API, database access, or neither.
5. Who owns it after launch?
A named person who will approve intents, review escalations, watch the dashboard and decide when to expand autonomy. AI systems without an owner degrade quietly. Good answer: a named operations lead with two hours a week reserved.
6. What is the monthly running budget?
Inference, platform fees, infrastructure and care are recurring. If only the build is budgeted, month three is a surprise. Good answer: a monthly figure agreed with finance, with the numbers from How much does AI development cost?.
7. What are the data and regulatory constraints?
Residency, consent, retention, sector rules. Regulated data may require private deployment; customer data under DPDP or GDPR needs a lawful basis and retention rules. Knowing this before design saves a rewrite.
8. What is the accuracy threshold, and what happens below it?
Every AI system has errors. Decide the accuracy needed for the decision and the path for cases below it: a human queue, a fallback rule, a refusal. Good answer: "95% field-level accuracy on identity documents; anything below 0.9 confidence goes to review."
9. Can the team operate it?
Someone must deploy, monitor, patch and re-run evaluations when models change. If not in-house, a care plan is part of readiness, not an afterthought.
10. Is there a smaller first step?
The readiest organisations start with one workflow, in shadow mode, with a fixed-price discovery. If your plan begins with a platform, it is probably not ready.
Scoring the assessment
| Score | What it means | What to do |
|---|---|---|
| 8–10 good answers | Ready to build | Run a ten-day Sprint Zero on the named workflow and get a fixed price |
| 5–7 | Prepare first | Fix data access, name an owner and budget running cost; then discovery |
| Under 5 | Not yet, or buy instead | Consider a product that covers the need, or a strategy engagement to sequence the foundations |
What a readiness assessment produces
A scorecard against the ten questions, a ranked list of use cases scored on value, data readiness, risk and effort, a reference architecture with a monthly cost model, and a roadmap that puts foundations before features. In our practice it is a two-to-four-week engagement that ends with a fixed-price proposal for the first build, so strategy turns into delivery without a second procurement. The AI strategy service describes the format; the McKinsey state-of-AI research is a useful external benchmark for where most organisations stand.
The most common "not yet"
Data spread across systems with no shared customer identity. It blocks personalisation, support agents, analytics and most copilots at once. The fix, a single event or record pipeline with a stable identity, is unglamorous, takes a few weeks, and is the foundation everything else stands on. We have seen it decide the outcome of more AI projects than any model choice.
A worked assessment: a regional hospital network
Decision named: front-desk staff spend the morning on routine appointment calls while patients wait at the counter. Data accessible: consented call recordings could be sampled within a week. Evaluation data: appointment outcomes recorded in the hospital information system. Systems: the HIS had no external API, so a scoped wrapper was needed, and that became the first engineering task. Owner: the operations lead, two hours a week. Running budget: telephony, speech and care, agreed with finance. Constraints: patient data stays inside the network; no clinical information spoken by the agent. Threshold: routine calls resolved without a human, hand-off for anything else. Operations: a 24×7 care plan because phones do not stop. Smaller first step: one site, a share of calls, three weeks. Score: nine of ten, with the missing API as the known gap. The voice-agent case study shows what followed.
Readiness by AI type
| AI type | Readiness hinges on |
|---|---|
| Customer service agent | Historical conversations, helpdesk API, written policies |
| Voice agent | Call recordings, telephony access, a system to act in |
| Document extraction | Sample documents including bad scans, verified values |
| RAG / knowledge assistant | Document sources, permission model, real questions |
| Copilot in a SaaS product | API surface, sample accounts, a ranked job list |
| Forecasting or scoring model | Two years of operational data and a decision that uses the score |
After the assessment
If the score says build, run a fixed-price discovery on the named workflow. If it says prepare, the roadmap sequences the fixes, usually data access and an owner, and dates the first build. If it says buy or wait, we say so; sometimes the answer is implementing a platform rather than building. Either way you leave with a document your board can read and your engineers can act on. Start with the AI strategy service or talk to an engineer.
Team and timeline
The assessment itself needs your time more than ours: a sponsor for an hour at the start and end, the owners of the data and systems for a working session each, and a finance contact for the running-cost conversation. We bring a principal engineer and an architect. Two to four weeks later you have a scorecard, a ranked use-case list, a reference architecture with a cost model, and a fixed-price proposal for the first build if the score supports one. If it does not, you have saved the cost of finding out the expensive way.
Before you start: a checklist
- Name the decision and its owner before the first meeting
- Identify where the data lives and who can grant access
- Pull a representative sample, anonymised if needed
- List the systems involved and whether each has an API
- Agree who will own the system after launch
- Bring finance into the running-cost conversation early
- Be willing to hear "not yet" or "buy instead"
Readiness is per workflow, not per company
Organisations are rarely ready or unready as a whole. The support team may have two years of tagged tickets and a helpdesk with a clean API while finance runs on spreadsheets nobody can export. Score each candidate workflow separately and start where the answers are strongest; the first system builds the pipelines, evaluation habits and ownership that make the second one easier. This is also the antidote to the platform pitch: a vendor proposing an enterprise-wide AI layer before any workflow has been proven is asking you to fund foundations for use cases that may never pass the ten questions. Prove one, then generalise.
Related reading
Related reading: How much does AI development cost? for budgeting the running line, How to choose an AI development company for the next step after readiness, and Application modernization vs rewrite if the blocker is a system with no API.
The assessment is not a gate to keep you out of AI; it is the shortest route to a first system that works. Ten questions, two weeks, and you either build with confidence or fix the one thing that would have sunk the project.
Frequently asked questions
How long does an AI readiness assessment take?
▾
The ten questions take a week with the right people in the room; a full strategy engagement with a ranked roadmap takes two to four weeks.
Can we be ready for one use case and not another?
▾
Yes, and that is normal. Readiness is per workflow; start where data, owner and decision are all in place.
Does readiness mean we need clean data everywhere?
▾
No. It means accessible, representative data for the one workflow you start with, and a plan for the rest.