Updated 17 October 2026. An adoption percentage and a governance percentage may measure different things. Subtracting them can produce a dramatic headline without producing a useful management decision. Earlier unsourced figures have been removed.
Measure the control you can inspect
Choose a specific claim about the system. For example: an agent cannot write outside its permitted scope. Define the test conditions, run the test and retain the result. That produces evidence the team can examine and challenge.
Distinguish three states: demonstrated under stated conditions, failed under stated conditions and not yet tested. A single maturity score can obscure those differences. A missing test should not receive a comforting average from unrelated controls.
An illustrative dashboard can show the controls relevant to a release and link each status to its evidence. Include the version and date so reviewers can tell whether the result still applies. The dashboard should lead to the record, not replace it.
Avoid presenting this as a universal maturity model. The relevant controls depend on the use, permissions and consequences. A useful local measure is one that changes a decision when the evidence changes.
| Question | Evidence or action |
|---|---|
| Demonstrated | Test conditions and result |
| Failed | Observed failure and response |
| Unknown | Missing evidence and owner |
The practical next step
Start with the few claims that matter most to the next release. Measure them honestly before inventing an enterprise-wide number that nobody can explain.
Keep the resulting decision, its owner and unresolved questions in a short decision record. For claims about agent behaviour, connect the decision to evaluation evidence rather than relying on a successful demonstration alone.
Further primary reading: NIST AI Risk Management Framework. The review map and product recommendations above are my analysis, not a certification or a legal assessment of a particular deployment.
