Enterprise AI capability model for use-case maturity decisions

Research Question

What enterprise-wide Artificial Intelligence (AI) capability model best supports deciding whether a candidate AI use case requires net-new foundational capabilities or can reuse capabilities already built across the enterprise?

Findings

(Seeded from section 6 synthesis above.)

Executive Summary

• The best enterprise AI capability model for use-case maturity decisions is a three-layer dependency map in which shared foundational capabilities are assessed before any use case is allowed to claim reuse, while a five-level maturity model remains a separate portfolio overlay.
• Software-delivery evidence shows why: model access and local productivity gains are easy to obtain, but organisation-level reuse only works when governance, internal context, platform safety nets, evaluation, and workflow redesign already exist as shared enterprise rails.
• A five-level maturity model remains useful as a separate portfolio view because it helps leaders assess broad organisational progression from experimentation to enterprise-scale operation, but it does not replace the dependency checks needed at use-case intake.
• A candidate use case should trigger foundational investment whenever one of those rails is missing, because governance and lifecycle control are not project-specific add-ons but reusable enterprise capabilities.
• Net-new enabling or differentiating capability is justified only after the foundations are already proved and the use case clearly needs specialised routing, internalised domain heuristics, or higher-assurance verification.

Key Findings

1. High confidence: The most useful enterprise AI capability model for use-case intake is a dependency map that separates foundational shared rails from enabling and differentiating layers, because the decision problem is whether a specific use case can safely ride existing enterprise capability rather than where the enterprise sits on a single five-level maturity model.
2. Medium confidence: DORA's 2025 research shows that AI amplifies existing system quality, so clear AI policies, internal context, high-quality internal platforms, user-centric workflow design, and safety nets are prerequisites for reliable reuse across a portfolio of use cases.
3. High confidence: Individual AI productivity gains cannot be treated as sufficient evidence of enterprise readiness, because faster task completion can coexist with higher churn, larger review queues, and flat company-level outcomes when downstream controls remain weak.
4. High confidence: Governance capability belongs in the foundational layer because both NIST AI RMF and ISO/IEC 42001 require organisation-wide intake, mapping, measurement, management, and lifecycle controls that are reusable across multiple AI use cases.
5. Medium confidence: Enterprise pressure to deploy AI is already intense, but scaling maturity remains uneven, which implies that operating-model and governance capability are now a stronger constraint than simple access to models or pilot opportunities.
6. High confidence: The foundational layer should contain governance and intake, authoritative context and access, platform and workflow safety nets, evaluation and measurement, and workforce adoption and change management, because each of these capabilities is repeatedly required before safe reuse becomes plausible.
7. Medium confidence: Net-new enabling or differentiating capability should only be added after the foundations are already in place and the use case clearly needs specialised routing, internalised domain heuristics, domain ontologies, or stronger review and checking layers than the shared baseline provides.
8. High confidence: The default enterprise failure mode is to scale generation before scaling control, which produces pilot sprawl, weak provenance, quality regressions, and local enthusiasm that never becomes reusable organisational learning.

Assumptions

• Assumption: The State of AI Report is useful as ecosystem context but not as direct capability-design evidence. Justification: the report is broad and signal-rich, but less direct than DORA, NIST, ISO, AI Index, GitHub, GitClear, and Faros for this decision problem.
• Assumption: McKinsey Superagency is a useful secondary reinforcement for workforce and operating-model capability, not a primary pillar of the final model. Justification: the listed page was not directly fetchable in this environment.

Analysis

• I weighted software-delivery evidence heavily because it shows the exact enterprise failure mode that a reuse-versus-build model needs to prevent: faster local generation arriving before shared control systems are ready.
• I weighted NIST AI RMF and ISO/IEC 42001 heavily because they turn vague maturity language into explicit organisational capabilities that can be reused across use cases and checked at intake.
• I resolved the model-shape question by comparing a concrete five-level maturity model, Microsoft's, with the prior repository conclusion that durable enterprise maps separate stable taxonomy from assessment overlays, because that keeps the AI capability map stable while still allowing portfolio-level progression scoring.
• The resulting model is intentionally conservative: if a use case exposes a gap in governance, context, platform safety nets, evaluation, or operating-model readiness, the right answer is foundational investment first rather than custom capability on top of weak ground.

Consolidated capability model

