Runtime proof · OVERT
An AI Governance Maturity Model: From Policy to Proof
Mature AI governance connects policy to configured controls, consequential actions, and scoped operational evidence. A signed record makes covered claims checkable; it does not prove complete coverage, control effectiveness, safety, or compliance.
Many AI governance maturity models reward what an organization has written down. A model that stops at “documented” measures intent, not operational evidence. This guide proposes a different top stage: not policy on a page, but independently checkable records about covered events. Policies, audit narratives, and logs remain useful, but they answer different questions.
The gap widens as AI systems begin to act — calling tools, invoking other agents, and making decisions at the inference boundary. A control described in policy and a configured control path that records a decision against live traffic are two different things. A stronger maturity model makes that distance, and the limits of the resulting evidence, explicit.
Why most AI governance maturity self-assessments are inflated
Ask a governance leader to score their program and the number usually comes back high. The reason is structural, not vanity: most AI governance maturity rubrics reward artifacts. A documented model inventory, an approved AI policy, a completed risk assessment, a signed-off architecture diagram — each earns a tick, and the ticks add up to a flattering score.
Those artifacts state that something was decided or built. By themselves, they do not establish what a configured control path reported when a real prompt arrived, whether a redaction decision was recorded before a covered egress event, or whether an override was captured when a human took control. A program can be richly documented while lacking event-level evidence.
This is the trap that makes ai assurance maturity look further along than it is. Documentation maturity and proof maturity are different axes. You can max out the first while sitting near zero on the second — and you will not know, because the instruments you used to grade yourself only ever looked at paper.
A maturity model with five stages
A useful AI governance maturity model treats each stage as a strictly higher bar of demonstrability — not a longer binder. Here are five stages, from least to most demonstrable.
Stage 1: Ad hoc
There is no written policy. AI use is informal and uninventoried. Decisions about acceptable use, data handling, and model selection live in people’s heads. Most organizations have already left this stage, at least on paper.
Stage 2: Policy
A formal AI policy exists. It names principles, prohibited uses, and accountable owners. This is the floor that frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001 help establish, and it is real progress. But policy describes intent. Nothing here proves that the stated rules touch production behavior.
Stage 3: Controls defined
Policy is translated into specific, named controls: input filtering, output classification, access scoping, human-in-the-loop checkpoints, escalation paths. Each control has an owner and a description. This is where many mature-looking programs actually sit. The controls are designed — but design is a claim about the future, not a record of the past.
Stage 4: Controls enforced at runtime
Configured controls now sit on the relevant inference, tool-call, or agent path. In-scope actions can be allowed, blocked, redacted, or escalated. This is a genuine leap from intention to operation. But operator-controlled logs alone still require a reviewer to assess their integrity, retention, selection, and coverage.
Stage 5: Independently verifiable evidence
The top of the model is not “more enforcement.” It is scoped, independently verifiable evidence. At this stage, each in-scope event on the configured path — permit, deny, override, escalation, or response — can produce a tamper-evident record an outside party can check. A data-minimizing configuration can avoid routinely exporting protected content. The record makes supported signatures, covered fields, and reported outcomes checkable; it does not prove complete collection, control effectiveness, safety, or organisational independence.
Teams can use the model to expose assumptions between defined controls, configured enforcement, and supported evidence. A maturity score should not imply a level the organization cannot demonstrate with stated scope and exclusions.
What the top stage actually requires
The jump from Stage 4 to Stage 5 is the hard one, and it is where an open standard earns its place. OVERT is the open, royalty-free format Glacis uses for signed operational records. It can make covered fields and recorded control outcomes independently checkable without replacing policy, risk management, evaluation, or the governance platform above it.
OVERT is organized around four commitments that map almost exactly onto the failure modes of lower maturity stages:
- Evidence with explicit scope. The artifact states the identity, covered fields, configured control claim, and recorded outcome.
- A data-minimizing path. A configured deployment can keep protected content local while bounded verification material travels.
- Independent checking. A reviewer can validate supported signatures and fields without accepting a Glacis conclusion; the cryptography does not establish organizational independence by itself.
- Measurement, not adjective. Coverage should name denominators, exclusions, and bypass paths rather than relying on “robust” or “comprehensive.”
In practice, a Stage 5 program can produce signed OVERT receipts for covered events. A verifier can check supported signatures, covered fields, and the recorded control outcome; the program must separately account for what was in scope, what was excluded, and any bypass paths. A configured data-minimizing path can support reconstruction without routinely exporting underlying content, but the receipt does not prove that no other data path exists.
The most recent version, OVERT 1.1.0, was released on 11 June 2026 as a backward-compatible, additive update to 1.0. It adds a normative Annex G covering local evidence retrieval and retention integrity, a transport binding for cross-boundary attestation, an automated auditor-discovery endpoint protocol, and a reference schema for the control-action artifact. The conformance requirements that define the standard’s core stayed unchanged from 1.0, so a program built against the standard does not have to relitigate its foundation to adopt the new capabilities.
How to use this model
Score yourself twice. First grade your documentation maturity — policies, defined controls, completed assessments. Then grade your proof maturity — what you could hand an independent auditor that does not rely on your own word. The gap between the two scores is your real backlog.
Then work the gap one control at a time. Pick the controls that matter most if they silently fail — the redaction step before a covered egress event, the human checkpoint on a high-risk action — and move them from “defined” to “configured on the action path” to “independently checkable for stated events.” Maturity is not the length of your policy library. It is the precision of the claims and evidence a reviewer can examine.
To see what the verification step establishes, Verify a record. To discuss a system you already run, Talk to us. The standard itself is open and published at overt.is.