AI readiness: 12 questions to answer before you invest

Most AI projects don’t fail because someone chose the wrong model. They fail because nobody checked whether the business could absorb the result before the money was committed. A readiness check catches that early, and it takes days rather than quarters.

MIT’s NANDA initiative reviewed more than 300 enterprise deployments and reported that roughly 95% of generative AI pilots produced no measurable return, with the causes lying in integration and how organisations work rather than in the models.

So the useful question isn’t which vendor to sign. It’s whether your organisation can turn a working model into a changed way of working. Below are twelve questions we ask before any build starts. Answer them honestly and you will know within a week whether to go ahead, wait, or fix something else first.

Why this beats a vendor demo

A demo runs on clean data, a narrow task and someone who knows which button to press. Your business runs on none of those. That gap explains most of the disappointment after a contract is signed.

The evidence points the same way. Gartner found that 63% of data management leaders either didn’t have the right data practices for AI or weren’t sure they did, and predicted that organisations would abandon 60% of AI projects not supported by AI-ready data. McKinsey’s State of AI survey found 88% of organisations using AI in at least one function, but only about a third scaling it. Adoption is easy. Absorption is hard.

The four areas to score

Each area can sink a project by itself, so a good average hides nothing useful. Look at the weakest one.

• Data and infrastructure. Does the raw material exist, and can the system reach it?
• Business case and value. Will something measurable change?
• People and process. Will anyone actually use it?
• Governance and risk. What happens when it gets something wrong?

Data and infrastructure: questions 1 to 3

1. Can you name the exact data this use case needs, and does it exist today?

Not “we have lots of customer data”. Name the tables, the fields and the date range. A support automation needs resolved tickets with outcomes attached, not just ticket counts. A forecast needs consistent definitions of revenue across regions.

A good answer: a named list of sources, with row counts and a sample someone has actually opened. A warning sign: an answer that describes a system rather than a dataset.

2. Who owns that data, and how long does access take?

Ownership disputes delay more projects than engineering does. The data often sits with a team that gains nothing from yours, so access becomes a negotiation. Find out now whether that takes two days or two months, and ask about production access, not a sandbox export. Teams often prove a concept on an old CSV and then discover the live pipeline needs a security review nobody scheduled.

3. Can the output reach where the work already happens?

An answer that lives in a separate dashboard gets checked twice and forgotten. If your agents work in a service desk, the output belongs there. Check whether the target system has a usable interface, who maintains it, and whether IT already has three projects queued against it. If the plan involves searching your own documents, see our guide to building a knowledge base with RAG.

Business case and value: questions 4 to 6

4. Which decision or task changes, and who does it differently on Monday?

Name the role and the task. If you can’t describe what one specific person will stop or start doing, you have a technology purchase rather than a business change. It also catches vague scope early. “Improve customer experience” tends to fail. “Cut first-response time on simple tickets from four hours to twenty minutes” tends to ship.

5. What is the baseline today, and what counts as success at 90 and 180 days?

Measure before you build, or the review meeting becomes a debate about whether things feel better, and feelings lose budget arguments. Set two tiers of measure: early indicators you can see within a fortnight, such as adoption or time saved per task, and later ones at 90 and 180 days, such as cost per resolution. Without them, nobody has anything to approve a second phase against.

6. What is the full cost of ownership, not just the pilot?

Pilot budgets flatter everyone. Real cost includes running the system at production volume, data preparation, integration, monitoring, retraining and internal time nobody logs. Model the second year, not just the first, because costs that look small at pilot scale often become the largest line once volume grows.

People and process: questions 7 to 9

7. Who owns this internally, and can they change the workflow?

A sponsor who can’t redesign the process can’t deliver the project, however keen they are. Adoption means telling people to work differently, so the owner needs standing with the team whose work changes. Be wary of projects run only by a central innovation team with no operational owner. They tend to stall at handover.

8. What happens to the people currently doing this work?

Answer this before the rumours do. Teams that suspect a tool exists to replace them will find quiet ways to make it fail. Say plainly whether roles will change, shrink or shift towards handling exceptions. Honest answers survive contact with reality; vague reassurance doesn’t.

9. How will people learn the tool, and who supports them at week six?

Launch-day training is the easy part. By week six the novelty has faded, the edge cases have piled up, and people start drifting back to the old process. Someone needs to own that period. Plan on a few worked examples for each role rather than one general session. Teams learn faster from their own tasks, which is why our guide to AI prompts for business teams is built around task patterns.

Governance and risk: questions 10 to 12

10. What is the worst realistic failure, and what would it cost?

Every model gets things wrong, so the question is what happens downstream when it does. A wrong product suggestion costs a click. A wrong eligibility decision can cost far more. Match the level of oversight to the cost of failure: low-stakes outputs can run unsupervised, high-stakes ones need a person checking. McKinsey reports that nearly two-thirds of respondents named security and risk as the top barrier to scaling agentic AI, ahead of regulation or technical limits.

11. Where does your data go, and who else can see it?

Trace the path. Which provider processes the request, in which region, under what retention terms, and is anything used for training? Procurement often assumes answers the contract doesn’t actually give. Also check which AI tools staff already use without approval. An assessment that ignores that measures the wrong organisation.

12. Which regulations apply, and on what timeline?

European rules changed recently, so check your assumptions. The EU’s Digital Omnibus, approved in June 2026, moved the high-risk obligations in Annex III of the AI Act from 2 August 2026 to 2 December 2027. Many guides still show the older date. Our article on what the deferral does not cover goes through the details.

The extra time is no reason to stop. Use it to build the documentation while the work is cheap. The NIST AI Risk Management Framework offers a free structure built on four functions: govern, map, measure and manage. Most teams can adopt a light version without hiring a compliance function.

How to score your answers

Score each question from 0 to 3: 0 nobody knows, 1 someone has an opinion, 2 it is written down, 3 it is written down and tested. Then read the result by area rather than by total, because the lowest area sets your real ceiling.

• 28 to 36: go ahead. Build the narrowest useful version and measure it.
• 18 to 27: proceed carefully, with a fixed list of fixes running alongside.
• Below 18: fix the foundations first. Spending now buys a pilot you can’t scale.
• Any single area under 5: treat it as a blocker, whatever the total.

Run the exercise with the operational team in the room, not only leadership. The gap between what executives believe and what the people doing the work know is usually where the real answer sits.

If the score comes back low

A low score is information, not a verdict. Most organisations that score poorly the first time improve within a quarter, because the fixes are unglamorous and well understood. Work in this order:

1. Get data access sorted, since everything else waits on it.
2. Name an operational owner with the authority to change the workflow.
3. Write the baseline numbers down.
4. Choose a smaller use case than the one you started with.

Shrinking the scope is the most reliable move. A narrow workflow with clean data and a named owner beats an ambitious programme with none of those, and once the first one works the second is much easier to fund. Our overview of agentic AI for business leaders shows where those first workflows usually pay off. Then repeat the check each quarter, because readiness moves as systems, people and rules change.

A faster way to a first score

If you’d like a quick read before sitting down with the twelve questions, our AI Readiness Index scores strategy, data, systems, people and governance in about six minutes, and shows your result straight away. If you’d rather have someone outside the business ask the questions, book a 30-minute session and bring the use case you’re least sure about. We’ll tell you whether it’s ready and, if not, what to fix first.