An AI Governance Framework CTOs Can Actually Run

Every enterprise AI conversation eventually arrives at governance, usually in one of two tones. The first is anxious: legal has read about the EU AI Act and wants everything paused. The second is dismissive: governance is treated as paperwork to be generated after the interesting work is done. Both tones produce the same result — governance that exists on paper and nowhere else.

What follows is the framework I actually run: small enough to operate without a governance department, structured enough to satisfy the questions a board, a customer or a regulator will ask. It has four layers, and each one produces something you can point at.

Layer one: accountability that survives contact with the org chart

Every AI system in production gets a named owner — a person, not a committee — whose job includes the outcome, the behaviour and the retirement of that system. The owner is usually the leader of the workflow the system serves, not the engineer who built it. This is the single highest-leverage governance decision, and I made the fuller argument for it in CTO vs CIO vs Chief AI Officer.

Alongside the owner, keep a register: one row per system, recording purpose, owner, data used, model and vendor, risk class and review date. A spreadsheet is fine. The register matters because governance questions are almost always inventory questions in disguise — you cannot govern systems you cannot list.

Layer two: risk assessment proportionate to the decision

Not every AI system deserves the same scrutiny. A model drafting internal meeting summaries and a model influencing credit decisions should not pass through the same gate. Classify each use case by the consequence of it being wrong: who is affected, how reversibly, and with what legal exposure.

You do not need to invent the classes. The EU AI Act provides a legal taxonomy — prohibited, high-risk, limited-risk, minimal — that is a sensible starting point even for organisations outside its jurisdiction, because your customers increasingly operate inside it. The NIST AI Risk Management Framework complements it with the operating verbs: govern, map, measure, manage. My working translation: map before you build, measure before you scale, manage for as long as it runs.

The output of this layer is one decision per use case: the risk class, and what that class requires — human review, evaluation thresholds, monitoring, or a decision not to build.

Layer three: controls that live inside the workflow

Controls written in a policy are intentions. Controls embedded in the workflow are governance. The distinction decides whether the framework works: approval steps in the tooling, retrieval boundaries that respect document permissions, logged prompts and outputs where the risk class demands it, and a human checkpoint exactly where the assessment said one is needed — not sprinkled everywhere as ritual.

For agentic systems the control question sharpens into permissions: what the system may do, with which tools, under whose authority, with what recovery path. I covered that design surface in Designing for Agents; from a governance standpoint the point is that permissions are the control, and they should be reviewable like any other.

Layer four: evidence you can show someone

The final layer is the one most organisations skip: proof. For each production system, keep the evaluation results that justified going live, the monitoring that shows behaviour since, and the record of incidents and changes. If you need certifiable structure — some enterprise customers now ask — ISO/IEC 42001 defines an AI management system that this evidence trail maps onto naturally.

Evidence is also the honest feedback loop. If a system cannot produce results worth recording, that is not a documentation gap. It is a signal the capability is not ready — the same signal I described in From Pilots to Capability.

The cadence that keeps it alive

A framework without a calendar decays. The operating rhythm I recommend is deliberately light: a monthly review of the register and any new use cases; a quarterly look at evaluation and monitoring results for high-risk systems, with the owners in the room; and an annual re-classification pass, because both the regulation and your systems change.

Start smaller than feels impressive. This quarter: build the register, classify what is already running, name the owners, and pick the one high-consequence system that deserves a proper evaluation baseline. If you want the readiness questions that precede all of this, they are in The AI Readiness Assessment. Governance done this way is not a brake on AI adoption. It is the reason you can accelerate without flinching.