The AI Strategy Guide logo The AI Strategy Guide at the cusp of AI Subscribe →
Enterprise AI Readiness Assessment: The Four-Page Version — Capabilities illustration

Enterprise AI Readiness Assessment: The Four-Page Version

Tom Prommer · CIO/CTOUpdated 2026-05-2911 min read

I sat in a board meeting in November 2024 where a CIO presented a 78-page AI readiness assessment her organisation had paid €240,000 for. The board read the executive summary, asked four questions, and the four answers were already in the summary. The remaining 74 pages were appendices nobody opened. Six months later, the strategy that assessment was supposed to inform shipped with three workstreams; two of them ran into the same readiness cliff the assessment had flagged at page 47, in a section nobody had read. The cliff was data accessibility — specifically, the customer-data warehouse that the strategy assumed was queryable was technically queryable but operationally six weeks behind on every refresh cycle. The assessment knew. The strategy did not. The €240,000 had been spent producing a document, not producing a decision.

This is the structural problem with the readiness-assessment category. The artefact has become the deliverable. The artefact is not the deliverable. The decision the assessment produces — go, no-go, go-but-cut-this — is the deliverable, and the four pages it takes to write that decision are the right length for it. Everything beyond those four pages is either evidence (which belongs in an appendix nobody reads, but should still exist) or padding (which belongs nowhere).

This page is the four-page assessment, expanded with the working notes for each section and the scoring sheet I use. The expansion is so you can run it yourself, or audit one your team has produced. The compressed version still fits on four pages and is, in my experience, sufficient to gate a €4M-to-€40M AI programme. If you spent more than that on the assessment itself, you bought the wrong product.

The four pages

The four pages cover four diagnostic areas, in this order. The order matters: each section’s answer constrains the next. Treating them as independent (which the 60-page version usually does, because the consulting team is structured into siloed workstreams) produces a maturity Christmas tree. Treating them as sequenced produces a project plan.

Page one: data accessibility. Not data quality. Not data volume. Data accessibility. Specifically: can the engineering team query the data the strategy assumes it will use, at the freshness the strategy assumes, with the join paths the strategy assumes, under the access controls the strategy assumes, today. The Christmas-tree version of this assessment scores “data maturity” on a five-point scale and shades it green. The useful version names the three datasets the strategy is most likely to require — typically a customer record, a product or transaction record, and a behavioural or telemetry stream — and answers four sub-questions per dataset.

Where does it live, in what system, owned by which team. What is the actual refresh cadence, measured in days from event to availability for analytic use. What are the join keys to the other two datasets, and do the join keys reliably exist for at least 95% of the rows. Who has technical authority to grant query access, and what is the procurement lead time to add a new system to the access list. If any of those four answers is “we’d have to find out”, the readiness gap is real and the strategy needs to either descope around it or include a remediation workstream that pushes the user-facing capability six to nine months out.

The pattern I have seen most often: the data is technically present but operationally inaccessible because the join keys are dirty, the refresh is stale, or the access path requires a quarterly access-review cycle the strategy timeline does not accommodate. Customer-data governance tooling — the procurement category that has been growing fastest in this adjacency — is downstream of this finding. Buy the tooling after the assessment names the specific gap, not before.

Page two: the operating-budget transition path. This is the question the root hub called the most expensive transition an AI programme makes — moving capability from discretionary funding (paid by marketing, IT, or a CEO innovation budget) to operating funding (part of the year-on-year cost base). Most enterprise AI capabilities in 2026 still live in discretionary budgets, paid for by money the CFO has labelled “experimental” and has the option to cut at any quarterly review. The strategy that assumes the discretionary budget will keep flowing is a strategy that has not stress-tested its own funding model.

The page answers three questions. What is the realistic operating-budget envelope this capability would consume at steady state, including model inference costs at projected utilisation, the engineering headcount to maintain it, and the platform and observability spend underneath it. Who is the budget owner in the steady-state world — usually a business unit P&L owner, sometimes a shared-service function, occasionally the CIO directly. What is the path from the current discretionary funding to that owner’s budget, with named milestones (typically: pilot, expanded pilot, business-case approval, budget transfer at the next planning cycle).

