AI Readiness Assessment Checklist: Seven Dimensions, Scored

An AI readiness assessment is a structured evaluation of whether an organization has what it needs to take AI from pilot to production safely and repeatedly: strategy, data, platform, security, governance, talent and a credible use-case portfolio. It scores current capability against clear criteria, identifies the gaps that block specific priority use cases, and produces a sequenced plan to close them.

Many readiness assessments fail because they produce a maturity chart and nothing else. The scores are debated, filed, and the organization carries on as before. The version below is built to avoid that: every dimension is scored against observable evidence, and every gap is tied to the use cases it blocks. Use it as a self-assessment, or as a starting point for an independent review.

How to use this checklist

Score each item from 0 to 3:

Prefer to score it interactively? The free AI readiness assessment tool uses these same 35 items, totals each dimension, and keeps your answers private in your browser.

Score	Meaning
0	Absent. Nothing in place.
1	Ad hoc. Exists in pockets, depends on individuals, not documented.
2	Defined. Documented and used by some teams, with gaps in coverage or enforcement.
3	Operating. Consistently used across the organization, measured, and improved.

Score on evidence, not intent. A policy in draft is a 1. A platform that exists but no team uses is at most a 2. Each dimension has five items, so each dimension scores from 0 to 15, and the full assessment from 0 to 105.

Two rules make the results useful:

1. Ask for the artifact. For every score of 2 or 3, name the document, system or metric that proves it.
2. Tie gaps to use cases. For every item scored 0 or 1, note which priority use cases it blocks.

1. Strategy and leadership

1. An AI strategy exists that links AI investment to specific business outcomes, not to technology adoption for its own sake.
2. A named executive is accountable for AI outcomes and has budget authority.
3. AI priorities are reflected in the annual planning and budgeting cycle.
4. Success metrics are defined for AI initiatives before they start, and results are reported.
5. Leadership has agreed a position on risk appetite for AI, including what the organization will not do.

What good looks like: a short strategy that names the handful of outcomes AI should move, who owns them, and how progress is reported. See AI strategy and roadmap.

2. Data foundations

Our guide to AI-ready data explains how to test each of these per use case.

1. The data needed for priority use cases is identified, and its owners are known.
2. Data quality for those sources is measured, with known issues documented.
3. Unstructured content (documents, knowledge bases, tickets, transcripts) is inventoried, accessible, and has clear ownership.
4. Access permissions on source data are well defined and can be enforced downstream, including in retrieval systems.
5. Data classification and lineage allow you to know what sensitive data an AI system can reach.

What good looks like: you can answer, for any priority use case, which data it needs, who owns that data, how good it is, and who is allowed to see which parts. Permission-aware retrieval is often the hardest part of generative AI in practice. See data architecture for AI.

3. Platform and architecture

1. There is an approved way to access foundation models (for example through Azure OpenAI, Amazon Bedrock, Google Vertex AI or direct provider APIs) with enterprise terms in place.
2. Model access is centralized through a gateway or equivalent, with logging, quotas and routing.
3. Shared services exist for retrieval, vector storage, evaluation and observability, rather than each team building its own.
4. A reference architecture defines standard patterns for common AI workloads, such as RAG, agents and document processing.
5. AI workloads can move from experiment to production through a defined path, with CI/CD, environments and version control for prompts and models.

What good looks like: a new team can build on paved roads rather than assembling its own stack. The enterprise AI reference architecture guide describes the components.

4. Security

1. AI-specific threats are included in threat modeling, including prompt injection, data leakage through model outputs, and insecure tool use, for example using the OWASP Top 10 for LLM Applications and MITRE ATLAS.
2. Controls prevent sensitive data from being sent to unapproved AI services, and shadow AI use is visible.
3. Agents and AI applications use scoped, least-privilege credentials and cannot exceed the permissions of the user they act for.
4. AI applications are tested adversarially before production, proportionate to their exposure.
5. AI incidents are defined and covered by the incident response process.

What good looks like: security reviews of AI systems follow a known pattern with known controls, instead of being argued from scratch each time.

5. Governance and risk

1. An AI policy and acceptable use standard exist and are known to staff.
2. An inventory of AI systems exists, including third-party products with embedded AI, and is kept current.
3. AI systems are risk-tiered, and review effort is proportional to tier.
4. Release gates require evaluation evidence and named approval for higher-risk systems.
5. Governance aligns with a recognized framework, such as the NIST AI RMF or ISO/IEC 42001:2023, and with applicable regulation.

