A mid-size manufacturer signs off on an AI defect-detection project. Six weeks in, the team discovers the production images were never labelled consistently, the deployment edge boxes can’t run the model, and the line supervisors were never asked whether they’d act on the alerts. Budget is committed. Expectations are set. The project stalls — and the post-mortem records the cause as “AI doesn’t work,” when the real cause was that the organisation was never ready to run the project at all. This is the most expensive way to discover a readiness gap: mid-project, after money and credibility are already spent. The assessment that would have surfaced every one of those blockers — inconsistent data, an incompatible deployment target, an unaligned business unit — costs a fraction of the project it precedes. The question this article answers is narrow and deliberate: is the organisation ready to run an AI project at all? Not whether a specific use case is technically feasible — that is a separate, downstream question — but whether the preconditions exist for any AI project to succeed. What an AI Readiness Assessment Actually Asks Readiness is not a single property. It is a set of preconditions across five dimensions, and a gap in any one of them can stall a project that looks healthy on every other axis. The three failure patterns we see most often each map to a dimension that was assumed rather than verified. The first is data readiness assumed. The team scopes a model against the data they believe exists. No one audits the production data until training starts, at which point the labels turn out to be inconsistent, the historical records have gaps, and the “clean dataset” was a curated demo that doesn’t resemble what the system will actually see. This is the single most common cause of mid-project stall in our experience — and it is invisible until someone opens the actual tables. The second is organisational alignment assumed. The AI team builds a working model. The business unit that was supposed to use it never adopts it, because their workflow was never redesigned around it, or because the people whose jobs change were never consulted. A technically successful model that nobody uses is a failed project. The adoption question belongs in the readiness assessment, not the launch retrospective. The third is infrastructure readiness assumed. The model is built and validated in a development environment, then handed to operations to deploy — and the deployment environment doesn’t support it. The latency budget is wrong, the GPU isn’t there, the data pipeline that feeds the model in production was never built. Organisations that have never operationalised a model underestimate this gap badly; we wrote about the discipline that closes it in MLOps for organisations that have never operationalised a model. Each of these is preventable. Each is cheap to find before the project starts and expensive to find after. That asymmetry is the entire argument for assessing readiness first. Which Dimensions of Readiness Gate AI Success? A defensible assessment covers five dimensions. Treat them as gates, not as a score to average — a project can clear four and still be blocked by the fifth. Dimension What it gates The question that exposes a gap Data Whether a model can be trained and fed in production Has someone audited the actual production data, not a sample? Are labels consistent? Are there gaps, drift, or access restrictions? Infrastructure Whether a working model can be deployed and run Does the target environment support the model’s latency, memory, and throughput needs? Does the production data pipeline exist? Talent Whether the system can be built and maintained Who maintains the model after the consultants leave? Is there in-house capacity to monitor, retrain, and debug? Sponsorship Whether the project survives contact with budget reality Is there an executive owner who absorbs the political cost of a stalled milestone? Is the budget ring-fenced? Change management Whether the output is adopted Has the workflow that consumes the model’s output been redesigned? Have the affected people been involved? The dimensions interact. Strong sponsorship can buy time to fix a talent gap; weak sponsorship turns a minor data problem into a cancelled project. The assessment’s job is to surface every gap and then sort them — which brings us to the distinction that makes the assessment useful rather than merely thorough. Which Readiness Gaps Can Be Fixed During the First Project, and Which Must Be Fixed Before It Starts? Not every gap is a blocker. The value of an honest assessment is that it separates the two classes, so the organisation knows whether it is looking at a delay or a redesign. Must be fixed before start (hard blockers): No production data exists, or the data that exists is legally inaccessible for the intended use. You cannot train against data you don’t have. No executive sponsor. Without an owner who absorbs the cost of a stalled milestone, the first hard quarter kills the project. The deployment environment is architecturally incompatible and cannot change within the project horizon — for example, an air-gapped line that the proposed cloud model fundamentally cannot reach. Can be fixed during the first project (manageable gaps): Data labelling is inconsistent but the raw data is good — a labelling effort can run in parallel with early modelling. The team lacks MLOps capacity but is willing to learn — the first project can be structured to build that capacity, which is often the right way to acquire it. Change-management processes are immature but the business unit is engaged — adoption work runs alongside the build. The line between the two columns is the most important output of the assessment. A consultant whose business model depends on the project proceeding has a structural incentive to push hard blockers into the “manageable” column. This is why the honesty of the assessment matters as much as its content — a point worth dwelling on. What Does an Honest Readiness Assessment Cover That a Vendor-Driven One Doesn’t? A vendor’s self-assessment tool is built to qualify you as a buyer. It asks questions whose answers route toward “you’re ready, let’s start.” An honest assessment is built to find the reason not to start — and to tell you plainly when that reason exists. The difference is structural, not a matter of integrity. A vendor selling a platform benefits when you conclude you’re ready to buy the platform. An assessment whose deliverable is the assessment itself — regardless of whether the project proceeds — has no such incentive. The buyer can point to specific readiness criteria met or unmet, sign against them at each milestone, and walk away with a defensible artifact even if the honest conclusion is “not yet.” When the recommendation is “fix your data governance before you spend a euro on modelling,” that is a more valuable output than a green light that ignores the blocker. This is the same scrutiny we recommend applying to the firm running the assessment — covered in detail in what to look for when evaluating AI consulting firms. An assessment that can only conclude “yes” is not an assessment. Choosing an AI Governance Framework as Part of Readiness Governance is the dimension most often treated as a passing mention and most often the one that blocks deployment late. For a mid-size enterprise, the question is not which exhaustive framework to adopt — it is which governance scope is proportionate to the risk, and whether that scope is in place before the project starts. Governance readiness splits into three distinct concerns that are frequently conflated: Data governance — who owns the data, what consent and retention rules apply, whether the intended use is permitted under the basis on which the data was collected. This is the one that most often produces a hard blocker: a model trained on data you weren’t permitted to use that way is not deployable, regardless of how good it is. Model governance — how model versions are tracked, how decisions are explained where regulation or contract requires it, how bias and fairness are evaluated for the specific decision the model influences. The depth required scales with the consequence of the decision; a recommendation engine and a credit-scoring model sit at different points. Operational governance — who is accountable when the model is wrong in production, how incidents are escalated, how the model is monitored and retrained. This overlaps with the talent and infrastructure dimensions and is where SRE-style ownership discipline applies. For a mid-size company, the proportionate move is to size each of these to the actual decision the AI will influence, rather than importing an enterprise-wide framework that the organisation will never operate. Governance readiness gates the project-start decision in one specific way: if the data-governance basis for the intended use is absent or unclear, the project is blocked until it is resolved — and that resolution can take longer than the modelling itself. We treat governance scope as a gate alongside data and infrastructure, not as a compliance afterthought to be handled at launch. How Agent Readiness Differs from Readiness for Traditional ML When the project is an AI agent deployment rather than a traditional predictive model, the five dimensions still apply — but each one carries an agent-specific specialisation that a generic readiness assessment misses. Agent runtime constraints. A traditional model produces one output per inference. An agent runs a loop — planning, calling tools, reasoning over results, deciding what to do next. That loop has a cost and latency profile that compounds across steps, and the infrastructure dimension has to account for sustained multi-step execution rather than single-shot inference. An environment that comfortably serves a classifier can stall under agentic load. Tool-integration risk. An agent’s usefulness comes from the tools it can call — internal APIs, databases, external services. Each integration is a surface where the agent can fail, take an unintended action, or expose data. Readiness here means asking which tools the agent will touch, what the blast radius of a wrong call is, and whether those integrations are stable enough to depend on. This risk has no analogue in a traditional model that only reads and predicts. Additional data-governance requirements. Agentic workflows introduce data-governance questions that batch ML does not. An agent that reads from and writes to live systems, retains context across a session, and passes data between tools creates new paths for data to move in ways the original consent basis may not cover. The data-governance gate gets stricter, not looser, when the system can act. These are specialisations of the general readiness criteria, not a separate framework. An organisation that fails the general readiness assessment fails the agent version too; the agent-specific sections add gates, they don’t replace the foundation. How Readiness Sequences Before Per-Use-Case Feasibility Organisational readiness and use-case feasibility are two different questions, and they run in a fixed order. Readiness asks whether the organisation can run any AI project. Feasibility asks whether this specific use case is achievable given current model capabilities. Running them in the wrong order wastes effort. There is no point establishing that a generative summarisation feature is technically feasible if the organisation has no production data pipeline, no executive sponsor, and no governance basis for the data the feature would touch — the feature will stall on the readiness gap regardless of how feasible it is in isolation. Readiness first establishes that the ground is solid; per-use-case feasibility then tests whether a specific structure can stand on it. We treat the feasibility question as a distinct downstream filter, covered in how to evaluate whether a generative AI use case is technically feasible. The readiness assessment is also the precursor to a structured risk assessment, which is where the gaps it surfaces get turned into a project plan with milestones the buyer can sign against. The full shape of that engagement is described in how a structured AI consulting engagement works from scoping to delivery, and the assessment itself is one of the services that produces a deliverable whether or not the project proceeds. FAQ How do I assess whether my organisation is ready to start an AI project at all? Run a structured assessment across five dimensions — data, infrastructure, talent, sponsorship, and change management — before committing budget. Each dimension is a gate, not a score to average: a project can clear four and still be blocked by the fifth. The assessment’s job is to find the blockers while they are cheap to fix, before mid-project discovery makes them expensive. Which dimensions of readiness gate AI success? Data (can a model be trained and fed in production), infrastructure (can a working model be deployed and run), talent (who maintains it after launch), sponsorship (does the project survive budget reality), and change management (is the output actually adopted). These dimensions interact — strong sponsorship can buy time to fix a talent gap, while weak sponsorship turns a minor data problem into a cancelled project. What does an honest AI readiness assessment cover that a vendor-driven one doesn’t? An honest assessment is built to find the reason not to start and to say so plainly; a vendor’s self-assessment tool is built to qualify you as a buyer and routes toward “you’re ready.” The difference is structural: an assessment whose deliverable is the assessment itself has no incentive to push hard blockers into the “manageable” column. An assessment that can only conclude “yes” is not an assessment. How is organisational AI readiness sequenced before per-use-case feasibility? Readiness runs first and asks whether the organisation can run any AI project; per-use-case feasibility runs second and asks whether this specific use case is achievable. Establishing that a use case is feasible is wasted effort if the organisation has no data pipeline, sponsor, or governance basis to support it. Readiness confirms the ground is solid; feasibility then tests whether a specific structure can stand on it. Which readiness gaps can be fixed during the first project, and which must be fixed before it starts? Hard blockers — no production data, no executive sponsor, an architecturally incompatible deployment environment — must be fixed before start. Manageable gaps — inconsistent labelling on good raw data, a willing-but-undertrained team, immature change processes with an engaged business unit — can be addressed in parallel with the first project. Separating the two columns honestly is the most important output of the assessment. How does AI readiness for an agent deployment differ from AI readiness for traditional ML? The same five dimensions apply, but each gains an agent-specific gate: runtime constraints for sustained multi-step execution rather than single-shot inference, tool-integration risk where each connected API is a failure and data-exposure surface, and stricter data governance because agents that read, write, and retain context move data in ways the original consent basis may not cover. These are specialisations of the general criteria, not a separate framework. What does an AI readiness checklist actually contain, and how is it different from a vendor’s self-assessment tool? It contains the gating question for each of the five dimensions plus the three governance concerns — data, model, and operational governance — sized to the actual decision the AI will influence. The difference from a vendor tool is intent: a checklist that produces a defensible artifact the buyer can sign against at each milestone, including the conclusion “not yet,” rather than a funnel whose answers route toward a purchase. What are the core pillars an AI readiness assessment framework should cover for a mid-size enterprise? The five readiness dimensions (data, infrastructure, talent, sponsorship, change management) plus a proportionate governance layer split into data governance, model governance, and operational governance. For a mid-size enterprise the proportionate move is to size each governance concern to the specific decision the AI influences rather than importing an enterprise-wide framework the organisation will never operate. When the assessment concludes “not yet,” that conclusion is the deliverable — and it is worth more than a green light that ignores the blocker. The organisations that treat readiness as a precondition rather than a formality are the ones that don’t end up writing “AI doesn’t work” in a post-mortem that should have read “we weren’t ready.” The harder question, once readiness is established, is whether a given problem is even the kind of thing current models can solve — which is where telling an engineering task from a research question begins.
