AI Readiness for Enterprises: Assessment, Strategy & Roadmap

• AI readiness spans four separate things: your data, your infrastructure, your operating model, and your governance. They fail independently.
• Score each of the four from one to five. The lowest score, not the average, is what an AI programme can actually support.
• What stops enterprise AI is almost always organisational rather than technical. Access to compute is rarely the real constraint.
• Governance work produces no demo, so it gets deferred, and it is the most common reason a finished AI system never launches.
• An AI readiness assessment takes three to six weeks and costs between $15k and $45k for most enterprises.
• One AI system in production inside twelve months is realistic for most enterprises. Five systems in twelve months is not.

Enterprise AI readiness sits on most 2026 board agendas, and a large share of the assessments being run measure the wrong thing. Teams score their infrastructure, find it adequate, green-light a pilot, and watch it die eleven months later in a legal review nobody had scheduled. The infrastructure was never the problem.

Getting this wrong is expensive in a specific way. A pilot that fails on technology fails fast and cheap, usually inside a quarter. A pilot that fails on readiness fails slowly: it clears the demo, gets a budget line, absorbs a year of a good team's attention, and collapses at the point where it has to touch real customers, real records, or real regulated decisions. By then you've spent the money and lost the internal appetite to try again.

This guide is for the CIO or CDO being asked to sponsor an AI programme, the architect scoping the first use case, and anyone who has to defend an AI budget to a CFO who has already read one sceptical headline this month.

AI readiness is the state in which your data, infrastructure, operating model, and governance can support an AI system running in production against real business decisions, not just a demo running against a curated sample.

The distinction matters because the demo is easy now. Foundation models are a commodity, the APIs are excellent, and a competent engineer can build something impressive against a clean extract in a fortnight. What's hard is everything that happens after: keeping the data fresh, keeping the outputs monitored, keeping a human accountable for the decision, and keeping the whole thing running when the person who built it moves teams.

So business AI readiness is best understood as a question about production, not capability. Not "can we build this" but "can we run this, on live data, under our own audit and compliance rules, for three years."

The gap between those two questions is where most enterprise AI money currently goes. McKinsey's State of AI survey, covering 1,993 respondents across 105 countries in mid-2025, found that nearly two-thirds of organisations had not yet begun scaling AI across the enterprise, and only 39 percent reported any EBIT impact at the enterprise level at all. Adoption is close to universal. Production is not.

Organizational AI readiness is also not a single score, which is the most common way readiness assessments mislead the people commissioning them. A composite number averaging four dimensions hides exactly the information you needed, because the dimensions don't average in reality. They gate each other.

Readiness splits into four dimensions, and they fail independently. An enterprise can have excellent data and no governance, or excellent governance and no usable data, and both of those organisations will fail at the same point in the programme for entirely different reasons.

Note: these ranges come from Classic Informatics scoping conversations across enterprise engagements, stated in US dollars, and they move considerably with portfolio size and regulatory exposure. Treat them as planning bands, not quotes. A single-market mid-market business will sit at the bottom of every range; a multi-entity regulated group will sit above the top of several.

Four dimensions is also the shape most AI readiness framework and AI adoption framework models converge on, though the labels differ. What follows uses the same four labels for each dimension so you can compare them directly.

Data readiness

What it covers: whether the data an AI system needs exists, is accessible, is accurate enough to reason over, and has an owner accountable for keeping it that way.

What ready looks like: the data for your intended use case lives somewhere queryable, refreshes on a known schedule, and has a named owner. Lineage is documented well enough that when an output looks wrong, somebody can trace it back within a day.

Where it usually breaks: the data exists and nobody owns its quality. Every enterprise we assess has the records. Far fewer have anyone whose job description includes whether those records are right. That's a data governance framework problem long before it's an AI problem, and it's why data quality management work usually front-loads an AI programme rather than running alongside it. Data readiness for AI is an ownership question far more than a volume one.

Decision signal: if you can name the owner of your three most important datasets and they can tell you the refresh cadence without checking, start the AI work. If you can't, spend the next two quarters on data ownership before you spend anything on models.

That pattern is easiest to see where the data was never in a system to begin with. When Classic Informatics replaced Austin Engineering's steel planning process, the inputs were sitting in four disconnected facility spreadsheets that each told a slightly different story about available stock. Building a cloud-based steel resource planning platform integrated with Airtable and NetSuite gave them an 18-month rolling shortage forecast, but the forecast only became possible once the four versions of the truth became one.

Infrastructure readiness

What it covers: the platform, pipelines, environments, monitoring, and deployment path that carry a model from a developer's machine into production and keep it observable there.

