The 30-Question AI Readiness Test: Where Does Your Business Actually Stand?

Most AI readiness conversations end the same way. Someone says "we're probably about seventy percent there," everyone nods, and nobody can say which thirty percent is missing.

This test exists to replace that number with a real one.

Thirty questions, six dimensions, twenty minutes. It will not tell you whether to buy a particular model or platform. It will tell you which specific thing is going to stall your first serious AI project, which is a far more useful thing to know before you commit a budget.

A warning before you start: the goal is not a high score. We have seen organisations score in the low forties and ship a production AI system inside a quarter, and others score in the fifties and spend a year in pilot purgatory. The score is a diagnostic, not a grade.

How to score it

For each question, give yourself:

2 points if the answer is a confident yes
1 point if it is partly true, or true for some teams and not others
0 points if it is no, or if you are not sure

Thirty questions, sixty points available.

Be harsh with the ones. "Partially" is the honest answer far more often than people want it to be, and inflating it defeats the purpose. If you would not be able to defend the answer to a sceptical auditor, it is one.

Section one: strategy and intent

This section catches the most common failure of all, which is an AI programme that exists because AI exists. If you score low here, nothing further down matters much, because you will build competent systems aimed at nothing in particular.

• Can you state, in one sentence and without using the word AI, what business outcome you are trying to change?
• Have your senior leaders actually agreed on that, rather than each holding a different version of it?
• Have you identified specific processes where AI would create measurable value, not just categories where it might?
• Do you have a target number attached, with a baseline you can compare it against?
• Do you have a sequenced roadmap, so you know what comes second and why?

A note on question four: "improve productivity" is not a target. "Cut average claim review from twenty minutes to seven" is. The difference determines what data, architecture and controls you actually need, so getting vague here makes everything downstream vague too.

Section two: data

Almost nobody has a data shortage. Most organisations have a data organisation problem, and it only becomes visible when an AI system starts confidently answering from the wrong version of a document.

• Can the systems that need your critical business data actually reach it?
• Is that data accurate and consistent enough that you would act on it without checking?
• Do you know where your most important information lives, including the parts living in email and spreadsheets?
• Does someone specifically own each critical dataset, by name?
• Do you have governance covering access, quality, privacy, lineage and retention?

Question nine is the one people score generously and shouldn't. "The data team owns it" is a one, not a two. Two means you could name the person today.

Section three: technology and architecture

The gap between a working pilot and a working product is usually architectural, and it usually surfaces late.

• Can your current architecture support AI workloads, including pipelines, model services, retrieval and integration?
• Can your systems integrate with external models and services without a bespoke project each time?
• Can your infrastructure absorb production load, not just pilot load?
• Do you have monitoring that would tell you if output quality degraded, not just if the service went down?
• Can AI sit inside the applications people already use, rather than in a separate tab?

Question fourteen separates organisations that will catch a problem from ones that will hear about it from a customer. Uptime monitoring is not output monitoring.

Section four: security and governance

Governance gets treated as a gate at the end. It is actually a set of design constraints at the start, and it matters more every quarter as systems move from generating content to taking actions.

• Do employees know what they may and may not put into AI systems?
• Do you have a governance framework covering accountability, approved use cases and model controls?
• Can you control who accesses which AI system and what it can retrieve on their behalf?
• Can you evaluate outputs before they influence decisions that matter?
• Do you understand your legal, regulatory and privacy exposure for the use cases you are planning?

If you are considering anything agentic, question nineteen is not optional. A system that can act needs a defined answer for what it may do alone, what needs approval, and what happens when the approver is on leave.

Section five: people

The most common way for a technically successful AI project to fail is that nobody uses it.

• Do employees understand how AI changes their specific role, rather than in general terms?
• Do you have people with genuine AI, data and platform skills, or access to them?
• Are business and technology teams working on this together, rather than IT building and business receiving?
• Is there a named executive sponsor who will resolve conflicts when priorities collide?
• Is there an enablement plan that goes beyond a one-off training session?

Question twenty-one is where ambiguity is most expensive. Silence about job impact is always read as bad news, and it kills adoption before launch.

Section six: adoption and execution

This is where scores usually collapse, and it is the section that best predicts whether a pilot ever becomes a product.

• Do you know exactly who will use each solution, by role?
• Have you defined adoption metrics beyond raw usage, such as task completion or time saved?
• Do you have a defined path from pilot to production, including integrations, permissions, cost ceiling and ownership?
• Can you measure financial impact against total cost, including inference, integration, maintenance and change management?
• Are you set up to keep improving the system after launch, as models and requirements change?

Question twenty-eight is the single highest-leverage item on this list. A pilot with no defined production path is not a pilot, it is a rehearsal for a decision nobody intends to make.

What your score means

48 to 60. Ready to execute.
Your foundations are sound. Your risk now is not readiness, it is choosing badly. Prioritise ruthlessly, pick one use case with a defensible business case, and build it properly rather than starting four.

36 to 47. Ready in parts.
You can start, but not everywhere. Identify your two lowest-scoring sections and treat them as work in their own right while you run one carefully chosen pilot. This is the most common band, and the most common mistake in it is scaling before the gaps close.

24 to 35. Foundation work first.
There is real appetite here but not yet the base to support it. More experiments will not help. A structured readiness assessment against one specific use case will tell you what to fix and in what order, which is cheaper than discovering it mid-build.

Below 24. Start earlier than AI.
This is not a reason to ignore AI. It is a reason to spend the next two quarters on data quality, ownership, architecture and leadership alignment. Organisations that skip this stage do not avoid the cost, they just pay it later with a failed programme attached.

The thing the score will not tell you

Readiness is relative to what you are trying to do.

A customer service assistant leans heavily on retrieval quality and escalation paths. A forecasting model lives or dies on historical data. An agent that takes actions needs far more attention to permissions and monitoring than either. A score of forty-two might be entirely sufficient for one of those and nowhere near enough for another.

Which is why the useful next step is not "improve the score." It is to pick the use case you actually care about, and assess readiness against that.

That is where a general self-test stops and real diagnosis starts.

If you want a view of where you actually stand against a specific use case rather than in the abstract, book an advisory session. We start with how the business runs, not with a technology recommendation.

Frequently Asked Questions

What is an AI readiness assessment?
A structured review of whether an organisation can turn AI into business value. It covers strategy, data, technology, governance, people and adoption rather than technology alone.

What score do we need before starting an AI project?
There is no threshold. Above 48 you can execute, between 36 and 47 you can pilot carefully while closing gaps, and below 36 the foundation work will pay back faster than another experiment.

Which dimension causes the most AI failures?
Adoption and execution. Systems that are technically sound but do not fit how people work get built, launched, and quietly ignored.

Do we need to be fully ready before investing in AI?
No, and waiting for a perfect score is its own failure mode. Assess readiness against one specific use case and start there.

How often should we retake this test?
Every six months, or whenever you take on a materially different type of use case. Moving from AI that generates content to AI that takes actions changes the requirements enough to warrant a fresh look.

What does Applore do after a readiness assessment?
We work as an advisory practice across Technology Strategy, Platform and Architecture, and Data, AI and Automation, running Plan, Execute, Adopt. Diagnosis leads to a prioritised roadmap, then delivery, then adoption measured as an operating number.