What good looks like: low-risk work moves quickly on standard controls, and high-risk work gets real scrutiny. See the NIST AI RMF implementation guide.

6. Talent and operating model

1. The organization has, or has access to, the core skills: AI architecture, AI and ML engineering, data engineering, evaluation, and AI security.
2. Roles and decision rights for AI are clear between central teams and business units.
3. There is a structured intake for new AI ideas, with a defined path to delivery.
4. Builders and users receive role-appropriate training on AI capabilities, limits and policy.
5. Production AI systems have named owners and funded teams to operate them after launch.

What good looks like: someone owns every production AI system, and people know where to take a new idea.

7. Use-case portfolio

1. Candidate use cases are collected in one place and assessed consistently.
2. Use cases are prioritized by value, feasibility and risk, not by who asked loudest. Our AI use case prioritization framework gives a scorecard.
3. Each priority use case has a business owner, a defined metric and a baseline.
4. The portfolio balances quick wins with a smaller number of higher-value, harder use cases.
5. Pilots have explicit criteria for moving to production or stopping.

What good looks like: a short list of well-defined use cases with owners and metrics, and a record of pilots that were stopped on purpose.

Interpreting the scores

Add each dimension’s score out of 15. Then read the pattern, not just the total.

Dimension total	Interpretation
0-5	A blocker. Priority use cases in this area will stall or carry unmanaged risk.
6-10	Workable for pilots and low-risk production, with specific gaps to close.
11-15	A strength. Build on it and use it as a model for weaker areas.

These bands are a heuristic for prioritizing, not a benchmark against other organizations. Some patterns we see often:

• Strong strategy, weak data. Ambitious plans, but priority use cases depend on content nobody owns. Fix data ownership and access for the top use cases before adding more.
• Strong platform, weak portfolio. Good infrastructure with little in production. The problem is use-case selection and business ownership, not technology.
• Strong pilots, weak governance and security. Pilots are impressive but cannot pass review for production. Build proportionate release gates and standard security controls.
• Everything at 1. Pick two or three priority use cases and build only the capabilities they need. Readiness improves fastest through real delivery.

Running the assessment well

The checklist is only as good as the evidence behind the scores. A few practices make the difference between a credible result and a self-congratulatory one.

Gather evidence from more than one direction

Interview leaders, but also interview the people who have tried to ship AI: engineers who built pilots, security reviewers who had to approve them, and business owners whose projects stalled. Leaders tend to describe the intended state. Builders describe the actual one. Where the two differ, the builders are usually closer to the truth, and the difference itself is a finding.

Supplement interviews with inspection. Look at the gateway logs or cloud billing to see which model services are actually in use. Read two or three real design documents and risk reviews. Walk through the steps a team would take to get a new AI use case into production, and time them.

Anchor on real use cases

Choose three to five priority use cases before scoring, and trace each through all seven dimensions. What data does it need, and is that data ready? Which platform services would it use? What security and governance steps would it face? Who would own it after launch? This turns abstract maturity scores into concrete blockers that a sponsor can fund and an owner can fix.

Calibrate the scores

Have two people score independently, then reconcile. Disagreements usually reveal that the organization is uneven: one business unit at a 3, another at a 0. Record the spread, not just an average, because an average hides exactly the gaps that stall enterprise rollouts.

From scores to a plan

A readiness assessment should end in decisions. Structure the output this way:

1. Top blockers: the five or so gaps that block the most valuable use cases, each with an owner.
2. Use-case sequencing: which use cases can proceed now, which after specific gaps close, and which should wait.
3. Foundation investments: the shared capabilities (model gateway, retrieval platform, evaluation, inventory) that unblock multiple use cases.
4. A 90-day plan with named owners and visible milestones, followed by a 12-month roadmap.
5. A reassessment date, typically six to twelve months out, using the same scoring so progress is comparable.

Avoid the temptation to close every gap before starting. The best-sequenced plans deliver one or two production use cases while building the shared foundations underneath them.

How we help

Our fixed-scope AI readiness assessment applies this framework with interviews, architecture and data reviews, and inspection of your existing AI work, and ends in a prioritized roadmap tied to your use cases. Contact us to scope one.