What ready looks like: you have somewhere to deploy that isn't a laptop, a way to version what's deployed, and monitoring that would tell you if outputs degraded. Access to compute matters less than people expect, because most enterprise use cases run against hosted models rather than trained ones.

Where it usually breaks: there's no path from notebook to production. The data science function builds in one environment, the platform team runs another, and nothing crosses between them without a bespoke project. That's an AI integration problem, and it's the reason capable teams ship demos for two years without shipping a system. AI infrastructure at this stage means less compute than most teams expect and more deployment path than any of them budget for.

Decision signal: if a model your team built could be deployed, monitored, and rolled back by someone who didn't build it, your infrastructure is ready enough. If deployment depends on one named person, fix that before scoping a use case.

Operating model and people readiness

What it covers: whether the organisation can absorb a change in how a decision gets made, and whether the people whose work changes have been given a reason to want it to.

What ready looks like: the process you're targeting has a business owner who wants the change, not just an IT sponsor who was told to deliver it. Someone has decided what happens to the time the AI saves. The team affected has heard about it from their own manager rather than from a launch email.

Where it usually breaks: a technical sponsor with no business owner. This is the single most common readiness gap we see, and it's invisible in every infrastructure-led assessment, because nothing about it shows up in a systems review.

Decision signal: if you can name the business leader whose numbers improve when this works, proceed. If the only person who wants it is the person building it, stop and find the owner first.

Governance and risk readiness

What it covers: the policies, approval routes, documentation, monitoring, and accountability that let an AI system pass legal, compliance, and procurement review and stay compliant afterwards.

What ready looks like: you have an inventory of where AI is already in use, a route by which a new system gets approved, and a named human accountable for each automated decision. An AI governance framework doesn't need to be elaborate to be real, but it does need to exist before launch rather than during it.

Where it usually breaks: it gets deferred until procurement blocks the launch. Governance is the dimension teams postpone because it produces no demo, and it's the dimension that most reliably stops a finished system from going live.

Decision signal: if you can produce a list of every AI system currently touching customer or employee data, you're ready to build the rest of the governance layer. If that list doesn't exist, build the inventory this quarter regardless of what else you do.

Score each of the four dimensions from 1 to 5, weight them against what your first use case actually depends on, and then treat the lowest score as your ceiling rather than averaging it away.

An AI readiness assessment, sometimes run as an AI readiness audit where the emphasis is on evidence rather than planning, is a three-to-six-week exercise for most enterprises. It involves interviews with the data owners, a look at the deployment path, a conversation with the business owner of the target process, and a review of whatever governance already exists. It doesn't require a tool, and the ones that produce a single composite number are actively unhelpful.

Weighting matters because use cases depend on the dimensions unevenly. An internal document search tool leans almost entirely on data and infrastructure and barely touches governance. A model influencing credit decisions or hiring inverts that completely. Weight each dimension by how much your intended first use case depends on it, then score.

The readiness floor is your lowest-scoring dimension, and it caps the programme. A business scoring 5 on data, 5 on infrastructure, 4 on operating model and 1 on governance is not an average of 3.75. It's a 1, because the governance gap will stop the system going live no matter how good the other three are. This is the single most useful output of a readiness assessment and it's the one a composite score destroys.

What your floor permits:

• Floor at 1. No production use case. Spend two quarters closing the floor before anything else.
• Floor at 2. Six to twelve months of foundation work first. A sandboxed internal pilot is reasonable in parallel, provided nobody calls it a production plan.
• Floor at 3. One production use case, narrowly scoped, in a low-consequence process.
• Floor at 4. Scale within a single function. Multi-function scale is still premature.
• Floor at 5. Embed. At this point the constraint is use-case supply rather than readiness.

Two honest limits on this model. It tells you what you can support, not what's worth doing, and those are different questions — a business with a floor of 4 and no valuable use case is in a worse position than one with a floor of 2 and an obvious one. And it assumes your first use case is representative. If you plan to start somewhere trivial and scale somewhere regulated, score against the regulated case, because that's where the floor will actually bite.

In our experience the assessment phase is underscoped by roughly a factor of two, almost always because the governance interviews get skipped. An AI readiness checklist helps here, but only if it scores rather than ticks. The output of an AI readiness assessment should be a number per dimension, not a list of yes and no answers.

That combination of near-universal adoption and rare production impact is what the McKinsey research describes as the scaling gap. Roughly 6 percent of organisations in that survey qualified as high performers attributing more than 5 percent of EBIT to AI. The rest weren't short of models. They were short of floor.

Five stages, running from ad hoc experimentation to AI embedded in how the business operates. Readiness tells you what you can support today. Maturity tells you where you sit on the path, which is a different and slower-moving thing.

Note: maturity models for AI vary considerably between vendors and analysts, and several use six or seven stages. This is a practical five-stage version tuned to what distinguishes enterprises in delivery, rather than an attempt to reproduce any single published model.

