In brief
- Inventory first. You cannot govern AI that the organisation cannot see. Create a usable register of AI systems and material use cases, including externally procured tools and embedded AI.
- Put decisions in the model. Every material use case needs owners for business value, risk, approval, operation and escalation.
- Control the lifecycle. Classification, approval, human oversight, monitoring, incident handling and change should form one operating flow rather than separate policy documents.
- Use ISO 42001 to formalise and improve. ISO/IEC 42001 provides a management-system structure for responsible development, provision and use of AI. It works best when there are real processes and decisions to manage.
The policy-first trap
Many organisations begin AI governance by writing an AI policy. The document may be sensible, but it often sits above an environment where nobody can answer basic operating questions: which AI systems are in use, who owns them, which use cases are high impact, who can approve them, what must be monitored and what happens when the model or context changes.
The result is governance theatre. The organisation has words about responsible AI but no reliable mechanism that turns those words into decisions. A stronger sequence is to build the operating model first and formalise it as maturity increases.
Governancy view: the smallest useful AI governance system is not a policy. It is a repeatable decision process with enough evidence to show which AI use was accepted, under what conditions and by whom.
A seven-part AI governance operating model
1. Inventory
Identify AI systems and material use cases across procurement, SaaS, internal development, customer services and employee productivity. Record purpose, owner, provider, data, affected people, integration and current status.
2. Ownership
Assign a business owner who is accountable for the use case, plus the specialist functions that advise or control risk. Avoid making the AI or security team the owner of every business decision.
3. Classification
Use a proportionate method to determine which use cases need lightweight approval and which need deeper assessment. Consider legal role, potential impact, data sensitivity, autonomy, affected persons, criticality and reliance on third-party models.
4. Approval
Define the decisions that must be made before use. Approval can include conditions such as human review, restricted data, monitoring, fallback arrangements or prohibited uses.
5. Monitoring
Track whether the AI system continues to perform within the accepted conditions. The right indicators depend on the use case and may include quality, overrides, complaints, incidents, drift, supplier changes or control exceptions.
6. Incident and change control
Define what triggers re-assessment. Material model changes, new data, changed purpose, new integrations, incidents or changes in legal classification should not pass silently through the lifecycle.
7. Assurance
Periodically test whether the governance process is followed and effective. Assurance can include internal audit, sample reviews, control testing, management review and independent assessment.
What belongs in the AI inventory
An inventory should support decisions, not become a catalogue of every software feature marketed as AI. Capture enough information to determine ownership, risk and next action.
| Field | Why it matters |
|---|---|
| Business purpose | Clarifies why the use exists and what outcome is expected. |
| Business owner | Creates accountability for the use case and its continued acceptability. |
| Provider and model | Reveals external dependencies and supplier change risk. |
| Data used | Helps identify confidentiality, privacy, quality and provenance concerns. |
| Affected people or decisions | Helps identify impact, human oversight and regulatory relevance. |
| Autonomy and human involvement | Shows where AI advises, recommends, generates or makes decisions and how humans can intervene. |
| Classification and approval status | Connects the inventory to the governance workflow. |
Where does your AI governance need attention?
An AI Governance Assessment helps identify AI use, accountability, risks and gaps before a wider implementation programme.
Explore the AI Governance AssessmentClassify for governance, not for taxonomy
A useful classification model has one job: decide how much governance a use case needs. It can combine legal classification with business impact and organisational risk. The EU AI Act uses a risk-based regulatory structure and imposes specific requirements on certain categories of AI systems. Your internal classification can use that legal analysis, but it should also capture risks that matter to the organisation even when a use case is not legally high-risk.
Low governance intensity
Limited impact, low sensitivity, easy human correction and no material external effect. Register the use, set basic conditions and monitor through normal controls.
Medium governance intensity
Meaningful business reliance, sensitive data, customer-facing output or material operational consequences. Require documented assessment, approval conditions and monitoring.
High governance intensity
Potentially significant legal, safety, fundamental-rights, financial or service impact. Require specialist review, explicit approval, stronger evidence, testing and ongoing oversight.
Prohibited or unacceptable
Some uses may be prohibited by law or outside organisational risk appetite. The operating model needs a way to stop them, not merely record them.
Define the decision rights
AI governance becomes practical when people know which decisions they own. The labels will vary by organisation, but the decision rights should not.
| Decision | Typical accountable role | Specialist input |
|---|---|---|
| Why are we using this AI? | Business owner | Product, operations, strategy |
| Is the risk acceptable? | Risk owner or delegated authority | Legal, privacy, security, compliance, AI governance |
| Can the use go live? | Defined approval authority | Relevant control functions based on classification |
| What happens when conditions change? | Business owner | Technical owner, provider manager, control functions |
| When must use stop or be escalated? | Predefined incident or risk authority | Legal, security, privacy, operations |
The minimum evidence trail
- Inventory record: what the AI use is, who owns it and what it does.
- Classification rationale: why the chosen governance level is proportionate.
- Assessment: material risks, affected parties, dependencies and required controls.
- Approval decision: approver, date, conditions, exceptions and review trigger.
- Monitoring: indicators and evidence showing whether conditions remain satisfied.
- Change and incident history: what changed, what happened and whether re-assessment was required.
Where ISO 42001 adds value
ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. That creates a structure for leadership, policies, objectives, risk management, operational controls, performance evaluation and improvement around AI.
The standard is valuable when AI governance needs to become repeatable across functions, geographies or many use cases, when customers or regulators expect demonstrable management, or when the organisation wants an auditable management-system approach. It is less useful to treat ISO 42001 as the first task when basic AI visibility and ownership do not yet exist.
Start with the operating model when
You cannot reliably identify AI use, decision owners or approval routes. Build the mechanics before formalising the management system.
Move toward ISO 42001 when
You need consistent governance, management review, internal audit, continual improvement and evidence that the organisation manages AI systematically.
A practical first 90-day sequence
Weeks 1 to 3: visibility
Define scope, inventory known AI use, identify business owners and establish a simple intake route for new use cases.
Weeks 4 to 6: decisions
Create classification criteria, approval thresholds, minimum assessment questions and escalation rules.
Weeks 7 to 10: lifecycle control
Add monitoring, change triggers, incident handling, supplier dependencies and evidence retention.
Weeks 11 to 13: assurance and management
Review whether the process is being used, report exceptions, adjust responsibilities and decide whether a formal ISO 42001 implementation adds value.
Primary sources
- ISO/IEC 42001:2023, AI management systems
- Regulation (EU) 2024/1689, Artificial Intelligence Act
- ISO/IEC 42005:2025, AI system impact assessment guidance
Practical next step: If your AI policy exists but ownership and lifecycle decisions are still unclear, assess the operating model before adding more documentation. Discuss the scope with Governancy.