• Foundational - governance and intake: reuse is plausible only when a use case has a named owner, risk class, approved policy, and escalation path; if any of those are missing, the right decision is foundational investment first.
• Foundational - authoritative context and access: reuse is plausible only when trusted sources, permissions, provenance, and refresh rules already exist as shared capability; if they do not, the gap is foundational.
• Foundational - platform and workflow safety nets: reuse is plausible only when logging, testing, review, rollback, and fast feedback loops already exist as shared delivery controls; if they do not, the gap is foundational.
• Foundational - evaluation and measurement: reuse is plausible only when benchmark sets, error thresholds, incident metrics, and drift checks already exist as shared capability; if they do not, the gap is foundational.
• Foundational - workforce adoption and change: reuse is plausible only when training, workflow redesign, support, and user accountability are already planned as operating capability; if they are not, the gap is foundational.
• Enabling - reusable retrieval and orchestration: shared context stacks, routing, policy enforcement, and human approvals should be reused once the foundational layer is already in place.
• Differentiating - domain-specific optimisation: ontologies, adapters, specialised review components, and specialised benchmarks should be added only after foundations are proven and a specific use case clearly needs them.

Triage rubric

1. Gate 1: If the use case lacks an owner, risk class, or lifecycle control path, classify it as foundational investment first.
2. Gate 2: If the use case lacks authoritative context, internal data access, platform safety nets, or measurable evaluation, classify it as foundational investment first.
3. Gate 3: If all foundations exist and the use case mainly needs configuration on shared retrieval, policy, and evaluation rails, classify it as reuse shared capability.
4. Gate 4: If all foundations exist but the use case needs specialised routing, internalised domain heuristics, or higher-assurance verification, classify it as add new enabling or differentiating capability.

Risks, Gaps, and Uncertainties

• The listed a16z source was inaccessible as a live page in this environment, so venture-style strategy framing is underweighted in the final synthesis.
• The listed Faros source URL was inaccessible as a live page, so Faros support relies on a later Faros analysis page and linked PDF rather than the original destination.
• The listed McKinsey Superagency page did not fetch directly, so workforce and training claims from that seed source carry less weight than the DORA, NIST, ISO, AI Index, GitHub, GitClear, and Faros evidence.
• The evidence is very strong on adoption pressure and governance gaps, but it is still weak on the exact cost threshold at which an enterprise should graduate from shared foundations to expensive differentiating layers such as adapters, ontologies, or specialised checking components.

Open Questions

• What benchmark should tell an enterprise that its shared retrieval, policy, and evaluation rails are mature enough for higher-autonomy use cases?
• Which governance controls can remain fully shared across the enterprise, and which must always remain specialised by domain or risk class?
• What is the best early-warning metric for the point where generation capacity begins to outrun verification capacity in enterprise delivery systems?

sources

Starting points - papers, articles, videos, repos, docs.

• [x] DevOps Research and Assessment (DORA) Research Program — - primary source for the 2024 and 2025 DORA reports and associated AI capability guidance
• [x] Google Cloud DORA overview — - contextual landing page for DORA report publication and capability framing
• [x] GitClear AI code quality research — - telemetry-based counterpoint on code churn and cloning
• [x] State of AI Report — - annual ecosystem synthesis across research, market, and policy signals
• [x] Stanford Human-Centered Artificial Intelligence (HAI) AI Index — - data-heavy annual benchmark across investment, policy, education, and model progress
• [x] a16z Big Ideas in Tech — - listed URL returned a 404 page in this environment, so it was checked for context but not used for core evidence
• [x] McKinsey State of AI — - enterprise survey evidence on adoption and scaling bottlenecks
• [x] McKinsey Superagency in the Workplace — - listed page failed to fetch directly in this environment; supporting claims use the associated McKinsey Portable Document Format (PDF) file when noted
• [x] GitHub Octoverse — - software ecosystem and developer workflow trend context
• [x] GitHub Research and impact posts — - publicly shared findings on Copilot productivity and developer outcomes
• [x] Faros AI Productivity Paradox — - listed URL resolved to a page-missing page in this environment; supporting claims use Faros follow-on analysis and the linked Faros report PDF
• [x] NIST AI Risk Management Framework — - governance and risk capability baseline for enterprise maturity
• [x] ISO/IEC 42001 standard overview — - AI management system standard relevant to organisational capability design
• [x] Microsoft agentic AI adoption maturity model overview — - concrete five-level maturity model used here as the comparison point for why maturity models are useful overlays but weaker primary intake tools