Most enterprises reading this are at stage 2, and a meaningful number who believe they're at stage 3 are at stage 1 with a stage 3 slide deck. The tell is shadow usage. If your people are using consumer AI tools for real work and you don't have an inventory of it, you're at stage 1 regardless of what your funded pilots are doing, because the ungoverned usage is the larger surface.

The jump that costs the most is 2 to 3, and it costs more than teams plan for because it's the first stage where the work stops being interesting. Getting one system to survive twelve months in production means monitoring, retraining, on-call ownership, and a documented rollback. None of it demos well. All of it is the difference between a pilot and a system.

The jump people underestimate in the other direction is 3 to 4. Once one system is genuinely in production, the second and third are dramatically cheaper, because the deploy path, the governance route, and the monitoring already exist. Enterprises that budget linearly across three use cases consistently overspend on two and three.

Positioning yourself honestly against an AI maturity model is most of the value here. The stage you claim matters far less than the stage your ungoverned usage puts you in.

Pilots fail on three named patterns, and all three are organisational rather than technical.

The headline numbers are worth holding lightly but not dismissing. MIT's NANDA initiative, in research covering 300 public deployments, 150 executive interviews, and a survey of 350 employees, found that around 95 percent of enterprise generative AI pilots produced no measurable P&L impact. Gartner reports that at least half of generative AI projects were abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, escalating costs, and unclear business value. Both figures have been argued about, and both are directionally consistent with what we see: the demo works, the system doesn't ship.

The unowned pilot

What it looks like: the project has an enthusiastic technical sponsor, a budget, and no business leader whose targets improve if it works. Progress reviews are attended by the delivery team and nobody else.

Why it happens: AI budgets frequently originate in IT or innovation functions rather than in the business unit whose process is being changed. The funding route determines the ownership, and innovation funding produces innovation ownership.

How to fix it: refuse to start until a named business owner has agreed a metric. Not a steering group. One person, one number.

The bolt-on workflow

What it looks like: the AI is added to an existing process without changing the process. A summary appears in a field somebody already had to read. Time saved is real and small, and it never reaches the P&L.

Why it happens: redesigning a workflow requires authority over the people doing the work, which the delivery team doesn't have. Layering on top requires nobody's permission, so that's what gets built.

How to fix it: treat workflow redesign as in scope from the start, and budget for it. Where enterprises do report enterprise-level impact, redesign is consistently the differentiator rather than model choice.

The deferred governance bill

What it looks like: the system is finished, demoed, and approved by the business. Then legal asks how decisions are logged, procurement asks about the model provider's data handling, and the launch slips two quarters.

Why it happens: governance produces no visible progress, so it loses every scheduling argument against features. The bill doesn't disappear. It just arrives at the worst possible moment.

How to fix it: start the inventory and approval route in parallel with the build, not after it. The cost is the same. The timing is what kills you.

The pattern underneath all three is that the failure mode is organisational and the assessment that preceded it was technical. The broader adoption picture sits in AI adoption statistics.

Sequence the roadmap around your readiness floor, not around the use case with the best demo.

That's the whole principle, and it inverts how most AI roadmaps get built. The usual sequence is: pick the highest-value use case, scope it, discover the readiness gap, then spend the project budget on foundation work while explaining the delay. The better sequence is: identify the floor, cost the work to raise it, and pick a first use case that your current floor can actually carry.

A workable enterprise AI strategy has four moving parts, and they run partly in parallel. Together they're the whole of your AI implementation strategy for year one.

Raise the floor first. Whatever your lowest dimension is, that work starts immediately and independently of any use case. It has its own budget line and its own owner. If it's bundled into a use-case project, it will be cut when that project runs late.

Pick a first use case your floor supports. Narrow, low-consequence, with a business owner who wants it. Resist the temptation to start with the case that would impress the board, because that case almost always sits in a regulated or customer-facing process where the floor bites hardest.

Build the path, not just the thing. The first use case should leave behind a deploy route, a monitoring approach, and a governance decision that the second one reuses. If it doesn't, you've bought a system rather than a capability, and the second one will cost the same as the first.

Sequence the second and third before the first ships. Not to build them, but to make sure the path you're laying suits them. A first use case optimised in isolation frequently produces infrastructure choices the next two can't use.

On timing: a first production use case inside twelve months is achievable for most enterprises starting from a floor of 3. From a floor of 2, eighteen months is realistic and twelve is optimistic. From a floor of 1, the first year is foundation work and the honest roadmap says so.

