Book a Free Strategy Call
Skip the read: talk to Walid in 30 min.
Free strategy call. We map your AI engineering team, you keep the notes.
Ask five people at the same company how mature their AI governance is and you get five different answers, because most teams have never written down what "mature" means. They point to a policy document nobody reads, or a Slack channel where someone flags risky prompts, and call it governance. That is not a level. That is a level zero with a PDF attached.
A maturity model fixes this by giving you a scale, not a vibe. Five levels, 0 through 4, each with concrete signals you can check against your own org instead of guessing. This post walks through each level, gives you a self-assessment you can run in an afternoon, and explains what actually moves you up a level, which is rarely "write more policy."
Why a maturity model beats a checklist
A compliance checklist tells you whether a document exists. It does not tell you whether anyone follows it, whether it catches the AI system your marketing team spun up last month, or whether it survives contact with a real incident. A maturity model asks a different question at every level: what actually happens when an AI system does something wrong, and who finds out first?
That question is why regulators converged on the same structure. NIST built its AI Risk Management Framework around four continuous functions, Govern, Map, Measure, Manage, rather than a static list, because risk management is a loop that has to run continuously as systems and use cases change. ISO/IEC 42001, published in December 2023 as the first certifiable AI management system standard, works the same way: it requires a management system with defined roles, ongoing risk assessment, and continual improvement, not a one-time audit. The five levels below map that same logic onto a scale you can self-score.
Related Reads
The 5 levels of AI governance maturity
| Level | Name | What it looks like in practice |
|---|---|---|
| 0 | None | No inventory of AI systems in use. No owner. Governance means "we have not had an incident yet." |
| 1 | Ad hoc | A policy document exists. Nobody checks whether teams follow it. Shadow AI is common and undetected. |
| 2 | Defined | A written framework with risk tiers, an approval process for new AI use cases, and a named owner, but enforcement is manual and inconsistent. |
| 3 | Managed | An inventory of AI systems tied to risk tier, monitoring in production, an incident process that has actually been tested, and metrics reviewed on a schedule. |
| 4 | Optimized | Governance feeds back into the business: risk data changes which use cases get approved, controls are automated where possible, and the framework updates itself as regulation and the AI system portfolio change. |
Level 0: None
There is no list of what AI systems the company runs, who owns them, or what data they touch. If you asked "which teams are using an LLM in a customer-facing workflow right now," nobody could answer with confidence. This is the default state for most companies that have not deliberately built governance, and it is far more common than leadership assumes.
At this level the biggest risk is not that governance fails. It is that nobody would know if it did. KPMG's 2025 global trust study, run across more than 48,000 people in 47 countries, found that only 30% of employees say their organization has a policy on generative AI use, even as 71% of organizations now say they regularly use generative AI in at least one business function, up from 65% a year earlier.
Level 1: Ad hoc
Someone wrote a policy, usually after a scare, a client question, or a board request. It sits in a wiki or a shared drive. Teams building or buying AI tools may not know it exists, and even if they do, there is no process that checks a new use case against it before launch. Shadow AI, tools employees adopt on their own without IT or security review, thrives here because the policy has no teeth and no visibility into what people are actually using.
You are at Level 1 if: a policy exists, but you could not name who is responsible for enforcing it, and nobody has ever been told no.
Level 2: Defined
The framework has real structure now: risk tiers (an internal chatbot answering FAQ questions is not the same risk as an AI system approving loan applications), a documented approval workflow for new use cases, and a named owner, often a cross-functional committee spanning legal, security, and the business unit. This is roughly where the EU AI Act's risk-tier logic (unacceptable, high-risk, limited, minimal) enters as a practical model even for companies with no EU exposure, because it forces the question "how much scrutiny does this specific use case need" instead of applying one policy to everything.
The gap at Level 2 is enforcement. The framework exists on paper but relies on people remembering to use it, which means it gets skipped under deadline pressure.
Level 3: Managed
This is where governance becomes operational instead of aspirational. There is a live inventory of every AI system in production, tagged by risk tier. Production systems are monitored, not just approved once and forgotten. There is an incident response process specific to AI failures (a model that starts hallucinating, an agent that takes an action it should have escalated instead), and that process has been rehearsed, not just written.
Deloitte's 2026 State of AI in the Enterprise report, a survey of 3,235 IT and business leaders across 24 countries, found that only 21% of organizations currently have a mature governance model for agentic AI, which puts most companies below Level 3 even as agentic AI adoption accelerates. Getting to Level 3 is the point where governance starts reducing incidents instead of just documenting them after the fact, and the same discipline that shows up in a Claude Code security audit (know what is running, log it, review it on a schedule) applies just as directly to governing AI decision systems.
Level 4: Optimized
Governance and the business feed each other. Data from monitoring, near-misses, and audit findings actively changes what gets approved next and how controls are tuned, rather than governance being a fixed gate that new AI use cases pass through once. Controls that can be automated (access logging, PII redaction checks, escalation triggers) are automated instead of relying on someone remembering to check a box. The framework itself has an update cadence tied to regulatory change (EU AI Act amendments, new NIST profiles) and to the company's own AI portfolio growing.
Very few organizations sit here today. That is not a failure signal for anyone below it. Level 3 with a real incident process beats a Level 4 aspiration that exists only in a slide deck.
Free weekly brief
Steal our production automations
The exact n8n flows, Claude Code setups, and prompts we ship for clients, broken down step by step. No spam, unsubscribe anytime.
Self-assessment: score your organization in 10 questions
Answer yes or no. Each "no" tells you where to focus next, more than the total score does.
- Do you have a current, complete inventory of every AI system in production, including tools individual teams adopted without a formal request?
- Does every AI use case get a risk tier assigned before launch, not after?
- Is there a named individual (not a committee with no single owner) accountable for AI governance?
- Has your incident response process for an AI failure been tested in the last 12 months, even as a tabletop exercise?
- Do you monitor AI systems in production for drift or degraded output, or only check quality at launch?
- Can you tell, within a day, which teams are using a specific AI vendor or model if that vendor has a security incident?
- Do employees have an approved path to request a new AI tool, one that is faster than going around the policy?
- Does your governance framework reference a named standard (NIST AI RMF, ISO/IEC 42001, or an equivalent), or is it built from internal opinion alone?
- Is governance data (incidents, overrides, near-misses) reviewed on a recurring schedule by someone with authority to change the framework?
- Has your framework been updated in the last 12 months to reflect a regulatory change or a new class of AI use case (agents, generative AI, third-party AI features)?
0 to 3 yes answers: Level 0 to 1. Start with an inventory. You cannot govern what you cannot see.
4 to 6 yes answers: Level 2. You have structure. The next move is enforcement and monitoring, not more policy.
7 to 9 yes answers: Level 3. You are ahead of most of the market. Tighten the feedback loop between incidents and framework updates.
10 yes answers: Level 4. Rare, and worth documenting as a reference for other functions or business units still catching up.
How to move up a level
The jump between levels is never "write a better document." Here is what actually moves the needle at each transition.
0 to 1: Run a 2-week AI inventory sweep. Ask every department head to list every AI tool their team uses, including ones IT never approved. You will find more than you expect; that gap is the whole point of doing it.
1 to 2: Define 3 risk tiers, nothing more granular at first, and require every new AI use case to get a tier assignment before launch. Name one accountable owner, a person, not a committee.
2 to 3: Build the inventory into something living, not a spreadsheet reviewed once a year. Add monitoring to at least your highest-risk tier. Run one incident tabletop exercise before you need the real thing.
3 to 4: Automate the controls that are currently manual (access checks, PII scanning, escalation triggers). Put governance review on the same calendar cadence as a security review, not an annual audit. Tie framework updates to a named trigger (a new regulation taking effect, a new AI capability entering production) instead of an arbitrary schedule.
What this means for you
- Score yourself honestly before you build anything new. Most organizations overestimate their level because a policy document exists.
- Fix visibility before you fix policy. You cannot govern AI systems you do not know are running.
- Enforcement, not documentation, is what separates Level 2 from Level 3. A framework nobody follows is not a framework.
- Borrow structure from NIST AI RMF or ISO/IEC 42001 rather than inventing your own risk tiers from scratch. Both already answer the "how much scrutiny does this need" question.
- Treat Level 4 as a direction, not a deadline. Level 3 with real monitoring beats an aspirational governance deck that never gets tested.
If you are earlier than you would like on this scale, the AI governance framework guide walks through the charter-to-review build in order, and how to implement an AI governance framework covers the phased build in more detail.
FAQ
What is an AI governance maturity model? An AI governance maturity model is a scale, typically 5 levels from none to optimized, that describes how systematically an organization identifies, controls, and monitors the AI systems it uses. It gives teams a concrete way to self-assess instead of relying on whether a policy document exists.
What level is most companies at right now? Most organizations sit at Level 1 or 2. Deloitte's 2026 State of AI in the Enterprise report found only 21% of organizations have a mature governance model for agentic AI, meaning a strong majority have not reached what this model calls Level 3.
How long does it take to move up one level? An inventory sweep to reach Level 1 can happen in 2 weeks. Reaching Level 2 with defined risk tiers and an owner typically takes 4 to 8 weeks. Level 3, with live monitoring and a tested incident process, usually takes a full quarter because it requires building infrastructure, not just documentation.
Do we need to follow NIST AI RMF or ISO/IEC 42001 exactly to reach Level 3 or 4? No. Both are reference structures you can borrow risk-tiering and control logic from; neither requires certification to be useful internally. ISO/IEC 42001 does offer formal certification against clauses 4 through 10 plus Annex A controls if you need to prove governance maturity to a customer or regulator in writing.
Is a maturity model different from a compliance checklist? Yes. A checklist verifies that documents and approvals exist. A maturity model asks whether governance actually functions when something goes wrong, whether anyone would notice an unapproved AI tool, and whether the framework changes based on what incidents teach you.
What is the single fastest way to raise our level? Run the AI inventory sweep first, regardless of your current level. Every level above 0 depends on knowing what AI systems exist in your organization, and most companies discover the gap is bigger than they assumed the moment they actually ask every department to list its tools.
Sources: NIST AI Risk Management Framework, ISO/IEC 42001:2023, Deloitte, "State of AI in the Enterprise" (2026), KPMG, "Trust, attitudes and use of AI"
Continue Reading
AI Governance Jobs: Roles, Salaries, and Whether You Need a Full-Time Hire (2026)
AI governance job postings are up 150% year over year, but the titles behind them are not standardized yet. Real titles, real salary ranges from IAPP, Axial Search, and Heidrick and Struggles, and the honest question to ask before you open a req: do you need a hire, or a framework.
GTM Engineer Jobs: What Postings Actually Ask For (and What They Pay)
GTM engineer job postings grew 205% year over year. Here is what 1,000 real listings actually require, what they pay across three independent sources, and when to hire full-time versus bring in outside help.
AI Readiness Assessment: The 5-Dimension Scorecard That Predicts Success (2026)
Most companies pilot AI before they assess whether they are ready to run it in production. Here is the five-dimension scorecard we use instead, sourced Gartner and MIT research on why that gap sinks projects, and what a low score actually means.
Book a Free Strategy Call
Building this in production?
Walid runs a 30-min call to map your AI engineering team. Free, no slides.
Free weekly brief
Steal our production automations
The exact n8n flows, Claude Code setups, and prompts we ship for clients, broken down step by step. No spam, unsubscribe anytime.

Robel engineers production-grade automation pipelines at AY Automate, focused on integrations, reliability, and the systems that keep client workflows running.



