Every organisation deploying AI has a set of principles — fairness, transparency, accountability, usually on a slide. Governance is what turns those words into things that actually happen: a risk tier assigned before a model is built, a review that can say no, monitoring that fires when behaviour drifts, and a named person who is accountable when it goes wrong. This article is about the machinery, not the principles.
Why it stopped being optional
Two forces made AI governance a formal function. The first is regulation. The EU AI Act entered into force in 2024 with obligations phasing in through 2027: prohibited practices first, then transparency and governance duties for general-purpose models, then the full compliance regime for "high-risk" systems in areas like employment, credit, education, critical infrastructure and law enforcement. In the US there is no single federal law, but the NIST AI Risk Management Framework has become the shared vocabulary, sector regulators (FTC, financial and health agencies) enforce existing rules against AI harms, and several states have their own statutes. Other jurisdictions — the UK, Canada, Singapore, Japan, China — have frameworks with overlapping expectations.
The second force is exposure. Models make decisions at scale, and a systematic error becomes a systematic harm quickly. A biased screening model, a chatbot that gives dangerous advice, a generative system that leaks training data — these have become board-level incidents, and boards want to know who is responsible.
Start with an inventory and risk tiers
You cannot govern what you haven't listed. The first artefact of any programme is an AI inventory: every model and AI-enabled system in use, including third-party APIs and the copilot features inside SaaS tools people already use. Each entry gets a risk tier based on what the system does and to whom:
- Minimal: internal productivity uses with a human reviewing output — drafting, summarising, code assistance.
- Limited: customer-facing but low consequence — a support chatbot with escalation, content recommendations.
- High: decisions affecting people's access to money, work, health, safety or rights; anything the AI Act lists as high-risk.
- Unacceptable: uses you won't do regardless of legality — the Act's prohibited list is a starting point.
The tier determines everything downstream: how much documentation, what testing, whether a human must be in the loop, and who signs off.
Documentation that people actually use
Two lightweight documents carry most of the weight. A model card records what a model is for, what it was trained on, how it was evaluated, known limitations and out-of-scope uses. A datasheet does the same for a dataset: provenance, consent basis, collection method, known gaps. Keep them short, version them with the model, and require them at the review gate — a card that exists only as a compliance artefact will be stale within a quarter. For systems built on third-party foundation models, record the provider's own documentation and the date you reviewed it; the models change.
Roles and the review gate
Governance needs three layers with distinct jobs:
- Executive sponsor who owns the policy, funds the programme and takes the escalations.
- AI review board — cross-functional: legal, security, privacy, the relevant business owner, and someone who understands the models technically. It reviews high-tier systems before launch and on material change, and it must have the authority to block.
- Product and engineering owners who complete the assessments, run the evaluations and own the monitoring. Governance that lives entirely in a central committee doesn't scale; it has to be embedded in the delivery process.
The review gate should be proportional. Minimal-tier uses get a checklist and a self-attestation. High-tier uses get an impact assessment, bias and robustness testing against defined thresholds, red-teaming for generative systems, a human-oversight design, and sign-off from the board. The point is not to make everything slow; it's to make the important things deliberate.
Controls that match the risk
For high-tier systems, the controls that regulators and auditors expect are now fairly standard:
- Pre-deployment evaluation on representative data, sliced by relevant demographic groups, with documented thresholds for accuracy and disparity.
- Human oversight that is real: the reviewer has the information, time and authority to overrule the system, and the override rate is measured.
- Privacy engineering — data minimisation, differential privacy or federated approaches where raw data is sensitive.
- Explainability proportionate to the decision: a credit denial needs a reason; a search ranking doesn't. See Explainable AI.
- Access control and logging so that who used the system for what is reconstructible.
- Incident response with an AI-specific playbook: how to pause a model, roll back, notify affected users and regulators.
Monitoring is where governance lives or dies
Most governance failures happen after launch. The model that passed review drifts as the data changes; the chatbot that was safe at launch is jailbroken by a technique invented a month later; a vendor updates their model and behaviour shifts overnight. Continuous monitoring — performance, fairness metrics, input distribution, user complaints, and for generative systems a sample of outputs reviewed by humans — is not optional for anything above the minimal tier. Wire it into the same alerting as the rest of production; a governance dashboard nobody looks at is theatre.
- Governance is machinery: inventory, risk tiers, review gates, monitoring and accountable owners.
- Tier by consequence; apply heavy controls only where the decision affects people's rights, money, health or safety.
- The EU AI Act and NIST AI RMF define the expectations; most other frameworks map onto them.
- Post-launch monitoring is where most failures happen — and where most programmes are weakest.