AI Governance Maturity
Where does your organization actually stand ?
A lot of organizations cannot answer the question that determines whether they are genuinely compliant with the EU AI Act or merely believe they are : where are we on AI governance maturity ?
The answer for many organizations is that they haven’t a clue. They have policies, sometimes. They have conducted a risk assessment, perhaps at least once. They have AI systems in production that someone has reviewed. But when pressed to characterize their state against recognized dimensions of AI governance maturity, against the structural requirements the Act imposes on high-risk providers, against the operational evidence regulators will expect to see; they cannot produce a defensible answer.
This is not a failure of effort. It is a failure of vocabulary. Without a maturity model, “we are working on AI governance” can mean anything from “we have a draft policy” to “we have an ISO 42001-certified management system with operational post-market monitoring.” Both statements are technically true and operationally incomparable. Maturity models exist to make the comparison possible.
This is the seventh article in our ten-part series on AI governance and compliance. The previous six have covered the regulatory landscape, the high-risk system obligations, GPAI model obligations, the February 2025 enforcement cliff, and the agentic AI governance gap. This article focuses on how to characterize your organization’s state honestly against what the regulation actually requires; and why the answer matters more than the framework you use to reach it.
Why AI Governance Maturity Is Hard to Self-Assess
Four structural reasons make AI governance maturity uniquely difficult to self-assess compared to other governance domains.
First, the obligation surface is fragmented. A single high-risk AI system may trigger obligations under Articles 9, 10, 11, 12, 13, 14, 15, 16, 17, and 72 simultaneously : risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness, quality management, post-market monitoring, and serious incident reporting. Organizations may have addressed some of these thoroughly and not others at all, and the resulting state is not on a single axis. A maturity assessment that asks “where are we on AI governance?” without decomposing the question into the dimensions that actually map to obligations will produce a meaningless average.
Second, the documentation discipline gap is invisible from inside the organization. Organizations that have done the work (e.g. that have risk records, oversight procedures, monitoring systems) but cannot produce the evidence to a regulator within 24 hours are not mature. Organizations that have not done the work but believe they have because they have a policy document appear mature from the inside. Both self-assessments can be sincerely held. Both are wrong. The difference between them is evidence architecture, not intention.
Third, the agentic AI dimension was not in the original maturity frameworks. Article 6 of our series documented how the existing EU AI Act provisions were not designed for autonomous agents capable of dynamic goal revision, tool chaining, and multi-agent coordination. Most maturity models in the AI governance space were published before the agentic turn. The maturity levels they define may describe a state that is genuinely mature for static AI but inadequate for agentic deployment. Self-assessment against a pre-agentic model can give organizations false confidence about their readiness for the systems they are now actually deploying.
Fourth, the obligation surface depends on your role, and many organizations hold multiple roles simultaneously. A provider that develops and places a high-risk AI system on the EU market carries obligations under Articles 9 through 17 : risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness, QMS, post-market monitoring. A deployer that uses a high-risk AI system in its operations carries a distinct, non-overlapping set of obligations under Article 26 (operational human oversight, six-month log retention, notification of affected persons on consequential decisions, cooperation with national competent authorities) and, where applicable, the Fundamental Rights Impact Assessment under Article 27. The two obligation surfaces do not share controls. An importer or distributor under Article 24 carries yet another subset. Maturity assessment that produces a single composite score without decomposing by role will conflate obligations that are genuinely separate, and the resulting gaps will not be visible in the headline number. Organizations that both build and deploy high-risk AI systems must run parallel maturity assessments against each role’s obligation surface.
Four Maturity Models Worth Knowing
Four maturity models have emerged as the reference points that organizations doing serious self-assessment work tend to converge on. They are not interchangeable, and none of them is the canonical answer. But taken together they cover the dimensions that matter.
AIGN — Five Levels from Ad Hoc to Self-Governing
AIGN (now.digital / AIGN Global, v1.0 July 2025) defines five maturity levels: Ad Hoc, Engagement Certificate, Trust Label (Basic), Trust Label (Advanced), and Self-Governing. Each level has minimum requirements (for the Basic Trust Label), an 8-dimension AIGN OS-based assessment covering 25+ governance criteria; for the Advanced tier, deep technical validation and third-party governance review; for Self-Governing, board defensibility, quarterly surveillance reviews, and continuous operational monitoring through the Continuous Monitoring API. The progression tracks the organization’s ability to demonstrate governance, not just to describe it.
AISM — Five Levels Plus a Sovereignty Matrix
AISM (Cyber Strategy Institute, v3.0 March 2026) defines five maturity levels scored on a 1.00–5.00 scale across ten topics grouped in five pillars (Shield, Ledger, Circuit Breaker, Command Center, Learning Engine). What distinguishes AISM is its scoring methodology; each topic is rated across three metrics (Coverage, Robustness, Sovereignty Assurance) using three evidence categories : documentary (policies, architecture documents), operational (logs, dashboards, SIEM integration), and attestation (penetration tests, red team findings, compliance audits). A maturity claim supported only by documentary evidence is not equivalent to a maturity claim supported by operational evidence; and a regulator will recognize the difference. The AISM Sovereignty Matrix separately positions organizations across four zones (Runaway Autonomy, Autonomous Operations, Guarded Autonomy, Human Controlled) based on AI autonomy versus human control; exposing mismatches between what an organization deploys and what it can govern.
AgentID — Operational Maturity for Production AI
AgentID targets teams running AI in production workflows. Its five levels (Ad Hoc, Policy-Led, Instrumented, Controlled, Audit-Ready) track operational capability rather than documentation completeness. The eight capability pillars (Runtime Controls, Observability, Audit Trails, Compliance Evidence, Human Oversight Design, Agent/Tool Execution Governance, Browser/Public AI Governance, Governance Operating Model) place equal weight on the technical substrate that produces evidence and the governance process that consumes it.
Digital Applied — Enterprise Progression for Agent Deployment
Digital Applied (March 2026) defines five stages of organizational progression for AI agent deployment : Exploration, Experimentation, Integration, Orchestration, Autonomous Operations. It is the most deployment-centric of the four models; it measures where the organization is on the path from first experiments to fully autonomous production operations. Higher stages presuppose the governance substrate of the previous stages; Autonomous Operations without Orchestration-level controls is the failure mode the model is designed to surface.
What Each Maturity Level Means Operationally
The shared insight across the four models is that maturity levels are not bureaucratic milestones; they describe operationally distinct states with different regulatory exposure.
At Ad Hoc / Exploration level, AI systems are deployed without systematic governance. Risk assessments are informal or absent. Documentation exists in scattered locations : chat threads, design documents, individual engineers’ notebooks. There is no defined process for human oversight because the concept has not been operationalized. Logging is whatever the platform emits by default. The organization believes it is acting responsibly because the people involved are competent and well-intentioned. It is not audit-ready in any meaningful sense.
At Policy-Led / Engagement Certificate level, governance has been formalized in documents. An AI policy exists. A risk assessment template has been used; often once. Roles are defined. The structural foundation is in place, but the operational infrastructure to enforce it is not. Documents have not been translated into processes ; processes have not been wired into systems. A regulator that asks to see evidence of compliance will see documents. What the regulator will not see is evidence that the documents describe what is actually happening.
At Instrumented / Trust Label (Basic) level, the organization has moved from documenting governance to instrumenting it. Logs are retained and queryable. Risk records are linked to system versions and updated when systems change. Human oversight is technically implemented, not just procedurally described. The first conformity assessment can be approached with confidence because the evidence base exists. This is the level at which most EU AI Act obligations become credibly demonstrable rather than aspirational.
At Controlled / Trust Label (Advanced) level, governance operates continuously. The QMS is integrated with the change management process; every model update triggers a documented risk review. Post-market monitoring feeds back into risk management automatically. Internal audits are scheduled and produce findings that are tracked to closure. The organization can answer questions from a regulator about its AI systems with evidence retrieved in hours, not weeks. This is the level at which the QMS requirement of Article 16 is most credibly satisfied; not because the organization has a QMS, but because the QMS is functioning as the structural backbone that ties the other requirements together.
At Audit-Ready / Self-Governing / Autonomous Operations level, governance is embedded in the operating model. The distinction between “doing governance” and “doing the work” dissolves; governance is what the work looks like when it is done correctly. Surveillance is continuous, not periodic. The organization’s governance posture is independently verifiable, not just self-attested. This is the level at which board-level defensibility, third-party attestation, and continuous regulatory readiness converge.
The progression is not automatic. Organizations spend years at Policy-Led level because the work to move from documents to instrumentation is really difficult. It involves system engineering, log architecture, change management discipline, and process redesign; not just policy authorship. The maturity models expose this gap; they do not close it.
Where Article 16’s QMS Requirement Fits in the Maturity Picture
Article 3 of this series covered the technical detail of Article 16 : the quality management system requirement for providers of high-risk AI systems. The minimum QMS components include document control, change management, risk management documentation, post-market monitoring procedure, non-conformity and incident response, internal audit, and management review.
What the previous article did not cover is where QMS implementation sits on the maturity scale. The truth is that a functioning QMS is the dividing line between Policy-Led and Instrumented maturity; and for quite a lot of organizations, building that QMS is the work that takes the longest.
The reason is structural. Document control, change management, incident response, internal audit, and management review are not AI-specific obligations. They are generic management system disciplines that apply across regulated industries; medical devices, pharmaceuticals, aviation, financial services. Organizations that have already implemented ISO 9001, ISO 13485, ISO 27001, or similar management system standards have the structural foundation on which an AI-specific QMS can be built. They can satisfy the QMS components of Article 16 by extending an existing management system rather than building one from scratch.
ISO/IEC 42001:2023 (the AI management system standard) is the most direct regulatory bridge. Organizations with ISO 42001 certification are presumed to satisfy Article 16. This makes the QMS implementation timeline closely tied to the ISO 42001 certification timeline, which for most organizations is a 12–18 month undertaking when starting from a blank slate, or 4–8 months when extending an existing management system.
Organizations without an existing management system face a different problem. They cannot satisfy Article 16 by writing a QMS document; the regulation requires a system, not a document. A QMS without operational change management, without a functioning internal audit program, without management review that produces decisions, is documentation theatre. It does not satisfy Article 16, and it will not survive contact with a regulator who asks to see the change records, the audit findings, and the management review minutes.
The maturity implication is direct. If your organization is at Ad Hoc or Policy-Led level on the maturity scale, the QMS is the single largest gap; and it is a gap that typically requires more time, more cross-functional coordination, and more operational change than any other Article 9–17 obligation. Building the QMS is what moves an organization from Policy-Led to Instrumented, because the QMS is the mechanism by which the other obligations become sustainable rather than episodic.
What A (real) Self-Assessment Actually Requires
Real self-assessment against any of these maturity models requires three disciplines that many organizations find difficult.
Evidence over assertion. Each maturity claim must be backed by evidence in one of the three categories AISM defines (documentary, operational, or attestation) and the maturity score must reflect the weakest category. An organization whose QMS exists in documented form but has never been tested through an internal audit is not at the maturity level its policy documentation suggests. Self-assessment that confuses the existence of a document with the existence of a process produces inflated maturity scores and, eventually, regulatory exposure.
Decomposition by obligation. A single overall maturity score is less useful than decomposed scores against the dimensions that map to EU AI Act obligations. An organization may be at Instrumented level on logging and Controlled level on human oversight while remaining at Ad Hoc level on post-market monitoring. A maturity assessment that produces an average hides exactly the gaps that matter. Decomposed scoring is harder to do well; and that is why it is more useful.
Honest agentic readiness check. Article 6 documented the governance gap between existing EU AI Act provisions and agentic AI reality. If your organization is deploying agentic systems, your maturity assessment must include a separate check on the dimensions that agentic operation introduces (runtime observability, behavioral drift detection, multi-agent coordination controls) rather than allowing your pre-agentic maturity score to imply agentic readiness it does not have.
The Right Question to Ask First
The maturity model question is the wrong first question. The first question is: what is the highest-risk AI system we have in production, what role does our organization hold with respect to it (provider, deployer, importer, distributor, or some combination), what obligations does each role trigger under the EU AI Act, and what is the maturity level we need to credibly satisfy each of those obligations?
Once that question is answered for the highest-risk system, the maturity model becomes a tool for diagnosing the gap; not a framework to adopt for its own sake. The four models referenced above can each serve that diagnostic purpose. The choice between them matters less than the discipline of using one of them honestly.
The organizations that take AI governance maturity seriously are not the ones with the highest scores. They are the ones whose scores are accurate. Inaccurate self-assessment is the failure mode that produces regulatory exposure; and it is the failure mode that many organizations are currently in.
Download our free AI Governance Maturity Self-Assessment Workbook
---
Next: The 24-Hour Compliance Test — What Regulators Actually Expect to See