AI Governance Maturity Model: Where Does Your Org Stand?

An AI governance maturity model sorts an organization’s AI oversight into stages — from no written rules at all up to an independently audited, continuously improving program — so you can tell which one you are actually in before you go looking for a template. This page is a self-scoring rubric: read the five stages below, find the last one where every diagnostic question is genuinely true for your organization today, and follow that stage’s link to the specific CASRAI template built for it.

The short version: Ad Hoc → Developing → Defined → Managed → Optimizing. Most organizations that have never formally assessed themselves sit at Ad Hoc or Developing, whether or not they think of it that way.

Where the stage names come from — and where they don’t

It’s worth being precise about this, because it’s tempting to assume a five-stage “ad hoc to optimized” scale is lifted directly from a specific AI standard. It isn’t, and checking that is the responsible thing to do before publishing a rubric.

The NIST AI Risk Management Framework (AI RMF 1.0) does not define maturity levels or implementation tiers. Its structure is four functions — Govern, Map, Measure, Manage — broken into categories and subcategories that an organization implements, not a 1-through-5 scale that scores how well it has implemented them. Reviewed directly against the published AI RMF 1.0 document: there is no “tier” or “maturity” construct in it.

The closest thing in NIST’s own catalog is a different framework entirely: the NIST Cybersecurity Framework’s four Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive), which describe how rigorously an organization integrates risk decisions and shares threat information. But NIST is explicit that these “do not necessarily represent maturity levels” — a Tier 1 organization with low risk exposure can be an entirely appropriate, deliberate choice, not a deficiency to climb out of. So even the nearest NIST precedent isn’t the staged, cumulative “you should be trying to move up” model this page uses.

The Ad Hoc → Developing → Defined → Managed → Optimizing structure itself descends from the Capability Maturity Model lineage — originally developed at Carnegie Mellon’s Software Engineering Institute for software process assessment, and later generalized as the process capability levels in ISO/IEC 33001 (Incomplete, Performed, Managed, Established, Predictable, Optimizing). It’s real, decades-old, and it’s the same staged-capability logic nearly every published AI governance maturity model from consultancies and standards bodies borrows, because organizational process maturity — not AI-specific technical maturity — is what these stages actually measure. This page adapts that structure to the five governance artifacts CASRAI’s frontier-ai-safety cluster already covers in depth, rather than inventing new stage definitions from scratch.

The five stages — score yourself

Stage 1 · Ad Hoc

What it looks like: People use AI tools because they’re useful, not because anyone decided they should. There is no written policy, no one specific person is accountable if an AI-assisted decision goes wrong, and “governance” so far means informal conversation, if it means anything.

Score yourself here if: your organization has no written AI usage policy, AND no one could name the specific person or committee accountable for an AI governance decision if asked today.

Start here: Responsible AI Usage Policy Template — the acceptable-use and prohibited-use document written for the people actually using the tools, not for leadership. It’s the minimum viable governance artifact, and every later stage assumes it already exists.

Stage 2 · Developing

What it looks like: A usage policy exists and staff have seen it, but there’s no consistent process for a new, higher-stakes AI use case — no defined risk tiers, no governance council, no documented escalation path when someone wants to deploy something riskier than day-to-day tool use.

Score yourself here if: you have a written usage policy, but new AI use cases get evaluated ad hoc rather than against a defined risk-tiering process, and there’s no standing council or named escalation path.

Next: AI Governance Framework Template — the organizational structure above the policy: a governance council, a risk-tiering methodology, and defined escalation paths for when a use case crosses a threshold.

Stage 3 · Defined

What it looks like: The framework and council exist on paper and are genuinely in use, but no one has checked them against the full set of functions a governance program is supposed to cover — incident reporting, audit function, documented risk assessment, and so on — so there may be real gaps sitting underneath what looks like a complete program.

Score yourself here if: you have a working framework and council per Stage 2, but you have not run your program against a complete checklist of the functions a mature governance program needs.

Next: AI Governance Best Practices: A Practical Checklist — the completeness check across committee, framework, policy, risk assessment, audit function, and incident reporting, so nothing important is missing just because it wasn’t on anyone’s radar.

Stage 4 · Managed

What it looks like: Governance isn’t just internally complete — it’s actively tracked against specific, named external obligations with real dates attached, and someone can show, on request, exactly what’s done and what’s still outstanding before each one.

Score yourself here if: your program clears Stage 3, and it is also being actively measured against specific regulatory deadlines that apply to your organization — not just general best practice.

Next: EU AI Act High-Risk System Compliance Checklist — the concrete provider/deployer obligations and dates, verified against the 2026 AI Omnibus amendments, for organizations whose AI systems fall in scope.

