Ten categories of exploratory questions to ask before running an AI maturity assessment. The point of this bank is to surface the evidence gaps a self-reported maturity score usually hides — run this before AIMA-02.
How to Use This Bank
Work through each category with the function owner responsible for that area, not just the risk team's assumption of the answer. Where the honest answer is 'we don't know,' that's the evidence gap — record it as a finding, not a zero score, and feed it into the current-state scoring in AIMA-02.
This structured approach ensures that gaps are captured as findings rather than penalised as zero scores, giving a more accurate and actionable picture of current AI governance maturity.
Categories 1 & 2: Inventory & Ownership
Inventory Completeness
How was the current AI inventory built — self-report, technical discovery, or both? When was it last refreshed? Does it include embedded AI inside existing SaaS tools, or only standalone AI purchases?
Build Method
Self-report, technical discovery, or both?
Refresh Cadence
When was it last updated?
Scope
Includes embedded AI in SaaS, or standalone only?
Ownership & Accountability
Who owns AI risk decisions at the executive level? Is there a named individual or committee accountable for AI governance, or is it distributed informally?
Executive Owner
Named individual or committee?
Governance Model
Formal accountability or informal distribution?
Escalation Path
Where do AI risk decisions land?
Categories 3 & 4: Policy & Risk Classification
Category 3 · Policy Existence vs. Operation
Does an AI use policy exist? When was it last actually referenced in a real decision, not just published?
Category 4 · Risk Classification Practice
Is there a defined process for classifying a new AI use case by risk tier before deployment? Who runs that classification, and how long does it take?
These two categories probe the gap between policy on paper and policy in practice. A published AI use policy that has never been referenced in a real decision provides no governance value. Similarly, a risk classification process that exists in theory but has no defined owner or timeline is unlikely to be applied consistently before deployment.
Categories 5 & 6: Data Lineage & Model Validation
Data Lineage and Consent
Can you trace what data a given AI system was trained or fine-tuned on? Is consent status tracked per data source used in AI processing?
Training Data Traceability
Can lineage be traced back to source?
Fine-Tuning Records
Are fine-tuning datasets documented?
Consent Tracking
Is consent status tracked per data source?
Model Validation and Bias Testing
Is there a standard bias or fairness testing step before a model goes into production? Who signs off on the results?
Standard Testing Step
Is bias/fairness testing mandatory pre-production?
Sign-Off Authority
Who approves the results?
Documentation
Are test results retained as evidence?
Category 7: Change Management for AI Systems
What triggers a re-review of an AI system already in production — a model update, a data source change, a usage expansion? Is that trigger monitored or assumed?
Model Update
Does a version change to the underlying model automatically trigger a re-review, or is it left to the team to notice?
Data Source Change
If the data feeding the model changes — new sources, removed sources, schema changes — is there a formal re-assessment process?
Usage Expansion
When a model is applied to a new use case or user group beyond its original scope, is that treated as a new deployment requiring fresh review?
Trigger Monitoring
Are these triggers actively monitored through tooling or process, or are they assumed to be caught informally?
Category 8: Incident Response Readiness
Is there a defined process for an AI-specific incident — a biased decision, a hallucinated output causing harm, a data leak through a model — distinct from a standard security incident process?
Many organisations route AI incidents through their existing security incident response playbook. This category tests whether AI-specific failure modes — which may require different expertise, different stakeholders, and different remediation steps — have been explicitly accounted for in incident planning.
Category 9: Vendor & Third-Party Visibility
Does your vendor questionnaire ask about AI subprocessors? Do you know which of your vendors have added AI features since your last formal review?
Vendor Questionnaire Coverage
AI Subprocessors
Does the standard vendor questionnaire explicitly ask vendors to disclose AI subprocessors they rely on?
AI Feature Additions
Is there a mechanism to detect when an existing vendor adds AI capabilities to a product you already use?
Why This Matters
Vendors routinely embed AI features into existing SaaS products — often without proactive notification. An organisation that reviewed a vendor two years ago may now be processing personal data through an AI layer it never assessed. This category surfaces whether third-party AI risk is actively tracked or passively assumed to be covered by existing vendor management processes.
Category 10: Evidence & Audit Trail
If a regulator asked for evidence of AI governance maturity tomorrow, what could actually be produced versus what would need to be reconstructed from memory?
This is the ultimate stress-test question for any AI governance programme. It cuts through self-reported maturity scores and asks what documentary evidence actually exists at the moment of asking.
Immediately Producible
Policies, registers, signed-off test results, incident logs, vendor questionnaire responses — artefacts that exist and can be retrieved now.
Reconstructable
Decisions and processes that happened but were not formally documented — could be pieced together from emails, meeting notes, or individual memory.
Not Available
Governance activities that were assumed to have occurred but for which no evidence exists and cannot be credibly reconstructed.
The gap between the first and third columns is the true measure of governance maturity. Record what falls into each bucket as a finding to feed into AIMA-02 scoring.
All Ten Categories at a Glance
A summary of the full scoping question bank — use this as a reference card when running sessions with function owners.
Inventory Completeness
How was the AI inventory built, when was it refreshed, and does it include embedded SaaS AI?
Ownership & Accountability
Who owns AI risk decisions at the executive level — named individual, committee, or informal?
Policy Existence vs. Operation
Does an AI use policy exist, and when was it last referenced in a real decision?
Risk Classification Practice
Is there a defined pre-deployment risk tiering process, with a named owner and timeline?
Data Lineage & Consent
Can training data be traced, and is consent status tracked per data source?
Model Validation & Bias Testing
Is bias/fairness testing standard before production, and who signs off?
Change Management
What triggers a re-review of a live AI system, and is that trigger monitored?
Incident Response Readiness
Is there an AI-specific incident process distinct from standard security response?
Vendor & Third-Party Visibility
Do vendor questionnaires cover AI subprocessors and newly added AI features?
Evidence & Audit Trail
What governance evidence could be produced immediately versus reconstructed from memory?
AI Maturity Scoping Question Bank