AI Governance Is a Risk Register, Not a Committee

Category: AI & Automation Author: Cody Swidler Tags: AI governance, NIST AI RMF, EU AI Act, ISO 42001, shadow AI, acceptable use policy, risk register

When I was asked to stand up AI governance at a company a while back, the first artifact I was handed was a draft charter for an AI Governance Committee: a standing body, a dozen named members across legal, security, data, and product, a monthly cadence, and a mandate to "review and approve AI use cases." It was a serious, well-intentioned document, and it would have accomplished almost nothing. I asked one question before we scheduled the kickoff: how many AI use cases are live in the company right now? Nobody knew. Not roughly. The committee was going to convene monthly to govern a population it had never counted, using a definition of "AI use case" it had never written down. We were building the boardroom before taking the inventory. That's the default failure mode of corporate AI governance — it starts as a meeting instead of a register, and a meeting with no data governs nothing but its own agenda.

The uncomfortable truth is that AI governance is not a new discipline that requires a new apparatus. It's risk management applied to a fast-moving asset class, and the parts that actually work are the parts you already know: an inventory, a scoring method, a review cadence earned by risk, and a policy people can follow. The committee is the least important thing in the room. The register is the program.

You Can't Govern What You Haven't Counted

Every AI governance effort has to start where the committee draft skipped: a census. And the census is harder than it sounds, because most AI in your company didn't arrive through a procurement process you can query. It arrived as a checkbox in a SaaS tool you already owned, a browser extension someone installed, a Copilot license switched on by a team lead, an API key a developer pasted into a side project. This is shadow AI, and it's the same shape as the shadow IT problem before it — except the adoption curve is faster and the surface is every knowledge worker with a login. If your inventory has eleven entries and your company has two thousand employees, you don't have eleven AI use cases. You have eleven you know about.

So the first deliverable is not a policy and not a committee — it's a list, built by actively hunting rather than waiting for self-reporting: what tools, doing what, on what data, with how much autonomy, owned by whom. An incomplete register that exists and grows beats a perfect framework that governs a phantom. Until the use cases are enumerated as rows, everything downstream — scoring, policy, oversight — is theater performed for an empty house.

Score the Use Case, Not the Technology

Once you have rows, you need a way to rank them, and this is where most frameworks go soft and start sorting AI by model type or by vendor. That's the wrong axis. The risk of an AI use case is not a property of the model; it's a property of what the use case is allowed to do and to touch. A frontier model summarizing public marketing copy is low risk. A smaller, cheaper model with write access to customer records and the authority to act without a human in the loop is a serious one. Same technology tier, opposite risk — because the thing that matters is autonomy and consequence, not sophistication.

The scoring that has held up for me is deliberately simple: use-case risk = autonomy × the greater of data sensitivity or decision impact. Autonomy is how much the system does without a human checkpoint — from "drafts text a person reviews" up to "takes actions on its own." The second term takes the worse of two harms, because a use case is dangerous if it touches sensitive data or if it drives a consequential decision; you don't get to average those down. Multiplying by autonomy captures the intuition that danger scales with how far the leash extends. It's the same discipline I argued for in the data-driven risk assessment: a score you can defend to an auditor is one derived from named inputs by a fixed rule, not one asserted in a workshop because a use case "felt" high. And the payoff is a specific, actionable flag — the use cases that combine high autonomy with high consequence are the oversight gaps, the ones running with the least human control over the most sensitive work. Those are what the program exists to surface, and they're invisible until you score every row the same way.

Cadence Earned, Not Calendared — Again

AI governance has one property that makes it harder than most risk domains: the underlying capability changes under you. A use case you scored as low-autonomy text drafting in the spring can, by autumn, have quietly gained tool access, memory, and the authority to act — same vendor, same line item, a completely different risk. This is why a once-a-year AI review is already obsolete when it's scheduled, and why the review cadence has to be driven by the score, exactly as I argued for vendors in reassessment cadence should be earned. The high-autonomy, high-impact use cases earn a short leash and a frequent review; the low-risk long tail gets a light annual touch. And defined events reset the clock regardless of the calendar: a new data source connected, a jump in autonomy, an incident, a model swap. Overdue reviews on high or critical use cases can't accumulate silently — they're the exact places where the gap between what you approved and what the system now does grows fastest.

The Policy People Can Actually Follow

Only now, with an inventory scored and a cadence running, does a policy earn its place — and it should be the shortest document in the program, not the longest. Most AI acceptable-use policies fail in one of two directions. They either say nothing enforceable ("employees shall use AI responsibly") or they say too much and become the self-inflicted audit finding I wrote about when the Good Idea Fairy writes your policies — "all AI use shall be pre-approved by the committee," a promise your enforcement can't keep by lunchtime. A usable AI policy does a few concrete things: it defines what counts as an AI use case so people know when the rules apply, it names the data classes that may never go into an external model, it sets the human-oversight requirement as a function of the risk band rather than a blanket rule, and it gives people a fast path to register a new use case instead of a slow gate that guarantees they'll route around it. A policy that's easy to comply with gets complied with. A policy that's hard to comply with produces more shadow AI, which is the opposite of governance.

Let the Frameworks Confirm, Not Drive

You'll notice I haven't led with NIST's AI Risk Management Framework, the EU AI Act, or ISO 42001 — and that's deliberate, the same stance I take on frameworks generally in the frameworks worth your time. They are genuinely useful, but as confirmation that your program is complete, not as the thing you build first. Build the register, the scoring, the cadence, and the policy — the operating machinery — and then map it: the AI RMF's govern-map-measure-manage functions fall out of what you've already built, the EU AI Act's risk tiers line up against your scored bands, and ISO 42001 becomes a management-system wrapper around a program that already runs. Lead with the framework instead and you get the committee charter I was handed on day one: an impressive structure governing a population nobody counted. The register comes first. It always did — AI just made the cost of skipping it arrive faster.

That company got its program, and it looked nothing like the original charter. The committee still met, but it met over a live register it could actually see: every use case scored on the same rule, the oversight gaps flagged in red, the overdue high-risk reviews impossible to ignore, and a two-page policy that a new engineer could read and follow before shipping their first AI feature. The governance wasn't the meeting. The meeting just read the numbers the program produced — which is the only useful thing a governance committee has ever done.

Cody Swidler is the founder of PivotRisk and Head of Platform Resiliency at Apex Fintech Solutions. He designed and launched enterprise risk and AI governance programs at Miro, and has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, and Zayo.