An AI readiness assessment settles one question before budget is committed: can this organisation, with the data, infrastructure, governance, skills and sponsorship it has today, carry the kind of AI it intends to adopt? The useful version scores each of those dimensions against the intended use rather than an abstract ideal, closes the weakest dimension first, and records the result as a dated snapshot that will not guarantee anything after launch. AI Singapore’s AI Readiness Index (AIRI) makes the same weakest-first point explicitly, and says its dimensions can only be unlocked with capability across all of them.
The stakes are not abstract. RAND’s 2024 study of AI project failure, based on interviews with 65 experienced AI engineers and researchers, notes that by some estimates more than 80 percent of AI projects fail, twice the rate of IT projects that do not involve AI. The same report cites a survey in which only 14 percent of organisations said they were fully ready to adopt AI, while 84 percent of business leaders expected AI to have a significant impact on their business.
How do I assess whether my organisation is ready to start an AI project at all?
Start from what you intend to do with AI, because the readiness you need depends on it. AIRI matches readiness levels to adoption approaches: organisations adopting commercially available solutions can sit at its lower levels, those integrating AI features such as cloud AI services into their products should be at “AI Ready”, and those developing customised AI solutions should reach “AI Competent”. AIRI also states that not every organisation needs its highest level, recommending AI Ready (Level 2) as the target for most.
With that target set, we would run the assessment in this order.
Readiness assessment procedure
- Name the adoption approach. Buying off-the-shelf, integrating hosted AI features and building custom models each set a different bar for skills and data, as AIRI’s level mapping shows.
- Confirm AI is the right tool. The UK Government’s 2025 AI Playbook tells teams to stay open to the conclusion that a problem may be more easily solved with established technologies.
- Inventory current capability. Microsoft’s Cloud Adoption Framework asks organisations to evaluate skills, data assets and infrastructure before planning, because projects fail when they go beyond the organisation’s technical maturity or data availability.
- Check governance prerequisites. The UK AI Playbook lists an AI strategy and adoption plan, AI principles, a governance board, a communication strategy, a sourcing and partnership strategy and training among the structures to establish.
- Score each dimension and find the weakest. Improvement effort goes to the weakest dimension first.
- Decide: start, start with conditions, or close gaps first. Write down which criteria are met and which are not, so the decision can be defended later whichever way it goes.
Where unready organisations lose the project
RAND’s root causes include models optimised for the wrong metrics or that do not fit the business workflow, organisations lacking the data to train an effective model, a focus on the latest technology over real user problems, and infrastructure inadequate to manage data and deploy finished models. We read each of those as an assumption nobody checked.
Data readiness assumed. Organisational alignment assumed. The AI team builds, the business unit doesn’t adopt, and the model was validated against the documented process rather than the real workflow. Infrastructure readiness assumed. The model is built before anyone confirms the deployment environment supports it.
All three surface at the most expensive moment: mid-project, with budget committed and expectations set. And when the project stalls, the failure is attributed to “AI doesn’t work” rather than to the readiness gap that caused it. We cover the broader pattern in why enterprise AI projects fail before reaching production.
Which pillars should a mid-size enterprise’s AI readiness assessment cover?
A mid-size enterprise’s assessment should cover six pillars: strategy, data, infrastructure, governance, talent and culture. One review finds enterprise frameworks usually score strategy, data, governance, talent and culture; Cisco’s assessment tool adds infrastructure as a sixth pillar. The academic work divides the space differently, and the differences are informative.
| Framework | Dimensions | Basis | What it adds |
|---|---|---|---|
| Jöhnk, Weißert and Wyrtki (BISE, 2021) | Five categories of readiness factors with actionable indicators | Interviews with 25 AI experts, triangulated with literature | Indicators tied to the specific adoption purpose, not a generic score |
| Holmström (Business Horizons, 2022) | Technologies, activities, boundaries, goals | Peer-reviewed framework | Treats readiness as sociotechnical, linked to digital transformation |
| AI Singapore AIRI v3.1 | Five pillars mapped to fifteen dimensions, each at five levels from AI Unaware (L0) to AI Catalyst (L4) | Hundreds of AISG engagements across industries and sizes | Weakest-first prioritisation and a recommended target level; open standard under CC BY 4.0 |
| Cisco AI Readiness Index (2025) | Strategy, Infrastructure, Data, Governance, Talent, Culture | 49 indicators, weighted Infrastructure 25%, Data 20%, Strategy, Governance and Talent 15% each, Culture 10% | Benchmark bands: Pacesetters, Chasers, Followers, Laggards |
| Microsoft AI readiness self-assessment | 45 questions across seven pillars, including Model Management | Vendor tool; no public scoring methodology | Five maturity stages from exploring to realising |
For a mid-size enterprise, we would take the six recurring pillars as the skeleton and borrow two things from the academic side: Jöhnk’s insistence that readiness is assessed for the individual adoption purpose, and AIRI’s weakest-first rule. A score against “AI in general” tells you little about whether the specific first project can succeed.
Which of those dimensions actually gate success?
No single pillar gates everything: AIRI describes its dimensions as synergistic and only unlocked with capability across all of them. Where dimensions tie, AIRI prioritises Leadership & Culture, then Ethics & Governance, Business Value, Data Foundation and finally Infrastructure & Standards. Cisco’s weighting puts infrastructure first, at 25%. AIRI’s order only breaks ties between equal scores, while Cisco’s percentages weight the overall score, so the two are not directly comparable.
Data readiness, with the numbers
A Gartner survey of 1,203 data management leaders in July 2024 found that 63 percent of organisations either do not have, or are unsure whether they have, the right data management practices for AI. Gartner predicts that through 2026, organisations will abandon 60 percent of AI projects unsupported by AI-ready data.
Gartner distinguishes AI-ready data from traditionally managed data. Gartner defines it as data representative of the use case, including the patterns, errors, outliers and unexpected cases needed to train or run the model, and notes that traditional data management leaves uses undocumented and data siloed, without the metadata needed to judge readiness. The UK AI Playbook adds the mechanism: insufficient data stops a model generalising, and poor-quality, biased or noisy data produces inaccurate outcomes.
The practical test is an inventory of data assets evaluated for the intended use cases. Microsoft’s Cloud Adoption Framework frames this inventory as what reveals data preparation needs and which use cases are feasible at all. Where labelled data is scarce, our note on when self-supervised learning fits your data covers which approach suits it.
Infrastructure and the serving envelope
Infrastructure readiness means compute, storage, network bandwidth and security controls sized for the target use cases, since infrastructure capacity constrains project scope and deployment strategy. Security belongs in this pillar from the start: the UK AI Playbook warns that tools used to train, host and operate models have been found lacking basic security features, and tells teams to check default configurations, enable authentication, avoid unneeded public endpoints and apply least privilege.
We cover what performance engineering research implies for AI readiness (p95/p99, throughput, cost).
Skills, culture and the capacity to absorb change
The UK AI Playbook describes a minimum viable AI team that can identify user needs, build and iterate, manage data ethically and securely, test with real users and support the live service through to retirement. It also notes that building bespoke models and using pre-trained models through APIs need different specialist skills, which is one more reason to fix the adoption approach before scoring talent.
Assessments rarely ask two culture questions. One is change capacity: whether the organisation can absorb AI on top of an ERP migration or reorganisation already competing for the same people. The other is trust: if users keep double-checking the model’s output, the tool adds a step instead of saving one. The people side of adoption is covered in depth in improving workforce engagement with AI through training and change management.
Choosing an AI governance framework a mid-size company can actually run
Governance readiness is a precondition for project start, not a programme to perfect first. The UK AI Playbook argues that AI programmes need strong governance because of risks around lawfulness, security, bias and data, and accepts that the processes can sit inside existing governance frameworks or a new one. The Playbook gives a choice between setting up an AI governance board and including AI experts on existing governance boards. Gartner describes enterprise governance of AI, a method for combining separate governance areas into responsible AI decisions.
We set the scope by separating three layers of governance.
| Layer | What it governs | Readiness question before start |
|---|---|---|
| Data governance | Legal and ethical use of data for AI | Is a data protection impact assessment done where personal data is involved, and is the data minimised? |
| Model governance | What is deployed, how it changes, how it is monitored | Is there a systems inventory, a managed release process with rollback, and drift monitoring? |
| Operational governance | Who decides, reviews and answers for outcomes | Is there a named accountable owner and a board or equivalent that authorises uses? |
The operational layer hides a gap that readiness scores almost never test. A project charter names an owner, but readiness questionnaires seldom ask whether that person has the authority to pull a drifting model out of production or approve its expansion. The same applies to accountability when a model is wrong: who reviews edge cases and who can overrule the system has to be settled before deployment, not improvised after the first bad decision.
We would not start a project until there is an accountable owner with real decision rights, a review route that can authorise the use, and the data-protection assessment the use requires. Principles, training resources and a mature inventory can follow; the UK AI Playbook states that adoption structures do not need to be fully mature before the first project, and that the first project will shape them.
What does an honest AI readiness assessment cover that a vendor-driven one doesn’t?
An honest assessment is allowed to conclude that the organisation should not start, or that AI is not the best solution. Free tools from Microsoft and Cisco can establish an organisational baseline in one to two hours. That is genuinely useful for a board conversation, and one independent review recommends them on exactly those terms, provided you discount each vendor’s product-line bias.
The bias is structural rather than dishonest. Microsoft’s tool outputs a Microsoft maturity score, may require tenant permissions, and has no published scoring methodology. Microsoft’s adoption planning guidance frames the infrastructure review partly as a way to select appropriate Azure services. Self-scoring also flatters: CloudBees reports that organisations self-assessed at an average of 83.6 out of 100 on its CARE score, a figure CloudBees itself contrasts with operational reality.
Readiness frameworks stop short of what happens after launch. One practitioner analysis argues that readiness frameworks measure whether you can build AI, not whether it will last, and lists the missing questions: who can kill or scale a model, whether it fits real rather than documented workflows, who keeps it accurate after month three, whether the organisation can absorb another change, whether users will trust it, and who owns a wrong outcome. A review of AI coding-tool rollouts describes the same result: the organisation scores “scaling” on a maturity questionnaire, the pilot launches, and six months later the initiative stalls.
What does an AI readiness checklist actually contain?
A working checklist asks for names, documents and dates, not self-ratings. One analysis proposes this pressure test directly: if a readiness question cannot be answered with a specific name, process or date, it is a blind spot rather than a strong score.
Pre-project readiness checklist
- Purpose: the adoption approach (buy, integrate, build) is written down with the readiness level AIRI maps to it.
- Problem fit: goals, user needs and the case for AI over established techniques are stated.
- Data: an inventory of data assets for the first use case, with quality and representativeness assessed.
- Infrastructure: compute, storage, network and security controls reviewed against the target use case.
- Tooling security: authentication enabled, no unneeded public endpoints, least privilege applied to ML tools.
- Skills: the team can design, build, test, run and retire the service, or the sourcing route for missing skills is decided.
- Accountability: a senior responsible owner named, with decision rights to stop or scale the model.
- Review route: a governance board, or AI expertise on an existing board, authorises the use.
- Data protection: a DPIA completed where the use triggers one.
- Operations: monitoring, managed release with rollback, and ownership of drift agreed.
- Fallback: a process to keep critical services running if the AI system is withdrawn.
- Change capacity: competing initiatives listed and the adopting team’s capacity confirmed.
The difference from a vendor’s self-assessment tool is the unit of evidence: a tool returns a score and a stage, while this checklist returns artefacts someone can inspect.
How is organisational readiness sequenced before per-use-case feasibility?
Organisational readiness comes first, and per-use-case feasibility second. Microsoft’s Cloud Adoption Framework follows the same order: assess skills, data and infrastructure, then evaluate each use case against current maturity, data availability, technical infrastructure and staffing. Running feasibility first produces a promising use case that the organisation cannot carry; running readiness first tells you which use cases are worth testing. Once readiness is established, the next filter is whether a specific generative AI use case is technically feasible.
The assessment should also sort gaps by timing, because not every gap blocks the start. Our split, offered as judgement:
- Fix before the project starts: data access and representativeness for the first use case, an accountable owner with decision rights, the data-protection assessment the use requires, security baselines on the ML toolchain, and a clear goal with a sponsor behind it.
- Fix during the first project: AI principles, a training programme, a communication strategy, a use-case register and a full systems inventory. The UK AI Playbook supports this sequencing, noting that adoption structures need not be mature before the first project and will be shaped by it.
The readiness bar moves with the adoption approach. AIRI sets a lower readiness target for an organisation integrating a hosted AI feature than for one building custom models.
How does AI readiness for an agent deployment differ from traditional ML?
Agent readiness uses the same pillars, but each one carries extra load because the system acts as well as predicts. Microsoft’s agentic AI maturity model states that autonomous decision-making, multistep orchestration and human-agent collaboration require a new enterprise operating model, and assesses five pillars (AI strategy and experience, business strategy, AI governance and security, technology and data, organisation and culture) across five levels. The UK AI Playbook makes the risk point plainly: the scale of an AI service’s autonomy can increase operational risk.
One evidential caution: RAND excluded projects that simply used pretrained large language models through prompting, so its failure findings do not speak directly to prompt-based agents. The MAP study by Pan et al. surveyed 86 practitioners with deployed agent systems across 26 domains and ran 20 case studies. It found that 68 percent of production agents execute at most 10 steps before human intervention, 70 percent rely on prompting off-the-shelf models rather than weight tuning, 74 percent depend primarily on human evaluation, and reliability (consistent correct behaviour over time) is the top development challenge.
Read as readiness criteria, that evidence adds three specialisations.
Agent runtime constraints. We would fix in advance how many steps an agent takes before a human checks it, and who reviews, since MAP finds most production agents stop within 10 steps and rely on human evaluation. Reliability over time becomes an operational requirement, not a launch metric.
Tool-integration risk. Every tool an agent can call is an access path, so we would apply the toolchain security baseline (authentication, no unneeded endpoints, least privilege) to each integration. Agents built on text prompts also inherit prompt injection, where crafted input makes a generative model behave in unexpected ways.
Additional data governance. Using your own data with a model raises data security risk, and the UK AI Playbook lists the questions to answer: where the data is sent and processed, whether it trains future models, how long it is retained, and who can read the logs. For an agent that reads and writes across systems, those questions apply to every system it touches.
Who can run an AI readiness assessment that holds up at review?
TechnoLynx’s AI Readiness Scorecard scores your AI programme against a named published rubric such as NIST AI RMF, with an evidence trail and a remediation backlog. The point of the structure is that the decision stays defensible either way: at any later review you can show which readiness criteria were met, which were not, and why the start decision was made. Our AI engineering services describe how that first step leads into delivery.
It is not the right route for everyone. If you need a quick board-level baseline, a free vendor self-assessment does that in hours, with its bias discounted.
When the assessment needs running again
A readiness assessment ages. We would treat it as void after any of the changes that alter its inputs: a different adoption approach, a new data source, a move to agentic autonomy, or a reorganisation that changes who holds decision rights. The question the assessment cannot settle on its own is durability, whether the owner, monitoring and user trust it recorded at the start will still be in place a quarter after launch, and that is the part worth checking again first.
FAQ
What are the three pillars of AI readiness?
None of the frameworks reviewed here uses three pillars. Published frameworks use four to seven: Holmström uses four (technologies, activities, boundaries, goals), AIRI five, Cisco six and Microsoft’s self-assessment seven.
What is the major benefit of a ready-to-use cloud AI vendor service?
By AIRI’s mapping, adopting commercially available solutions can start at AI Unaware or AI Aware, integrating cloud AI services into products calls for AI Ready, and building custom models calls for AI Competent.
