Effective AI governance is a decision system. It helps an organisation know which uses of AI are acceptable, who is accountable, what evidence is required and how performance and risk will be managed throughout the lifecycle.
Govern outcomes, not labels
Governance can become trapped in definitions: whether a feature is AI, whether a model is generative or whether a supplier calls a capability an agent. Those distinctions can matter, but the more durable starting point is impact. What decision or action does the system influence? Who could benefit or be harmed? What information can it access? Can a person detect and correct failure? What happens at scale?
An impact-based approach captures purchased features, embedded models and employee-built tools as well as formal AI programmes. It also supports proportionality. A drafting assistant using public information should not follow the same path as a system influencing employment, safety, finance or access to essential services.
Create clear accountability
Every AI system needs an accountable business owner. Technical, data, security, legal and risk specialists contribute essential judgement, but accountability for purpose and outcomes cannot be outsourced to a committee or vendor. The owner should understand the intended use, approve its boundaries and ensure that resources exist to operate and monitor it.
An AI governance board should set principles, risk appetite and enterprise priorities; resolve material exceptions; and examine the overall portfolio. It should not review every low-risk experiment. The UK Government AI Playbook describes governance boards as providing oversight, accountability and strategic guidance across risk, compliance, assurance, resources and alignment with objectives. Existing boards can often take this role if they gain the right expertise.
Maintain a useful AI inventory
An organisation cannot govern what it cannot see. The inventory should capture purpose, owner, users, data, supplier or model, deployment status, risk tier, approvals, evaluation evidence and review dates. It must include AI embedded in software and material uses introduced through procurement, not only internally developed models.
The inventory is not merely an audit register. It enables leaders to identify duplicated investment, shared dependencies, concentrations of supplier risk and systems approaching review. Keep the minimum information needed to make decisions and integrate updates into procurement, architecture and delivery workflows so the register does not depend on periodic surveys.
Use risk tiers and evidence gates
Risk tiers translate principles into routes. Factors can include consequence, affected population, autonomy, information sensitivity, reversibility and the strength of human oversight. Each tier should have explicit evidence requirements. Low-risk uses might require owner confirmation and basic testing; higher-risk systems may require impact assessment, security review, legal analysis, independent evaluation and senior approval.
A gate is a decision, not a paperwork milestone. Decision-makers should be able to approve, approve with conditions, request more evidence or stop. NIST's Govern, Map, Measure and Manage functions provide a useful structure: establish governance, understand context and impacts, assess the system, then prioritise and treat risk. The functions continue after deployment as conditions change.
Make evaluation operational
AI systems need evaluation that reflects their actual task and environment. Measures may cover accuracy, robustness, bias, privacy, security, explainability, latency, cost and user outcomes. Generative systems require representative test sets and examination of harmful or unsupported outputs. Agentic systems also require tests of tool use, permissions, recovery and unintended actions.
Thresholds should be agreed before results are known. Otherwise teams are tempted to rationalise weak performance after investing time and reputation. Evaluation should continue in production through monitoring, feedback, incident reporting and scheduled reassessment. A change to model, data, prompt, tools, user population or operating context may require new evidence.
Integrate law, security and ethics
Legal compliance, cybersecurity and ethical impact overlap but are not interchangeable. A lawful system can still be unfair or insecure; a secure system can still lack a legitimate purpose. Governance should bring these perspectives together early enough to shape design. Privacy, intellectual property, accessibility, records, sector regulation, contractual obligations and workforce impacts may all be relevant.
Security deserves particular attention where models consume untrusted content or can call tools. NIST has highlighted indirect prompt injection and agent hijacking, where malicious instructions in data cause unintended actions. Controls can include data separation, constrained permissions, allow-listed tools, transaction limits, confirmation for consequential actions, secure logging and tested recovery.
Ethical assessment should be connected to design choices rather than framed only as abstract principles. Identify who is represented in data and evaluation, who experiences errors, who can challenge an outcome and whether accessibility needs are met. Document trade-offs where objectives conflict. Meaningful transparency is audience-specific: users may need to know that AI is involved and how to seek help; operators need performance and limitation information; assurance teams need traceable evidence; executives need a view of material exposure and accountability.
Manage suppliers without outsourcing responsibility
Suppliers should provide evidence on model limitations, security, data handling, subcontractors, evaluation, incident notification, service changes and exit. Contracts need rights that match the risk, but due diligence cannot guarantee the behaviour of a system in the organisation's context. Internal testing and monitoring remain necessary.
Architecture should preserve options where practical. Record which processes depend on a model or platform, how information can be exported and what would happen if terms, performance or availability changed. Concentration and lock-in are governance questions because they affect resilience and the organisation's ability to manage future risk.
Procurement and governance should share a common intake route. Commercial teams can then identify AI capabilities before contracts are signed, while specialists focus their review on the aspects that affect risk and operability. Require suppliers to notify the organisation of material model or data changes and define when those changes trigger reassessment. For high-impact services, evidence should be testable rather than accepted solely through marketing claims or generic certifications. Independent assurance may be appropriate, but it complements rather than replaces the organisation's own accountability.
Build a system that learns
ISO/IEC 42001 frames AI management as Plan-Do-Check-Act. That is a better model than a one-time policy launch. Governance should learn from incidents, user feedback, assurance findings, regulatory change and new technical capabilities. Policies, risk tiers and evaluation methods need owners and review dates of their own.
The test of governance is not the number of forms completed. It is whether people can make timely, explainable decisions; whether unacceptable uses are prevented or stopped; and whether approved systems continue to create value within agreed boundaries. Done well, governance creates confidence to move—not permission to ignore uncertainty.