Appendix B: AI Governance Maturity Model
This appendix gives an organisation a way to judge how far it has come in adopting the practices in this book, and what to do next. The model has five levels (Exploring, Piloting, Industrialising, Governing, Optimising) and eight dimensions (data, platform, model lifecycle, governance, security, evaluation, organisation, sustainability). For each dimension and level it names observable indicators, and it closes with a self-assessment template in YAML, so that the assessment is itself a version-controlled artefact. The model extends the maturity model in Appendix E of Architecture as Code (66, Nordqvist, 2025).
Figure B.1: The maturity staircase. Each step names the enabler that most often unlocks the next level; the eight dimensions are assessed at every level and are set out in the model below.
How to use the model
Assess each dimension separately. A bank may be Governing in security and Piloting in sustainability. The profile shows where the next investment belongs.
An organisation is at a level in a dimension when it meets the indicators for that level and every level below it. Where a single overall level is needed, use the lowest dimension. Assess twice a year with the same assessors and store the result as the YAML record below; the diff between two assessments is the progress report.
The five levels
| Level | Name | Characterisation |
|---|---|---|
| 1 | Exploring | Individuals experiment. No inventory, no shared platform, no agreed way to decide what may be built. |
| 2 | Piloting | A few bespoke, sponsored pilots. Governance is a committee reviewing slides; few pilots reach production. |
| 3 | Industrialising | A platform team provides a golden path. Use cases reach production through repeatable stages with decision records and an inventory. |
| 4 | Governing | Policy, risk and evidence are code. Classification, approval and evidence gates run in pipelines; audits consume generated documentation. |
| 5 | Optimising | Production telemetry feeds evaluation, routing, cost and risk. Models are retired deliberately; value and carbon are measured per use case. |
The eight dimensions
Each table lists observable indicators per level and the step that most often leads to the next level. Platform, model lifecycle, security and evaluation describe engineering rather than governance practice; they are kept because governance maturity cannot outrun the platform that enforces it, but this book treats them only at the depth a governance function needs to assess them.
Data
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | Data copied by hand. No record of which datasets built which model. Personal data in prototypes without a documented lawful basis. | Catalogue datasets with owner, lawful basis and personal-data status. |
| 2 Piloting | Data owners and a DPIA where personal data is involved. Lineage reconstructed afterwards. | Introduce data contracts and automate their quality rules. |
| 3 Industrialising | Data contracts with quality rules executed in pipelines. Lineage captured automatically. | Add and enforce an AI-use block, so training without permission fails the build. |
| 4 Governing | Permitted AI uses enforced by policy. Datasheets for every training set. Article 10 evidence generated. | Route production drift and quality signals to contract owners. |
| 5 Optimising | Drift signals trigger contract reviews. Data products retire with their consumers. | Use the signals to decide which data products deserve investment. |
Platform
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | Public model APIs called with personal accounts or shared keys. No record of models used or money spent. | Route all model traffic through one gateway with authentication and logging. |
| 2 Piloting | A shared endpoint for some pilots. Hosting decided case by case. | Form a platform team and define the golden path. |
| 3 Industrialising | Mandatory gateway with cost attribution. Registry holds every production model. Infrastructure as code. | Make the sovereignty decision explicit per workload class. |
| 4 Governing | Gateway enforces routing by data classification. EU-hosted or on-premises capacity for sensitive workloads. Platform changes pass the same gates as model changes. | Add capacity and cost telemetry to plan capacity. |
| 5 Optimising | Cost, latency and energy per route drive routing and procurement. | Retire components telemetry shows are unused. |
Model lifecycle
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | Models and prompts live in notebooks and chat histories. | Put every model, prompt and configuration under version control. |
| 2 Piloting | Deployment by scripts one person understands. Prompts edited in production. | Define promotion stages in a registry and pipeline. |
| 3 Industrialising | Promotion pipeline with validation, evaluation, shadow and production. Rollback is a registry operation. | Add evaluation gates with thresholds read from the decision record. |
| 4 Governing | Promotion blocked without evaluation, policy and supply-chain gates. Signed artefact, ML-BOM and evidence manifest per version. Retirement criteria checked. | Let production drift degrade model status automatically. |
| 5 Optimising | Champion–challenger routine. Drift opens retraining or retirement work. Lead time and time to retire measured. | Reduce lead time without weakening gates. |
Governance
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | No one can list the AI systems in use. Shadow AI widespread. | Build an inventory with an accountable owner per system. |
| 2 Piloting | Inventory of known pilots. A committee approves in minutes. Classification by legal counsel on request. | Introduce AI Decision Records and review the record, not the slides. |
| 3 Industrialising | AI Decision Records reviewed in pull requests. Documented classification procedure. Inventory maintained as data. | Codify classification and approval in the pipeline. |
| 4 Governing | Classification, approval and evidence as policy gates. Obligation mapping (Appendix A) under test. Waivers with owner and expiry. AI management system aligned with ISO/IEC 42001. | Measure governance itself: approval time, waivers, evidence gaps. |
| 5 Optimising | Governance metrics drive policy revision. Regulatory change absorbed by changing the mapping. Algorithm register entries updated automatically. | Share policy modules across units or agencies. |
Security
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | API keys shared in chat. Corporate data pasted into public tools. | Bring model access under identity management. |
| 2 Piloting | Managed identities for pilots. Prompt injection known but untested. | Threat-model every pilot with OWASP Top 10 for LLM applications and MITRE ATLAS. |
| 3 Industrialising | Threat models for production systems. Guardrails versioned. Agents under their own identities with permission manifests. | Introduce ML-BOM, signing and adversarial evaluation. |
| 4 Governing | Artefacts signed and attested. Tool permissions and MCP servers allow-listed. Incident response covers AI incidents. | Monitor production for injection and anomalous tool use. |
| 5 Optimising | Red-teaming findings become regression tests automatically. Posture reported per system. | Rotate red-teaming focus as attacks change. |
Evaluation
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | Quality judged by demonstration. No test sets. | Build a first golden dataset with a named owner. |
| 2 Piloting | A test set and a scoring notebook. Thresholds implicit. | Define a suite with explicit thresholds run on every change. |
| 3 Industrialising | Suites with golden datasets and thresholds run in the pipeline. Model judges calibrated against human labels. | Add fairness slices and red-teaming scenarios. |
| 4 Governing | Gates block promotion. Fairness metrics recorded. Human evaluation sampled. Results serve as evidence for Articles 9, 10 and 15. | Evaluate production samples continuously. |
| 5 Optimising | Production quality measured against the baseline. Findings open work items automatically. | Review coverage gaps on a schedule. |
Organisation
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | AI is a side activity. No role accountable for AI risk. | Name an executive owner and an accountable AI architect. |
| 2 Piloting | A centre of excellence runs pilots. Legal, security and data protection consulted late. | Establish platform and enabling teams; involve control functions in the golden path. |
| 3 Industrialising | AI architect, model risk manager and data steward roles defined. AI literacy training under Article 4. | Define a competence framework; include works councils in readiness reviews. |
| 4 Governing | Responsibility matrix covers every AI Act obligation. Competence enforced as an access precondition. Works council consultation is a release gate where law requires. | Measure adoption and trust by business unit. |
| 5 Optimising | Adoption and trust metrics inform the operating model. The centre of excellence has dissolved into platform and enabling teams. | Keep reviewing the operating model. |
Sustainability
| Level | Observable indicators | Moving up |
|---|---|---|
| 1 Exploring | AI cost invisible. Energy and carbon not considered. | Attribute every model call to a cost centre. |
| 2 Piloting | Pilot costs known afterwards. GPU capacity bought per project and often idle. | Introduce per-use-case budgets and routing to smaller models. |
| 3 Industrialising | Cost per use case reported. Routing to the smallest adequate model. Capacity shared. | Add carbon accounting with the Software Carbon Intensity specification (44, Green Software Foundation, 2024). |
| 4 Governing | Cost and carbon budgets enforced by policy. Chargeback operating. Procurement requires vendor energy disclosure. | Feed cost and carbon telemetry into routing. |
| 5 Optimising | Value per euro and per kilogram of carbon dioxide equivalent reported per use case. | Publish the figures. |
Moving up
Do not skip Industrialising. The most common failure is an organisation at Piloting that tries to reach Governing by writing policies. Policies without a platform to enforce them produce governance theatre (Chapter 20).
Let the lowest dimension set the pace. A programme Governing in security and Exploring in data is exposed through its data, so invest in the lowest dimension until it is within one level of the others.
Use regulation as the forcing function, not the goal. The AI Act obligations map onto Level 4 indicators, and reaching it brings the reproducibility and speed organisations want anyway.
Make the assessment a record, and expect levels to be lost. Each assessment is a commit, and its actions are work items with owners and dates. A reorganisation or a rushed project can drop a dimension by a level; the evidence tests of Appendix A often catch the slip first.
Relationship to national readiness assessments
This model is deliberately organisation-level. It does not measure the national legal framework, the supply of skills or the maturity of supervisory authorities; UNESCO's Readiness Assessment Methodology (RAM), introduced in Chapter 5, assesses that environment and UNESCO publishes the country reports (30, UNESCO, 2023). Its system-level companion, the Ethical Impact Assessment, belongs with the checks of Chapters 8 and 10 (31, UNESCO, n.d.).
The RAM is useful in three ways. A country report explains constraints that no internal maturity removes, such as a shortage of specialist skills; these belong in the readiness assessment and the risk register, not in the maturity score. Public authorities are often asked to contribute evidence to a national RAM exercise, and the inventory, evidence store and algorithm register are exactly that evidence. Finally, the RAM's dimensions map onto this model's: legal and regulatory onto governance and security, scientific and educational onto organisation, technological onto platform and data, and social and economic onto sustainability and organisation.
Self-assessment template
The template records one assessment of one scope, such as the enterprise for board reporting or an agency for improvement planning. Each dimension records current and target level, indicators met and not met, evidence and actions; one dimension is filled in to show the pattern.
# governance/maturity/assessment-2026-11.yaml
apiVersion: ai-architecture.example.eu/v1
kind: MaturitySelfAssessment
metadata:
organisation: example-authority
scope: enterprise # enterprise | business-unit | agency | programme
assessedOn: 2026-11-15
nextAssessment: 2027-05-15
previousAssessment: governance/maturity/assessment-2026-05.yaml
dimensions:
sustainability:
currentLevel: 2
targetLevel: 3
targetDate: 2027-06-30
indicatorsMet:
- Costs attributed per use case through the gateway
indicatorsNotMet:
- No carbon accounting
evidence:
- reports/finops/2026-10.json
actions:
- id: SUS-01
description: Introduce Software Carbon Intensity estimates per model tier
owner: head-of-ai-governance
due: 2027-06-30
# Remaining dimensions carry the same fields; abbreviated here.
data: {currentLevel: 3, targetLevel: 4}
platform: {currentLevel: 4, targetLevel: 4}
modelLifecycle: {currentLevel: 3, targetLevel: 4}
governance: {currentLevel: 3, targetLevel: 4}
security: {currentLevel: 3, targetLevel: 4}
evaluation: {currentLevel: 3, targetLevel: 4}
organisation: {currentLevel: 3, targetLevel: 4}
summary:
overallLevel: 2
method: lowest-dimension
narrative: >
Industrialising in most dimensions and Governing in platform.
Sustainability is the constraining dimension and receives the next
investment.
Sources
- Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. aac.geon.se. (66, Nordqvist, 2025)
- UNESCO (2023). Readiness Assessment Methodology: A Tool of the Recommendation on the Ethics of Artificial Intelligence. UNESCO. (30, UNESCO, 2023)
- UNESCO. Ethical Impact Assessment: A Tool of the Recommendation on the Ethics of Artificial Intelligence. UNESCO Global AI Ethics and Governance Observatory. (31, UNESCO, n.d.)
- Green Software Foundation. Software Carbon Intensity (SCI) Specification (ISO/IEC 21031:2024). (44, Green Software Foundation, 2024)