The cliff the page surfaces is the moment when the discretionary budget runs out before the operating budget arrives. This is the moment most AI programmes either fail or quietly transform into an engineering hobby with no business owner. The page exists to make the cliff visible before the strategy commits to a timeline that runs the team off it.

Page three: governance maturity, for the specific risk profile of the proposed capability. Not generic governance maturity. The capability-specific kind. The Christmas-tree version of governance maturity assesses the organisation against a 40-point checklist of policies, committees, and frameworks. The useful version asks: given the risk profile of the specific capability the strategy will deliver, can the organisation execute the four governance artefacts the CISO governance piece names — the model inventory, the deployment gate, the incident-response runbook, the red-team evidence log — at the cadence the capability requires.

For a high-risk customer-facing capability (a credit-decision model, an agentic customer-service assistant, a recruitment-screening tool), the cadence is quarterly red-teaming, weekly deployment gating, and 24/7 incident-response readiness. For an internal productivity capability, the cadence is annual or semi-annual on most artefacts. The mismatch between the capability’s required cadence and the organisation’s existing cadence is the gap to name. If the strategy proposes a high-risk capability and the organisation has no incident-response runbook for any AI system today, the gap is six to nine months of governance-build work that has to either precede the capability launch or run in parallel under a defined risk acceptance.

The EU AI Act’s August 2026 deadline for high-risk systems — Article 6 in combination with Annex III of Regulation (EU) 2024/1689 — makes this section more load-bearing than it was a year ago. An assessment in mid-2026 that does not explicitly answer “is this capability in scope for Annex III, and if so are we on the Act’s documentation timeline” is incomplete; it is just optimistic.

Page four: the engineering organisation’s current capacity to deliver. Not headcount. Not skills inventory. Capacity, measured as: of the engineering organisation’s available delivery throughput in the next two quarters, what fraction is realistically uncommitted, and what fraction of that uncommitted slice is available to AI work versus the rest of the strategic roadmap. Most organisations claim 30%, deliver against the AI strategy at about 8%, and are surprised when the strategy slips.

The page answers four questions. What is the current committed throughput (the existing roadmap, regulatory work, technical-debt service, on-call burden). What is the uncommitted throughput, and how is it currently allocated across competing priorities. What named senior engineers — by name, not by team — would lead each AI workstream the strategy proposes. What is the cost of pulling those people off their current commitments, expressed as the work that would slip.

The honest answer to this page is uncomfortable. Most organisations discover, when forced to name the engineers, that the AI strategy is built on the implicit assumption that the same five senior engineers will lead every new initiative, and those five are already at 110% commitment on the existing roadmap. The strategy that does not surface this discovery is the strategy that will slip its first milestone in month three, and the cost of that slip will be charged to “AI capability” rather than to the prior over-commitment that caused it.

The scoring rubric

Each page gets a single rating: green, amber, or red. The rubric is deliberately simple because the Christmas-tree version of rubric design (five-point scales across forty criteria) is what produces the assessment-as-artefact failure mode this whole piece is about.

Green means: the strategy can proceed as scoped, with normal program-management oversight. Amber means: the strategy can proceed if specific named remediation work is added in parallel, with a clear owner and a clear deadline that lines up with the capability launch. Red means: the strategy cannot proceed as currently scoped; either the capability is descoped or the prerequisite work is added as a separate funded workstream that precedes the capability launch.

Two reds anywhere in the four pages should stop the strategy. One red plus two ambers should reshape it. Four greens, in my experience, almost never happens honestly; it usually means the assessment did not look hard enough.

The recommended cadence for the assessment is annual at minimum, plus a refresh whenever the strategy adds or substantially modifies a capability. A pre-strategy version (one focused day) is the right input to the strategy document work. A post-strategy version (one focused week) is the right input to the budget approval.

What the question most assessments do not answer

The four pages above answer abstract readiness in a way that, if you do them honestly, is genuinely sufficient for most strategies. But there is a fifth question that the best assessments ask and the most produce-no-decision ones do not.

