AI Maturity Is the Wrong Unit of Analysis

I have become increasingly skeptical of the AI maturity assessment as the starting point for an investment decision. Not because maturity is useless, but because I do not think the organization is always the right unit of analysis.

I did not arrive at that conclusion because a maturity assessment failed. The concern came earlier. Any maturity model starts from an idea of what “good” looks like: the capabilities, governance, skills, technology, processes and behaviors an organization should possess before it can use a new method or technology well. That can be useful. It is also a very consultant-shaped way of looking at the problem.

AI makes that logic unusually difficult. The range of plausible applications is enormous, the value mechanism differs radically from one workflow to another, and the strategic importance of an initiative depends on what the company is actually trying to become. A good AI strategy therefore cannot be separated from business strategy. If the intervention feels like technology being applied to the organization rather than a better way of achieving something the organization already cares about, resistance is a rational response.

That was one of the reasons I created the AI Value Assessment in the first place. I was not interested in telling a company whether it had reached level two, three or four on somebody else’s ladder. I wanted to identify where AI could change an outcome enough to justify the organizational effort around it—and then use that value signal to bring governance, security, data, people and operating-model questions into the work.

A maturity model can tell me what is missing. It cannot tell me whether the thing I am trying to mature for is worth doing.

A pilot can make an organization look more mature without making AI more useful

Over the last two years, every organization I collaborated with already had some form of internal CustomGPT pilot running. If I used the existence of pilots as a maturity signal, I could reasonably say that these organizations were at least one step beyond companies still discussing whether generative AI mattered.

But that signal did not tell me what I actually needed to know. Most of those organizations still struggled to create traction with employees. People had access to the technology and often understood that it was strategically important. What they did not necessarily have was a reason to use it in their daily work. The technology existed before the work had been redesigned around a meaningful advantage.

This is the gap I keep returning to. An enterprise technology function can become genuinely sophisticated at selecting models, building platforms, defining policies and launching pilots while the front- and back-office teams who are supposed to benefit from that sophistication remain largely unchanged. The organization has become more capable of providing AI without necessarily becoming more capable of creating value with AI.

That distinction is not an argument against enterprise capability. It is an argument against treating capability as a proxy for opportunity quality. AWS’s generative AI maturity guidance explicitly acknowledges that characteristics of multiple maturity levels can apply across teams and use cases, and that maturity should be considered independently across different aspects. Even a maturity model designed to describe organizational progress recognizes that maturity is uneven.

Why an AI maturity assessment can answer the wrong question

There is another problem with the question “How mature are we at AI?” In my experience, the executive need behind it is often reassurance. Sometimes the desired outcome is to sleep well because the organization is “doing OK.” Sometimes the score becomes a way to pressure the person who is considered responsible for why the organization is not doing OK.

Neither outcome is inherently irrational. Leaders need orientation. They need to know whether governance is missing, whether data foundations are weak, whether skills are insufficient and whether their operating model can support the ambitions they are setting. Microsoft’s AI Readiness Assessment, for example, evaluates preparedness across business strategy, governance and security, data foundations, AI experience, organization and culture, infrastructure and model management. That is a legitimate diagnostic job.

The difficulty begins when a diagnostic of organizational conditions quietly becomes an investment decision. An AI maturity assessment can tell me that governance capability is underdeveloped. It cannot tell me whether one claims-review workflow would save enough time, reduce enough error or improve enough customer experience to justify fixing that governance gap. It can tell me that adoption is weak. It cannot tell me whether employees are resisting AI or simply have not yet been shown an application that makes their work meaningfully better.

The model begins with expert knowledge: the assessor knows what “right” looks like and measures the organization against it. That is useful when the task is gap analysis. It becomes dangerous when the model starts defining the destination before the organization has established which destination creates value.

The better starting point is the consequential workflow

The redesign of my own AI Value Assessment became much clearer once I forced the unit of analysis down from the company to one consequential workflow, business problem, opportunity or decision. That is small enough to ask questions that actually change an investment choice.

This is closely related to the AI Value Hypothesis I have written about before, but it’s still important to note the distinction. The earlier question was how to test whether an attractive AI idea deserves transformation investment. The question here comes one step earlier: what exactly are we assessing in the first place?

NIST’s AI Risk Management Framework points in a similar direction from a risk perspective. Its MAP function begins by establishing the intended purpose, beneficial uses, specific users, deployment setting, assumptions, limitations and context-specific impacts of an AI system. Context is not an implementation detail; it is part of understanding what the system is and which risks and benefits matter.

That logic is useful beyond risk. A workflow-level opportunity lets me connect value, behavior and constraints in one place. I can see who does the work today, what “better” means, what information exists, where judgment is required and what would have to change around the technology. The assessment stops being a portrait of the organization and becomes an investigation of a decision.

Start with value, then invite governance into something concrete

This is where my view can sound more cavalier than it is. I am not arguing that a promising workflow should be pushed into production while governance, security and architecture catch up later. I am arguing that the organization should first establish enough evidence of value to give those functions a concrete problem worth solving.

If a bounded workflow has obvious added value, I would use that signal to build general buy-in. People who own governance, security, data, risk and compliance now have something tangible to engage with: a defined workflow, users, data, potential benefit and failure modes. Their job becomes helping the organization make a valuable thing safe and scalable rather than enforcing a generic readiness checklist against an abstract ambition.

