The AI governance operating model

Most AI governance fails the same way: a policy document exists, a committee exists, and neither can answer the only question that matters — who decided this model could do this thing, and on what evidence? This playbook lays out the working parts of governance that can answer it. 1. What good looks like Good AI governance is boring. Every material decision about an AI system has a named owner. Every policy statement is backed by a control that actually enforces it. The evidence a board or regulator would ask for is produced by the platform as a by-product of operating — not assembled by hand in the week before the meeting. Governance designed alongside the AI strategy is cheap and mostly invisible. Retrofitted, it is the most expensive control there is. 2. Decision rights Write down who may decide what. Who approves a new use case entering development. Who approves it entering production. Who approves a model change, a prompt change, an expansion of what the system is allowed to touch. For material systems, pair the business owner with technical and risk sign-off — two perspectives, named individuals, recorded outcomes. If a decision cannot be traced to a person, it was not governed; it just happened. 3. The policy hierarchy Three layers, each answering a different question. Principles — set by the board: what we will and will not use AI for. Standards — set by the governance forum: what must be true of any system we run (evaluated before deployment, monitored in production, human gate on irreversible actions). Controls — built by engineering: the mechanisms that make the standards true. The hierarchy earns its keep at the bottom: a policy without a control enforcing it is a hope with a letterhead. 4. The operating cadence Governance is a rhythm, not a document. A forum that meets on a schedule; a live register of every AI system and its risk tier; the evidence for each — evaluation results, incidents, drift — visible in the meeting, not requested after it. The forum decides: approve, expand, remediate, retire. The decisions are recorded where the next audit can find them. Frequency scales with risk: material systems monthly, the long tail quarterly. The register itself stays cheap: a page per system — owner, tier, status, last evaluation, open actions. If it takes a project to maintain, it will die; if it takes ten minutes before the forum, it will live. 5. Mapping to the frameworks ISO 42001 gives the management system a certifiable shape; the NIST AI RMF gives risk teams a shared vocabulary for AI-specific failure modes. Use them as the map, not the territory: build the operating model that fits how your organisation actually decides, then map it to the frameworks for the auditor. An operating model built from the framework outward tends to produce paperwork that mirrors the standard and controls that mirror nothing. 6. The first 90 days Inventory what is already running, including what nobody approved. Tier it by risk. Name an owner for every material system. Stand up the register and hold the first forum with whatever evidence exists — the gaps in that meeting are the backlog. Build the two controls that matter most first: access (who and what can invoke the system) and evaluation (proof it does what it claims). Then rehearse: run one attestation dry-run against a production system and time how long the answers take. The test of the whole model is a single question asked without warning: show me the decision that put this system in production. If the answer is a link, you have governance. If the answer is a meeting, you have a project.