The question is: where would we be unready if we tried to ship Capability X in nine months. Pick the specific capability the strategy is most likely to require — an agentic customer-service assistant, a code-generation copilot for the engineering organisation, a credit-decision model, a knowledge-management retrieval system — and locate the cliffs for that build specifically. The abstract version of readiness scoring produces a four-page document with three ambers and a green. The specific version produces a list of seven concrete blockers with named owners and approximate remediation cost. The first is an artefact. The second is a project plan. The second is what the executive sponsor needs.

This is the move that distinguishes assessment-as-decision from assessment-as-document. It also distinguishes the four-page version from the 60-page consultancy version, because the consultancy version is structurally biased toward generality (it has to be reusable for the next client), and the operator version is structurally biased toward specificity (it has to be useful for this decision, this quarter).

The consultancy version, and why it costs €200k

The consultancy version of this work is not stupid. The frameworks are real, the consultants are competent, and the document, if you read it carefully, will mention every issue the four-page version names. The problem is structural, not intellectual. The consultancy bills by the engagement, and the engagement is sized to produce a deck the steering committee can present at the next board meeting. The deck has to look comprehensive. Looking comprehensive requires forty pages of context, methodology, and benchmarking. The forty pages of padding are not useless to the consultancy — they are the artefact the next client will see in the sales process — but they are useless to the decision the current client is trying to make.

Past that, the consultancy version is timed against the consultancy’s delivery schedule, not the strategy’s decision deadline. The 60-page deck arrives a quarter after the engagement starts. The strategy decision the assessment was supposed to inform was due last month. The deck becomes a retrospective justification for a decision already made, which is the worst possible outcome for the original purpose.

Do the four-page version yourself, with one experienced fractional advisor if you need an outside read, in two to four weeks. Use the consultancy version only if the regulator or the auditor specifically requires the longer artefact for filing purposes. In that case, commission the long version after the short one has driven the decision; the long version is then a documentation exercise rather than a deliberation one, and it costs less because it is being filled in against an existing answer rather than producing one.

The honest signal of a useful readiness assessment is that it changes the strategy document. The signal of a useless one is that it gets cited in the strategy’s footnotes and otherwise ignored. The four-page version is short enough that the strategy author cannot avoid reading it. That is most of why it works.

Sources

The four-page assessment template and the green/amber/red rubric are CC-BY-4.0 and linked from the capabilities hub. Fork it, change the criteria, publish a variant with different cliffs for your sector and send me the link; I will reference it from the next refresh. Methodology: criteria drawn from fractional CTO and CIO engagements (2023-2026) where the assessment either preceded the strategy and the strategy shipped, or did not precede the strategy and the strategy slipped. The pattern is consistent enough to publish.

Frequently asked questions

How long should an enterprise AI readiness assessment actually take?
Two to four weeks of calendar time, two to four days of focused effort. The four-page output is small; the work behind it is mostly interview-and-data-extraction. The 60-page consultancy version takes a quarter because it has to justify the invoice, not because the underlying question takes a quarter to answer. If your assessment is taking longer than a month, somebody is running scope creep against you.
Should the readiness assessment happen before or after the strategy document?
Before. Or, more precisely: a draft assessment before, a refined one after. The strategy document asks four questions — posture, cost ceiling, timeline, failure tolerance — and the readiness assessment answers a fifth that constrains all of them: what can you actually execute on. Writing the strategy without that constraint produces a document that assumes capabilities you do not have. The right sequence is a one-day pre-strategy readiness scan, then the strategy, then a refined assessment against the approved scope.
Who should run the assessment?
One person, accountable, who has seen the inside of more than one organisation's AI programme. A fractional advisor, an internal head-of-data who has run a comparable transition, or in rare cases the CIO directly. The role to avoid is the consultancy team of six who will produce the 60-page deck. The role to also avoid is the new hire who has read the McKinsey report but has never executed against a real operating budget. Specifically: the assessment should be done by somebody who has cut a workstream before.
What is the question most readiness assessments do not answer?
Where would we be unready if we tried to ship Capability X in nine months. Generic readiness assessments produce abstract scores against abstract capabilities. Useful ones name a specific capability the strategy is likely to require — an agentic customer-service assistant, a credit-decision model, an internal copilot for engineering — and locate the cliffs for that specific build. The abstract version produces a maturity-grid Christmas tree. The specific version produces a project plan.