Stage 5 · Optimizing

What it looks like: Someone other than the people who wrote the policy periodically checks whether it’s actually being followed — not whether something has already gone wrong, but whether the written commitments hold up against what the organization is actually doing. Findings feed back into the framework, closing the loop.

Score yourself here if: your program clears Stage 4, and a defined internal function independently verifies your AI governance commitments on a periodic, scoped basis, separate from whoever owns the policy itself.

Next: Building an Internal Audit Function for Frontier AI Safety — how that internal check differs from incident response and from third-party evaluation, and how it reports back into governance.

A NIKOLAI signal for the Developing → Defined jump

NIKOLAI is CASRAI’s own frontier-AI-safety dictionary — an independent, unendorsed reference vocabulary, not an official standard any organization has signed on to. One of its 64 elements maps unusually well onto exactly the gap between Stage 2 and Stage 3 above: Accountable Decision-Maker and Sign-Off, in NIKOLAI’s N9 track (Commitments and Governance).

NIKOLAI defines the element as capturing “the named role (and, where published, the named person) who makes or approves a threshold determination, risk-acceptance decision, deployment decision, redaction, or framework change, together with the approval record itself — what was approved, by whom, and when.” That’s a useful test in practice: a Stage 2 organization can usually point to a policy document, but frequently cannot produce an actual sign-off record for a specific decision. A Stage 3 organization can. NIKOLAI’s own crosswalk notes that most frontier labs with a published framework name a C-suite or board-level role for this — a useful benchmark for what “defined” looks like structurally, even though none of those crosswalk rows are binding on any organization outside the one that published them, and CASRAI has not independently verified each one against the named labs’ current practice.

A second N9 element, Roadmap Item — “a dated, non-binding future goal with a trackable status value (not met / met / slipped), published so that its completion or slippage against the stated date can be monitored independently” — is a similarly concrete signal for Stage 4. An organization that can point to dated, trackable governance commitments, rather than open-ended intentions, is managing its program against real external checkpoints rather than describing it in the abstract.

How this fits the rest of the cluster

This page is a router, not a replacement for the guides it points to. For the underlying concepts rather than the self-assessment, see What Is AI Governance? for the foundational definitions, and Building an AI Safety Framework with NIST’s Govern, Map, Measure, Manage Functions for the underlying framework this page confirmed does not itself carry a maturity scale.

FAQ

Is there an official AI governance maturity model?

No single body publishes one. NIST’s AI RMF defines functions and categories, not a maturity scale. ISO/IEC 42001 (the AI management system standard) is certifiable — an organization either conforms or it doesn’t — which is a different mechanism from a staged maturity model. The five-stage structure on this page is CASRAI’s own synthesis, built on the decades-old Capability Maturity Model lineage rather than any AI-specific standard’s staging language, because none of the AI-specific standards currently define one.

How is this different from CASRAI’s AI Safety Index or SaferAI rubric guides?

The AI Safety Index and the SaferAI grading rubric both score frontier AI labs’ published safety frameworks — a third party grading OpenAI’s or Anthropic’s public documents. This page scores something different: your own organization’s internal AI governance practice, whether or not you build or deploy frontier models yourself.

Do we need to reach Optimizing to comply with the EU AI Act or similar laws?

No. Legal compliance is defined by the specific law that applies to you — see the EU AI Act checklist for what’s actually required and when. What Stage 5 (Optimizing) adds isn’t a new legal requirement; it’s independent internal verification that whatever you’ve documented is actually happening, which is what protects you when a regulator, auditor, or incident asks you to prove it.

Can an organization skip a stage — go straight from Ad Hoc to Managed, for example?

In practice, no: Stage 4 and 5 both depend on artifacts (a defined framework, a completeness check) that the earlier stages produce. An organization racing to demonstrate regulatory compliance without the underlying structure typically discovers the gap during an audit or an incident, not before one. The honest move if you’re unsure where you stand is to work through the diagnostic questions above in order, not to assume you’re further along than the evidence shows.

Why This Matters for Research Administration

A university’s research-integrity or sponsored-programs compliance office has a concrete reason to run itself through this five-stage rubric. NSF’s own PAPPG was amended via policy supplement NSF 26-200, effective December 8, 2025, to fold AI-assisted misconduct directly into the federal definition research offices already operate under: Chapter XII.C now defines research misconduct as fabrication, falsification, or plagiarism “whether committed by an individual directly or through the use or assistance of other persons, entities, or tools, including artificial intelligence (AI)-based tools.” An NSF-funded institution sitting at this page’s Stage 1 (no written AI-use policy) has no documented basis for distinguishing legitimate AI-assisted drafting from an AI-enabled fabrication allegation once that clause is tested against a live case.