An AI governance assessment should reveal observable strengths and gaps, not produce a reassuring score from policy statements. Assess each domain against evidence that the organisation can show: current records, named decisions, operating controls, tests and verified outcomes.
What This AI Governance Assessment Measures
The assessment covers the connected capabilities required to govern AI across its lifecycle: inventory, ownership, risk decisions, controls, agent oversight, evidence and third-party AI. It is a diagnostic, not a certification or legal-compliance conclusion.
How to Use the Assessment
Score every domain separately. Record evidence, uncertainty and the next practical action. Do not average the results into a single universal maturity number; a strong policy domain cannot compensate for unknown systems or missing owners.
| Level | Meaning | Observable condition |
|---|---|---|
| 0 · Absent | No defined practice | Responsibility and evidence cannot be identified |
| 1 · Ad hoc | Individuals respond case by case | Records are incomplete and outcomes depend on personal effort |
| 2 · Repeatable | A common process exists | Teams use standard intake, decisions or controls, but coverage varies |
| 3 · Managed and evidenced | Operation is owned and measured | Coverage, decisions, exceptions and tests are traceable |
| 4 · Integrated and continuously verified | Controls operate in normal delivery | Change triggers reassessment and evidence supports ongoing improvement |
Assessment Domains
Inventory and discovery
Can the organisation identify internally built, embedded, third-party and agentic AI, including undeclared use? A mature record connects purpose, owner, lifecycle, model or supplier, data, tools, dependencies, approval and evidence.
Ownership and decision rights
Is one role accountable for purpose and residual risk? Are technical operation, data, security and assurance responsibilities clear? Can people identify who may approve, accept an exception, suspend or retire the system?
Risk and lifecycle decisions
Does risk classification reflect use, impact, affected people, data, autonomy and dependencies? Do material changes reopen the decision rather than inherit an old approval?
Policies and control operation
Are principles translated into minimum requirements, procedures and technical or human controls? Is control effectiveness tested rather than inferred from configuration?
Agent identity and runtime oversight
Are agent identities, delegated permissions, tools and action limits visible? Can the organisation approve, constrain, block, pause or investigate material actions?
Evidence and monitoring
Can reviewers reconstruct decisions from source, policy version, owner, test, approval and final state? Do metrics expose coverage and control failure rather than activity volume?
Third-party AI
Are supplier AI services and embedded features tiered, assessed, contracted, monitored for change and covered by incident and exit arrangements?
AI Governance Maturity Assessment Matrix
| Domain | Assessment question | Level 0–1 evidence | Level 2 evidence | Level 3–4 evidence | Priority next action |
|---|---|---|---|---|---|
| Inventory | Do we know which AI exists and how it is used? | Local lists or no reliable record | Common intake with partial discovery | Maintained inventory with source, owner and change signals | Define scope and establish one minimum record |
| Ownership | Who makes and answers for each decision? | Team names or informal contacts | Named owners for important systems | Explicit decision rights, capacity and escalation | Assign accountable owners to high-impact systems |
| Risk and lifecycle | Are controls proportional and reassessed after change? | One-off or generic review | Common risk tiers and approval gates | Change-triggered decisions with residual-risk evidence | Define material-change and exception rules |
| Policies and controls | Can we prove requirements operate? | Policy documents without testing | Control library with uneven operation | Tested controls linked to systems, owners and results | Select critical controls and define tests |
| Agent oversight | Can we see and constrain delegated action? | Shared identities or application logs only | Agent registry and some scoped access | Attributable runtime decisions, intervention and review | Map effective permissions and high-impact actions |
| Evidence | Can assurance reconstruct the decision? | Screenshots and scattered files | Standard records with manual consolidation | Traceable, versioned and portable evidence | Define a minimum evidence object |
| Third parties | Do supplier changes trigger governance action? | Procurement questionnaire at purchase | Tiered due diligence and contract controls | Continuous change, incident and exit oversight | Identify high-dependency suppliers and triggers |
Interpreting the Results
Look for dependencies and exposure, not the highest average. Advanced runtime controls do not compensate for missing inventory and ownership. Strong supplier due diligence does not prove that the organisation governs how the service is used. Prioritise gaps that affect high-impact systems and unlock several downstream capabilities.
Worked Example: Moving From Ad Hoc to Managed Governance
A company stores use cases in separate spreadsheets. High-impact projects receive legal and security review, but embedded AI and agents are missing, ownership is inconsistent and evidence sits in email.
- Create one minimum intake and inventory record, starting with high-impact and externally supplied AI.
- Assign business and technical owners and define who approves, accepts exceptions and suspends use.
- Apply a common risk tier and minimum control set to new and existing priority systems.
- Retain assessment, test, approval and exception evidence against the same system record.
- Add change triggers and selected discovery signals before automating broader reporting.
The programme moves from Level 1 to Level 2–3 in foundational domains without buying every possible control at once.
Turn Assessment Gaps Into Platform Requirements
Translate each priority gap into an outcome and demonstration scenario. Use the platform requirements method to define proof, then compare relevant capabilities in the AI Control Map catalogue. A low maturity score is not a reason to buy the broadest platform; it clarifies which operating capability must work first.