Readiness is the question before “what should we build?” Most organisations approach AI adoption backwards. They start with use cases — “we want to build a chatbot,” “we need predictive maintenance,” “we should use GenAI for document processing” — and then discover, weeks or months in, that the prerequisites for executing those use cases were never in place. The data infrastructure cannot support model training. The team has no production ML engineering experience. There is no governance framework that can authorise an AI decision when one is needed. The use-case evaluation quietly assumed a level of organisational readiness that does not exist. AI readiness assessment inverts that order. It evaluates the organisation’s capability to execute AI projects at all, before committing to any specific one. The output is a map of the gaps that would cause projects to fail, and a sequencing of how to close them so the highest-value projects become executable first. There is a related question that this assessment deliberately does not answer: is this specific use case technically feasible given current model capabilities? That is a per-use-case question — one that only makes sense to ask once organisational readiness is established. Readiness first, feasibility second. Reversing that order is how organisations end up with technically feasible projects stalled inside organisations that cannot run them. The downstream symptoms of that reversal are visible in why most enterprise AI projects fail. The gap between paper-readiness and execution-readiness Organisations that score well on data quality audits and have ML-titled staff can still fail at AI execution. The pattern we observe most often across our engagements: the data is clean in the warehouse but not accessible to training pipelines; the ML engineers have research experience but have never put a model in production; the governance framework exists as a policy document but has never been tested against a live AI decision. Paper-readiness is a checklist; execution-readiness is whether the organisation can actually run a project end-to-end without discovering structural gaps mid-flight. The three named failure patterns — data readiness assumed, organisational alignment assumed, infrastructure readiness assumed — share a common shape. Each is invisible until the project is already committed. Each becomes most expensive to fix at exactly the moment the project surfaces it. The assessment exists to surface them before that point, when fixing them is a planning decision rather than a damage-control exercise. The three dimensions of AI readiness Data infrastructure readiness AI models consume data. The organisation’s data infrastructure determines whether data is available, accessible, and usable for AI workloads — not merely whether it exists. Data quality. Is the organisation’s data clean, consistent, and complete enough to train and operate AI models? Missing values, duplicates, inconsistent formats, and stale records degrade model performance proportionally to their severity. As a planning heuristic from our AI readiness engagements (observed pattern across mid-size engagements; not a benchmarked industry rate): an organisation with around 30% missing values in its key datasets is not ready for AI projects that depend on that data. Data accessibility. Can the data be accessed programmatically by training and serving pipelines? Data locked in departmental silos, legacy systems without APIs, or third-party platforms with restrictive licensing is not accessible for AI workloads — regardless of its quality. The engineering effort to make data accessible (extraction pipelines, data-sharing agreements, legacy modernisation) is the single most underestimated cost in early-stage AI planning. Data infrastructure. Does the organisation have the storage, compute, and pipeline infrastructure to support AI data workflows? Training data must live in formats and systems that support efficient retrieval — data lakes, feature stores, vector databases. Serving data must flow through pipelines that deliver it to models at production latency. Infrastructure designed for BI reporting and analytical queries often cannot meet the throughput or latency profile of AI workloads without modification. The operational machinery that holds this together is the subject of MLOps and why we need them. Organisational capability readiness AI projects require specific skills the organisation may or may not have, and the gap between adjacent skills is wider than job titles suggest. ML engineering — the ability to build, train, evaluate, and deploy ML models — covers data preprocessing, model selection, evaluation methodology, and deployment infrastructure. If the organisation does not have this capability, the options are hire (expensive, slow), train existing engineers (moderate cost, slow), or engage R&D engagements with outcome ownership and knowledge transfer (moderate cost, faster, with capability transferred during the engagement). Data engineering is a different skillset focused on ingestion, transformation, quality assurance, and pipeline reliability. Many organisations underinvest here relative to ML engineering, ending up with teams that can build models but cannot feed them with reliable data. This is the most common organisational-capability failure we see. Product and business integration determines whether model output becomes business action. A churn model has no value unless the prediction triggers a retention move — a call from account management, a discount offer, a service improvement. That requires product managers, business analysts, and operations teams who understand how to operationalise predictions. Without them, the model runs in production and nothing changes downstream. The workforce-engagement dimension of this — how teams adopt and trust AI outputs in daily work — is explored in AI workforce engagement, training, and automation. Governance readiness AI governance is how the organisation manages the risks, responsibilities, and oversight of AI systems. It is the dimension most often treated as a policy artefact rather than an executable capability. Decision authority. Who approves AI projects? Who owns the model’s decisions once it is live? If a fraud detection model incorrectly blocks a legitimate transaction, who is accountable? If a hiring algorithm produces biased recommendations, who is responsible? These accountability questions need answers before deployment, not after the first incident forces them. Risk management. What framework does the organisation use to assess AI-specific risks — bias, fairness, security, privacy, reliability? AI introduces risks traditional IT risk frameworks do not address: model drift as data distributions change, adversarial inputs that cause specific failure modes, and emergent behaviour that was not anticipated during development. A governance framework that only covers static IT risk does not cover AI risk. Compliance. What regulatory requirements apply? The EU AI Act, sector-specific regulations (FDA in healthcare, PRA/FCA in financial services), and data-protection regulations (GDPR, CCPA) impose specific requirements on AI systems — transparency, explainability, data handling, bias assessment. Organisations that deploy without understanding the applicable regime risk non-compliance and the associated penalties. Choosing an AI governance framework Governance readiness is often where mid-size organisations stall — not because they lack policies, but because they have not chosen a framework with enough specificity to gate the project-start decision. A useful framework distinguishes three governance scopes, each of which must have a named owner before any AI project begins. Data governance covers data lineage, access control, retention, consent, and quality monitoring. It is the precondition for everything else; without it, neither model governance nor operational governance has reliable inputs to work from. Mid-size organisations typically already have a data governance function — the gap is usually that it has not been extended to cover AI-specific concerns (training-set provenance, synthetic data, vector embeddings of customer content). Model governance covers approval to train, approval to deploy, model registries, evaluation thresholds, and change-control for retraining. This is the layer that says “yes, this model meets the bar to go live” and “no, this retrained version regresses on the fairness criteria we set.” It is the most common gap, because organisations often treat model approval as a one-off project decision rather than an ongoing governance function. Operational governance covers monitoring in production, incident response when a model behaves badly, rollback authority, and the audit trail that connects an AI decision back to a human-accountable owner. This is the layer regulators ask about after an incident. For mid-size companies, a practical framework choice is to anchor on one external reference — the NIST AI Risk Management Framework is the most widely applicable starting point — and extend it with the sector-specific requirements that apply. The framework itself matters less than whether each of the three scopes has an owner, a decision threshold, and a documented escalation path before the first AI project starts. Governance readiness gates the project-start decision: if any of the three scopes does not have a named owner, the organisation is not ready, regardless of how the data and capability dimensions score. AI readiness for agent deployments Agentic AI — systems that take actions through tools rather than only producing predictions — extends the general readiness criteria rather than replacing them. The data, capability, and governance dimensions still apply; three additional readiness conditions sit on top. Agent runtime constraints. Agent runtimes have latency, cost, and reliability profiles that differ from traditional ML serving. A retrieval-augmented agent typically issues multiple model calls per user interaction, often against frontier models with rate limits and per-call costs measured in cents rather than fractions of a cent. The readiness question is whether the organisation’s infrastructure budget and observability stack can support a workload whose unit economics differ from anything it has run before. Tool-integration risk. An agent that can call tools — internal APIs, external services, database writes — has the surface area of every tool it can reach. Readiness here means knowing which tools an agent can call, what the blast radius of each call is, and whether reversibility is guaranteed for any state-changing action. Tool registries and per-tool authorisation are a hard prerequisite, not a refinement. Agent-specific data governance. Agents process data that crosses traditional governance boundaries — a single user prompt may pull customer data, internal documents, and external content into the same context window. Data governance for agents must specify what data is allowed into a context, what is allowed to leave it (through tool calls or model outputs), and how the trail is audited. Organisations whose data governance was designed for static ML training data typically need to extend it explicitly before an agent deployment is responsible. Agent readiness is the specialisation of general readiness, not a separate framework. An organisation that fails general readiness will also fail agent readiness; an organisation that passes general readiness still needs to verify the three agent-specific extensions before deploying. The readiness assessment process A structured assessment runs through all three dimensions plus the agent-specific extensions where relevant: Data infrastructure audit. Examine the organisation’s key datasets against the data requirements of the proposed AI use cases. Score data quality, accessibility, and infrastructure capability. Capability mapping. Assess the technical team against the skill requirements for the proposed projects. Identify gaps and map them to hiring, training, or engagement strategies. Governance review. Evaluate existing governance frameworks against AI-specific requirements across data, model, and operational scopes. Map gaps to the regulatory regime that applies. Gap-to-action mapping. For each gap, define the specific action required, the estimated effort, and the priority — which gaps are prerequisites for the most valuable projects. Roadmap. A phased plan that closes readiness gaps in the order that unlocks the highest-value projects first, so execution can begin in parallel with continued readiness investment. AI readiness scorecard The dimensions below align with the readiness frameworks used by Gartner (AI Maturity Model, 2023), McKinsey (AI readiness diagnostic), and Google Cloud’s AI Adoption Framework — adapted here for practical self-assessment rather than vendor-specific tooling. Score each dimension 1–3, multiply by the weight, and sum. Dimension Score 1 — Not Ready Score 2 — Partial Score 3 — Ready Weight Data quality >20% missing values; no quality monitoring; inconsistent formats <10% missing; monitoring exists but manual; partial standardisation <2% missing; automated monitoring and remediation; consistent formats ×2 Data accessibility Data in silos or legacy systems without APIs; no data lake; batch-only APIs for most sources; data lake exists but no feature store; latency gaps Programmatic access to all datasets; feature store operational; production-grade latency ×2 ML & data engineering No ML/data engineering staff; no deployment experience; no pipeline tooling Some ML experience but no production deployment; fragile or manual pipelines Dedicated roles; production deployment experience; reliable automated pipelines ×2 Business integration No model-to-action process; no product/ops involvement in AI planning Stakeholders identified; ad hoc integration; manual handoffs Clear model-to-action ownership; product and ops teams embedded in AI projects ×1 Governance & compliance No AI governance; no decision authority; regulatory requirements unassessed Framework drafted but not implemented; partial accountability; landscape partially mapped Accountability assigned; risk management covers bias, drift, adversarial inputs; regulatory compliance verified ×1 Scoring guide (maximum 24): 8–13 — Not ready. Critical gaps in foundational dimensions. Address data and capability gaps before committing to AI projects. 14–19 — Conditionally ready. Some dimensions support execution; others require targeted investment. Start with projects that depend on the ready dimensions while closing remaining gaps. 20–24 — Ready. All dimensions at or near full readiness. Proceed to project selection and execution. Closing readiness gaps: realistic timelines Each readiness dimension maps to remediation actions with predictable effort ranges. The table below provides planning-grade estimates (observed pattern across our engagements; actual timelines depend on organisational size, existing infrastructure, and gap severity). Readiness dimension Score 1 → 2 Score 2 → 3 Data quality Deploy profiling tools; fix critical missing-value issues in priority datasets. 4–8 weeks Automate quality monitoring and remediation; standardise all formats; reduce missing values below 2%. 8–16 weeks Data accessibility Build extraction pipelines for priority legacy systems; deploy initial data lake. 8–16 weeks Implement feature store and vector database; build real-time production-grade pipelines. 12–24 weeks ML & data engineering Engage consultants with knowledge transfer; begin hiring first ML/data roles. 6–12 weeks (engagement) / 12–24 weeks (hiring) Build dedicated team with production experience; establish automated pipelines and MLOps practices. 16–32 weeks Business integration Identify stakeholders per use case; define model-to-action workflows; run manual pilot. 3–6 weeks Embed product/ops teams in AI projects; automate handoffs; establish outcome-to-retraining feedback loops. 8–16 weeks Governance & compliance Draft governance framework; assign decision authority; map regulatory landscape. 4–8 weeks Implement risk management for bias, drift, adversarial inputs; verify regulatory compliance; establish audit cadence. 8–20 weeks Organisations scoring 1 in a dimension should plan for both columns sequentially. Organisations scoring 2 can proceed directly to the Score 2 → 3 column. Dimensions weighted ×2 (data quality, data accessibility, ML capability) should be prioritised first; they are prerequisites for most AI projects, including agent deployments. Which gaps must close before the project starts, and which can close during it Not every gap is a blocker. Some can be closed during a first project, treating the project itself as the forcing function for closure. Others must close before the project starts, because the project depends on them. Must close before starting: any Score-1 dimension in data quality, data accessibility, or governance authority. A project cannot train on data it cannot access, cannot operate on data that is structurally broken, and cannot deploy without a named owner for its decisions. These are pre-conditions, not co-conditions. Can close during the first project: business integration gaps and partial ML engineering gaps. A first project with consulting support that includes knowledge transfer can close ML capability gaps as part of delivery. Business integration can be built around the first project’s specific model-to-action workflow, then generalised. Risk management for bias, drift, and adversarial inputs can be implemented for the first model and then templated for subsequent ones. The discipline is to know which is which before committing. Treating a pre-condition gap as a co-condition gap is one of the most common ways the enterprise AI failure patterns take hold. Honest assessment versus vendor-driven assessment A vendor-driven readiness assessment tends to optimise for the assessment producing a “ready for our product” verdict. An honest assessment optimises for accuracy regardless of what it implies for follow-on work. The difference is structural, not motivational — a vendor whose downstream economics depend on the project proceeding is not the right party to decide whether the project should proceed. What an honest assessment covers that a vendor-driven one often does not: the option of not doing the project, the option of doing a smaller project first to close capability gaps, and the option of pausing entirely until governance authority is in place. The assessment itself is a defensible artefact — the buyer can point to specific readiness criteria met or unmet, regardless of whether any project follows. If the answer is “not ready,” that is the deliverable. If AI readiness has not been assessed across all three dimensions before committing to specific projects, an AI Project Risk Assessment evaluates the gaps and produces an actionable roadmap. FAQ How do I assess whether my organisation is ready to start an AI project at all? Score the organisation across three dimensions — data infrastructure, organisational capability, and governance — using the weighted scorecard above. A weighted total below 14 indicates critical gaps that must be closed before any project starts; 14–19 is conditional readiness where some projects are executable while others are not; 20+ is broad readiness. The assessment is the precondition for any per-use-case decision, including whether a specific GenAI use case is feasible. Which dimensions of readiness (data, infrastructure, talent, sponsorship, change management) gate AI success? Data quality, data accessibility, and ML and data engineering capability are weighted heaviest because they are prerequisites for almost every AI project. Business integration and governance and compliance are weighted lower in the scorecard but are still gating: a project without business integration produces no business value, and a project without governance authority cannot be deployed responsibly. Talent, sponsorship, and change management are encoded inside the capability and integration dimensions rather than treated as separate axes. What does an honest AI readiness assessment cover that a vendor-driven one doesn’t? An honest assessment covers the option of not doing the project, the option of doing a smaller project first to close capability gaps, and the option of pausing until governance authority is established. A vendor-driven assessment tends to optimise for a “ready for our product” outcome because the vendor’s downstream economics depend on the project proceeding. The assessment itself should be a defensible artefact regardless of whether a project follows. How is organisational AI readiness sequenced before per-use-case feasibility (TK3-CCU-04)? Readiness first, feasibility second. Organisational readiness answers whether the organisation can run any AI project; per-use-case feasibility answers whether a specific use case is technically achievable given current model capabilities. Reversing the order produces technically feasible projects stranded inside organisations that cannot execute them. Per-use-case feasibility is a separate evaluation that runs only after readiness is established. Which readiness gaps can be fixed during the first project, and which must be fixed before it starts? Score-1 gaps in data quality, data accessibility, or governance authority must close before the project starts — a project cannot run on broken or inaccessible data and cannot deploy without a named decision owner. Business integration gaps and partial ML engineering gaps can close during a first project, particularly when the project is delivered with knowledge transfer that builds capability as part of execution. How does AI readiness for an agent deployment differ from AI readiness for traditional ML? The three general dimensions still apply, plus three agent-specific extensions: runtime constraints (agents have different latency, cost, and reliability profiles because they issue multiple model calls per interaction), tool-integration risk (an agent inherits the blast radius of every tool it can reach, so tool registries and per-tool authorisation are prerequisites), and agent-specific data governance (context windows cross traditional governance boundaries, so what enters and leaves a context must be specified and audited). Agent readiness is the specialisation of general readiness, not a separate framework.
