AI Readiness Assessment: A Practical Methodology

Most AI readiness assessments are theatre. A consultant runs a workshop, scores you against a 50-point framework copied from a vendor whitepaper, and delivers a heatmap that confirms what you already knew: your data is messy and your people need training. The output sits in a SharePoint folder. Nothing ships.

A useful AI readiness assessment does the opposite. It produces a short list of specific, costed bets the organisation can place in the next 90 days, a defensible reason to either invest or wait, and an honest map of the gaps that will sink those bets if left alone. This article sets out the methodology we use - what to measure, how to score it, and how to translate the score into action.

What an AI readiness assessment actually needs to answer

Before picking a framework, get clear on the questions the assessment exists to answer. In our experience, leadership teams commissioning a readiness exercise want answers to four things, in this order:

1. Where will AI pay back fastest in our business? Not in general - in our specific operations, with our specific data, against our specific cost base.
2. What will stop us shipping? Data quality, infrastructure, skills, governance, vendor lock-in, culture - which of these is the binding constraint?
3. What does the first 90 days look like, concretely? Which use case, which team, which tools, which budget.
4. Should we build, buy, or wait? For each candidate use case, with a defensible reason.

Frameworks that score you against 60 abstract criteria fail because they answer none of these directly. A good methodology drives toward those four answers and discards anything that does not contribute.

The Information Commissioner's Office guidance on AI and data protection is a useful benchmark for the governance dimension - if your assessment cannot map to those expectations, it is not fit for a UK context.

The five dimensions worth measuring

Readiness is not one number. It is a set of capabilities that interact. Score them independently, then look at the shape of the result rather than the average. We assess five dimensions.

1. Strategic clarity

Does the organisation have a clear view of where AI fits the commercial strategy? Specifically: which P&L line is AI meant to move, by how much, by when. Vague ambitions ("become AI-first") score zero. "Reduce cost-to-serve in tier-1 support by 30% within 12 months" scores high.

Sub-questions: is there an accountable executive sponsor with budget authority? Is there a published view of which use cases are in scope and which are explicitly out? Are success metrics defined before tools are picked, not after?

2. Data foundation

Forget data maturity models that take six months to complete. Ask three practical questions. First: for the top three candidate use cases, can you access the required data today, in a structured form, without a six-month integration project? Second: who owns it, and will they give you access? Third: what is its quality - measured by sampling, not by reputation.

This is where most assessments are dishonest. Stakeholders say data quality is "okay" because admitting otherwise creates work. Insist on a sample. Take 200 records from the CRM, the ticketing system, the product database, and have someone score completeness, consistency, and freshness. That two-day exercise tells you more than a 40-page data maturity report.

3. Technical infrastructure

Can you run modern AI workloads without rebuilding your stack? The questions worth asking: does the organisation have an approved cloud account with budget? Are there working CI/CD pipelines for non-AI code, or is everything still being deployed by hand? Is there a clear pattern for how production services are authenticated, logged, and monitored? Can a new internal tool reach the CRM, the data warehouse, and identity provider without a three-month security review for each one?

If the answer to most of these is no, your first AI build will spend 70% of its budget on plumbing. That is not a reason to delay - it is a reason to scope the first project to include the plumbing and not pretend otherwise.

4. Skills and operating model

Who will actually run the AI systems once built? The most common failure mode we see is a successful pilot that nobody owns in production. Score this dimension on three axes: technical skills to maintain (someone who can debug a retrieval pipeline at 2am), product skills to evolve (someone who tracks usage, defines roadmap, talks to users), and domain skills to evaluate output (the people who know whether the AI is right).

The McKinsey State of AI reports consistently show that organisations achieving measurable EBIT impact from AI have redesigned workflows and assigned clear ownership. Tooling is rarely the constraint. Operating model is.

5. Governance and risk posture

For UK and EU operations this is not optional. The EU AI Act is in force, with risk-classification obligations that bite from 2026 onwards. UK GDPR applies to any model training or inference using personal data. Sector regulators (FCA, MHRA) have their own positions.

Assess three things: is there a defined process for approving an AI use case before it goes live? Are there minimum requirements for logging, human review, and contestability? Is there clarity on which use cases are off-limits (automated decisions on credit, employment, healthcare diagnosis without human-in-the-loop)? An organisation that cannot answer these will either move too slowly out of fear or too quickly into a regulatory problem.

Scoring: a rubric that produces decisions, not heatmaps

Score each dimension 0-4, with explicit definitions per level. Avoid 1-10 scales - they invite bargaining and false precision.

• 0 - Absent. No capability exists. Building from scratch.
• 1 - Emerging. Some informal activity, no consistency, no ownership.
• 2 - Functional. Capability exists but is uneven across the business. Specific projects can succeed with effort.
• 3 - Reliable. Capability is consistent, owned, documented. Projects can plan against it.
• 4 - Differentiating. Capability is a competitive advantage. Other companies would benchmark against you.

