An AI governance maturity model is a scale for judging how well an organization controls the AI systems it builds and buys, from no rules at all to governance that corrects itself. NIST’s AI Risk Management Framework, released on January 26, 2023, never uses the word “maturity”, so the levels and the rubric below are ours. They are built from outcomes that NIST and the EU AI Act describe, and each cell names something an assessor can ask to see.
Key takeaways
- The NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) sets no maturity levels. It treats Govern as a cross-cutting function that runs through the other three, and suggests comparing a Current Profile with a Target Profile to find the gaps.
- GOVERN 1.6 of the NIST framework calls for mechanisms to inventory AI systems, resourced according to the organization’s risk priorities.
- ISO/IEC 42001:2023 (first edition, December 2023) is a management system standard: ISO’s page says it sets the requirements for an AI management system that the organization keeps improving.
- Under the EU AI Act, the risk management, record-keeping and human oversight duties for high-risk systems (Articles 9, 12 and 14) apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I systems, the dates set when Regulation (EU) 2026/1744 amended the Act in July 2026.
- Microsoft’s Responsible AI Maturity Model (May 2023) has 24 dimensions in three categories, each scored on five levels from Latent to Leading.
What is an AI governance maturity model?
It measures one thing: whether the controls an organization says it has over AI are in place and working. An AI maturity model, by contrast, stages how far an organization has come with AI as a whole, including its strategy and skills. Whether you are ready to start one AI project is a third question, the subject of an AI readiness assessment. The maturity model is also different from the framework itself. An AI governance framework lists the parts you need (policy, roles, risk management, the standards you follow); the maturity model asks how far each part has come.
The published references don’t settle the levels for you. NIST’s framework is voluntary and outcome based. ISO/IEC 42001 is a set of requirements you either meet or don’t. The EU AI Act is law. Microsoft’s Responsible AI Maturity Model does have five levels, but it was written for planning, and its authors write that studying the higher levels “is more important than assessing your organization’s or team’s current level.” A rubric that you can score against evidence fills the gap between them.
What are the five levels?
The level names are the five our assessments use for every framework, the same five as in our data maturity model. For AI governance they read like this:
| Level | What AI governance looks like | What separates it from the level below |
|---|---|---|
| 1 Initial | People pick AI tools on their own. Nobody could say how many AI systems are running | Nothing yet: this is the starting point |
| 2 Developing | Some teams have rules and a partial list of systems, written by whoever cared enough to write them | Somebody has written something down |
| 3 Defined | An approved policy, one register of AI systems and a risk method apply across the organization | The rules are approved by an executive and apply to every team |
| 4 Managed | Controls are measured: policy exceptions and incidents are counted and reviewed on a schedule | Figures show whether the rules are followed |
| 5 Optimized | Incident and audit findings change the policy and the tests, and the records show it | The governance changes itself from its own evidence |
In our view the step that matters most to an auditor is from 2 to 3. At level 2 the controls depend on the people who happen to be on a project. At level 3 they belong to the organization, so they survive a resignation or a reorganization.
The rubric: six capabilities by level
The rubric has six rows, from policy to incident handling. Read each row from left to right and stop at the first cell you can’t show evidence for.
| Capability | 1 Initial | 2 Developing | 3 Defined | 4 Managed | 5 Optimized |
|---|---|---|---|---|---|
| Policy | No AI policy; staff decide for themselves which tools to use | An acceptable-use note exists, but no executive has approved it | An approved AI policy says who may approve a new AI use and what is not allowed, and staff have acknowledged it | Exceptions to the policy are logged, and a sample of AI uses is checked against it each year | The change history shows policy updates that came from incidents or audit findings |
| Inventory | Nobody can list the AI systems in use | A spreadsheet lists the systems IT knows about; AI features inside purchased software are missing | One register lists every AI system, built or bought, with its owner and purpose | No purchase or release can close without a register entry, and the register is reconciled against supplier contracts every quarter | Risk tiers, review dates and retirement dates are read from the register rather than kept elsewhere |
| Risk classification | No one rates the risk of an AI use | Risk is judged case by case by whoever builds or buys the system | A written method gives every registered system a risk tier and names what makes a use high risk, such as decisions about a person’s employment or credit | The tier decides the controls: a high-risk system can’t go live without the testing and approval its tier requires, and the tier is checked again when the system changes | Tier decisions across the portfolio are reviewed, and the method has been revised from what that review found |
| Oversight | No one is accountable for an AI system once it is live | Builders review their own systems | A named group approves high-risk uses, and every live system has a person with the authority to pause it | The group meets on a schedule and keeps minutes; the people who review high-risk outputs are trained, and their overrides are counted | Internal audit or an outside reviewer tests the oversight, and its findings are closed by a date |
| Records and evidence | Nothing beyond the code or the vendor contract | Some projects keep design notes or test results, each in its own format | Every system has a file in one format: purpose, data used, test results and the approved version | Logs are kept for the period the risk tier sets, and an auditor’s request is answered from the file without rebuilding it | The file updates itself as the system runs, so it is current whenever someone asks |
| Incident handling | AI problems are handled as ordinary IT tickets, if at all | Staff tell the team that built the system, informally | A written process defines an AI incident, who is told and who decides to suspend the system | Incidents are logged with severity and time to resolve, and serious ones reach an executive within a set time | Each closed incident records what it changed: a test, the policy or the register |
The inventory row is NIST’s GOVERN 1.6. The oversight row draws on GOVERN 2.1, which asks for documented roles and responsibilities, and on the Act’s Article 14 on human oversight. Incident handling reflects GOVERN 4.3, on practices that let teams test AI, identify incidents and share what they learn. Records follow the Act’s Article 12: a high-risk system must be able to log events automatically for as long as it is in use. For a deployer, Article 26 adds that the people assigned to oversight need the competence and authority for it, and the training, which is why the level 4 oversight cell asks for trained reviewers. These EU duties apply from December 2, 2027 at the earliest, under the July 2026 amending regulation, so an organization that builds the rows now has them before the duties start.
How to score your organization
Book an hour with the people who own the evidence: whoever runs the policy, someone from procurement, the owner of one high-risk system and someone from risk or legal. Collect the documents before the meeting, not during it.
- Choose a sample of systems. Take three or four AI systems that differ: one you built, one bought product with AI features switched on, and a generative assistant staff use every day. If you score only the flagship project, the bought tools nobody registered stay out of the score.
- Score each row against the sample. A capability reaches a level only when the evidence in that cell exists for every system in the sample. If the register lists two of the four, the inventory row stays at 2.
- Average the six rows. The overall score is the plain average of the six capability scores, and the level follows from its band: an overall 2.8, for example, sits in level 3, which runs from 2.5 to just under 3.5. Our data maturity assessment guide gives the other bands.
- Write down the weakest row and its owner. The next quarter’s work goes there first.
For illustration: a retailer samples its demand forecasting model, a bought recruiting tool that ranks applicants, and the chat assistant in its office suite. Its policy is approved, says who may approve a new AI use and what is banned, and staff have acknowledged it (3). IT’s spreadsheet of AI systems misses the recruiting tool (2). Each buyer judges risk case by case, with no written method (2). A named group approves high-risk uses, the recruiting tool among them, and every system has someone with the authority to pause it (3). Design notes and test results are kept project by project, each in its own format (2), and AI problems go into the ordinary IT ticket queue (1). The overall score is (3 + 2 + 2 + 3 + 2 + 1) ÷ 6 = 2.2, level 2, Developing.
The weakest row is incident handling, so the next quarter goes into a written incident process. Registering the recruiting tool is a smaller job that shouldn’t wait for it: the EU AI Act’s Annex III lists AI used to analyze and filter job applications among its high-risk uses.
Governance takes two of the eight areas in our free AI readiness assessment: Governance and Compliance, and Responsible AI and Trust, with nine questions each across its Quick and Detailed versions. Use it when you want the governance score next to the other six areas, from strategy to adoption. Any “Don’t know” answer is excluded from the score, not guessed.
What to do at each level
At level 1, start with the inventory, because every other row needs a list of systems to work on. Ask each department head and the procurement team for every AI tool in use. Include the AI features switched on inside software you already pay for, and put the answers in one place with an owner per line.
Moving from 2 to 3 takes approvals. Turn the acceptable-use note into a policy an executive signs, and merge the team lists into one register. Then write the risk method, even if it fits on a page: which uses count as high risk, and what each tier must pass before go-live.
From 3 to 4 the work is counting. Pick the figures the oversight group will see at every meeting (systems without an owner, overdue reviews, overrides of high-risk outputs, open incidents) and make the register the only place they come from.
Level 5 is reached when the loop closes on its own: an incident leads to a new test, an audit finding to a policy change, and the records show both. In our view it is worth the effort first in the rows that govern your highest-risk systems. The data side of the same controls, such as lineage and quality checks on training data, is covered in AI data governance, and governance of data in general has its own rubric in our data governance maturity model.
The Responsible AI Maturity Model is published by Microsoft Research. Level Up Your Data is not affiliated with or endorsed by NIST, ISO, the European Union or Microsoft. The rubric is our own and is not legal advice.
Frequently asked questions
What are the levels of AI governance maturity?
Our model has five, from Initial to Optimized. Other models name them differently. Microsoft’s Responsible AI Maturity Model runs Latent, Emerging, Developing, Realizing and Leading, so “Developing” is level 2 in ours and level 3 in Microsoft’s. Compare models by what each level asks for, not by its name.
How do you assess AI governance?
Against documents and records, on a sample of real AI systems that includes at least one bought product. An interview tells you what people believe the controls are; the register, the approvals and the incident log tell you what they are. When two people disagree on a row, ask for the document before you discuss the score.
Is AI governance maturity the same as data governance maturity?
No. Data governance decides who owns data and the rules for using it. AI governance adds controls on the system that uses the data, such as its risk tier and who may switch it off. In our view the two move together on records: an AI system’s file is hard to keep current when the data it was trained on has no owner.
Which standards does an AI governance maturity model use?
This one maps its rows to the NIST AI RMF and the EU AI Act. ISO/IEC 42001 sits beside them as the management system standard. NIST’s framework has no levels, so the scale comes from the model, not the standard. NIST’s page says AI RMF 1.0 is being revised as part of the White House AI Action Plan, so note the version you map to.
Summary
AI governance maturity is the distance between the controls you describe and the evidence you can show for them, system by system. Pull three or four AI systems from different parts of the business and score the six rows against them. Then give the weakest row an owner and a date.