Common signs include multiple approved-looking policies, limited live monitoring, unclear ownership for agent access, and no reliable way to explain what an AI system did during a session. Another warning sign is heavy reliance on manual review after the fact. That usually means the organisation has a governance story, but not an operational control model.
What “mature on paper” usually looks like
A programme can look mature because the documents are there: policies, standards, review boards, and approval workflows. The weakness shows up when those artefacts do not translate into day-to-day control. In practice, maturity means the operating model is measurable, enforced, and visible, not just documented.
One common gap is that governance is treated as proof of control. A well-written policy can coexist with weak telemetry, limited exception tracking, and no evidence that controls are working during live sessions. That is especially true when an AI system can act, call tools, or make decisions faster than a human review cycle can keep up.
Another tell is the absence of clear ownership for who can grant, review, or revoke agent access. If nobody can answer who is accountable for access decisions, what gets logged, and when access is removed, the programme is still in an early governance stage even if the org chart and policy suite look complete.
Where operational weakness becomes visible
The most reliable sign is that the organisation cannot reconstruct what happened in a session without manual detective work. If teams cannot explain which prompts, tools, data sources, approvals, or exceptions were involved, then the programme lacks operational traceability. That usually means control evidence exists only after the fact, not at the point of action.
Another practical indicator is heavy dependence on human review as the primary safeguard. Manual review can be useful for escalation and exception handling, but if it is doing the work that telemetry, policy enforcement, and runtime checks should do, the programme is compensating for missing controls rather than operating maturely.
The same pattern often appears when risk reviews are periodic but runtime oversight is sparse. For AI governance to be real, it must cover the live behaviour of systems, not only the design-time intent. The gap between “approved” and “observable” is where weak programmes usually show themselves.
What a genuinely mature AI operating model should demonstrate
A mature programme has a clear line from policy to control to evidence. It can show who owns each control, what signal proves the control is active, and what happens when the control fails. It also has enough instrumentation to answer basic accountability questions without reconstructing events from scattered tickets and chat logs.
That is why ISO/IEC 42001:2023 AI Management System Standard is a useful reference point: it frames AI governance as an operating system, not a paper exercise. For practitioners, the important test is whether the programme can sustain transparency, accountability, and continual improvement in live use, not just in a documented policy stack.
Maturity also shows up in exception handling. A strong programme knows which deviations can be accepted, which require escalation, and which should block deployment or runtime use. If those decisions are informal or inconsistent, the organisation may have a governance story, but it does not yet have a dependable control model.
Risk and Threat Considerations
When an AI programme is stronger in documentation than in operations, the main risk is false assurance. Leaders may believe access, oversight, and accountability exist because they have been approved on paper, while the real environment still allows unobserved actions, weak session traceability, and delayed response to misuse.
Failure mechanism: Weak runtime monitoring, unclear ownership, and after-the-fact review create a gap between authorised intent and actual system behaviour, which makes it hard to detect misuse, prove accountability, or contain harm quickly.
Impact: The organisation can miss unsafe actions, over-trust the programme’s posture, and discover control failures only after an incident, audit challenge, or business impact event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | AI programme maturity depends on translating governance context into operating reality. |
| 5.2 — AI policy | The question contrasts written policy with operational effectiveness. | |
| 8.2 — AI risk treatment | Weak practice shows up when risks are reviewed on paper but not controlled in operations. | |
| Recommendation — Use context analysis to align AI governance expectations with live operational controls. Turn AI policy into enforceable controls with measurable evidence of execution. Implement risk treatment actions that produce runtime evidence, not just approvals. | ||
| NIST AI RMF | GV — Govern | This is a governance-versus-operations maturity question for an AI programme. |
| MAP — Map | Understanding where AI is used and who owns it is central to spotting paper-only maturity. | |
| MEASURE — Measure | The key signal is whether controls are measurable in live use, not just documented. | |
| Recommendation — Establish accountable governance that maps directly to operational control evidence. Inventory AI use cases, owners, and dependencies so accountability is explicit. Measure live control performance and session-level traceability for AI systems. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Mature programmes need clarity on AI ownership and operating context. |
| GV.RM-03 — Risk Appetite and Tolerance | Paper maturity often exists when risk decisions are not tied to operational limits. | |
| DE.CM-09 — Continuous Monitoring | Limited live monitoring is a direct sign of weak operational maturity. | |
| Recommendation — Define who owns AI decisions, evidence, and escalation paths. Set explicit risk tolerance for AI actions that require runtime oversight or blocking. Monitor AI activity continuously to confirm controls work during actual use. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | The programme cannot explain what happened if records are not generated at session level. |
| Recommendation — Generate audit records for AI actions, approvals, and exceptions. | ||
Practitioner Guidance
What to verify: Ask whether every material AI action has an owner, a logged decision path, and a way to prove who approved or triggered it. If the answer depends on someone manually pulling records from multiple tools, the control model is weaker than the governance narrative suggests.
What to measure: Track whether runtime evidence exists for the controls the policy claims to require, such as session logs, approvals, exceptions, and revocation timing. A mature programme can show control performance continuously, not only during reviews or incidents.
Common mistake: Treating policy volume as maturity. Multiple approved artefacts do not equal operational control if teams cannot explain live behaviour, identify accountable owners, or reproduce the sequence of actions that occurred in a session.
Practitioner takeaway: Real maturity is visible when governance can be proved during operation, not just narrated after the fact.