This is also where picking the right process matters more than picking the right model. A global industrial manufacturer we've worked with for eight years across multi-site operations got its clearest automation return from sales order processing, cutting processing time by 60 percent with no post-launch errors, because the process was high-volume, rule-heavy, and had an owner who wanted it changed. None of those three qualities are about AI. All three are why it worked.

The delivery-side view of this sequencing sits in how to implement AI in business.

Readiness work runs in bands, and the assessment itself is the cheapest part of it by a wide margin.

Three separate costs get conflated in most AI budget conversations, and separating them is the first useful thing a finance conversation can do:

• The assessment. Three to six weeks. $15k–$45k for most enterprises, more where the portfolio spans multiple entities or regulated markets.
• The readiness work. Whatever it takes to raise your floor. This is the large and variable number, and it's in the dimension table earlier in this guide.
• The AI build. The use case itself, which is usually the smallest of the three and the only one anybody budgets for at the start.

For context on the upper end, Gartner has put generative AI deployment costs in the $5 million to $20 million range for organisations pursuing business model change rather than process improvement. That's a different order of ambition from a first production use case, and quoting it in a first-year budget conversation tends to end the conversation.

The ratio worth planning around is that readiness work typically costs somewhere between one and three times the first use case it enables. That sounds bad until you compare it against the alternative, which is discovering the same gap eleven months in, having already spent the use-case budget.

One caveat on all of these. They're planning bands in US dollars, drawn from scoping conversations rather than a price list, and rounded to sensible increments rather than converted at a spot rate. The variable that moves them most isn't company size. It's how much of the data work has already been done for reasons unrelated to AI. Enterprises that invested in a data strategy three years ago consistently land at the bottom of every band.

Governance is the dimension most often deferred and the one regulators reached first, which is an uncomfortable combination for anyone planning a 2027 launch.

The regulatory position changed recently enough that most published guidance is now wrong. The EU's Digital Omnibus on AI entered into force on 27 July 2026, and the Council of the EU confirmed new application dates of 2 December 2027 for stand-alone high-risk AI systems under Annex III and 2 August 2028 for high-risk AI embedded in regulated products. The high-risk deadline that had been sitting at 2 August 2026 moved by sixteen months.

What did not move is the part most enterprises will actually touch. The Article 50 transparency obligations applied from 2 August 2026 as originally scheduled: telling people when they're interacting with an AI system, and labelling AI-generated content. The prohibited-practices regime has been in force since February 2025, and the general-purpose AI provider obligations since August 2025. Reading "the EU delayed the AI Act" as "nothing applies yet" is the expensive version of this mistake.

The practical implication is that the sixteen-month deferral buys preparation time rather than relief. The hard part of AI Act compliance was never the documentation template. It's building an inventory of every AI system in the organisation and keeping it current as new ones ship, and that work takes the same amount of time whenever you start it.

For the framework layer underneath the law, the NIST AI Risk Management Framework remains the most widely used structure, organised around four functions: Govern, Map, Measure, and Manage. It's voluntary and non-certifiable, which is precisely why it's useful as an internal operating model rather than a compliance artefact. The function enterprises consistently skip is Measure, because it needs monitoring data that the infrastructure dimension was supposed to provide. That's the two dimensions gating each other, visible in the wild.

Three things worth doing before any launch, in this order: build the inventory, define who approves a new AI system and on what evidence, and name a human accountable for each automated decision. None of them require legal counsel to start. All of them take longer than anyone expects. The adjacent discipline, and a workable template for the approval route itself, is technology risk management.

• Score four dimensions separately. Never average them.
• Treat your lowest score as the ceiling on the whole programme.
• Fund floor-raising as its own line item, not inside a use-case project.
• Refuse to start a use case without a named business owner and a number.
• Budget for workflow redesign, or expect the value to stay at the use-case level.
• Start the AI inventory this quarter regardless of what else you do.
• Pick a first use case your current floor supports, not the one that demos best.
• Assume the second use case costs a fraction of the first, if you built a path.
• Score against your most regulated intended use case, not your easiest one.
• Expect assessment to be underscoped by half. Add the governance interviews back.

AI readiness isn't a technology question with a technology answer, which is why so many enterprises pass their own assessment and then fail their own pilot. The four dimensions fail independently, the lowest one caps everything above it, and the one that stops the most finished systems from going live is the one that produces no demo and therefore never wins a scheduling argument.

The practical move is unglamorous. Score the four dimensions honestly, find the floor, fund raising it separately from any use case, and pick a first project the current floor can actually carry. Enterprises that do this reach one production system in about a year and their second one for a fraction of the cost. Enterprises that skip it reach a very good demo.

Classic Informatics has been building the systems underneath decisions like these for a couple of decades, and the readiness conversation is usually the shortest part of an engagement and the part that changes the plan most. If you want a second pair of eyes on where your floor actually sits, we're happy to look at it with you.