I have described a related dynamic before in Governance Follows Momentum. The point is not that governance is secondary. It is that governance works better when it is attached to a value-producing system that people are motivated to make viable. The controls become part of the design rather than a distant permission gate.

McKinsey’s 2025 State of AI survey provides a useful supporting signal. Among 25 organizational attributes tested, workflow redesign had the strongest relationship with respondents reporting EBIT impact from generative AI; only 21% of respondents whose organizations used generative AI said at least some workflows had been fundamentally redesigned. That does not prove that workflow-first assessment causes value, but it reinforces the idea that enterprise capability alone is not the end state. Value appears when the work itself changes.

One or two hours can be enough to decide what deserves deeper investigation

The obvious objection is scale. A CIO may have 150 AI ideas. Nobody is going to run a bespoke investigation into every workflow before deciding what matters. I agree. The answer is not to replace one AI maturity assessment with 150 miniature consulting projects.

I would start with one or two hours and a deliberately broad group of interested people. The purpose is not to produce a perfect prioritization matrix. It is to expose the ideas to enough perspectives that the organization can identify the three to five opportunities with the strongest combination of meaningful problem, plausible value mechanism, access to evidence and willingness from the people who would need to change the work.

This is where my Design Thinking background still strongly influences how I work. Stanford’s d.school describes human-centered design as both problem-finding and problem-solving: understand the people for whom you are designing, discover meaningful opportunities and use prototypes to learn before committing too early. That orientation is valuable in enterprise AI because the first job is not to fit a technology into the organization. It is to understand where a change in the work would matter to the people doing it and to the outcome the business cares about.

Lean Startup thinking adds the next discipline. Once an opportunity looks promising, make the assumptions explicit and test the ones that matter most. Strategyzer’s experimentation guidance frames this as identifying critical hypotheses across desirability, feasibility and viability, then choosing small experiments that generate the most valuable evidence. That is the logic I would borrow: not “Which idea scored highest?” but “What would have to be true for this idea to deserve more investment, and what is the cheapest credible way to find out?”

The sequence becomes practical: explore broadly, select a few consequential opportunities, investigate them at workflow level, test the value hypothesis, and commit more organizational capability only as the evidence justifies it. That is very different from asking the enterprise to prove it is mature before it is allowed to learn.

An AI maturity assessment becomes more useful after the opportunity survives

This is why I do not want to throw maturity models away. I want to change their position in the decision.

Once an opportunity has survived the first evidence gate, a competent professional-services practitioner needs to ask what is missing. Can the organization govern this responsibly? Is the data available and reliable enough? Who owns the workflow? Which human decisions must remain explicit? What security controls are required? What capability gaps prevent the solution from moving beyond one team? Where will adoption fail if people do not understand how their work changes?

At that point, an AI maturity assessment becomes genuinely useful because it helps identify which organizational capabilities must be strengthened for a promising initiative to become repeatable. AWS makes this distinction visible at its Experiment level: organizations define and prioritize use cases based on business value and feasibility, establish success metrics and keep proofs of concept bounded while also developing governance and foundational capabilities. Opportunity selection and organizational capability building can reinforce each other. They do not have to be the same question.

The difference is that the gaps now have a reason to exist. I am not telling an organization to improve governance because mature organizations have governance. I am telling it that a specific opportunity is worth scaling and that governance is one of the things standing between today’s evidence and a reliable production system.

That also changes the role of professional services. The consultant is no longer primarily the person who arrives with a maturity model and explains what the client is missing. The more valuable job is to help the client recognize which opportunities matter, test the assumptions quickly, and then use expertise to fill the capability gaps that the evidence makes consequential.

This is consistent with a broader argument I have made about redesigning work with AI. The technology is most interesting when it changes the structure of the work, not when it simply appears beside the existing process. An assessment should therefore help leaders decide where redesign is worth pursuing before it asks whether every supporting capability already looks like the textbook answer.

The largest maturity gap may be inside the organization, not around it

The last reason I distrust a single enterprise score is that organizations do not experience AI uniformly. One team may have redesigned its work around AI and developed strong judgment about where the technology helps. Another may have access to exactly the same tools and still be struggling to identify one useful application. A central platform can be sophisticated while the individual employee experiences AI as an empty chat box.

There are few gaps greater than the assumption of AI maturity in an organization and how mature individual employees are with it.

That gap matters because transformation happens through people doing work differently. If employees cannot see why AI changes their own workflow, the organization can accumulate strategy documents, governance frameworks, training programs and pilots without creating much pull from the people expected to use them.

An AI maturity assessment may still belong on the dashboard. It can show whether the organization is developing the capabilities required to scale. It can identify gaps that deserve professional attention. It can help leaders see whether ambition is outrunning foundations.

I just do not think it belongs at the beginning of the investment decision.

Start with the three to five opportunities that could materially change an outcome. Get specific about the workflow. Make the value mechanism explicit. Find the weakest important assumption. Generate enough evidence to decide whether the opportunity deserves another step.

Then use maturity expertise to close the gaps that stand between a promising opportunity and a system the organization can trust and scale.