An AI governance maturity model helps a board judge whether AI oversight is evidenced, repeatable and improving. The useful test is not the score. It is whether each material AI system has an owner, a control, evidence, review and a decision route.
Use the assessment when approving new AI use, reviewing risk appetite, or deciding whether to commission assurance. For a UK board in 2026, maturity must be measured against use, risk and evidence. The House of Commons Library briefing published on 10 June 2026 describes UK AI as regulated in context, through existing legal frameworks rather than one AI-specific statute. That makes a maturity score useful only if it points to the duties, regulators and artefacts that apply to the systems you run.
Key takeaways
- Maturity is not a badge or benchmark. It is the board's evidence that AI use is known, controlled, reviewed and improved.
- The useful scale runs from inventory to assurance: list the systems, approve the uses, operate controls, measure exceptions, then test the framework.
- Assess material AI systems separately. Averaging a low-risk drafting assistant with a model that informs decisions about people hides the risk the board needs to see.
- Map the assessment to UK regulator principles, ISO/IEC 42001, the NIST AI RMF, data protection and cyber security guidance. No single framework answers every board question.
- The next decision should be practical: take the Scorecard for a baseline, then commission a diagnostic if the evidence is missing or scattered.
How to use an AI governance maturity model
The model should help the board make decisions, not decorate a slide. Its purpose is to answer five questions about each material AI use:
- Do we know this system exists and what it does?
- Has a named owner accepted accountability for it?
- Which policy rule or risk appetite statement governs it?
- Which control operates, and what evidence proves it?
- Who reviewed the evidence, and what changed as a result?
Those questions keep the assessment close to board work. They support approval, risk acceptance, investment and assurance. They also stop the organisation confusing general enthusiasm about AI with governed use of AI.
The right unit of assessment is the system or use case, not the organisation as a whole. A customer-service summariser, a board-paper drafting assistant and a model that informs housing allocation decisions carry different risks. They should not be collapsed into one corporate average. The board can still ask for an overall view, but the backing evidence should sit in the system register and the AI risk register, where an individual risk can be traced to an owner and dated evidence.
This is also why maturity belongs with the questions every UK board should ask about AI, not with a generic technology dashboard. The chair does not need a model architecture lesson. The chair needs to know which decisions can be affected, which controls hold, and which evidence would be shown to a regulator, auditor or counterparty.
What the board needs to decide
A board-level assessment should end in decisions. If it only produces a score, it has failed.
- Scope: Which uses count as material AI for this organisation, including embedded supplier features and shadow AI adopted by teams?
- Ownership: Who owns the register, who owns each system, and who can pause or reject an AI use if the control evidence is weak?
- Risk appetite: Which uses are prohibited, which need board or committee approval, and which can be approved by management?
- Evidence standard: What artefacts must be available before go-live: DPIA, equality impact assessment, supplier due diligence, test result, disclosure text, human-review route, incident plan?
- Assurance rhythm: Which evidence comes to the board, how often, and who tests whether it is true?
- Target level: What level is proportionate for each use case? Not every AI tool needs certification-level assurance, but every material use needs a traceable control.
The GOV.UK AI Playbook, published on 10 February 2025, is useful because it treats AI as a life-cycle and assurance problem, not only as a procurement or policy problem. It asks government organisations to know AI's limits, use it lawfully, use it securely, keep meaningful human control at the right stage, manage the full life cycle, work with commercial colleagues early, and use assurance alongside organisational policies.
For listed companies, the FRC's UK Corporate Governance Code 2024 also matters as a board discipline. The Code has applied since financial years beginning on or after 1 January 2025, with Provision 29 applying from 1 January 2026. It expects boards to make a declaration on the effectiveness of material internal controls. AI is not named as a special category there. That is the point: if AI affects material operations, compliance or reporting, its controls need evidence like any other material control.
Controls and evidence at each maturity level
Use a five-level scale, but read it as a set of board tests. A level is not achieved because someone says the organisation is mature. It is achieved when the evidence in the right-hand columns exists and is current.
| Level | Board test | Control and evidence | Typical owner |
|---|---|---|---|
| 1. Unmapped use | Can we list where AI is already being used? | Discovery exercise, shadow-AI log, supplier feature review, initial system register | Company secretary, risk lead or CIO |
| 2. Approved use | Has each material use been approved against policy and risk appetite? | AI policy, approval threshold, documented owner, go-live decision record | Executive owner with risk or compliance |
| 3. Controlled use | Does a control operate before harm can occur? | Human-review route, access restriction, test record, DPIA or equality assessment where relevant | System owner and control owner |
| 4. Measured operation | Do we know whether the control is working in live use? | Exception log, incident record, model-change record, complaint or redress log, periodic metric review | System owner, risk and internal audit |
| 5. Assured improvement | Has independent or second-line review changed the framework? | Management-review minutes, internal audit finding, remediation plan, certification or external assurance evidence where proportionate | Board, audit committee or designated board committee |
The jump from level 3 to level 4 is where many boards overstate their position. A system can have a pre-deployment test and still be unmeasured in use. Live AI systems change through data drift, model updates, prompt changes, supplier releases, user workarounds and new downstream effects. A maturity assessment should therefore ask for dated operating evidence, not only launch evidence.
The NCSC guidelines for secure AI system development, published on 27 November 2023, make the same life-cycle point for security. They divide the work into secure design, secure development, secure deployment, and secure operation and maintenance. A board maturity scale should follow that logic: design controls are not enough if deployment and operation are not measured.
How the framework mapping should work
No board should invent its own maturity language from scratch. The assessment should map to recognised sources, with a simple rule: each framework line must resolve into an artefact the board can request.
| Source | What it contributes | Board evidence to ask for |
|---|---|---|
| UK government's AI regulation response | The 6 February 2024 response confirmed a regulator-led approach using cross-sector principles, including safety, transparency, fairness, accountability and contestability | Principle-to-control map for each material system |
| ISO/IEC 42001 | The international AI management-system standard for establishing, maintaining and improving an AI management system (AIMS) | AIMS scope, AI policy, risk assessment, impact assessment, control selection, management-review evidence |
| NIST AI RMF | A voluntary framework whose core is operationalised through Govern, Map, Measure and Manage | Register fields for owner, context, measure, treatment and residual risk |
| ICO AI and data protection guidance | Data protection governance, transparency, lawfulness, accuracy, fairness, security and individual rights for AI using personal data | DPIA, lawful-basis analysis, fairness assessment, transparency material, human-review route where required |
| NCSC secure AI guidelines | Security across design, development, deployment and operation | Threat model, security test, access control, monitoring and incident process |
| FRC UK Corporate Governance Code 2024 | Board discipline around material controls, risk and evidence | Board or audit committee record showing how AI controls were reviewed and what action followed |
There is one important caveat. The ICO's guidance page says it is under review because the Data (Use and Access) Act came into law on 19 June 2025. Treat data-protection maturity as live work, not a one-off compliance statement. Date the assumption, record the guidance version used, and assign someone to refresh the assessment when final guidance changes.
If the organisation is considering certification, read the distinction carefully. ISO/IEC 42001 gives the management-system structure; it does not prove that a particular model is safe. NIST gives a risk practice; it does not issue a certificate. Our comparison of ISO 42001 and the NIST AI RMF sets out that difference in more detail. For maturity work, the practical answer is often both: ISO for the management system, NIST for the risk method inside it.
Common mistakes in maturity assessments
Treating level 5 as the goal for every system. That wastes assurance effort and weakens judgement. A low-risk internal summariser may only need policy, disclosure and light monitoring. A system that informs a decision about a tenant, employee, pupil, customer or patient needs stronger evidence before use and stronger review after use.
Scoring the organisation, not the decision. A single score hides the part the board needs to govern. Ask for the lowest maturity level among material systems, not only the average.
Counting policies as controls. A policy is an instruction. A control changes what can happen. Examples include an approval gate before deployment, a read-only data role, a human-review workflow, a supplier assurance requirement, a test threshold or an incident escalation route. The UK AI governance framework is useful only when policy sentences connect to operating controls and evidence.
Missing supplier and embedded AI. AI now arrives inside document suites, CRMs, finance tools, case-management systems and search products. A mature register includes third-party AI features, not only systems the organisation deliberately built.
Letting the score freeze. Maturity should change when systems change. A new supplier model, a new use case, a complaint, a data incident, a failed bias test or a regulator update should reopen the assessment.
Using the assessment to avoid a decision. Boards sometimes ask for a maturity exercise because the real question is uncomfortable: should we pause, fund controls, reject a supplier, tell users, or accept a residual risk? The maturity work is valuable only when it forces that question into the minutes.
Next step
Start with the Board AI Scorecard if you need a fast baseline across board oversight, risk, controls and assurance. It is the right route when the board wants to know where to look first.
Use the AI governance diagnostic when the gaps need to be mapped into evidence, owners and a board-ready plan. The diagnostic is designed for the work this article describes: tracing material AI systems from use case to policy, control, evidence, framework mapping and next decision.
Last reviewed: 18 June 2026.
Sources: House of Commons Library: AI regulation in the UK · GOV.UK AI Playbook · UK government AI regulation response · ISO/IEC 42001 · NIST AI RMF · ICO AI and data protection guidance · NCSC secure AI guidelines · FRC UK Corporate Governance Code 2024