For each level, write down what evidence would justify the score before scoring. "Reliable data foundation" means: data dictionaries exist for the top 10 systems, access requests are fulfilled in under 10 working days, a documented quality monitoring process catches at least 80% of upstream issues. If you cannot point to evidence, the score is lower than you think.

The output is not a single composite number. It is five scores and a shape. Common shapes we see:

• The slide-deck shape (high strategy, low everything else): strategy team has done the work, the rest of the organisation has not been told. Action: stop the strategy work, ship one production use case to force the other dimensions to develop.
• The shadow-IT shape (high skills, low governance): engineering teams are already using AI, often without approval. Action: formalise rather than ban, build a fast-lane approval process.
• The platform shape (high infrastructure and data, low strategy and skills): typical of organisations that spent 2020-2023 on data platform work. Action: stop building platform, run three use-case pilots with clear sponsors.
• The compliant-paralysis shape (high governance, low everything else): regulated industries that have over-indexed on risk frameworks. Action: pick a low-risk internal use case, ship it through the governance process to prove the process works.

The assessment process: two weeks, not six months

A readiness assessment that takes six months is itself a sign of low readiness. The methodology below runs in 10 working days and produces something the executive can decide on.

Days 1-2: Define scope and gather inputs

Confirm the four questions the assessment must answer. Identify 8-12 candidate use cases from operations leaders - not a brainstorm, ask each function head for the two processes they would most want to automate or augment. Pull existing documentation: data catalogues, architecture diagrams, recent audit reports, the last AI strategy deck if there is one.

Days 3-6: Interviews and evidence gathering

Run 12-18 interviews of 45 minutes each, across executive sponsors, function heads, engineering leads, data team, security, legal. The interview script is structured around the five dimensions, with concrete questions, not opinions. Sample three datasets directly. Walk through the deployment pipeline with an engineer. Read the last three security review minutes.

Days 7-8: Use case shortlisting

For each of the 8-12 candidate use cases, score on four axes: business value (annualised £ impact if it works), feasibility (given current readiness scores), time to first value (weeks to a usable v1), and reversibility (how cheap is it to stop). Shortlist three. Spend half a day on each costing the first 90 days specifically: tools, people, infrastructure, expected output by week.

Days 9-10: Synthesis and review

Write the report. Score the five dimensions with evidence. Present the three shortlisted use cases with costed plans. Make a clear recommendation: invest now in use case A, run a 6-week proof on B, defer C until the data foundation work is done. Review with the sponsor. Adjust. Ship.

Translating the score into a 90-day plan

The assessment is wasted unless it produces action. The 90-day plan should fit on one page and contain four things: the use case being shipped, the person accountable, the budget envelope, and the explicit decision criteria for whether to continue, expand, or stop at day 90.

Common structures we use:

• Weeks 1-2: kickoff, technical discovery, data access confirmed, success metrics signed off, governance approval secured.
• Weeks 3-8: build and iterate, with a working version demonstrable from week four. Weekly review with the sponsor.
• Weeks 9-12: production rollout to a defined user group, measurement against success metrics, decision on continuation.

In parallel, address the binding-constraint dimension from the readiness scores. If governance scored 1, the 90 days should include building the approval process the next 10 use cases will use. If skills scored 1, the 90 days should include hiring or contracting the operating-model role that will own production AI. Do not treat readiness work as separate from delivery work - the only way readiness improves is by shipping something that forces the gaps to close.

What to avoid

A few patterns we see repeatedly that waste readiness budgets:

Scoring against vendor frameworks. Microsoft, AWS, Google, and the big consultancies all publish readiness frameworks. They are not neutral. The scoring criteria reflect what those vendors sell. Use them as input checklists, not as the basis of your score.

Confusing maturity with readiness. An organisation can be mature on data and infrastructure and still not ready for AI, because nobody owns AI as a product. Conversely, a scrappy 80-person organisation can be ready because it has a clear sponsor, one good engineer, and a willingness to ship.

Assessing in isolation from delivery. The best readiness assessments are run by people who are also accountable for shipping. When the assessor knows they will be on the hook for the build, the assessment becomes honest fast.

Treating the report as the deliverable. The deliverable is a decision and a plan. The report is just evidence for the decision. If the executive cannot make a decision on the day the report is presented, the assessment failed regardless of how thorough the document is.

Conclusion

An AI readiness assessment is worth doing when it forces specific commitments: this use case, this sponsor, this budget, this date. It is worth skipping when the only output will be a maturity score. The methodology above - five dimensions, 0-4 scoring with evidence, two-week timeline, three costed use cases - is what we have found produces decisions rather than decks. The shape of the scores matters more than the total, and the binding constraint matters more than the shape.

