An AI maturity assessment should tell leaders what the organization can do reliably today, what is holding it back, and which action deserves funding next. It should not produce a flattering score that places the company in a fashionable category while teams continue running disconnected pilots with unclear business value.
I have seen maturity assessments used across data, analytics, ERP, cloud and transformation programs for years. They can create a useful common language, especially when business and technology leaders have different impressions of progress. They can also become theater. A company answers a long questionnaire, calculates an average, chooses a maturity label and commissions a roadmap toward the highest level. Six months later, the label has changed but operating behavior has not.
Artificial intelligence makes this problem more visible. One team may have a production model with strong engineering practices. Another may be experimenting with public generative AI tools. A third may have good data but no approved use case. The company can be advanced and immature at the same time, depending on the capability and business workflow being examined.
A useful analogy is physical fitness. Someone can have strong cardiovascular endurance and poor mobility. Averaging the two into a single fitness score hides what could cause the next injury. The right training plan depends on the specific weakness, the person’s goal and the evidence observed. AI maturity works the same way.
My perspective comes from years of leading data, analytics, AI, SAP, engineering, governance and transformation work across complex organizations. Public experiments on this site provide inspectable examples, but they do not form the entirety of that view. I use them to test how current tools behave when they meet business definitions, imperfect data, operating controls and human judgment.
This guide provides an AI maturity assessment model for business direction, data, delivery, governance, adoption and value. More importantly, it explains where to start at each maturity level. A company beginning with isolated experiments should not receive the same advice as one operating AI products across several business units.
Take the free AI readiness assessment
The fastest way to use this guide is to rate one workflow against the five capabilities below. The assessment takes about five minutes and returns a readiness profile, the gap most likely to block your next step and what to fund next.
It rates each capability separately, for the reasons explained in the rest of this article, and it never averages them into one number. Answer for what operates today, not what is planned. Enter your email at the end to see your profile, then save it as a PDF for your next review.
What an AI maturity assessment should measure
Maturity is the ability to produce a result repeatedly under normal operating conditions. A demonstration proves that something can work once. Maturity asks whether the organization can choose the right problem, supply appropriate data, deliver a dependable service, control the risk, change the workflow and prove the result.
That definition matters because companies often rate themselves using assets rather than capability. Buying an AI platform does not prove that teams can deploy useful products. Publishing a policy does not prove that controls operate. Training thousands of employees does not prove that work changed. A long use-case list does not prove that leadership made investment choices.
I would assess five connected capabilities:
| Capability | What the assessment examines | Evidence that matters |
|---|---|---|
| Business direction | How the company selects problems, allocates funding and stops weak ideas | Prioritized portfolio, named sponsors, investment limits and rejected use cases |
| Data foundation | Whether teams can find, understand, access, test and correct the required data | Source ownership, defined grain, quality results, lineage and correction paths |
| Delivery | Whether experiments can become supported production services | Evaluation results, deployment history, reliability, monitoring and support ownership |
| Governance | Whether controls match data sensitivity, decision impact, reversibility and AI autonomy | Risk tiers, control tests, access records, overrides, incidents and escalation decisions |
| Adoption and value | Whether people use the changed workflow and whether the business result improves | Active usage, corrections, removed steps, outcome measures and full operating cost |
These capabilities should be assessed separately. Business direction might be scaled because executives make clear portfolio choices, while governance remains repeatable because each team interprets policy differently. Data might be managed for customer analytics but ad hoc for unstructured maintenance records. The scope of the assessment must make those differences visible.
Why one AI maturity score can mislead leaders
A single score is attractive because it simplifies reporting. It also encourages false precision. An organization rated 2.7 out of 4 sounds measurable, but the number does not tell leaders whether a missing data owner, unreliable deployment process or weak adoption is blocking the next investment.
Averages create another problem. Strong technology can offset weak governance mathematically even though it cannot do so operationally. Likewise, a polished strategy can offset poor delivery in the score while producing no real business result.
The visual below shows the progression for each capability without assigning a fictional company rating. Read every row independently from left to right.
I prefer a maturity profile to a maturity score. The profile shows the current level for each capability, the evidence supporting that rating and the action required next. Leaders can still summarize the assessment, but the summary should preserve the limiting gaps.
Not every capability must reach the highest level. A company running a few low-risk internal assistants may not need the same reusable operating model as a company deploying autonomous agents across financial and customer processes. The target level should follow the business strategy, scale and risk of the work.
The four AI maturity levels
Level 1: Ad hoc
At the ad hoc level, progress depends on individual energy. Teams test tools, build proofs of concept and solve local problems. Funding may come from discretionary budgets. Data access is negotiated for each effort, while evaluation and risk review happen differently across teams.
This stage is not automatically bad. Early exploration should be inexpensive and flexible. The problem appears when the organization mistakes experimentation for operating capability or keeps funding many isolated efforts without learning which ones deserve another investment.
Evidence of this level includes personal spreadsheets of use cases, one-off data extracts, manual testing, unclear production ownership and success stories based mainly on demonstrations.
Level 2: Repeatable
At the repeatable level, common methods begin to appear. Teams use an intake process, basic evaluation criteria, approved data-access patterns and initial risk rules. Similar projects can reuse some work, although adoption and value may still depend on the local team.
The main risk is duplication. Every business unit may follow a basic method while still rebuilding retrieval, evaluation, integration and controls. The company has more order than before but may not yet have a shared production capability.
Evidence includes standard templates, a visible portfolio, defined pilot gates, recurring review forums and common technical patterns used by more than one team.
Level 3: Managed
At the managed level, AI products operate with named business, product, data, technology and risk owners. Teams monitor quality, reliability, cost and adoption. Controls vary by risk, and leaders compare outcomes against an agreed baseline.
Organizations at this level often discover that the model is no longer the hardest part. Workflow redesign, service ownership, exception handling and benefit realization become the larger constraints. Scaling without correcting those issues can spread operating friction across more teams.
Evidence includes production service measures, control results, incident records, user correction patterns, operating-cost reports and business outcomes reviewed by accountable leaders.
Level 4: Scaled
At the scaled level, the company can reuse data products, platforms, evaluation methods and control patterns across domains. Business units retain responsibility for their decisions while working within common guardrails. Funding moves toward the use cases with the best evidence.
Scaled does not mean every process uses AI. Mature organizations should be better at stopping low-value work, retiring obsolete solutions and deciding where ordinary automation or analytics is sufficient. Restraint is part of maturity.
Evidence includes repeatable returns across several domains, reuse that lowers delivery cost, consistent risk decisions, portfolio-level investment changes and deliberate retirement of solutions that no longer earn their cost.
How to conduct an AI maturity assessment
Define the scope before asking questions
Decide whether the assessment covers the enterprise, one business unit, one capability or one workflow. The enterprise-wide question “How mature are we at AI?” is too broad to answer responsibly. A scoped alternative such as “How prepared are we to operate AI-assisted invoice exception handling across North American accounts payable?” gives the assessment a business boundary.
Scope should identify the intended outcome, users, important data, decisions affected, operating geography and risk. An enterprise view can follow later by combining several scoped profiles without losing their differences.
Collect evidence before assigning a level
Interviews reveal how leaders believe the organization works. Artifacts and operating records show how it actually works. Both matter, but they are not interchangeable. A defensible AI maturity assessment records the evidence behind every assigned level.
Ask for portfolio decisions, funding records, source definitions, quality results, evaluation sets, deployment logs, service measures, access reviews, control tests, incidents, usage data, correction patterns and benefit calculations. Missing evidence is itself useful information.
The next visual shows how to convert broad claims into evidence that can be inspected.
Rate current behavior, not planned capability
Assess what operates today. A funded platform, approved hiring plan or published roadmap may improve future capability, but it does not belong in the current-state rating until the capability works and evidence exists.
When evidence conflicts, use the lower defensible level and record the reason. For example, a team may have sophisticated deployment automation but no accountable production owner. The delivery capability should not receive a managed rating merely because the technical pipeline is strong.
Separate enterprise capability from local exceptions
One advanced team does not make the company scaled. Conversely, one weak team does not erase an established enterprise capability. Record where the capability is available, who can use it and whether other teams have actually reused it.
A useful rating statement is specific: “Managed delivery capability for customer analytics in two business units, with repeatable delivery elsewhere.” That is more actionable than “Delivery maturity equals 3.”
Convert every gap into a decision
An assessment should end with decisions about investment, ownership and timing. Each material gap needs an accountable owner, evidence required, funding limit and review date. Avoid a roadmap containing dozens of generic initiatives with no connection to selected business use cases.
A realistic example of uneven AI maturity
Consider an industrial company exploring AI-assisted maintenance. One plant has years of sensor history, defined asset hierarchies and a production data pipeline. A data-science team can predict some failure patterns. However, maintenance planners still schedule work through a separate process, technicians do not consistently record failure causes, and nobody owns the model after the project team leaves.
The organization could appear advanced because it has a working model and modern platform. An evidence-based AI maturity assessment would show a more useful profile:
| Capability | Observed level | Evidence | Action before further scale |
|---|---|---|---|
| Business direction | Repeatable | Prioritized maintenance use case and plant sponsor, but no cross-plant portfolio decision | Define the business threshold for selecting the next asset class or plant |
| Data foundation | Managed for one plant | Stable sensor pipeline and asset identifiers, with inconsistent technician failure codes | Correct the failure-recording process and assign source ownership |
| Delivery | Repeatable | Model deployed with project-team support, but no permanent service owner | Assign production support and define reliability and retraining measures |
| Governance | Ad hoc | Engineering review exists, but there is no agreed response when a recommendation conflicts with technician judgment | Define decision authority, override recording and escalation |
| Adoption and value | Ad hoc | Accuracy measured offline, while planner usage and avoided downtime are not tracked | Pilot the changed maintenance workflow and measure operational outcomes |
The correct next investment is not another model or a company-wide rollout. It is a controlled workflow pilot that improves source recording, assigns operating responsibility, captures overrides and measures maintenance outcomes. The profile changes the decision.
I have seen this pattern in predictive maintenance and other analytics programs. Technical performance can improve long before the operating process is ready to use it. Human judgment is not a temporary inconvenience to automate away. Technicians, planners and operations leaders hold context that must shape thresholds, exceptions and escalation.
Where to start at each AI maturity level
Not every reader should leave an AI maturity assessment with the same checklist. The next move depends on current capability, the selected business outcome and the gap most likely to block it. Use the AI maturity assessment to select the next investment, not to copy every action associated with a higher level.
The following action board provides a different starting point for each level. It also identifies a common mistake and the proof required before moving forward.
If your organization is ad hoc
Do not begin by designing an enterprise platform or collecting hundreds of ideas. Select one material workflow with a measurable baseline, accessible data and an accountable business sponsor. Run a bounded experiment using representative cases, including difficult exceptions.
The goal is to learn whether the problem deserves a pilot. Record what worked, what failed, where people corrected the output and which source limitations appeared. Set a spending and time limit before work begins.
Advance when the result can be repeated with real data and the sponsor agrees that changing the workflow could create enough value to justify a controlled pilot.
If your organization is repeatable
Stop treating each pilot as a separate invention. Standardize use-case intake, baseline requirements, evaluation, risk classification and funding gates. Reuse approved data-access methods, testing patterns and controls.
Manage the work as a portfolio. Compare use cases by business value, feasibility, data readiness, risk and adoption cost. Close weak pilots and preserve their lessons. This is also the point where a shared enablement team can help, provided it supports business ownership rather than taking it over.
Advance when multiple teams use the common method, the company can move selected pilots into production without heroics, and leaders can explain why some ideas were stopped.
If your organization is managed
Shift attention from launching products to operating them. Monitor quality by meaningful risk segment, not only as one average. Track reliability, cost, adoption, corrections, overrides and business outcomes. Remove workflow steps that the new product makes unnecessary.
Strengthen permanent ownership. The business owner holds the outcome, while product, data, engineering, security and risk owners maintain their parts of the service. Review whether controls still match current autonomy and consequence.
Advance when production outcomes remain stable, operating costs are understood, people use the changed workflow and several capabilities can be reused safely.
If your organization is scaled
Scaling creates a new responsibility: preventing shared capability from becoming central bureaucracy. Reuse platforms, data products, evaluations and controls where economics support it. Allow business domains to make decisions within clear guardrails.
Optimize the portfolio instead of celebrating its size. Compare realized value with full operating cost. Retire low-value models, duplicated assistants and legacy workflow steps. Review concentration risk created by shared platforms and vendors.
Evidence at this level should show repeatable returns across domains, lower marginal delivery cost from reuse, effective local decisions and deliberate retirement of work that no longer deserves investment.
What to do when capabilities sit at different levels
Most organizations will have a mixed profile. Do not force every capability through the same improvement program. Start with the gap that constrains the selected use case.
If business direction is ad hoc but technology is managed, stop building until leaders select outcomes and investment boundaries. Weak data calls for definitions, source correction and access before adding model complexity. Weak adoption calls for workflow and incentive changes rather than another accuracy improvement.
The lowest rating is not always the priority. A low-risk writing assistant may operate responsibly with repeatable governance, while an agent that can alter supplier data requires stronger controls. Materiality comes from the use case, not the maturity number alone. The AI maturity assessment should identify which gap is material to each selected workflow.
| Limiting gap | What leaders may be tempted to fund | Better next investment |
|---|---|---|
| No selected business outcome | More use-case workshops | Portfolio decisions, named sponsors and explicit funding boundaries |
| Undefined data and weak source ownership | A larger model or retrieval tool | Data definition, correction process, access and quality evidence |
| Pilots cannot reach production | Another innovation team | Production architecture, service ownership, monitoring and support |
| Controls are generic or late | More policy documents | Use-case risk tiers, tested controls and clear escalation authority |
| Users bypass the product | More training and communication | Workflow redesign, correction analysis and removal of duplicate work |
| Value remains anecdotal | A larger rollout to create scale | Baseline, controlled measurement, full cost and benefit ownership |
Download the AI maturity assessment scorecard
I created a one-page scorecard for a working session. Use it for one business unit or workflow at a time. Choose one current level for each capability, record the evidence inspected and name the next action and owner.
Ask business, technology, data and risk leaders to complete the scorecard independently before comparing answers. Disagreement is useful. It reveals where teams are working from different evidence or using different definitions of success.
Common AI maturity assessment mistakes
Scoring ambition instead of current behavior
A roadmap, budget or executive statement belongs in future planning. Rate the current state using operating evidence. Otherwise, the assessment cannot show whether the planned investment changed anything.
Letting technology dominate the assessment
Architecture, tooling and model skills matter, but they do not substitute for business choices, source ownership, workflow adoption or value measurement. An advanced platform can support an immature operating model.
Assuming the highest level is always the goal
Maturity should fit the strategy. A company does not need enterprise-scale capability for every experiment. It does need controls and ownership appropriate to the consequence of each use case.
Producing a roadmap with no investment choices
If every identified gap becomes an initiative, the assessment has avoided prioritization. Connect actions to selected business outcomes and the evidence needed for the next funding decision.
Repeating the assessment without checking outcomes
A higher rating is not the result. Leaders should ask whether delivery became more reliable, controls operated, adoption increased and business outcomes improved. Maturity is useful only when it changes performance and investment decisions.
How AI maturity connects to strategy, governance and ROI
An assessment establishes the current capability. An AI strategy chooses the business outcomes, workflows, operating model and investment boundaries the company wants to pursue. The strategy should shape the target maturity. The assessment then shows which gaps could block those choices.
My AI governance framework explains how controls should change with business impact and autonomy. The data governance framework addresses meaning, ownership, quality and decision rights for the data underneath AI. For implementation practices, use the related data governance best practices guide.
Once leaders choose the gaps worth funding, my complete AI ROI roadmap provides the execution path from readiness and use-case selection through pilots, adoption and benefit measurement.
For a deeper treatment of investment logic, operating ownership, adoption and value measurement, AI to ROI for Business Leaders book on Amazon expands these decisions beyond the limits of one article. The financial risk is not limited to choosing the wrong model. Companies also lose time and attention by scaling pilots before the surrounding operating capability is ready.
Free official resources for AI maturity work
The NIST AI Risk Management Framework is a free voluntary framework for incorporating trustworthiness considerations into the design, development, use and evaluation of AI systems. Its govern, map, measure and manage functions can help shape the governance evidence in an assessment.
The U.S. Government Accountability Office AI Accountability Framework provides free questions and practices across governance, data, performance and monitoring. It is useful when leaders need to test whether accountability exists beyond a policy statement.
The OECD AI Principles provide another free reference for trustworthy AI and responsible stewardship. These resources inform an AI maturity assessment, but each organization still needs to translate them into evidence, owners and controls for its actual workflows.
An AI maturity assessment earns its value when it changes the next decision. It should help an early organization select one disciplined experiment, help a repeatable organization stop duplicating foundations, help a managed organization improve operations and help a scaled organization retire work that no longer creates enough value.
What are you trying to build with AI? Share the business workflow, the data involved, your current maturity level and where the work is getting stuck in the comments. I am especially interested in cases where one capability appears advanced while another is preventing the result.