If you want a second opinion on where your organisation actually sits, or a structured two-week assessment run by people who also build the systems, AI Advisory runs this process as a fixed-fee engagement. Get in touch to discuss scope.

Frequently asked questions

How long should an AI readiness assessment take?

Ten working days for a focused mid-market assessment, six to eight weeks for a complex multi-business-unit organisation. Anything longer is either scope creep or political. The deliverable is a decision, and decisions do not get better after week three of analysis - they get harder because the evidence goes stale. If a vendor proposes a six-month readiness exercise, ask what specific decisions it will enable that a 10-day assessment would not. The honest answer is usually "none, but we charge by the month." Cap the timeline up front.

Who should run the assessment - internal team or external agency?

Either works, with trade-offs. Internal teams know the business and the politics, but often cannot be honest about the gaps without career risk. External agencies bring pattern recognition from other clients and can say uncomfortable things, but need 2-3 weeks to understand context. The best results we see are hybrid: an external lead paired with an internal sponsor who has authority to act on findings. Avoid pure external assessments where no internal person is accountable for what happens next - those end up in the SharePoint folder.

How much should an AI readiness assessment cost?

For UK mid-market organisations, expect £15,000-£35,000 for a focused two-week assessment with three costed use cases. Larger or regulated organisations with multiple business units run £40,000-£80,000. Anything above £100,000 should include actual proof-of-concept build work, not just analysis. If a quote is below £10,000 you are buying a templated questionnaire, not a methodology. If it is above £150,000 without included build work, you are funding a consultancy's bench rather than getting useful output.

What is the difference between AI readiness and data readiness?

Data readiness is one input to AI readiness, not a substitute for it. An organisation with excellent data can still fail at AI if there is no executive sponsor, no operating model, or no governance process. Conversely, organisations with imperfect data succeed at AI by scoping use cases that match what they have. The mistake is sequencing - "we will do AI when our data is ready" - because the data is never ready in the abstract, only relative to a specific use case. Assess them together, not in sequence.

Should we wait until our data warehouse is complete before assessing readiness?Should we wait until our data warehouse is complete before assessing readiness?

No. Waiting is itself a high-cost decision. Run the assessment now, scope your first use case against whatever data is accessible today, and let the data warehouse work proceed in parallel. The most common pattern we see is organisations completing 18-month data platform programmes and discovering the AI use cases they originally planned no longer match the business priorities. Ship something small with imperfect data, learn what data actually matters for AI in your context, then prioritise warehouse work against that learning. Assessment-before-platform-completion is the right sequence.

How do we measure ROI on an AI readiness assessment itself?

Two ways. First, the avoided cost: how much would you have spent on the wrong use case, or the right use case at the wrong time, without the assessment? For mid-market organisations this is typically £100,000-£500,000 in saved build cost on use cases that would not have shipped. Second, the time-to-value on the use cases that do proceed: a well-assessed shortlist gets to production 30-50% faster than a use case picked from a brainstorm, because the readiness gaps are known and budgeted from day one. Measure both at the 6-month and 12-month mark.

What if the assessment shows we are not ready for AI at all?

This is rare and usually wrong. Almost every organisation has at least one use case where existing data, existing skills, and existing infrastructure are sufficient for a useful AI deployment - typically internal-facing, low-risk, augmenting rather than replacing humans. If an assessment concludes "not ready," it usually means the assessor was scoring against ambitious external use cases (customer-facing AI agents, automated decisions) rather than appropriate ones (internal search, document summarisation, knowledge retrieval). Push back and ask for the lowest-risk use case that would still produce measurable value. There is almost always one.

How often should we re-run the assessment?

Annually for the full five-dimension scoring, with quarterly check-ins on the shortlisted use cases and the binding-constraint dimension. The technology changes fast enough that an assessment older than 12 months is using outdated assumptions about cost, capability, and regulation. The binding constraint also moves - an organisation that scored 1 on governance last year may have built the approval process and now have skills as the binding constraint. Treat readiness as a rolling capability measurement, not a one-time gate.

Does this methodology work for organisations under 50 employees?

The principles transfer but the process compresses. For a 20-50 person organisation, the assessment is closer to 3-5 days with 4-6 interviews. The five dimensions still apply, but the bar for each level is different - "reliable infrastructure" for a 30-person SaaS company means clean cloud deployment and basic CI/CD, not enterprise-grade platform engineering. The use case shortlist is usually two rather than three. The 90-day plan is more aggressive because smaller organisations can move faster. The biggest difference: skip the governance dimension as a formal score, replace with a single conversation about which decisions need human review.

Ready to scope an assessment for your organisation?

Further reading

Sources referenced for context not directly cited in the body:

Ready to put this into production? book a discovery call.

• Medical device stand-alone software including apps (MHRA guidance)